Friday, July 13, 2007

Why Functional Programming Languages Fail

I've recently been dabbling in Haskel. Its a purely functional programming language and I have to say that its pretty cool. I've also messed around with SMLNJ in college and enjoyed it.

The proponents of functional programming languages always say that they are easier to program in, more concise, and are less prone to errors. The detractors always say that they're slow. In response to that proponents of functional programming languages say they aren't that much slower and that most people don't care about performance anyway.

So why isn't everyone programming in a functional language?

My theory is that the proponents of functional languages have their heads up their academic asses. Everyone writing interesting and marketable code cares about performance. Why do you think Intel and AMD make so much money selling the latest and greatest silicon? Could you imagine implementing OpenGL, a JVM, a JIT, or a graphics library in a functional programming language? It would be unbearably slow.

Some argue that if you try hard enough, you can get Haskel to run just as fast as C. They are probably right. But I would bet that its easier to write really fast C code than it is to write really fast Haskel code.

Also with the advent of quality static analysis (which in a couple years I believe will be the default) many of the benefits of a functional programming language can also be found in C/C++.

For everyone else who isn't writing interesting or marketable code, there are languages like Python and Visual Basic. People who write in this straitforward and simple languages prefer very simple languges. Its much easier to understand 'if' and 'for' statements (and also structs and classes) than it is to understand foldr, monads, and polymorphism.

Today we're not programming in Haskel because most of us care about performance, and those who don't prefer easy scripting languages.

3 comments:

DiscĂ­pulo do Vazio said...

I think you should see the following video, with the father of C#, about the next big thing from Microsoft(LINQ). I think functional programming will catch you on your sleep.

http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx

enjoy

Michael said...

I just watched that video.... LINQ is pretty cool. But its nothing like Haskel. It only borrows some of the ideas of functional programming and adds some syntactic sugar.

DiscĂ­pulo do Vazio said...

Well, I'm a Java programmer in my work time, and some of the things that I know so far are:

1. Programmer time is more valuable than Computer time;

2. With the multicore processors, efficient threading is crucial to use them, and the answer to solve that is: functional languages, that have no side effects.

3. All major languages are incorporating more and more functional capabilities.

The second oldest language in existence is LISP, a multiparadigm language with a strong focus on the functional paradigm. I suggest you read the following Paul Graham Article:http://www.paulgraham.com/avg.html

I'm only learning the functional paradigm, and I'm not religious about it, as I am not with the OO paradigm. They may in fact work well together, and Python is a strong example of what I'm saying. And Python is not a kid's language. Visit Python.org and see in wich areas it is used.

Personally I find functional programming very suitable to certain domains, like web programming. What if you could interrupt a program execution while you are waiting in the server for the client(browser) response, and then retake the program flow as if nothing has happened? Search for call with current continuation(Scheme).

Want to know some of the advantages of Functional Programming in something you use in a daily basis?
What about the most known/unknown of the functional languages: Javascript? See this:
http://invisibleblocks.wordpress.com/2007/02/23/functional-programming-in-javascript-and-ruby/

and Watch the Douglas Crockford videos at Yahoo Video.

and to finish:

http://paste.lisp.org/display/44852