I've decided to leave twitter by changing my password and then deliberately forgetting it, so that my old tweets remain up but I will no longer have access to my account. You can find me on or

Today I learned about the HTML <q> element, which is used for inline quotations and has the neat property that when you nest, it can change from double quotes to single quotes!

I wrote about the philosophy that underlies Topos Institute modeling software: Also, it's a job ad; see the end for details!.

This specific feature, the graph-rewriting, is enabled by the local mode that Yaron is talking about: it ensures that no reference to the graph escapes into the runtime of your app, so the graph can't be mutated after the startup of your app.

So far, the only UI library I know that explicitly support Mealy machines, and that does a graph-rewriting pass to optimize how state propagates through your app.

And you can play around with the new Cont-based bonsai interface! Some really cool design here:

If you want to see how abstract, general code can perform *faster* than traditional C programs, check out .

But pre-scheme uses macros and not comptime! And then of course, there are things like MetaOCaml which allow you to do a somewhat similar thing (generate code for your problem) but with a different set of tradeoffs.

An addendum: there are of course other differences between zig and LISP, like the fact that zig gives you the tools to write "systems-y" code in a way that *most* LISPs don't. I say *most* LISPs, because there are some really cool LISPs that *do* do this!

And I'd also like to say: there are many programming languages out there! Many of them, if not all, have some unique features which will enrich your life (yes even Java and Go). Rather than dunking, try to understand why people are excited. Who knows, you might learn something!.

To conclude, I'd like to point to my library which simulates zig's comptime features in Julia using macros and Julia's @generated functions. Note that this really relies on Julia's type system to work. This would be much harder to do in scheme.

It also has drawbacks: you can't change at all the meaning of zig's syntax, so you can't build DSLs in the way that you can in LISP. Of course, some see this as a benefit.

Which, incidentally, is *not* a solved problem in the vast majority of LISPs; really only Racket's scope tags system solves this in a principled way, and that was *definitely* not known in the Kennedy administration.

Using comptime as opposed to macros has a lot of benefits, because *conceptually*, it's not any different from just writing a normal program in a language like python that has type introspection. You don't have to think about things like variable hygiene.

You could "implement an compiler in LISP macros" which did this, but it would be about as much work as writing the compiler from scratch in the first place.

For instance, you can use this to unroll for loops, statically eliminate branching, and even introspect on the structure of types.

Additionally, zig functions can have some comptime parameters and some runtime parameters. Such a function is compiled by being *partly evaluated* with respect to the runtime features. This is a fairly sophisticated program transformation.

Thus, m(2) and let comptime x = 2; m(x) *cannot be distinguished by the body of m.*.

Zig comptime works in a different way. Rather than operating on syntax, a zig function with a comptime argument must be called with an expression whose *value* is statically-known to be computable at compile time.

If one of the arguments to a macro *happens* to be, say, a literal integer, then the macro can see that. However (m 2) and (let (x 2) (m x)) will behave very differently!.