Re: Language Purity and Dirty and Clean Functions
Posted: Jun 27, 2006 9:36 AM
I apologise for playing the devil's advocate, but in my opinion there are certain things that need to be said about FP.
The so called 'cleaness' of a language from side effects does not offer any practical benefits in real coding environments. Everybody is saying how pure functional programming is so much better, but I disagree, and I have a lot of reasons to:
1) the so-called "side effects" are there nevertheless, even if one codes in a pure functional language. While in imperative languages an erroneous side effect is immediately visible at its creation point, in FP the side effect is activated in a much different context and therefore it is a much harder error to find.
For example, let's say the following imperative code is an error:
object1 = data.get("foo");
It is an error because 'object1' is not the proper object to add to the list.
Let's reproduce the effect in some pseudo-FP:
let object1 = map data findObject
object1 :: list1
In this purely functional example, 'object1' is added in a list. There is no side effect error, but the program enters an invalid state.
In FP, this sort of error is very hard to detect by a programmer, because the effect of using 'object1' may come much later, usually at a top-level loop which is a monad that manipulates state.
2) it is a myth that 'order of operations' does not matter in pure functional languages. In order to validate an algorithm in ones mind, even if there is no assignment in it, the correct order of operations must be respected. The cause always comes before the effect, and one has to take that into account.
3) The phrase "pure FP programs are easier to reason about" is a catch-all phrase that I have heard many times...but what does it mean? are programs easier to reason from the perspective of the programmer or the compiler? and does the ease come from the type system or from the purity? I do not believe pure FP programs are easier to reason about. Take Haskell, for example, and remove its purity, i.e. allow assignment...then apply SSA to the compiler and the result is the same.
4) "Pure programs are easier to optimize". Yet no purely written program can reach the overall performance of C/C++. Isn't C/C++ supposed to be more difficult to optimize?
I think the importance of pure functional programming languages is overestimated. They are good from an academic point of view, or for bridging together already written components, but not for anything else. And before someone posts a list of 'successful real world projects written with Haskell', I would like to explain myself: there are programs which are mainly computations and transformations, like compilers, CVS systems, etc, and there are programs which are event-driven state machines with a lot of state in it. Pure FP programmers have a very great difficulty for doing the latter style of programs...it's not entirely undoable, but one has to twist his/her brain around the concepts. Since programming is more about commodity and less about science, pure FPs will never catch on.
Ultimately, the constraint for proving a program as correct is nature itself: no language can solve the halting problem (even if the language is a purely FP one), and therefore correctness of a program is always subject to the programmer's ability to run the program in his/her head.
And something else I would like to add about functional programming: the one and only characteristic that makes functional programming different from imperative programming is the "side effects not allowed" principle. Take that way, and all other features of functional programming languages can happily exist within an imperative language. Therefore languages should not be divided into 'functional' and 'imperative', but rather to 'pure' and 'dirty', i.e. the ones that allow side effects and the ones that do not allow side effects.
Programmers need other kinds of facilities in order to speed up development and increase correctness. Instead of twisting our brains around monads, we need imperative languages that allow better abstractions to exist and less things to type...