Various priors inoculate me from feeling some of the rejection expressed in other comments. I knew Sammy Eilenberg, perhaps the most famous mathematician to work at Columbia University. He hired me. With friends, I ran into him one night out in NYC, and in his 70's we all stayed out past dawn. His late career focused on topos theory, and everyone in the building politely rolled their eyes. Those are working mathematicians having an understandable reaction; most reactions to topos theory here are simply uninformed. The evolution of programming languages has lead from the lambda calculus to many forms of category theory. Topos theory would not be a surprise.

The Leech lattice? Could be a brilliant idea. Compare Lenstra's elliptic curve factorization algorithm. Sometimes famous landmarks in mathematics have remarkable properties; mining them for algorithmic advantage is no different than mining asteroids for rare metals.

The involvement of AI is most problematic. Mathematics fears being swamped by mediocre AI-authored papers, but the truth is "publish or perish" has long lead to mathematics being swamped by mediocre papers. Bad artists are losing jobs, but good artists are working faster.

I welcome a new era of programming language design, where AI makes rapid prototyping a reality. We just have to take sharing this work with a grain of salt. Stop reading when you lose interest, but welcome the churn!

I have email locally dating to the dawn of the internet; it's one form of external mind-mapping for me. I'm completely baffled that a decent mail program can't handle the mail for a small town, rather than struggling with one person's life history. This is a question of algorithm choices; performance has to be the top priority. If search is instant, who needs "features"?

That strikes a chord for me. In grade school my teachers could not distinguish between these perspectives, for the standard shoelace knot. I found their method stupid, and they thought my method was wrong. This was but one of many lessons that helped me to learn to think for myself.

She was nevertheless welcome at a frequent flyer event hosted by Continental in Houston, where she beat me at poker.

In Bordeaux, winemakers consider themselves geniuses manipulating a many variety blend. In Alsace, winemakers view their role as not screwing up God's work.

AI agents fielded by major AI players still fail at the basic task of providing immediate and correct support for use of the current versions of their products. If a programming language is too new to have adequate representation in the training corpus, there isn't an accepted standard way to provide a reference manual targeting AI agents. Even the best way to include documentation in a large project so new AI agents can take over is controversial. A pile of linked markdown files really isn't an answer, less structured than a codebase itself, that AI is good at navigating.

Other HN posts have discussed using SQL as a backbone for the AI "mind mapping" support we need for AI more critically than for ourselves.

I was hoping that CQL could be an answer to this. Perhaps, but not its current primary goal.

    UFBT: Unofficial Flipper Build Tool (installation guide)

    uFBT is a cross-platform tool for building applications for Flipper Zero.

I'd love to extract just the foreign language from Pimsleur foreign language lessons, for faster review before trips. Your pipeline has many elements in common for what would be required.

While a native APL would be nice, the cloud solution would be robust access to a professional product. Build the chain via existing tools to bridge the iPad to APL running on a desktop machine.

I looked into this recently; but I've decided on Lean 4 as the successor "best language in existence" for my needs.

My recent language comparison: https://github.com/Syzygies/Compare

My APL one-liner story: https://news.ycombinator.com/item?id=27460887

My work is more combinatorial. Julia does excel at numerical computation. There's a tribal divide in math between people who can't go 30 seconds away from the real or complex numbers, and those whose tolerance is about that long. I try to keep an open mind, but I'm closer to the second camp. Julia is good enough to consider either way.

A development in recent months, AI can assist in general purpose Lean 4 programming, no longer getting confused by the dominant proof-oriented training corpus. If one is a functional programmer who believes that Haskell was on the right track, then Lean is the most interesting language choice for shaping one's thoughts. Benchmarks are inherently misleading if a better language makes it possible to express algorithms out of reach of more primitive languages.

https://github.com/Syzygies/Compare

            C++  100    13.08s  ±0.08s
           Rust   99    13.16s  ±0.02s
          Julia   90    14.54s  ±0.01s
             F#   90    14.54s  ±0.04s
  Kotlin-native   88    14.79s  ±0.01s
         Kotlin   86    15.18s  ±0.01s
          Scala   79    16.50s  ±0.08s
   Scala-native   76    17.14s  ±0.02s
            Nim   65    20.17s  ±0.01s
          Swift   64    20.54s  ±0.04s
          Ocaml   52    25.38s  ±0.04s
           Chez   49    26.64s  ±0.02s
        Haskell   37    34.96s  ±0.06s
           Lean   29    45.39s  ±0.15s

I set them all aside for several Leopold FC660C Topre keyboards with the Hasu mod supporting QMK firmware.

Then I started getting ulnar nerve issues, either the gym or too many AI prompts. I discovered MoErgo's keyboards, and their custom Cherry Blossom switches. I honestly believe they have subtle design genius pervading their work, beyond anything I have ever experienced. Quiz me; I've also tried X.

Their Glove80 could use a bit of the "door slams like a Rolls-Royce" quality that many of these bespoke keyboard makers apply to more conventional designs. The design nevertheless triumphs.

Their second generation Go60 is my "Stay60" I can't give up. The build quality, and I don't want more keys.

At first it feels like the Cherry Blossom switches fire from a breeze with the window open. One adapts.

Perhaps an expert could strike a better balance, but it struck me and my various agents that we'd be fighting the language to make it faster.

https://github.com/Syzygies/Compare

Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousands of lines of Scheme this way, hands down my favorite code to read), but doing so will lead to a tribal swarm attack. It is also easy to train Common Lisp to lay off the caps, but any stock installation greets users with an old man shouting (GET OFF (MY LAWN)).

The idea of Lisp is pure genius. One wonders where we would be today if any Lisp took a more pragmatic attitude towards encouraging adoption.

I still can't get AI to code well in Lean 4, but I'm writing a parser for a language that doesn't exist. AI understands the language as well as I do.

Lean 4 is the most interesting language on my list. I didn't reject it on price.

As for parallelism this is a primary concern of mine, and I tried multiple approaches for every language where there was a choice. I used my own work-stealing code only when it beat standard libraries. AI warned me I was in over my head, that writing such a library takes years of experience, but my use case (and my expected use cases in my research) is so uniform that simple can win, minimally touching the required bases such as permuting tasks to avoid false sharing.

I don't believe that the JIT languages (F# on top) do so well because of better parallelism. This is branch optimization. For this use case an AOT compiler with ample benchmark data to influence output should do better. That isn't a thing, and the argument seems to be that few use cases stay consistent. A JIT can adapt.