Now, this and other articles about the difficulty of writing standard algorithms in functional languages makes me want to see FP's pitch be unbundled. The thing is that FP is pitched as a useful thing to learn to get an insight into programming, improve your mental fitness, see things at a higher level and so-forth. But it's also pitched as a way to be more productive and effective as a programmer. Effectively, it's sold as an exercise cycle and a real bicycle, a way to improve yourself and good way to get somewhere.
Now, I'll acknowledge that functional programming probably is great for the higher-level view of programming and such. But the challenges outlined in this article makes me doubtful fp is a productivity tool, a system which will allow some large number of programmers to make a large step in productivity.
I mean, if fp doesn't make simplistic programming faster and stands in the way of a large number of algorithmic approaches, it seems your productivity would consistently hobbled. Is there a counter-argument to this problem?
At the end of the day, you still write some stateful, imperative code.
It's just that your utility/work functions are pure, which means that you have predictable side-effects: you've stuck them all in one (imperative) place, or perhaps a couple places, but you're guaranteed to know where they are because the type system enforces notating which code has the ability to cause side effects. (Makes it easy to grep on type signatures, for example.)
Most of my workload is dominated by high level concerns: correctness, large-scale data flow, coordination of state, and security.
The purity of functions means that I explain all of the constraints/solutions of those problems in pieces, which I then compose with a clear data flow between them (since they can't have shared, mutable state), and only at the end, lift them to operate on the state of the system (in a stateful, imperative block).
This way of programming gives me much more confidence in replacing pieces of the code without worrying about the side effects, because the side effects are predictably related to that code.
At the end of the day, that predictability of side effects makes the majority of my work MUCH easier, even if it adds complexity to some low level data manipulation.
I easily write 10x the high level code I do low level code, so a 20% savings on that code, even if I double the complexity of low level code, is a net savings on my time/effort.
tl;dr: Functional programming is a productivity booster if most of your work is of a high level nature, even if it makes low level manipulations harder to do. Interfacing with low level imperative code can be (and is) regularly done, to get the best of both worlds.
This is certainly an intriguing answer, and makes me want to try Haskell sometime, but it also makes me wonder if I can't get the same benefits, with a little effort and discipline, in a "semi-functional" language such as something in the ML family or even (if I can live without static typing) Lisp.
In fact, I've always made a point, when working in a semi-functional language, of writing as much code functionally as possible. My experience is that it has the same benefits as you describe. So I don't know how much more there is to be gotten by actually switching to Haskell. My guess is, most of the additional benefit would come from the type system. But maybe I would be motivated to write even more code functionally.
All being a "functional language" means is that it's easy to write with a particular paradigm in the language.
You certainly can write similar code in ML, Java, or C - or whatever language strikes your fancy. It just helps when the type system is lined up with that goal, such as forcing you to denote where side-effects occur, and ensuring only functions that expect side-effect based code can operate on them. (For what it's worth, I've used both ML and Scheme to write similar style code as part of a programming languages class; and similarly, the C code I write relies on the functional ideas as much as possible.)
I just like the combination of Haskell's syntax and type system, so I prefer it to something like C (where functions aren't exactly a first class datatype, and the type system is somewhat weaker).
I just started to work with Haskell seriously, and after some trouble I discovered exactly the same development approach as DerpDerpDerp. However since I am not yet experienced I wish I had an "observer" to print debug messages (I know that there is a debugger in EclipseFP but I prefer Emacs for performance reasons). With observer I mean a compiler pragma that lets me print Haskell values without violating the functional nature of the code.
By the way, you don't need to live without static typing in Lisp. Shen provides a powerful type-safe layer on top of Lisp.
Many of the same effects can be obtained using even non-functional languages in a disciplined way. However, many of the best strategies and patterns for constructing pure, stateless software are enshrined in the Haskell standard libraries.
Once you learn the techniques and programming styles of Haskell, you can certainly apply those ideas elsewhere, but they lose a lot of their power when you (or another developer on the same code base) start "cheating".
It depends on your toolbox. FP (Haskell-FP anyway) appears at first to hobble a lot of mutable algorithms, but (a) it has its own toolbox which has its own strengths and (b) you can embed mutability in such a way to use all of your standard mutable algorithms just the same.
From a personal perspective, I program a lot in Haskell and I find it perfectly fluent.
Just don't expect to take an algorithm predicted on assumptions of a particular memory model and translate it unmodified without at least using the embedding trick I mentioned above.
---
Fortunately, you're in luck. The whole point of this series is to culminate in a description of the "embedding trick" I referenced above. Part 2 is written and being edited now. It introduces a slow, simple, buggy way of writing Union/Find "purely".
Part 3 will fix the bug and then explore a fast embedding trick.
When will Haskell have a standard library that provides fast embedding, so programmers don't have to resort to creative tricks to get working algorithms at readkanky
The standard counter-argument is that by enforcing purity, Haskell improves encapsulation and the ability to reason about the program (see paeans about equational reasoning [1]), and prevents all the myriad classes of bugs associated with mutable state - thus greatly improving productivity. (The same applies to its more precise type system in general.) I'm not sure how much I believe it, but some people swear by it...
Now, this and other articles about the difficulty of writing standard algorithms in functional languages makes me want to see FP's pitch be unbundled. The thing is that FP is pitched as a useful thing to learn to get an insight into programming, improve your mental fitness, see things at a higher level and so-forth. But it's also pitched as a way to be more productive and effective as a programmer. Effectively, it's sold as an exercise cycle and a real bicycle, a way to improve yourself and good way to get somewhere.
Now, I'll acknowledge that functional programming probably is great for the higher-level view of programming and such. But the challenges outlined in this article makes me doubtful fp is a productivity tool, a system which will allow some large number of programmers to make a large step in productivity.
I mean, if fp doesn't make simplistic programming faster and stands in the way of a large number of algorithmic approaches, it seems your productivity would consistently hobbled. Is there a counter-argument to this problem?