In much that same way that many people do the daily wordle or crossword, I do the daily leetcode.

I flip a coin and solve it first in either C++ or Python, then re-write my solution in the other one.

Usually it takes me around 20 minutes to solve it in either language, and 5 minutes to re-solve it in either language.

Recently I decided to start learning emacs lisp. This is an imperative lisp dialect that’s pretty different from scheme, but I think that the particular language doesn’t matter much for this process. I could a bit biased because I do have prior experience with SML and scheme.

I started re-solving the problems a third time in emacs lisp. And I’m still learning but I’ve felt my comfort with the language increase over time, and I expect that if I continue doing this then I will eventually reach parity with C++ and Python.

Currently it takes me about 20 minutes to re-solve a problem in emacs lisp, because I usually have to read documentation and/or look up something new.

Personally I find it easiest do design data flows: think about what we need in order to compute the result. The less I have to think about state the better. Functional patterns fall out and it feels simple and easy to me, so I do it. I'm way over the phase I thought that's somehow cooler than the OOP folks, however.

I do wonder what a language with the same “taste” and minimalism as Scheme but embracing the actor model would look like. Erlang?

Even better if someone could figure out how to harmonize them in the same language: “There are exactly two ways to do it, and they’re interchangeable.”

Best of all, is that the syntax grammar is so simple, that a simple CLAUDE.md + a few review agents lets me move super fast using AI. I spend most of my time anchoring on the design/plan and let AI write the implementation for most of the code.

Official docs: https://docs.racket-lang.org/rhombus/index.html

Collection of small examples: https://github.com/racket/rhombus/blob/master/demo.rhm

stack traces are esoteric and error messages entirely unhelpful,

documentation masquerades as deep but is indeed inconsistent and prosaic, mixing styles of reference, explanation, and how-to willy-nilly, (compare with Dybvig’s The Scheme Programming Language, which is focused and consistent, and it takes no time to get your answers; there’s just no method to guile and guix manuals), i hate it big time,

there’s big gaps in documentation (especially with Guix – there’s literally zero information about `define-record-type*` which is used everywhere in its codebase; admittedly, not scheme related, but still),

the cli requires too much memorization,

most modules are not named, but numbered, ie, instead of something like `(base list)`, you get `(srfi srfi-1)`, so you need to either memorize, or go through the info pages for each procedure you need to import, which means you also need to know the exact names for the procedures you need beforehand,

there’s like 4 ways to define a record, each with a different feature set and incompatibilities,

etc.

these are the reasons i find it hard to use.

to respond to the content of the article, the different neurotype idea is off, because scheme allows you very well to express sequences of operations; the ecosystem of APIs may not cater to this tho. although if it was rephrased into “scheme emphasizes symbolic manipulations, as opposed to operating a machine”, i would agree