🏠 back to Observable

Enabling other languages?


#1

Congratulations on Observable, it is a great idea and the execution is very nice!

I’d prefer to use Clojurescript over javascript given enough support (I actually got something working here https://beta.observablehq.com/@jeroenvandijk/untitled/3).

Are you considering supporting other languages natively as how you support javascript (e.g. syntax highlighting, no need to wrap with backticks etc)?


#2

Super cool that you got something working inside of a notebook!

Though it would be super cool to add more languages in, it’ll be a pretty gradual process. Unlike most other notebooks, Observable is very semantic - a lot of the magic is how a mixture of static analysis and a smart runtime can simplify programming. We wouldn’t want to, say, add ClojureScript support but require you to manually re-evaluate cljs cells - we’d want cross-language evaluation to be at least reasonably reactive, in the way that evaluation is currently reactive.

Of course no shade on ClojureScript (I’ve built a few things with Clojure and mightily enjoyed it), but the focus for now is on making an exceptional environment, and then on potentially cross-language capabilities.


#3

I wonder if we could have other languages in Observable. Is this issue in the pipeline?


#4

There’s an older thread on this here: Enabling other languages?

(And now we’re merged!)


#5

I suppose you can always try the tagged template approach, but then the other language is more like a pre-processor (edit: just noticed that this is exactly how the ClojureScript works in linked notebook at the start (waarom is Kees eigenlijk een topper, @jeroenvandijk?))

Take a look in the ganja.js topic for more ideas:

Also, you just inspired me to try embedding the Walt compiler in the Observable notebook, seems to work pretty well!

So that means runtime JS-like WASM for the masses :slight_smile:


#6

very nice notebook! to make it work on a retina screen, you might want to use context = DOM.context2d(width, height, 1) or adapt all the canvas.onmouse* (otherwise it paints only the top-left quarter of the screen).


#7

Thanks for the tip! (I wonder if this fixes the phone size bugs in my other notebooks too edit: nope :frowning: )


#8

A small suggestion: https://beta.observablehq.com/d/a725945e96948f7b#compiledWaltBuffer uses the visual (barcode) of the compiled code as a viewof. This way, no need to have two separate cells. And the function is reusable. This is similar to https://beta.observablehq.com/@fil/pt


#9

Nice, thanks! So are the graphics is still clearly visible on retina screens at that size? Or should we perhaps also scale that with devicePixelRatio?


#10

Yes they have the correct size, but you can see they’re using “non retina pixels”.
But as you’re making the images with a matrix and putImageData(), I don’t think you want to have to think about devicePixelRatio.


#11

It’s just a constant multiplication factor, no big deal.


#12

(mods, maybe talking about Walt/WASM should be split into its own thread by now?)