<div class="gmail_quote">On Tue, Feb 17, 2009 at 3:25 PM, Marco Morazan <<a href="mailto:morazanm@gmail.com">morazanm@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I am always shocked to hear stuff like this. Functional programming exacts a small intellectual price for a great deal of power that *most* when they discover it feel relieved and a sense of satisfaction. Yet the myth -- and let's be frank it is a myth -- that functional programming is hard persists. </blockquote><div> Well - at the risk of appearing to be down on FP, I'll share my thoughts.  Let me first say that I've had a great ride so far learning FP and developing in PLT, but it's certainly not without bumps and bruises.  Note - I am talking about the implementations of FP, not the concept of FP. My view is completely from a practitioner perspective - my exposure to FP in school is absolutely minimal - I had challenges matching parentheses back then.   </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Seriously, what is painful about it? Is it painful not to have a mangled syntax? Is it painful to encourage the use of recursion? Really, c'mon! Is it painful for functions to be first-class? Is it painful not to encourage the use of sequencing and mutation/assignment? Is it painful not to have "for" and "while" as keywords? Is it painful not to think of state all the time? Is it painful not to have to manipulate pointers? Is it painful for the language to properly implement tail calls? Is referential transparency painful -- most of my students are shocked when I point out to them that in, say, Java (pick any language that encurages assignment) that f(x) == f(x) is not always true, which suggest huge gaps in their education when they learned Java --? Is having macros or continuations painful? </blockquote><div> The merits of FP are certainly there, but I don't believe they are well articulated or positioned. In general the message appears to be - you can write better, simpler, and shorter program in FP, without having to pull your hairs out trying to find the weird bugs. These are good value propositions, but for mass practitioners they are dubious at best. The reason is because there are serious competitors.  FPs are no longer competing against C/C++ or even Java.  They are competing against the newer wave of languages all vying for developers' attentions. Perl, Python, PHP, Ruby also offer ways to write better, simpler and shorter programs.  And they demand far lower learning curves.  Erann Gat previously <a href="http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6">shared his thought</a> and alluded to Python being a serious competitor to his favorite, lisp. These languages further lower the barrier to entry by providing massive plumbings.   The amount of tutorials, books, references on them are staggering.  Whether you consider them rubbish or not, their existences simplified the adoption problem. Besides being "battery included", the amount of 3rd party modules written in these languages makes most developer's job fairly simple.  Most developers simply have to find modules to plug and play. The fastest way to develop is not having to develop.  No matter how fast you can code in FP, you can't beat reusable code.  And no matter how well the FP code are written, they also go through product lifecycle of maintenance.  Hence maintenance (and having a vibrant community to do maintenance) is critical. The most important thing for a practitioner is to be *productive*.  Contrast the above with the state of FP language/platforms today.  Introduction materials are hard(er) to find, and even when you find them, it might or might not work with a given implementation.  And when you go through the hurdle to be proficient, you still have to develop most code yourself, as there simply isn't a big enough community to spread the burden and the maintenance. That *is* pain. The truth is, professional developers will put up with a lot of pain.  Just look at their day jobs.  They are stuck using C, Java, Cobol or whatever at work at most places in a dusty cubicle with little lights, working 60-80 hours a week, just so they can put some food on the table.  Why wouldn't they want to simplify their lives?  But change is scary.  Peopleware talks about people hate change, period.  People more readily adapt change when there are prior examples of success.  Or when they really have to solve a problem that existing solutions just don't cut it.  What they generally don't do is to jump through hoops for qualitative and possibly dubious value propositions such as better or simpler. That's why I believe plumbings are the most important task for a FP to catch on.  It's even better if there are such a well defined niche for the language to solve a problem, so it can take the time to build up the plumbings.  Even Perl's formiddable CPAN is built over time while Perl prospers from solving text processing and web CGI niches.  Erlang now also appears to catch on as it solves massive concurrency problems that's appearing to become important.  I am a lurker on erlang's list and can attest to the increase of interest there.  If Erlang does "get over the hump" it will cause more adoption for FP in general than other FP languages. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I am not being cynical here. I know that many pick up bad habits that become part of muscle memory and then may feel lost at sea using a different programming language. Is that a short coming of functional programming? Would any of those lost at sea feel more comfortable coding in Prolog? Would a Cobol programmer feel more comfortable programming in Java? Perhaps, it is a shortcoming of our education and not of functional programming. </blockquote><div> Education is certainly key, but education alone isn't going to influence the industry, until the above issues are addressed.  And given most will stay in industry longer than in school I would say it's more important to build up the plumbings.  Wouldn't you want to hear your student say "why don't you teach me scheme, I want to work at Google (or another hip company) and they standardize on it"?  Surely that'll make your life as a professor easier too. My 2 cents and ramblings.  Cheers, yc </div></div>