[Haskell-cafe] Why functional programming matters

[Sterling Clover]

On Jan 24, 2008, at 6:04 PM, Evan Laforge wrote:
>
> Java's just wordy like that.  In python you'd say max(foos, key=lambda
> x: x.update_time).  Python / perl / ruby / smalltalk have had first
> class functions forever, so those are basically already in the
> mainstream.  They may impress a java or C programmer who's never seen
> a dynamic language.  It might reassure a python programmer that static
> typing doesn't preclude using closures and doesn't mean c++ or java
> style huge long declarations.
>
> So you probably need some other examples to convince python
> programmers that their language didn't just cherry pick all the great
> ideas and that there are none left.


  Actually, citing the degree to which python, perl, ruby etc. have  
adopted some of the basics of functional programming seems like a  
clear win. The popularity of a book such as "Higher Order Perl"  
almost begs the question -- how much better would it be if folks were  
doing this in a language designed to make such things efficient from  
the get-go?
  While I'm not knowledgeable enough to give the inside scoop about  
Goldman, they're a good example in that they're doing some very  
functional stuff, especially frp-related for lots of their main  
worldwide pricing systems, but mainly doing this in languages that  
aren't purely functional. Here's one blog post that at least  
demonstrates that this is happening: http://www.kimbly.com/blog/ 
000505.html
   As I understand it, since they're working on a massively  
distributed architecture (literally worldwide), functional techniques  
are not only a huge win, but unavoidable.
   Along the lines of citing "Higher Order Perl" the popularity of C+ 
+ template metaprogramming might be a neat way to make the pitch as  
well. Drawing out how template metaprogramming is a form of  
functional programming might be a bit much for the talk. But, still,  
briefly mentioning that is widely recognized as helping to make  
things clean and efficient, although in a massively verbose and  
sometimes confusing way, and that more purely functional languages  
can do the same thing in a nicer way might again be a way to make the  
point.
    The neatest piece of simple Haskell code that I can think of, by  
the way, is the oft-cited Hamming sequence. There's so much going on  
in it, the manner it exploits laziness and infinite streams, and so  
forth.

--S