7 ms·

So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code. With test-driven development is it no

So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code. With test-driven development is it not the case that you are forced down the path of making your C++ code testable anyway? With multi-threading, there are numerous strategies to achieve this within C++ without blowing your foot off. Takes dicipline I know. Basically what I'm saying is, if functional programming is so great, why did LISP et al not take over the world? (Not a LISP hater, just curious).

mhh__ 6y ago
LISP and programming in a functional manner is comparing apples and oranges, surely?
ashton314 6y ago
Just some speculation, but one reason why C and friends took off better in enterprise domains is that they were on systems that people needed (C with Unix) or were more aggressively marketed. (Java) functional programming languages tended to not be as fast for single threaded programs compared to their imperative and object oriented counterparts. Now that we have stopped seeing such large gains in single thread and performance, most of our scaling comes from being able to scale horizontally. Functional programming languages are making a resurgence: the rise of Rust, Elixir, Scala, etc. is in response to this. I’m sure pg has plenty to say on the topic.
lalaithion 6y ago
Didn't LISP take over the world? Sure, not syntactically, but lambdas, complex expressions, garbage collection?
seer 6y ago
This is indeed a very interesting question! I’ve also asked myself that time and time again, along the path of slowly discovering what this FP thing is all about over the course of my career. It does look wonderful, it does save you a lot of effort in some cases, where “some” is a vast swathes of computational problems. And its so damn elegant. A lot of examples are thrown around were a bunch of lambda calculus can result in 10-20 fold reduction in source code size. So where’s the catch?There has to be something wrong right? Well recently I stumbled upon a clojure conf talk that tried to tackle precisely this question. https://youtu.be/QyJZzq0v7Z4 https://youtu.be/QyJZzq0v7Z4 The short of it is that its more of a historical inertia and chance than any specific hidden gotcha. Fascinating talk.
- jahaja 6y ago
  I'm sorry but this all strikes me as rather delusional. The reason why functional languages doesn't take off is because programming languages are tools, not an end in themselves. Carpenters that are obsessed with perfecting their power tools would rightly be out of a job in a very short amount of time. Furthermore most of these "perfections" aren't even virtuous - in the sense of searching for improvement - but just self-indulgence and aesthetics. Functional languages are dense, hard to read, have a high cognitive load, and are thus unproductive beyond the proverbial garage startup. They are also designed and used mostly by mentioned power tool decorators rather than practitioners, with the inevitable end result.
  - discreteevent 6y ago
    "Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans
  - seer 6y ago
    Totally understand the sentiment. I was very dismissive at first, as a self thought dev. Its really hard for me to learn something unless its helps directly to solve a concrete business problem I’m facing, so I know where you’re coming from. I think my epiphany was when I was trying to learn me some clojure on a couple of weeks sabbatical from work. As a mostly js/frontend/react dev at the time I was deep into React ecosystem for building SPAs. I knew and largely disliked the amount of code a redux based app would require in order to be “complete” with all the data fetching and state management (this was before hooks and contexts). And then I sew re-frame, that implements a lot of the features in that whole ecosystem, in like 100ish lines of code. Thats BS I told myself. Things are missing! It cannot be just this code in front of me. But no, it was all there, just elegant and clear. All of the “meat” of the logic distilled to its essence, without any of the boilerplate. It was just that I had to learn all the “higher level” stuff around FP, but it turns out those things are shared and repeated in lots of places, so once you index it in your brain, you can read the business logic itself, without all the additional “fat” of the code. Simply beautiful.
