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...
someone described APL listings as resembling pages from an alchemist spell book.
-
@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.
-
@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.
@smiteri @arclight
My main criticism of Scheme is that - like Forth - when you use it correctly you are writing your own DSL for solving your problem. A DSL that only you can read and understand.Scheme is a lot of fun for exploring stuff on your own, but it quickly becomes painful when you need to share and work with other people. Like a C++ where *anyone* in your team can add stuff to the standard at any time.
-
@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.
-
@smiteri @arclight
Sure - I wasn't trying to be precise. And there was no second element in your sum either.Here's the neat¹ thing about Scheme: a variable and a function is the same thing. A function is (sort of) just another data type. Talking about a function as a variable - or as the value of a variable - is perfectly fine.
1) individual emotional reaction may vary.
-
@arclight the subject might not be doing them any favours here
@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.
-
someone described APL listings as resembling pages from an alchemist spell book.
@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.
-
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.
