Pages

Wednesday, November 11, 2009

Functional Programming

I know this is old news, but it's new to me. I've been thinking about an article by Paul Graham which is basically about how functional languages are superior to OOP and other imperative languages, and languages are shifting towards functional programming in general, and LISP in particular. I disagree on both counts. Ignoring the fact that whether its right or not, OOP isn't going away any time soon, I think that there are certainly problems that are better suited to that paradigm, but there are many problems that are not. This is a good part of the reason that we see more multi-paradigm languages that pure languages.

I specifically object to the example he chose to demonstrate the 'power' of Lisp. He chooses a problem that Lisp and similar languages are naturally going to win. He wants to return a method that is an incrementer as the result. Its going to be ugly in any language where methods are not first class objects.

He also claims that design patterns exist to make up for shortcomings in a language. There is a related question on StackOverflow. The study referenced there states that 7 of the 23 patterns in the GoF still applied in functional languages. Even Lisp is not a purely functional language and needs what can be regarded as a design pattern (Monad) to allow for something stateful (like IO). (When was the last time you wrote a program that didn't use some kind of IO?).

Languages are not becoming more and more like Lisp, though many of them did borrow some concepts from Lisp. One of the main reasons for this is that Lisp was one of the first high level languages (even before C). Yes, things like garbage collection, dynamic typing, and recursion were initially eschewed by the programming community only to be later made mainstream. This is for reasons of computing power rather than a sudden realization that Lisp had it right all along. Paul Prescod talks about how Python isn't moving towards Lisp and how many former Lispers have adopted Python. I think Paul's statements stem from having sour grapes over the lack of success of his pet language more than historical fact.

That being said, Java certainly isn't perfect and has been constrained by Sun's unwillingness to break compatibility to add new features. Wouldn't it be better to say languages like Java could benefit from some additional Lisp-like options, such as lamda (available as closures in groovy) and first class methods (available in Scala) rather than immature statements like Lisp >> Java? While I agree that there might be a place for a language that keeps things simple to help curb mistakes, I would rather see greater flexibility and choice given to empower the programmer, allowing for whatever style best suites the problem at hand. Some problems lend themselves to functional programming, and some problems are stateful in their very nature. I find OOP easier to think in, because we fairly naturally think of things as interactions of systems. Though, this is perhaps overused currently in our industry for problems it shouldn't be used to tackle.
For this reason, I would like to study and work with functional languages more than I currently am to recognize and take advantage of those situations in which functional languages are the right choice (assuming the decision is up to me).

On a related note, the Computer Language Benchmarks Game is also good fun, for those who find religious wars amusing. 99 bottles of beer is also an interesting reference. It is programs that print the lyrics to the song 99 bottles of beer, in many languages. (check out an Erlang version, Lisp version, and a Java version).

Related links
http://norvig.com/design-patterns/
http://www.norvig.com/lisp_talk_final.htm
http://www.norvig.com/python-lisp.html
http://www.paulgraham.com/power.html

Something unrelated, but funny
http://www.willamette.edu/~fruehr/haskell/evolution.html

No comments:

Post a Comment