So I'm having a "This is why we still use Fortran" moment today.
-
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...
And mind you, this isn't a He-Man Lisp Hater's rant. It's more of a mope that I feel I'm wasting my time, like William from Mallrats who camps out in front of the random-dot-stereogram all day but can never see the sailboat. I just don't see it and I can't tell if I'm looking at it wrong or if there's just nothing there. I assume the former which has put me down this particular rabbit hole. At some point I need to stop digging.
-
@smiteri @arclight
That's only about being used to reading it. It's no less clear thanhistory(x, 0) * 2 +
Once you're used to it. Same with RPN for that matter.
Edit: stuff like the prefix notation and parentheses is surface level issues. You get used to it and it quickly feels normal. The functional approach takes a lot more work, and as an old language it lacks ergonomic stuff such as generics and so on.
-
@arclight I find it the opposite, I can just barely read the math notation, but SWEET CTHULHU would it kill mathematicians to use multi-letter words for symbols?
The Scheme example explains how x & t work, provides the stepper function, and the code's nicely nested and readable words.
I wouldn't do it that way, I don't think SDfF is the best text on Scheme, but it's how we code generally. It looks like a lot of my videogame code.
(TSPL by Dybvig is the best book on practical Scheme)
#scheme@mdhughes Typically in an application where variables aren't abstract, there's a notation list which would define all the symbols. t for time, x for distance, possibly subscripts to show an index or to add specifics. The problem is this is purely a numerical problem - just abstract math with nothing concrete to ground it or give context.
Much of the syntax issue is surface level but if you're trying to get at the actual concept they're trying to communicate, it's incredibly hard to parse the Scheme code if you spend most of your time dealing with traditional math notation. People who regularly use Scheme would likely have no problem with this. I'm caught in a chicken-egg problem where it's not clear that becoming more familiar with Scheme would get me anywhere I'd care to be but without that familiarity I can't read the roadmap.
-
@mdhughes Typically in an application where variables aren't abstract, there's a notation list which would define all the symbols. t for time, x for distance, possibly subscripts to show an index or to add specifics. The problem is this is purely a numerical problem - just abstract math with nothing concrete to ground it or give context.
Much of the syntax issue is surface level but if you're trying to get at the actual concept they're trying to communicate, it's incredibly hard to parse the Scheme code if you spend most of your time dealing with traditional math notation. People who regularly use Scheme would likely have no problem with this. I'm caught in a chicken-egg problem where it's not clear that becoming more familiar with Scheme would get me anywhere I'd care to be but without that familiarity I can't read the roadmap.
@arclight Right, it's very different audiences. There is a good math stack in Scheme (taken from Lisp), so it scales up to exact fractions or IEEE at least, and can do bignums in some impls. Autodesk uses a sorta-Lisp/Scheme based on XLISP, and does a LOT of math that way.
But it's a harder language to get into if you're used to anything else, everything is backwards, recursion is loops, lambdas are objects.
I do think R6RS Scheme is the best language, but it's def in a weird corner.
-
And mind you, this isn't a He-Man Lisp Hater's rant. It's more of a mope that I feel I'm wasting my time, like William from Mallrats who camps out in front of the random-dot-stereogram all day but can never see the sailboat. I just don't see it and I can't tell if I'm looking at it wrong or if there's just nothing there. I assume the former which has put me down this particular rabbit hole. At some point I need to stop digging.
@arclight Lots of capable programmers don't like declarative concepts. I think it's a brain thing.
One of the things I like about XPath is that it has operators that mean you don't have to nest the function parens; `function1() => function2() => function3()` is easier to read than `function3(function2(function(1)))`
-
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.
-
@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.
@arclight The authors should be shamed for using an ODE solver as an example of Scheme programming! It's just not that kind of language at its core.
-
@arclight The authors should be shamed for using an ODE solver as an example of Scheme programming! It's just not that kind of language at its core.
@arclight OK - I looked. It's not Runge-Kutta-Gill but something far less accurate. So they get bonus shaming for using a terrible algorithm for ODE solvers in a language not designed for numerical calculation *or even sane programming, which involves entities that have types*.
-
@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 OK - I looked. It's not Runge-Kutta-Gill but something far less accurate. So they get bonus shaming for using a terrible algorithm for ODE solvers in a language not designed for numerical calculation *or even sane programming, which involves entities that have types*.
@arclight Is there anyone that actually cares about solving ODEs that doesn't use this?
-
@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 Looks like the R solver wraps ODEPACK
-
@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
> 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.Sounds like a memory leak - were you compiling something? GHC does some really RAM-intensive things.
-
@felipe But this is exactly the sort of application I'm looking for because it's relevant to my problem domain.
I keep thinking I must be doing something wrong because I can never see how recursion solves more than a miniscule fraction of the issues I face, and most of those are better done with iteration because of clarity or efficiency. Someone has to be able to read the code and verify it's correct and Scheme, etc look completely amorphous to me beyond 3 lines or 4 levels of nesting. The routine's structure just eludes me.
@arclight Regarding math, at least for me, all lisps feel clunky and much less readable than the infix standard notation expressions, especially when compared to something like Fortran, Julia, or Python with the appropriate libraries.
Regarding missing something, and the "what is this even good for" feeling, I don't think you are missing much.
Some problems are lispy but usually, not things that scream "physics," and the reason is pretty simple (IMO): the languages we use for physics and maybe even physics in itself is full of mutability, and for anything more involved, also lacks locality in the sense that basically everything affects everything else in a deeply connected way, making the approach of coding by splitting effects into well bounded functions with clear data boundaries not so efficient.
In my experience, that's one reason why game-deving with functional languages is such a pain.
There are some things beyond recursion that I do like in lisps and seem to be broadly useful, like pattern matching, but that's everywhere now, not only in lisps.
With all that said, you can definitely be more fluent than ~3 lines chunks, just checked some Racket code and I myself can follow ~20 line functions and still think they are readable, albeit my personal sweet spot is probably more like 5-15 lines. Nesting does get me much quicker though, I can't follow too much more than what you mentioned.
-
@arclight Regarding math, at least for me, all lisps feel clunky and much less readable than the infix standard notation expressions, especially when compared to something like Fortran, Julia, or Python with the appropriate libraries.
Regarding missing something, and the "what is this even good for" feeling, I don't think you are missing much.
Some problems are lispy but usually, not things that scream "physics," and the reason is pretty simple (IMO): the languages we use for physics and maybe even physics in itself is full of mutability, and for anything more involved, also lacks locality in the sense that basically everything affects everything else in a deeply connected way, making the approach of coding by splitting effects into well bounded functions with clear data boundaries not so efficient.
In my experience, that's one reason why game-deving with functional languages is such a pain.
There are some things beyond recursion that I do like in lisps and seem to be broadly useful, like pattern matching, but that's everywhere now, not only in lisps.
With all that said, you can definitely be more fluent than ~3 lines chunks, just checked some Racket code and I myself can follow ~20 line functions and still think they are readable, albeit my personal sweet spot is probably more like 5-15 lines. Nesting does get me much quicker though, I can't follow too much more than what you mentioned.
@felipe Yes, basically all of this. Racket's editor (Dr. Racket, formerly Dr. Scheme IIRC) was a huge help and had some unique features to see connections and make sense of the code. I can put aside the mutability (that can be worked around though tediously) but the locality issue is much more difficult to crack. When you have an expression with 1-2 key variables and 4-5 secondary constants and variables and about 10 of these expressions to work through in sequence to get a final value, condensing all that to a single function with every parameter passed in as an argument is error-prone, unwieldy, and incredibly difficult to read and verify. Objects help a lot but there doesn't seem to be a way to create complex data-carrying types in Scheme - if there is, it's an advanced topic rarely demonstrated in most texts. Another way to pull in read-only parameters is via modules and imports - that breaks the atomicity that Scheme is striving for.
One area where the functional approach is essential is in 'elemental' functions which treat all arguments as either scalars or arrays and can work on each element either in parallel or vectorized (SIMD). Eliminating side effects is critical so mutability is strictly forbidden though there are special exemptions for printing or logging as a matter of practicality. Still, there's rarely any functional composition - functions are rarely passed as arguments. Scheme excels at composition but it doesn't help here because it's almost never needed.
The problem has been trying to identify the characteristics of a problem that make reframing the code into functional form painful or impossible.
There is value in writing a complex function in functional form - it clearly lays out every argument which is very useful for uncertainty quantification and sensitivity analysis. It's just not clear the cognitive load is worth it, and that's even before considering efficiency and storage needs.
-
@mdhughes Typically in an application where variables aren't abstract, there's a notation list which would define all the symbols. t for time, x for distance, possibly subscripts to show an index or to add specifics. The problem is this is purely a numerical problem - just abstract math with nothing concrete to ground it or give context.
Much of the syntax issue is surface level but if you're trying to get at the actual concept they're trying to communicate, it's incredibly hard to parse the Scheme code if you spend most of your time dealing with traditional math notation. People who regularly use Scheme would likely have no problem with this. I'm caught in a chicken-egg problem where it's not clear that becoming more familiar with Scheme would get me anywhere I'd care to be but without that familiarity I can't read the roadmap.
@arclight I don’t think you’re entirely wrong.
A possibly-relevant anecdote: in grad school I implemented a CYK parser in Clojure as a “fun” (I’m not well) exercise, partly just to not do Python. It was fairly challenging, not so much because of the Lisp syntax, which I’m plenty comfortable with, but because the algorithm just isn’t functional/immutability-shaped. It’s dynamic programming, which is … not that.
Great learning exercise, for why it was a suboptimal language choice. 1/
@mdhughes -
@arclight I don’t think you’re entirely wrong.
A possibly-relevant anecdote: in grad school I implemented a CYK parser in Clojure as a “fun” (I’m not well) exercise, partly just to not do Python. It was fairly challenging, not so much because of the Lisp syntax, which I’m plenty comfortable with, but because the algorithm just isn’t functional/immutability-shaped. It’s dynamic programming, which is … not that.
Great learning exercise, for why it was a suboptimal language choice. 1/
@mdhughes@arclight That said: I have that same book but haven’t worked thru it yet; I’m also only vaguely familiar with diffeq so definitely don’t have an informed opinion there. But it makes sense that Scheme/Lisp are uncomfortable fits out of the box for your problem space of expertise.
I say “out of the box” because IMO the strength of Lisps generally is the ability to mold it into the shape of your problem, but building up the kinds of affordances Fortran has is a big task. 2/ @mdhughes
-
@arclight That said: I have that same book but haven’t worked thru it yet; I’m also only vaguely familiar with diffeq so definitely don’t have an informed opinion there. But it makes sense that Scheme/Lisp are uncomfortable fits out of the box for your problem space of expertise.
I say “out of the box” because IMO the strength of Lisps generally is the ability to mold it into the shape of your problem, but building up the kinds of affordances Fortran has is a big task. 2/ @mdhughes
@arclight Still on my first coffee so that may make less sense than it seems to me right now, but it’s hopefully still useful.
There *are* folks doing numeric solutions in Lisps, and have been for decades, but the most natural fit is in analytic solutions and symbolic computing. (FWIW Common Lisp has a whole other syntax for that shape of problem: LOOP. Scheme is designed with a much “purer” syntax, to be cleaner and more theoretically consistent.)
Back to my coffeelurk.
3/3 -
@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).
-
@nyrath APL is simultaneously genius and batshit. It's incredible what you can do with 2-3 sigils but it is cryptic as hell. It the sort of language used by people who talk to crows.
When I was in college (1980s), we wrote our source code on DECwriters. Which could not handle the APL character set.
If you wanted to write APL you had to go to the computer lab's lonely IBM Selectric, and use the lab's only APL type ball.
-
And mind you, this isn't a He-Man Lisp Hater's rant. It's more of a mope that I feel I'm wasting my time, like William from Mallrats who camps out in front of the random-dot-stereogram all day but can never see the sailboat. I just don't see it and I can't tell if I'm looking at it wrong or if there's just nothing there. I assume the former which has put me down this particular rabbit hole. At some point I need to stop digging.
@arclight have you ever looked at the ML family of languages?
-
R relay@relay.infosec.exchange shared this topic
