I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional.
I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well.
However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections)
I would like to refer people to the concept of Collection Oriented Programming. In this paradigm, application specify most of there operations as mapping and reducing functions across different collections (trees, vectors, lists, etc).
Not only does it promote safety, but it works in such high level constructs, it allows the compiler/interpreter to optimize the operation in many ways, such as optimizing out the lambda calls, and even parallelizing the operations.
To name a few Language+Libraries for which this is hugely successful: Ruby, Clojure, C++11 w/ std::algorithm, Scala, and Haskell, of course.
He isn't confusing the terms, he's just using the correct one.
Functional programming is about programming with functions - "Purely functional" is redundant. It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects. Languages which don't use functions are not functional - they would be best described as psuedo-functional, nearly-functional, or mostly-functional, as he uses in the article title.
The only reason we've had to invent new terms like "purely functional" is because the original term has been abused to mean what it never meant - it was used to describe psuedo-functional languages, so we needed a new term to distinguish the two.
> Functional programming is about programming with functions
Actually I think the etymology of "functional programming" comes for programming with functions as first-class objects. So a "functional programming language" is one that supports higher-order functions.
> It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects.
It also doesn't say anything about non-termination. If you want to program with mathematical functions I suggest you use something other than Haskell (e.g. Coq, Agda).
I disagree that '"Purely functional" is redundant'. You can have a functional language that still uses mutable state. Lisps are a good example. Pure functional implies no mutable state. Pure functional is the only way to safely achieve laziness. Which seems to be the author's thesis.
Well, from the parent poster's position, Lisps would not be "functional" - they'd be "pseudo" or "mostly" functional or something. Obviously this disagrees with common usage, but the expressed motivation "mutation disagrees with 'function' in mathematics" isn't crazy. I do think it's insufficient, however, in the face of common usage given that we've collectively chosen that "purely functional" should mean that.
I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional.
Indeed. The problem with many of his earlier examples isn't using closures, it's mixing laziness with side effects.
Some of his other implicit assumptions seem dubious as well. For example, in the printf formatting example, he refers to "optimizations as simple as common-subexpression elimination", but again, if your subexpression has side effects, eliminating the duplicate isn't an optimization, because it explicitly changes the behaviour.
In any case, his basic premise is flawed. If it's really true that "the slightest implicit imperative effect erases all the benefits of purity" then we'd better abandon Haskell, because even programmers of the grandfather of lazy functional languages occasionally sneak outside for an unsafePerformIO while no-one's looking.
I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well.
However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections)
I would like to refer people to the concept of Collection Oriented Programming. In this paradigm, application specify most of there operations as mapping and reducing functions across different collections (trees, vectors, lists, etc). Not only does it promote safety, but it works in such high level constructs, it allows the compiler/interpreter to optimize the operation in many ways, such as optimizing out the lambda calls, and even parallelizing the operations.
To name a few Language+Libraries for which this is hugely successful: Ruby, Clojure, C++11 w/ std::algorithm, Scala, and Haskell, of course.