So I'm having a "This is why we still use Fortran" moment today.
-
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:
-
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:
-
That apparently translates to 8 lines of impenetrable Scheme:
@arclight the subject might not be doing them any favours here
-
That apparently translates to 8 lines of impenetrable Scheme:
@arclight
I mean, it's not *that* impenetrable? No more than the same Fortran or C code if you're not used to it.The math basically looks the same no matter what language you use; the novel (and neat) thing here would be the use of higher order functions almost without having to think about it.
-
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
I mean, it's not *that* impenetrable? No more than the same Fortran or C code if you're not used to it.The math basically looks the same no matter what language you use; the novel (and neat) thing here would be the use of higher order functions almost without having to think about it.
-
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 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 -
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.