TeMPOraL 6y ago
> Basically what I'm saying is, if functional programming is so great, why did LISP et al not take over the world? (Not a LISP hater, just curious). Because the two aren't the same. Sure, some of the functional programming techniques were invented or had one of their first implementations in early Lisps. But Lisp family isn't built around functional programming per se (particularly with two of the most popular Lisps today, Common Lisp and Emacs Lisp, being multiparadigm languages, with the former having an OOP model that puts everything else to shame). Lisp did take off, but then died in the early 90s because of AI winter, and in the meantime C took off. Lisp never recovered, but it lives on in a way, having invented and refined half of the techniques we use in programming languages today. (That's not to say Lisp is dead dead. Plenty of active development is going on. Scheme subfamily is alive and kicking, lots of code is being written in Emacs Lisp and Common Lisp too, and it shows up in many unexpected places. Hell, probably everyone at some point writes their half-baked, bug-ridden reimplementation of Lisp when they end up writing evaluators for XML or JSON.)
kazinator 6y ago
Computing happened in three main waves: the big iron wave, the minicomputer wave and the microcomputer wave. Each wave made computers cheaper and more affordable, but also, initially, substantially less powerful. At each wave, operating systems, languages and other software from the previous wave was not able to make the jump over. For instance, Multics didn't make it onto minicomputers, but some fellows who had worked with Multics created something scaled down to fit called, jokingly, Unix. Each wave opened up computing to more people, and most of those people were forever ignorant of the software that could only run on machines of the past, or institutional machines they couldn't personally afford. Lisp, being one of the oldest languages, belonged squarely to the first wave. It started small, but grew along with institutional hardware. By the time microcomputers came around, modern Lisp wouldn't fit. It took at least 15 years from the time computers became available and affordable to ordinary consumers to the time a fully featured Lisp would run on a computer affordable to the ordinary consumer. A whole generation of hackers had no experience with Lisp at all. Senior programmers who are now in their 50's might have started coding as kids on 8 bit micros, using BASIC (which was useless for non-toy applications and games) and assembler. Anyone younger than those people would be likewise Lisp ignorant. The result is that we have entire organizations, from very senior people on down, who don't know anything about any Lisp. There was some Lisp action on micros, but attempts to fit Lisp into those environments only harmed LIsp's reputation more than anything: the whole "interpreted, memory-hungry and slow" stereotype. One language which made the jump from minicomputers to micros was C. In the middle 1980s, micros were becoming about as powerful as 1970's minis, which played out very well for a language designed for efficiently programming 1970's minis. C had to make only a one-generation jump. There were companies selling Lisp machines in the 1980's, but these were expensive minicomputers. In this intervening time, minicomputers had become a lot more powerful, and so were able to run Lisp well. But the world had long moved on to microcomputers being the hot thing. Programmers were licking their lips at the prospects of making money in a large, consumer market. That included some Lisp programmers. Some of them hit a stark reality: they had to rewrite their code in something else, like C, to get it to run well on micros. A good case-in-point is the CLIPS system (https://en.wikipedia.org/wiki/CLIPS https://en.wikipedia.org/wiki/CLIPS). CLIPS is essentially a C clone of an earlier system called OPS5, that was written in Lisp. That is why CLIPS uses he Lisp-based surface syntax. That OPS5 was also rewritten away from Lisp, using Bliss. Lisp showed a resurgence in the 1990's, and one factor we have to thank for that is that consumer machines finally started showing memories measured in double digit megabytes and clock rates pushing past 100 MHz. Now, note how all the modern languages that borrow from Lisp are incredibly memory hungry. Javascript, Python, you name it; those things could not have ran on anything affordable in 1990. Not in their current form and the way they are used. In summary, there has been a recurring history in computing in several waves, each one representing a big regression in hardware capabilities, accompanied by a big jump in affordability. Each wave produced its own systems and languages due to the influx of new people not familiar with the older systems, and due to the older systems having specifications that would not fit. In each wave, there were some developments similar to what had occurred in the previous wave, but in new forms.
jcelerier 6y ago
> So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code. To give you my experience: during my phd, I developed https://ossia.io https://ossia.io in C++. For the manuscript redaction, I rewrote all the core algorithms in pure functional OCaml. When I did some tests, performance was slower than -O0 C++ (so it's not even a given that multithreaded OCaml would outperform single-thread C++), the tests weren't meaningfully simpler to write, and it would be pretty much impossible to have an average comp. sci. student contribute to the code. My experience multi-threading C++ code is, "slap cpp-taskflow, TBB, RaftLib" or any kind of threaded task system and enjoy arbitrary scaling. Hardly the pain it is made to be unless you have a need to go down to std::thread level, but even then using something like https://github.com/cameron314/concurrentqueue https://github.com/cameron314/concurrentqueue to communicate between threads makes things extremely painless.
pjmlp 6y ago
It did, just people are so focused on parenthesis that they loose focus of the remaining parts of Lisp's ideas. Guy Steele on Java: We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. https://lispers.org/ https://lispers.org/ Java and .NET, runtimes, languages and IDEs, share many ideas that trace back to Lisp and Lisp Machines/Interlisp-D. Python, Ruby, Julia do so as well.

