Side note to this: I noticed that a smart friend had trouble learning anything outside of trivial programming due to unfamiliarity with boolean algebra and boolean logic. She only seemed to begin to understand the concepts when relating them to patterns used in knitting. If those were more commonly taught in basic math, it might make programming generally more approachable.

It makes sense that it's a mathematical approach because Computer Science is ultimately a Mathematical discipline, the Church-Turing intuition aligns these machines to mathematics (and I would argue us too, but that's controversial).

Lots of elite CS courses start there, Cambridge did even when I was applying thirty years ago, Oxford does these days (back then it didn't acknowledge CS as a "real" subject, you were basically a mathematician and you'd just be studying this oddly practical sub-discipline of mathematics). Both teach an ML today. The place I studied began with an ML then too (today it begins with Java, which is I think inferior but they get $$$ so...)

My unconsidered guess is that your "begin with booleans" thing just gets to arithmetic via a long winding route, and either as it approaches arithmetic, or just before, it accidentally gets infected with Gödel incompleteness so you are no better off, with the same problems but maybe a greater appreciation of why they were unavoidable, except maybe you're very tired.

I agree with you, which is why I’ve found nand2tetris to be a joy to read and work through.

Different roads that reach the same place, I think.

Finite state machines are a small step away from sequential logic and help with managing complexity. Pushdown automata are a small step from finite state machines. I think of Turing machines as an architecture for a computer consisting of a separate CPU and memory, which happens to correspond to the most common architecture used today, but not a particularly useful tool for managing complexity as they have no structure. Functions are useful for managing complexity, and function call / return requires some notion of a stack. Once you're there you can build up the rest of FP. Pure function correspond to combinatorial. Those with state correspond to sequential logic. etc.

Going in the reverse direction, compilation connects functional programming to hardware.

I think it's the math notation and math problem domain that seems to leak into attempts to broaden the audience. Tersely named, far removed from anything I could reach out and touch.

I could never grok scala, all the examples and learning material used math idioms, metaphors and symbology. So I was always translating and it was very difficult to pick up.

And yes, I fully realize this was my own shortcoming. I should have put eight years into the foundational knowledge. But I wonder if these math metaphors translate to a more broadly shared experience. They should be in theory. Programming is supposed to be a tool to accomplish goals, it shouldn't force users into it's inner world as much as it does. It feels like I need a formula one crew just to drive a car from Seattle to Kansas.

I'm really surprised to hear Racket code was slower than Python. Racket has had a JIT compiler for a very long time, and v8 has a much better JIT compiler, so I would expect its performance to be vastly better than Python.

I can't believe I have never heard of Racket before, it's 28 years old!

Quite some libraries available too https://github.com/avelino/awesome-racket

Had him 25 years ago for Digital Logic. His enthusiasm was far beyond most of the other profs. Warms my cockles to see he’s still keeping it real.

That would be https://htdp.org/2023-5-12/Book/index.html (see https://users.cs.northwestern.edu/~robby/pubs/papers/htdp-si...) which also uses Racket