This is an interesting article, but the reasoning for why functional programming isn’t worked out fully. While a person who already likes FP may not notice, people who don’t are likely to be confused. In the “Functional programming to the rescue!” portion, he gives a simple example that assigns the results of inputting x into function f into the new “variable” (although it’s not actually variable, and so another name would be more appropriate) y. Then he jumps to say that because we can make some basic assumptions about this assignment all of our systems are inherently more understandable. But this is merely offered as a statement, and not actually proven or even shown with any particular care.
If people are going to be convinced to take up FP in the style of languages like Haskell, ML, F#, and the like, then several issues must be solved:
We must stop pretending (and the FP community perpetuates this to some degree) that FP is hard, that it’s mathematical, and that it’s academic.
The main thing going through my head when I read the “common objections” section was that it’s difficult to blame “outsiders” for being intimidated since seasoned FP hackers often contribute a great deal to this aura of extreme cleverness. Certain FP languages especially tend to attract people who are out to prove how smart they are, which obviously has implications for the wider perception of the language that may not have much to do with the language itself.
Interesting, but the Java example is a caricature, and no functional equivalent example is provided for comparison.
If you’re curious about what people are up to in the FP world, you should learn Haskell. I used to be a Clojure and Common Lisp user, not going to get expose to the full breadth and depth of how far the field has come outside of Haskell.
Yes, I know that Haskell is probably the best candidate to learn FP nowadays. Thanks for the advice.
Can you delve deeper into learning Haskell vs. Clojure? I’m currently learning Clojure (http://www.braveclojure.com/) but would be willing to switch to Haskell given a good reason.
I do Clojure for a living. Don’t bother with Clojure - go straight to Haskell.
Your blurb at the end of this article helped a lot. Thanks :).
Here’s a question about that, though. (I learned Haskell about a decade ago and have dabbled since, and it’s really cool. I just picked up Clojure because Ruby’s DSL for Storm was a flustercluck and have been writing topologies in Storm using Clojure for a couple months.)
Are you recommending not learning Clojure for the educational experience of Haskell, or the practical?
If the latter, what about all the aspects of writing in a programming language that aren’t code?
Clojure doesn’t feel very mind-expanding to me; it just feels like Java with lambdas and parentheses and a much harder work ethic. Whereas I feel like I learn a lot writing Haskell.
But if I need to use any of a thousand Java libraries I can, and leiningen makes it super easy to import any library in Maven. And the usage of the more popular libraries means that other people may have run into similar bugs or limitations, which makes writing code that much easier. Also, the interop with Java (from pulling in maven packages to the FFI to and from Java) feels really seamless, in a way that Haskell’s FFI interop with arbitrary C code somewhere has never seemed.
I’d be interested to hear your thoughts
Those are part of the reasons I favor Haskell. The code isn’t the only reason that it’s delightful.
But if I need to use any of a thousand Java libraries I can, and leiningen makes it super easy to import any library in Maven.
You don’t need a thousand Java libraries. It’s highly unlikely you’re boiling the ocean. I’ve heard this stuff 40 times time before. If you have a specific dependency you’re worried about not existing, say so. Otherwise, you’re subjecting yourself to FUD. :)
Also, the interop with Java (from pulling in maven packages to the FFI to and from Java) feels really seamless, in a way that Haskell’s FFI interop with arbitrary C code somewhere has never seemed.
C FFI in Haskell has seemed fine to me, but I guess if you’re not used to C that would do it.
I don’t consider FFI to Java a plus because I don’t need or want Java. It doesn’t do anything I couldn’t do better in Haskell. Whereas, C lets me do things I wouldn’t otherwise be able to do. That said, I never actually need the FFI. Pure Haskell is all I’ve needed.
I made a distributed k-ordered unique id service named Blacktip quite fast (faster than the original Flake by ~2x) just with simple, pure Haskell. If I wanted to push things a bit I might make some C wrappers for lower level APIs, but it’d be pretty minimal.
If the last time you poked at Haskell was a decade ago and all you did was dabble, you need to learn Haskell.
I’ve done a lot of Clojure and have moved over all my work to Haskell post-haste.
Here’s my guide for learning Haskell: https://github.com/bitemyapp/learnhaskell
Just learn both; Clojure is a pretty cool, fun and useful language; certainly worth learning! Haskell has some more in-depth type theory stuff; but well over half the fun of that requires you to care a far bit about type theory. Which is fun; but is maybe not the whole point of programming :)
(I quite like both languages, and would be very happy to know them both well.)
Haskell has some more in-depth type theory stuff; but well over half the fun of that requires you to care a far bit about type theory.
What? No. I don’t know crap about type-theory and I’m way happier using Haskell.
You are encouraging people to impoverish themselves. :\
I honestly don’t understand how your response is related to what I said …; did you read what I wrote?
I got the feeling you were implying Haskell would be less fun than Clojure if you didn’t care deeply about type theory.
I guess I was saying that; but I was trying to say “Half the fun of haskell is caring a lot about types and type theory, and that’s not for everyone, and maybe isn’t even the whole point of programming”.
That’s good to know. :)
I work at a (mostly) Rails startup but I’ve been dipping my toes into a few other languages that are faster so I can bring something valuable to the table. Elixir, Clojure, and Go are languages I’ve had my eyes on but Haskell has an advantage over the other functional languages in that it compiles to machine code.
They all have advantages and disadvantages. Do whatever seems the most fun and relevant for you :)
Definitely a great perspective. However I don’t think the “complexity” discussion was carried out correctly. Functional programming tends to name-drop a lot of mathematical concepts from category theory and whatnot. Sure, monads are simple, but few people can explain them simply - therefore they’re complex. The fear of math is the real reason why FP isn’t more popular.
I think the author takes an unnecessary diversion into questions of status like talking about “average programmers”. I think the real question is how much mental effort different paradigms require.
My personal experience with functional programming is that it produces nice, clean solutions but that it takes more mental work than imperative programming. If it takes 50% longer to come up with a functional solution - irrespective of the programmer’s individual skill level - then that’s a significant cost. In the end I find that I’m significantly more productive with (say) Go than Haskell and solutions present a smaller cognitive barrier.
Producing an actual solution is only a small portion of the total cost of ownership though. Code that took a month to write may need to be maintained for a decade. IME, this is where ‘FP’ shines. Depending on what you mean by FP. For myself it tends to revolve around separation of state. I don’t use Haskell but less pure languages like Ocaml and Erlang, but even in those languages immutability is the default. The value being your understanding of the system can be localized to the specific portion of code you’re reading. Since Ocaml and Erlang do not enforce this, it does come down to convention a bit with those languages, but they make it much easier than say, in Java, where working with immutable data is awkward.
I work on a project right now that is in Erlang. We have designed it using a set of well defined components that are composable. While this is possible in imperative languages, it’s harder. IME, most of the Go code I have read suffers from this. It’s hard to know where changes to the state of the program might come in because they can, and do, happen anywhere.