mhh__ 6y ago

LISP and programming in a functional manner is comparing apples and oranges, surely?

ashton314 6y ago

Just some speculation, but one reason why C and friends took off better in enterprise domains is that they were on systems that people needed (C with Unix) or were more aggressively marketed. (Java) functional programming languages tended to not be as fast for single threaded programs compared to their imperative and object oriented counterparts. Now that we have stopped seeing such large gains in single thread and performance, most of our scaling comes from being able to scale horizontally. Functional programming languages are making a resurgence: the rise of Rust, Elixir, Scala, etc. is in response to this. I’m sure pg has plenty to say on the topic.

lalaithion 6y ago

Didn't LISP take over the world? Sure, not syntactically, but lambdas, complex expressions, garbage collection?

seer 6y ago

This is indeed a very interesting question! I’ve also asked myself that time and time again, along the path of slowly discovering what this FP thing is all about over the course of my career. It does look wonderful, it does save you a lot of effort in some cases, where “some” is a vast swathes of computational problems. And its so damn elegant. A lot of examples are thrown around were a bunch of lambda calculus can result in 10-20 fold reduction in source code size. So where’s the catch?There has to be something wrong right? Well recently I stumbled upon a clojure conf talk that tried to tackle precisely this question. https://youtu.be/QyJZzq0v7Z4 https://youtu.be/QyJZzq0v7Z4 The short of it is that its more of a historical inertia and chance than any specific hidden gotcha. Fascinating talk.

jahaja 6y ago
I'm sorry but this all strikes me as rather delusional. The reason why functional languages doesn't take off is because programming languages are tools, not an end in themselves. Carpenters that are obsessed with perfecting their power tools would rightly be out of a job in a very short amount of time. Furthermore most of these "perfections" aren't even virtuous - in the sense of searching for improvement - but just self-indulgence and aesthetics. Functional languages are dense, hard to read, have a high cognitive load, and are thus unproductive beyond the proverbial garage startup. They are also designed and used mostly by mentioned power tool decorators rather than practitioners, with the inevitable end result.
- discreteevent 6y ago
  "Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans
- seer 6y ago
  Totally understand the sentiment. I was very dismissive at first, as a self thought dev. Its really hard for me to learn something unless its helps directly to solve a concrete business problem I’m facing, so I know where you’re coming from. I think my epiphany was when I was trying to learn me some clojure on a couple of weeks sabbatical from work. As a mostly js/frontend/react dev at the time I was deep into React ecosystem for building SPAs. I knew and largely disliked the amount of code a redux based app would require in order to be “complete” with all the data fetching and state management (this was before hooks and contexts). And then I sew re-frame, that implements a lot of the features in that whole ecosystem, in like 100ish lines of code. Thats BS I told myself. Things are missing! It cannot be just this code in front of me. But no, it was all there, just elegant and clear. All of the “meat” of the logic distilled to its essence, without any of the boilerplate. It was just that I had to learn all the “higher level” stuff around FP, but it turns out those things are shared and repeated in lots of places, so once you index it in your brain, you can read the business logic itself, without all the additional “fat” of the code. Simply beautiful.

TeMPOraL 6y ago

> Basically what I'm saying is, if functional programming is so great, why did LISP et al not take over the world? (Not a LISP hater, just curious). Because the two aren't the same. Sure, some of the functional programming techniques were invented or had one of their first implementations in early Lisps. But Lisp family isn't built around functional programming per se (particularly with two of the most popular Lisps today, Common Lisp and Emacs Lisp, being multiparadigm languages, with the former having an OOP model that puts everything else to shame). Lisp did take off, but then died in the early 90s because of AI winter, and in the meantime C took off. Lisp never recovered, but it lives on in a way, having invented and refined half of the techniques we use in programming languages today. (That's not to say Lisp is dead dead. Plenty of active development is going on. Scheme subfamily is alive and kicking, lots of code is being written in Emacs Lisp and Common Lisp too, and it shows up in many unexpected places. Hell, probably everyone at some point writes their half-baked, bug-ridden reimplementation of Lisp when they end up writing evaluators for XML or JSON.)

