> As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.
Questions like this, although very interesting, just don’t fit the Q&A format they are promoting, where they aim to be free of debate and opinion.
I totally agree. Probably a third of the useful answers I've gotten from SO have been cases where I asked Google, Google said "yes, StackOverflow has an answer to your exact question", and I am delighted to see that someone helpful and knowledgeable somehow managed to get the answer out before the guards swarmed in and demanded an end to all that forbidden usefulness.
The most involved part of a CRUD app is writing data and checks around it. This "checking" part can be written with little interaction to the outside world.
I like how Paul Chiusano answered the main question:
"If Haskell (or XYZ) is so great, why hasn’t it taken over?"
"The simplest explanation is probably that Haskell is not that much better than, say, Java,"
"for many of the software systems people write today."
I've never really thought about it quite this way before, but: pure functional systems basically want to ignore time. In some contexts this is ok or even desirable, but in other contexts it is counterproductive and futile.
Time is pretty critical to physical reality, one way or another, and the closer you get to it with lower and lower-level language systems, the harder it is to ignore.
It seems to me there needs to be some very basic computational/mathematical theory that integrates time more fundamentally into language/instructional design without being procedural per se. There probably is one but I don't know what it is, or am not recognizing it for what it is.
There are many buzzwords in the programming profession. These terms are bandied about with great regularity, and mean almost nothing. Fundamentally, we only have one kind of computer with two variations: the Intel and ARM instruction sets which drive 99.9% of all computers used today. Everything on top of these two hardware platforms is software, and since the hardware's only commonly used instructions are arithmetic, copy, load/store, compare, branch and call/return, the most powerful instruction is the function call and return, and every language from Assembler onward has striven to wring as much utility out of the call/return instruction. Functional programming is where you try to give functions more weight, as opposed to the move instruction which was COBOL's stock in trade. So one cannot be against functions, it is one of the only power tools we have. What i am against is waving these banners around, like OOP, Functional Programming, Top Down Design, etc., when what we really want is reliable software that is easy to understand. We are evolving towards better notations, but unless you change the hardware (and adding more cores does very little to help) you are pretending these terms actually mean something.
I think making arguments about programming languages fitting the hardware to explain their popularity doesn't make much sense outside of high performance or low level system programming. The obvious counterexample is languages with garbage collection, which is enormously popular (e.g. Github's five most popular languages by repository employ garbage collection: https://githut.info/ ). Another popular feature is dynamic type systems.
The elephant in the room of functional languages is that they all, somehow, fundamentally depend on garbage collected memory management. This GC is never coded in the functional language itself. Why? Because functional languages are very, very bad at resource management.
Real programs typically need to manage resources besides memory. So, they look good depending on GC for toy problems, but fail to graduate from their sandbox.
The only powerful languages not dependent on GC are C++ and Rust. They have facilities to manage any resources needed, and that are equally adept at managing memory.
As a consequence, it is possible to write libraries for these languages that can work in any program.
Programs in obligate-GC languages always need to compromise some aspect of GC to be practical, but that makes them incompatible with the majority of libraries. Thus, you don't see good library ecosystems grow up around them.
A functional language that did not depend on GC could be useful, but academics would kneecap it immediately. Academia absolute detests the idea of non-obligate-GC languages, for purely tribal reasons.
12 comments
[ 2.9 ms ] story [ 37.2 ms ] threadIn fact, most of the time I encounter one of these closed questions, it was precisely the question I was curious about.
I just don’t understand why they do this.
> As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.
Questions like this, although very interesting, just don’t fit the Q&A format they are promoting, where they aim to be free of debate and opinion.
What a ridiculous, hostile system.
Whereas "straight-forward CRUD app" is more about interacting with the outside world, which is harder to do in Haskell compared to, say, Go.
HN discussions 2018 https://news.ycombinator.com/item?id=17114308 2017 https://news.ycombinator.com/item?id=13450828
Time is pretty critical to physical reality, one way or another, and the closer you get to it with lower and lower-level language systems, the harder it is to ignore.
It seems to me there needs to be some very basic computational/mathematical theory that integrates time more fundamentally into language/instructional design without being procedural per se. There probably is one but I don't know what it is, or am not recognizing it for what it is.
Real programs typically need to manage resources besides memory. So, they look good depending on GC for toy problems, but fail to graduate from their sandbox.
The only powerful languages not dependent on GC are C++ and Rust. They have facilities to manage any resources needed, and that are equally adept at managing memory.
As a consequence, it is possible to write libraries for these languages that can work in any program.
Programs in obligate-GC languages always need to compromise some aspect of GC to be practical, but that makes them incompatible with the majority of libraries. Thus, you don't see good library ecosystems grow up around them.
A functional language that did not depend on GC could be useful, but academics would kneecap it immediately. Academia absolute detests the idea of non-obligate-GC languages, for purely tribal reasons.