
Functional Programming? Don’t Even Bother, It’s a Silly Toy - michaelchisari
https://medium.com/better-programming/fp-toy-7f52ea0a947e
======
Someone1234
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?

~~~
mrkeen
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.

~~~
stcredzero
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."

~~~
mcguire
Was Smalltalk ever mainstream?

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.

~~~
stcredzero
_Was Smalltalk ever mainstream?_

I'd say mainstream adjacent, like Lisp. There was once 80% penetration into
the Fortune 500.

 _various Lisps have most, if not all, of the above features and much more
mainstream use in the '80s._

One could argue that Smalltalk was designed in part to be a "Lisp for
children." So of course, Lisps already had those features.

~~~
futureastronaut
> One could argue that Smalltalk was designed in part to be a "Lisp for
> children."

This is the first time I've heard that, do you have a source?

~~~
stcredzero
_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"

[https://en.wikipedia.org/wiki/Smalltalk](https://en.wikipedia.org/wiki/Smalltalk)

Also, there's this article. Search for "children"

[http://worrydream.com/EarlyHistoryOfSmalltalk/#smalltalkAndC...](http://worrydream.com/EarlyHistoryOfSmalltalk/#smalltalkAndChildren)

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.

~~~
futureastronaut
I'm aware of Smalltalk being promoted in educational settings. What I wanted
to know more about was "Lisp for children" which I've never heard before.

~~~
lispm
Yes, sounds strange. Actually the programming language LOGO would be that:
LISP for children.

------
pron
> 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?

~~~
mrkeen
But that's precisely the point of functions (not methods, not procedures).

~~~
AnimalMuppet
Could you be a bit more specific here? So far, your statement seems like a
complete non sequitur.

~~~
mrkeen
absolutely!

> 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.

~~~
pron
> 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).

------
bovermyer
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.

~~~
icedchai
I assumed the article was satire. The OOP solution is overly complex garbage
compared to the simplicity of the functional solution.

~~~
jcadam
The author also states that the post is satire if you make it to the end.

~~~
icedchai
Never made it that far. It was obvious from the excessively verbose code.

------
mrkeen
This is at least the third sarcastic take on FP vs OO that I've seen, and
possibly the worst.

It's hard enough to communicate the differences without crap like this in the
mix.

edit: The two posts before did not pick up on the sarcasm.

~~~
human20190310
The irony is that the author's satire of object-oriented verbosity is itself
so verbose that the point gets lost in all the words.

------
stcredzero
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.

~~~
mrkeen
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?

~~~
stcredzero
_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.

~~~
mrkeen
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.

~~~
pepper_sauce
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.

[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg03277.html)

------
carti
> I have personally taught a few junior developers functional programming in
> JavaScript, and they became really good at it in about half a year.

If only...

------
lixtra
> 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.

~~~
girvo
Though if you do, it becomes clearer that it’s rather heavy-handed satire, I
think. And it loses a lot because of it, sadly. Oh well

------
splodge
Wouldn't a enterprise developer store pricing information in a database,
rather than hardcoding it, whether it is hardcoded into functional or OO
software?

------
MattBearman
I'm thinking this could do with a [satire] tag :)

~~~
human20190310
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.

------
phkahler
Seems more anti-OOP than pro-functional.

------
blikdak
Lols, thought it was serious at first, because enterprise.

------
smitty1e
This was Inversion Of Control applied to an essay.

------
juliangoldsmith
Tell that to Paul Graham.

