I've been working through advent of code using my own little compiler/language. It's in such an early state that some creative problem solving is required, not to mention the compiler bugs! But I'm very pleased to have it running interactively on my blog like this – I want to work towards some bigger notebooks in the style of explorable explanations.
I've spent the last couple of months porting the compiler from Julia to TypeScript. That's nearly done, so I'm hoping I can post an interactive web demo next month!
The author outlines a fair bit of the design thinking in this post [0].
What Datalog and co give you is the ability to do interesting program transformations. Mostly that's not because they are "declarative", if that means anything, but because they avoid all the little bits of non-determinism that imperative languages include. If you avoid those you're pretty much set. Coming from another angle, JAX [1] shows how you can do program transformations in Python with a relatively small set of semantic restrictions.
Even within HTTP services, (a) your TLS will not be end to end, so you have to be happy for Cloudflare to see your data and (b) they don't like you to use up all their bandwidth with media streaming or other large files. Tunnel is a great service but there are certainly reasons not to use it.
Hi there, can I know what browser version you're using? I'm the marketer leading this project and would love to ensure that it works for everyone. I believe the experience breaks in earlier versions of some of the browsers. Not sure if we'll have a fix but the least we can do is give the reader a warning while we find a suitable fallback solution. Thanks for the feedback!
You need (a little) JS to run Wasm in the same way you need (a little) HTML to run JS; it's a hosted platform. JS handles loading and invoking the wasm code, and because it's close to a pure instruction set there's very little you can do without calling JS APIs, which in turn requires support code to translate across the boundary.
The WASI project specifies wasm-native APIs (modelled on posix) for running locally without JS, so you could imagine something similar for the browser. But the complexity of the DOM is forbidding.
I've not tried Emscripten hello world for a while, but I imagine it depends on things like optimisation level, dead code elim etc. In general to compile C code you'll need a malloc, string support and so on as you say. You can make the wasm file tiny if you lean on JS strings, but that increases the amount of support code again. Languages other than C will have an easier time reusing parts of the JS runtime (like strings or GC).
Yeah. And hello world is (thankfully) much smaller now than it used to be. Bigger than you think if you use printf, which is a quite complex C function. But at a guess, 10kb or something including support files. There are some great guides and tooling around to help shrink wasm size. Eg for rust:
I mean, the article's logic is effectively that you can break code without the type system helping or warning you. I don't think Hickey would disagree with this – it's arguably a point in his favour.
There is also a Hangul adaptation of Gilbert called Gilbeot [1]. It also has an interesting feature that censors words that discriminate LGBT people (akin to Sans Bullshit Sans). I do have a feeling that they are clearly decorative and yet still being overused for non-heading text, maybe this is a major problem with many color fonts.
In fact, its design choice is questionable even as a title font. Normally the text color will be chosen so that it has enough contrast compared to the background. With color fonts you can't always change the text color, but you can still change the background. Gilbert however contains all hues in a single glyph, so some part of each glyph is always going to be hard to distinguish from the background without much care.
That is a beautiful font. Is it distributed in the same format as what's discussed in the material.io post (COLRv1)? It's still a good example of what's possible; I'm just curious.
Monotropism is compelling for all the reasons the author gives, but it isn't without any loose ends. For example, stimming is a characteristic feature of autism; the authors of the original paper briefly describe it as a focus on activity, but people often fidget to help them focus on something else (eg reading or listening), so it's unclear how that fits with the theory. The same goes for other common experiences like meltdowns, shutdowns and autistic burnout, as well as the higher incidence of alexithymia, queerness, and issues of anxiety and depression, which aren't obviously related to narrow focus.
Very possibly the "autistic"/"allistic" labels refer to a mix of different underlying cognitive variables, monotropism being just one. Either way, the theory seems an important step forward.
I think stimming is a bit like listening to music while coding: When you've heard the song a thousand times before it does not take much brain power to listen to it again and it provides an emotional safety by shutting out unwanted external stimuli.
Stimming is doing well known things that doesn't take much attention but also provides emotional safe feeling.
I dislike referring to WASM as a "stack machine" for this reason. It is useful to remember that the text format started out as a low-level lisp-y expression tree with local variables and nested control flow. It still basically is that, but with the AST syntactically flattened in a way that looks a bit like a stack machine. (Admittedly, multi-value and block returns have since made it trickier to recover the AST.)
Things like Forth or the JVM byte code are true stack machines: all locals can be on the stack, and the stack shape can vary at runtime (which in turn makes validation harder). I seem to be in the minority, but I think wasm is quite different and the distinction is useful to maintain.
I've been working through advent of code using my own little compiler/language. It's in such an early state that some creative problem solving is required, not to mention the compiler bugs! But I'm very pleased to have it running interactively on my blog like this – I want to work towards some bigger notebooks in the style of explorable explanations.