So I'm having a "This is why we still use Fortran" moment today.
-
@AlgoCompSynth @arclight
I believe a major concern here is software longevity. You need to be able to grab the source in 15-20 years and it should verifiably still just work, and in the same way it used to.R, for all its good points, is not meant for that. Similar issues would rule out Python, Perl, Ruby, JS and so on.
-
@AlgoCompSynth @arclight
I believe a major concern here is software longevity. You need to be able to grab the source in 15-20 years and it should verifiably still just work, and in the same way it used to.R, for all its good points, is not meant for that. Similar issues would rule out Python, Perl, Ruby, JS and so on.
-
My conclusion for the moment is that the functional approach is extremely limited in its application for the sort of software I deal with. Conceptually the notions of immutability and lack of side effects are valuable. Recursion has efficiency issues and subtle but catastrophic failure modes compared to known-finite iteration or array operations. Much of the problem seems to be bound up in notation and the expectated solution form of specific functions languages. The notational issue is obvious but the expectations of uniformity, simplicity, and elegance of problem are not reasonable for even simple (but tedious) non-repetitive calculation. There are good concepts to understand here but practical applicability is extremely limited because of the nature of physical modeling and the extensive need for varied and structured data.
I appreciate Harper & Sussman's efforts but ultimately, I think the problem is a lack of detailed and realistic case studies of actual physical analysis. The points they are trying to get across would be quickly mired in tedious calculation and coding. That should be a warning that their specific approach may not be able to address simpler common issues. Maybe those are addressed in a different book, maybe in my quick scan of their book I skipped over where they acknowledge these issues or point to a broader reference, I don't know because I jumped to a quick recognizable example. I'm not trying to blame them for not addressing an issue that they didn't set out to address. I'm just noting my frustration with finding any example of a purely functional approach using a common language to solving broadly data-heavy problems from a straightforward domain-specific problem statement. It's a lot of work to do even a small example and nobody wants to put in the effort to document the process of solving a problem with the wrong tool. The question is how do you know a tool is the wrong tool if you don't actually explore how the tool fails in practice and identify the characteristics of problems that are a bad fit for a language (e.g. hardware interfacing, text processing, expression evaluation in Fortran).
This isn't a complaint about Scheme. The language is what it is. It shouldn't be a surprise given that it descends from Lisp, the other long-lived language originally designed for the IBM 704 in the mid-1950s. It's simply not designed to solve problems with a broad set of unique (non-sequential) data with a moderately high degree of coupling. But as far as I can tell, nobody actually says that in a single coherent sentence. It's always vaguely alluded to but never spelled out. A lot I think is the myopia of the language community or instructors in not understanding the breadth of applications - the classes of problems actually solved by people who are outside computer science and how/which languages get used. There's virtually no feedback from engineering analysis to computer science the same way say web applications or databases or embedded firmware or search or text processing feeds back. CS hits floating point numerics and calls it a day, not looking at the actual applications and classes of problems that use those numerics.
Reading the book in earnest now starting with the preface and introduction and realizing that I have a companion for Michael Kuipferschmid's "Classical FORTRAN" https://www.routledge.com/Classical-Fortran-Programming-for-Engineering-and-Scientific-Applications-Second-Edition/Kupferschmid/p/book/9781138116436 Both books are well-reasoned and well-written but are based on values which are actively harmful and destructive in my environment. Kuipferschmid rejects the bulk of Modern Fortran and focuses on best practices to work within the capabilities of F77. The premise is flatly wrong and backwards but otherwise it's a great book.
With this book, the problem is the notion that software malleability and flexibility is an unalloyed good. This is more true among researchers and hacker hobbyists because they are writing software only for themselves and there are low consequences for failure. I'm in the camp of writing software for a small group of others in a very risk-averse framework. I actively don't want applications to be modified once they pass acceptance installation testing. Eval and treating code as data and data as code are liabilities, not features.
An example from That R Code: the input file is actually R code that's eval'd to set input parameters. It's quick and convenient and avoids the tedium of writing an input processor. Unfortunately, it also allows a user to add unfiltered executable code to the application and has virtually no input verification to warn of potentially garbage inputs. "Configuration data as executable code" is a concept that has no place in our environment and probably not in any environment where there are safety or security consequences.
Can you build flexible code without such gaping security and assurance holes? Maybe someone can; I don't this book is going to be much help for people who write code where failures have consequences greater than developer inconvenience. Which IMO should be most paid industrial or commercial development (heavily implying that a too-large fraction of code being developed for hire is inconsequential - side-eye at the majority of web code.)
I worked on web systems for 13 years; most were garbage then and the situation has only gotten worse since. But I digress.
I'll continue with the book because I'm curious about some of the concepts. Hopefully I can get some ideas that work within a high-integrity environment. If not, I still learn something interesting and have much more specific risks to watch for when someone naïvely suggests we need to move to a more Functional code model.
Honestly, the book has paid for itself for the discussion it prompted. I read maybe 3 pages, got excellent feedback and discussion, and it all greatly clarified my thinking and understanding.
-
Reading the book in earnest now starting with the preface and introduction and realizing that I have a companion for Michael Kuipferschmid's "Classical FORTRAN" https://www.routledge.com/Classical-Fortran-Programming-for-Engineering-and-Scientific-Applications-Second-Edition/Kupferschmid/p/book/9781138116436 Both books are well-reasoned and well-written but are based on values which are actively harmful and destructive in my environment. Kuipferschmid rejects the bulk of Modern Fortran and focuses on best practices to work within the capabilities of F77. The premise is flatly wrong and backwards but otherwise it's a great book.
With this book, the problem is the notion that software malleability and flexibility is an unalloyed good. This is more true among researchers and hacker hobbyists because they are writing software only for themselves and there are low consequences for failure. I'm in the camp of writing software for a small group of others in a very risk-averse framework. I actively don't want applications to be modified once they pass acceptance installation testing. Eval and treating code as data and data as code are liabilities, not features.
An example from That R Code: the input file is actually R code that's eval'd to set input parameters. It's quick and convenient and avoids the tedium of writing an input processor. Unfortunately, it also allows a user to add unfiltered executable code to the application and has virtually no input verification to warn of potentially garbage inputs. "Configuration data as executable code" is a concept that has no place in our environment and probably not in any environment where there are safety or security consequences.
Can you build flexible code without such gaping security and assurance holes? Maybe someone can; I don't this book is going to be much help for people who write code where failures have consequences greater than developer inconvenience. Which IMO should be most paid industrial or commercial development (heavily implying that a too-large fraction of code being developed for hire is inconsequential - side-eye at the majority of web code.)
I worked on web systems for 13 years; most were garbage then and the situation has only gotten worse since. But I digress.
I'll continue with the book because I'm curious about some of the concepts. Hopefully I can get some ideas that work within a high-integrity environment. If not, I still learn something interesting and have much more specific risks to watch for when someone naïvely suggests we need to move to a more Functional code model.
Honestly, the book has paid for itself for the discussion it prompted. I read maybe 3 pages, got excellent feedback and discussion, and it all greatly clarified my thinking and understanding.
I wonder sometimes if the people in positions of authority and influence, writing textbooks like this, if they ever deal with software of consequence? I don't expect every senior CS professor to have worked on DO-138C qualified avionics software for example. But it would be nice if the field as a whole taught students that bad engineering kills people and you need to take quality and safety seriously, at least for the duration of the students' education. Take your work seriously and do your best to avoid shipping shoddy, dangerous code. Have some standards and a conscience. #MinimumViableEthics
-
I wonder sometimes if the people in positions of authority and influence, writing textbooks like this, if they ever deal with software of consequence? I don't expect every senior CS professor to have worked on DO-138C qualified avionics software for example. But it would be nice if the field as a whole taught students that bad engineering kills people and you need to take quality and safety seriously, at least for the duration of the students' education. Take your work seriously and do your best to avoid shipping shoddy, dangerous code. Have some standards and a conscience. #MinimumViableEthics
@arclight this was one of the first papers we read in my systems engineering course in college and it was very formative for me
https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/therac-25.pdf
-
@arclight this was one of the first papers we read in my systems engineering course in college and it was very formative for me
https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/therac-25.pdf
@arclight many years later I discovered the rest of Prof. Leveson’s work and I won’t say that I made it my whole personality but it’s a lot of it
-
@arclight this was one of the first papers we read in my systems engineering course in college and it was very formative for me
https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/therac-25.pdf
@kevinr @arclight TY for reminding of this. Found a cleaner scan here btw https://sci-hub.st/10.1109/MC.1993.274940
-
I wonder sometimes if the people in positions of authority and influence, writing textbooks like this, if they ever deal with software of consequence? I don't expect every senior CS professor to have worked on DO-138C qualified avionics software for example. But it would be nice if the field as a whole taught students that bad engineering kills people and you need to take quality and safety seriously, at least for the duration of the students' education. Take your work seriously and do your best to avoid shipping shoddy, dangerous code. Have some standards and a conscience. #MinimumViableEthics
@arclight in Canada anyway we have a few Software Engineering programs that attempt to teach safety concerns and consequences. In the program I did 25 years ago we have some professors who had worked on nuclear power plants, avionics and medical equipment like pacemakers.
-
@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.
@arclight @nyrath dare I curse you with the knowledge that is LispE?
5.3 A la APL
An implementation of a full fledged Lisp interpreter with Data Structure, Pattern Programming and High level Functions with Lazy Evaluation à la Haskell. - 5.3 A la APL · naver/lispe Wiki
GitHub (github.com)
(° '* '(2 3 4) '(1 2 3 4))
-
@arclight @nyrath dare I curse you with the knowledge that is LispE?
5.3 A la APL
An implementation of a full fledged Lisp interpreter with Data Structure, Pattern Programming and High level Functions with Lazy Evaluation à la Haskell. - 5.3 A la APL · naver/lispe Wiki
GitHub (github.com)
(° '* '(2 3 4) '(1 2 3 4))
I vaguely remember that "Lisp" was an acronym for "Lots of Insignificant Silly Parentheses)"
-
@arclight @nyrath dare I curse you with the knowledge that is LispE?
5.3 A la APL
An implementation of a full fledged Lisp interpreter with Data Structure, Pattern Programming and High level Functions with Lazy Evaluation à la Haskell. - 5.3 A la APL · naver/lispe Wiki
GitHub (github.com)
(° '* '(2 3 4) '(1 2 3 4))
@jonocarroll @nyrath Thanks - that was very interesting, especially in the efficiency discussion in a later section.
Yes, it's definitely cursed but that's one of the strangely attractive aspects of APL. One look at APL and your immediate thought is "This cannot end well". But somehow it does, you marvel at the compactness of it all, look away for a split second, and the whole thing has evaporated from your memory and you're staring at a random string of crazy moon language again.
-
@jonocarroll @nyrath Thanks - that was very interesting, especially in the efficiency discussion in a later section.
Yes, it's definitely cursed but that's one of the strangely attractive aspects of APL. One look at APL and your immediate thought is "This cannot end well". But somehow it does, you marvel at the compactness of it all, look away for a split second, and the whole thing has evaporated from your memory and you're staring at a random string of crazy moon language again.
I've heard tell that with APL source code that needs editing, it is much easier to re-type the entire piece of code as opposed to trying to just edit bits of the code.
-
I've heard tell that with APL source code that needs editing, it is much easier to re-type the entire piece of code as opposed to trying to just edit bits of the code.
@nyrath @jonocarroll And good luck finding a decent set of APL keycaps for modern keyboards. I have a very nice set of new APL keycaps for an IBM Model M keyboard and a very very faint set of keycaps for modern Cherry MX style switches. I keep mulling over buying a reproduction Model M keyboard to make use of the otherwise useless keycaps but I poke at APL once every few years (props to Dyalog for keeping the language alive and having fantastic documentation and a Windows keyboard driver). Thus far I've resisted the Sunk Cost Fallacy but who knows how long I can hold out... #SendHelp #DesperatelyNeedTherapyAMovingCompanyAndABigStorageUnit
-
@nyrath @jonocarroll And good luck finding a decent set of APL keycaps for modern keyboards. I have a very nice set of new APL keycaps for an IBM Model M keyboard and a very very faint set of keycaps for modern Cherry MX style switches. I keep mulling over buying a reproduction Model M keyboard to make use of the otherwise useless keycaps but I poke at APL once every few years (props to Dyalog for keeping the language alive and having fantastic documentation and a Windows keyboard driver). Thus far I've resisted the Sunk Cost Fallacy but who knows how long I can hold out... #SendHelp #DesperatelyNeedTherapyAMovingCompanyAndABigStorageUnit
@arclight @nyrath @jonocarroll
The worst part of owning a Model M is knowing that it will not wear out so you can replace it with the keyboard you really want, which is a compact model F with backlighting and QMK firmware.
-
R relay@relay.mycrowd.ca shared this topic