kazinator 6y ago

Computing happened in three main waves: the big iron wave, the minicomputer wave and the microcomputer wave. Each wave made computers cheaper and more affordable, but also, initially, substantially less powerful. At each wave, operating systems, languages and other software from the previous wave was not able to make the jump over. For instance, Multics didn't make it onto minicomputers, but some fellows who had worked with Multics created something scaled down to fit called, jokingly, Unix. Each wave opened up computing to more people, and most of those people were forever ignorant of the software that could only run on machines of the past, or institutional machines they couldn't personally afford. Lisp, being one of the oldest languages, belonged squarely to the first wave. It started small, but grew along with institutional hardware. By the time microcomputers came around, modern Lisp wouldn't fit. It took at least 15 years from the time computers became available and affordable to ordinary consumers to the time a fully featured Lisp would run on a computer affordable to the ordinary consumer. A whole generation of hackers had no experience with Lisp at all. Senior programmers who are now in their 50's might have started coding as kids on 8 bit micros, using BASIC (which was useless for non-toy applications and games) and assembler. Anyone younger than those people would be likewise Lisp ignorant. The result is that we have entire organizations, from very senior people on down, who don't know anything about any Lisp. There was some Lisp action on micros, but attempts to fit Lisp into those environments only harmed LIsp's reputation more than anything: the whole "interpreted, memory-hungry and slow" stereotype. One language which made the jump from minicomputers to micros was C. In the middle 1980s, micros were becoming about as powerful as 1970's minis, which played out very well for a language designed for efficiently programming 1970's minis. C had to make only a one-generation jump. There were companies selling Lisp machines in the 1980's, but these were expensive minicomputers. In this intervening time, minicomputers had become a lot more powerful, and so were able to run Lisp well. But the world had long moved on to microcomputers being the hot thing. Programmers were licking their lips at the prospects of making money in a large, consumer market. That included some Lisp programmers. Some of them hit a stark reality: they had to rewrite their code in something else, like C, to get it to run well on micros. A good case-in-point is the CLIPS system (https://en.wikipedia.org/wiki/CLIPS https://en.wikipedia.org/wiki/CLIPS). CLIPS is essentially a C clone of an earlier system called OPS5, that was written in Lisp. That is why CLIPS uses he Lisp-based surface syntax. That OPS5 was also rewritten away from Lisp, using Bliss. Lisp showed a resurgence in the 1990's, and one factor we have to thank for that is that consumer machines finally started showing memories measured in double digit megabytes and clock rates pushing past 100 MHz. Now, note how all the modern languages that borrow from Lisp are incredibly memory hungry. Javascript, Python, you name it; those things could not have ran on anything affordable in 1990. Not in their current form and the way they are used. In summary, there has been a recurring history in computing in several waves, each one representing a big regression in hardware capabilities, accompanied by a big jump in affordability. Each wave produced its own systems and languages due to the influx of new people not familiar with the older systems, and due to the older systems having specifications that would not fit. In each wave, there were some developments similar to what had occurred in the previous wave, but in new forms.

jcelerier 6y ago

> So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code. To give you my experience: during my phd, I developed https://ossia.io https://ossia.io in C++. For the manuscript redaction, I rewrote all the core algorithms in pure functional OCaml. When I did some tests, performance was slower than -O0 C++ (so it's not even a given that multithreaded OCaml would outperform single-thread C++), the tests weren't meaningfully simpler to write, and it would be pretty much impossible to have an average comp. sci. student contribute to the code. My experience multi-threading C++ code is, "slap cpp-taskflow, TBB, RaftLib" or any kind of threaded task system and enjoy arbitrary scaling. Hardly the pain it is made to be unless you have a need to go down to std::thread level, but even then using something like https://github.com/cameron314/concurrentqueue https://github.com/cameron314/concurrentqueue to communicate between threads makes things extremely painless.

pjmlp 6y ago

It did, just people are so focused on parenthesis that they loose focus of the remaining parts of Lisp's ideas. Guy Steele on Java: We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. https://lispers.org/ https://lispers.org/ Java and .NET, runtimes, languages and IDEs, share many ideas that trace back to Lisp and Lisp Machines/Interlisp-D. Python, Ruby, Julia do so as well.