I look at the code and sigh; this is just as impenetrable and unreadable as the machine code that would have been used to implement this in 1955.

I know what they're trying to do and I'm familiar with the paren-heavy inside-out prefix notation of Lisp/Scheme - it's like one horrific run-on sentence that stops having any meaning by the time you hit line #4.

This notation is alien and illegible, a human factors disaster.

Fortran was specifically designed to have notation familiar to people who work with algebra. The contortions needed to map symbols in Eq. 3-3 to the Scheme code are mind-bending so whatever point is trying to be made is completely mired in complex tedious symbol association.

This is why we still use Fortran. As in 1956, it's fast and legible to practitioners.

I honestly didn't cherry pick an example - I keep trying to find a case for Scheme and I just can't. Not everything is for everybody and I'm just going to have to accept that the Scheme/Lisp universe was designed for someone other than me. APL makes sense to me in a way Scheme never will which is really weird to me. I can deal with the crazy moon language because the expression is all on one line and it's dead simple to parse. Scheme code is like the inside of a telephone cabinet - thousands of strands of wire but nothing coherent. You can spend a lifetime trying to untangle that rat's nest; a moment's glimpse away and whatever pattern you saw is gone. Start over tracing each wire...

@arclight There is a way to refactor Scheme code so it's much more readable on things like an ODE solver. (Without looking at it I'm guessing it's Gill's variant of Runge-kutta. 😈 )

But here's the thing they don't tell you. Lisp 1.5 / Scheme is not much more advanced than the lambda calculus. If you want to write numerical code in a functional paradigm with ***types*** to preserve your sanity, there's Julia and Haskell and other languages.

@AlgoCompSynth I tried Haskell and within 30 minutes had hard-locked my desktop and needed to power-cycle it to get it back. Hadn't had that happen in decades. I looked at Julia; it's designed for research code with odd design choices plus this breathless fascination with multiple dispatch. Didn't seem worth pursuing.

I'm still having a big problem finding anything but C++ and Modern Fortran for writing production code. Ada was too hard to get traction with and it's more intended for embedded systems rather than desktops and servers. Everything else is single source, the implemtation is the spec. Great until the maintainers decide that slop PRs are acceptable and you're chained to that sinking ship. :/

@arclight @AlgoCompSynth
Maybe Go or possibly Rust might be possible alternatives for you.

But. What you're looking for is an imperative language for numerical computing. And modern Fortran is right there. I honestly don't think you'll find anything that can really improve a lot on that.

C++ has, to me, sort of the same issue as Scheme. A language committee keeps creating a new, incomprehensible language every few years and insists it should still be called C++.