So I'm having a "This is why we still use Fortran" moment today. New (to me) Book Day bring me "Software Design for Flexibility" by Chris Harper and Gerald J. Sussman (who we know from SICP). My hope was I might finally find a context familiar to me where I could see how Scheme gets applied. It took me about a minute or two to grind to a halt and now I am a little sad.
Being fair, this is literally after flipping to "A Simple ODE Integrator" a quarter of the way through the book - skipped the preface, introduction, and the first two chapters just for a quick scan. So we have this pile of algebra - standard mathematical infix notation for a moderately complex differential equation solver:
That apparently translates to 8 lines of impenetrable Scheme:

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 The secret to Julia is it’s essentially a Lisp with infix syntax. Multiple dispatch is how they solve the problem of fast numerical solutions being extremely sensitive to types, which is probably the only way you can sensibly do it, but it has taken a lot of work to get it to where it is now (which AIUI is much better than it was even a year or two ago).

@curtosis @arclight

S is a happy marriage of Lisp and Fortran. R is S with Lisp replaced by Scheme. Julia is "R is too <expletive deleted> slow so let's do the Fortran - Lisp marriage over, because it ain't 1976 any more!"😈