I don't find the satirical framing particularly constructive. I feel like a lot of people are going to miss the point, and the article wastes a lot of words just keeping up the pretense.
I do wonder though, why functional programming hasn't taken off in a bigger way? Languages like F# are certainly very good, but their usage remains fairly small, what do they lack that would allow them to take off? Or is it a problem with too few programmers being trained in functional and not being comfortable with it?
It's like the "what have the Romans ever done for us" Monty Python skit.
Unless I'm mistaken, garbage collection, types, typeclasses, polymorphism, option-types, lambdas, REPLs etc. all debuted in functional languages.
It could be argued that garbage collection, polymorphism, lambdas, and REPLs were semi-mainstreamed by Smalltalk. That's not to say that it was the first appearance of those features. However, it was a big incursion into mainstream awareness. In 2019, all of those things are squarely mainstream. In the 1990's, lots of programmers regarded them akin to "woo."
It was explored briefly in the early '90s at IBM (Hi, OS/2 Workplace Shell!), but the general consensus before the project was cancelled was to go with C/C++. I suppose education also saw some use, but various Lisps have most, if not all, of the above features and much more mainstream use in the '80s.
This is the first time I've heard that, do you have a source?
This is very widely known inside the language community and beyond. It's mentioned in many keynotes and talks by Alan Kay and others. You can go to the Wikipedia page and search for "children"
In one keynote talk, Alan Kay stated that the design goal was to create a common programming substrate usable by everyone, from children, to hobbyists, to enterprise programmers, to researchers. Arguably, they succeeded.
IMHO, it's harder to read. I love the idea of Erlang (really like Joe Armstrong's book) but it just isn't readable in quantity compared to OOP languages, IMHO.
> functional programming ... is based on mathematics
Can we stop with this nonsense? I don't even know what "based on mathematics" means. All programming languages are formal languages, and all formal languages are inspired by mathematics in their design, and we can use mathematical reasoning to reason about them (although the form of mathematical reasoning can differ; pure FP strives to use equational reasoning, while imperative code uses assertional reasoning). While it is true that functional programs bear more resemblance to mathematical notation than imperative programs, but the majority of elementary mathematics cannot be directly expressed in FP in a similar notation -- or in any programming language with some computational complexity features (in the computational, "executable" part of the language; it can be expressed in the specification part, like a type system or a contract system).
E.g. x + 4 = 5 cannot be directly expressed in the computational part of the language, let alone f(x) = 5. Nothing that's nondeterministic can be expressed, either, such as x < 10, or x > y. Some of those can be expressed in logic programming (so it's even more "based on mathematics" than FP!), but at a cost in computational complexity.
But while glibly dismissing silly strawman arguments (which, I assume, some do make), the author contributes some silly claims of his own. For example:
> This has [the] consequence of reducing complexity, and thus reducing the number of bugs.
So, seeing as the author is so interested in precision and mathematics, I'd like to enquire where he pulled this fact from. But let me put this more generally: if pure functional programming has such obvious huge advantages over OOP with a big, real, impact and all, then a curious person with a scientific mind would ask what is the average difference in cost/quality that a company should expect when switching to pure FP? This should be a very easy question, because clear, obvious, large effects are easy to find (in fact, they're hard to hide) even over small samples. If a prediction of an easily observable effect does not turn out an easily observable effect, could there be something wrong with the hypothesis? And if the hypothesis makes a prediction of an effect that is hard to observe in practice, is it really so clear and obvious?
You are correct that the semantics (meaning) of subroutines in pure functional languages resembles mathematical functions more than their semantics in imperative languages (which is a different mathematical object [1]). But so what?
> I don't even know what "based on mathematics" means.
Sure - it's too broad to be a useful definition. Perhaps it would be better to say "based on mathematical functions". Function outputs depend only on their inputs. So you can take f(x) == f(x) as true.
> Nothing that's nondeterministic can be expressed
Sweet! This way my production code can do the same thing as my test code. My job is to know what my code will do. I'll take all the determinism I can get.
> Perhaps it would be better to say "based on mathematical functions"
OK, and imperative code is "based on mathematical predicate transformers." My point is that some FP advocates use the "based on mathematics" as some marketing tagline that mostly shows they understand neither mathematics nor FP.
> Sweet! This way my production code can do the same thing as my test code. My job is to know what my code will do. I'll take all the determinism I can get.
That wasn't my point. The expression x ∈ ℕ ∧ x > 10 ∧ x < 12 is perfectly deterministic, but because its components are nondeterministic it cannot be expressed in FP, even though it is very convenient to do so (and commonly done in mathematics).
> We do not attach any character of uniqueness or absolute truth to any particular system of logic. The entities of formal logic are abstractions, invented because of their use in describing and systematizing facts of experience or observation, and their properties, determined in rough outline by this intended use, depend for their exact character on the arbitrary choice of the inventor.
That's the American logician Alonzo Church (1903-1995) in his 1932 paper, A Set of Postulates for the Foundation of Logic, in which he expresses his disagreement with Wadler and also invents the (untyped) lambda calculus [1]. You can find this passage and many more in a 300-page anthology of (mostly) primary sources that I composed over a year ago [2], many of them describing the meticulous, intentional invention of various formalisms over the centuries, as well as aesthetic concerns which have led some to prefer one formalism over another (e.g. the invention of a logical algebra by Boole, and its later amendment into what we know as the Boolean algebra, by Jevons, Peirce and Schröder to make it more pleasing). In fact, Alan Turing's 1937 paper directly demonstrates the essence of computation and the "accident" of formalisms, which are linguistic, aesthetic, subjective formulations of a fundamental, non-linguistic idea (as Gödel said, when he called Turing's discovery a miracle, it does not just show that one formalism is equivalent to another, but uncovering the essence of all formalisms at once).
Wadler is not an authority on the history of logic, and his perspective (which, unlike his actual academic work, is not based on serious scholarship), combined with his guru stance, is one of the causes for the deep confusion among functional programmers about FP and mathematics, and fosters a mystical adoration of mathematics, one of whose symptoms are nonsensical statements like "based on mathematics," rather than understanding. I wish he'd stop doing that, as I don't think it's helpful.
[1]: In that paper the lambda calculus appears as a proof calculus for a logic that was later proven unsound. The calculus itself was then extracted and used in Church's more famous 1936 paper, An Unsolvable Problem of Elementary Number Theory in an almost-successful attempt to describe the essence of computation. That feat was finally achieved by Turing a few months later.
This feels very much like the author tried to use functional programming to solve a particular problem, got bit by it, and is now raging that the tool is broken.
I'm not in favor of functional programming everywhere, but it's a valid tool in the toolbox.
It's clear, but it's not immediately clear. You have to read a substantial amount of the article before it becomes clear, because the author starts with very little indication of it satirical. I found myself starting from the premise that it was in earnest and only realized it was satirical about 1/3 of the way through. Until that point I had a mental checklist of things I disagreed with, beginning with the phrase "expected amount of embedded abstractions".
Come to think of it, it's really an excellent example of effective satire, and these comments are an illustration of Poe's Law.
The article even claims, highlighted in the article, "It is obvious that so-called “functional” programming is flawed, it makes redundant things like refactoring and unit testing unnecessarily easy". If you are not capable of judging it as blatant sarcasm, I would in fact call you incompetent.
I doubt that is the problem. I think most people didn't read long enough for the sarcasm to be obvious and then wrote their comments as if they had read it all, despite probably not making it longer than the first paragraph. That might not be incompetent, but it is at least intellectually dishonest.
Or, more likely, it just surfaced that a lot of us skim articles. It is clear, but really only about halfway through the article itself (which isn’t a very good statement on the article getting its message across, to be honest)
> Either it's not clear, or you're implying that multiple commenters here are in some way incompetent.
Reading comprehension—especially deciding if something is satire or not—is a common problem on HN. I wouldn't classify that as incompetence, but it is an issue.
The article is satire, but I have some observations of and questions about FP. It seems like every FP programming environment develops objects of some kind. React/JSX has classes. Clojure has a few ways to use Java classes. Monads seem to be wrappers at some level. Then, you have environments which are explicitly "hybrids" between OO and FP, like Scala and MOP in Common Lisp.
The whole world seems to be converging on the usefulness of immutability, and this process started decades back. Also going decades back, at least as far as the 90's, Smalltalk folks recognized that a lot of the goodness in the class library and environment came from the majority of class library functions being pure, or the encapsulation allowing programmers think about them as if they were pure.
Would it be going too far to observe that programming is generally converging on pragmatic, mixed environments where the value of immutability and referential transparency is emphasized, but where encapsulation of state is also used? This is not absolutely true 100% across the board, but it seems to be one of the larger scale trends.
I have used Scala quite a bit, and I do feel it does a few things better than Java.
That said, I really dislike the 'best-of-both-worlds' argument for mixing OO and FP.
Immutability is fantastic. If you are sitting in OO land, and someone gives you a library for immutable collections - great! But if you're already practicing immutability, and someone starts modifying your stuff, what is to be gained?
It's the same story with null. I finally got rid of that - why would I want to become 'pragmatic' and get null back?
That said, I really dislike the 'best-of-both-worlds' argument for mixing OO and FP.
I'm not making that argument. I'm making the observation that over time, upon collision with the enterprise or real world, all Functional Programming environments seem to develop OO features, and most Object Oriented environments either have or embrace FP features.
It's the same story with null. I finally got rid of that - why would I want to become 'pragmatic' and get null back?
I think it's possible to get rid of null. However, I don't think it's possible to get rid of Objects in FP. They always seem to return in some form, disguised by nifty and abstruse terminology and mechanisms. It's not some rosy "best of both worlds" situation. It's more or a realist, well, I guess we're stuck with things from here and there.
Despite the "almost a field" having its disfunctions, three decades of programming language history and the efforts of countless geniuses likely means something, and this pattern of OO environments gaining FP features, and FP environments gaining (perhaps disguised) Objects persists across that.
I have not come across objects in FP - aside from those languages which advertise themselves as hybrid.
clarification: the term 'object' comes up in reference to category theory, but it's meaning may as well be 'anything'. Completely different from the association of data and methods.
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures.
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
> So-called “functional” programming has no proper mechanism of abstraction since it is based on mathematics (which obviously is inferior and has no applications in the real world apart from academia).
It’s tough to read on after that.
Edit: Okay, I missed the irony that becomes clear later on.
Wouldn't a enterprise developer store pricing information in a database, rather than hardcoding it, whether it is hardcoded into functional or OO software?
If I hadn't skipped the middle part and read the ending, I might never have known. I think the author is losing a lot of readers before the satire becomes apparent.
I do wonder though, why functional programming hasn't taken off in a bigger way? Languages like F# are certainly very good, but their usage remains fairly small, what do they lack that would allow them to take off? Or is it a problem with too few programmers being trained in functional and not being comfortable with it?