<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">

<HTML>

<HEAD>

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">

  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">

</HEAD>

<BODY>

On Tue, 2009-02-24 at 21:39 -0800, Richard Andrews wrote:

<BLOCKQUOTE TYPE=CITE>

    I think it is a derivative of 1. Not that people are too stupid to understand functional languages; rather that they don't "get" them straight away. <BR>

</BLOCKQUOTE>

<BR>

This is true.  But people didn't "get" object-oriented programming when it first came out either.  (I know.  I was there when the big shift happened and was one of the OOP evangelists in my workplaces crying out in the desert.)  Yet now OOP is the dominant paradigm, despite its obvious flaws (including the fact that even well-written OOP code is impossible to follow in any medium-sized and up project).<BR>

<BR>

People don't "get" functional when they first encounter it.  But people didn't "get" that "X = X + 1" makes sense in the imperative paradigm when they first encountered it.  It looked like total gibberish, in fact.  (Think back to your first exposure to a statement like that.  I know <B>my</B> reaction was certainly one of gaping at the blatantly false assertion.)<BR>

<BR>

Functional-capable languages have been around longer than object-oriented ones.  (Lisp predates Simula, no?)  Hell, functional programming was known at about the same time that the whole notion of structured programming reared its head if memory serves (and it may not).  Yet imperative programming, despite its counter-intuitiveness (X=X+1?  are you smoking those funny cigarettes again?) won the day.  There must have been a clear advantage (or at least a clear <I>perceived</I> advantage) to imperative approaches that the functional didn't have.<BR>

<BR>

<BLOCKQUOTE TYPE=CITE>

    Java, C, C++, python, etc. all have familiar syntax elements that work pretty much the same way in all of them. People feel comfortable moving from one to the other. <BR>

</BLOCKQUOTE>

<BR>

This I agree with.  Any programming paradigm I already know I can pick up a new language for and be relatively productive in within about six months.  New paradigms take me years to suss.  (I'm still not 100% comfortable--more like 80%--with the functional, for example.  I've been trying off and on, more off than on, for about ten years now.)<BR>

<BR>

But.<BR>

<BR>

As I said, the shift to OOP involved syntax and conceptual elements that broke existing thought patterns.  Yet OOP caught on, functional did not.<BR>

<BR>

<BLOCKQUOTE TYPE=CITE>

    My first functional language was elisp. If it had been erlang I think I would have started using functional languages seriously a lot earlier in my career.<BR>

</BLOCKQUOTE>

<BR>

Mine was Scheme which I hated.  Oatmeal with fingernail cuttings littering it.  Then I found Haskell and began to see the beauty, despite struggling with some of the hopelessly over-abstracted, under-explained notions within it like monads and arrows and functors (oh my!).  (One of the single dumbest statements I've ever heard a really smart guy say was something along the line of "if we'd called monads 'Warm Fuzzy Things' instead people wouldn't be so afraid of them".  The scary part of monads isn't the name.  It's the fact that nobody has coherently and concretely explained what they are!)  Now I tinker with Erlang, although I really don't like its inability to do complex data types well.  Haskell wins on that front hands-down.<BR>

<BR>

<BLOCKQUOTE TYPE=CITE>

    As for those who *make* imperative languages. They probably also use (or even write) functional languages. Use the right tool for the job. C is still the best tool for a lot of work I do. <BR>

</BLOCKQUOTE>

<BR>

This.  This is the thing.  Yes, functional languages are a thing of beauty (some more beautiful than others).  They do not, however, act as EABAs for every problem domain.  I'd laugh at anybody who suggested I write device drivers or certain categories of embedded code in Erlang or Haskell over C/C++ in the same way that I'd laugh at someone who suggested I hand-roll data storage in C++ or Java instead of using SQL.  There are times when the stateful approach is not only right, but <B>necessary</B>.  Like, say, when you're dealing with a problem domain that has states.  (You know, like registers in a peripheral device.)<BR>

<BR>

<BLOCKQUOTE TYPE=CITE>

    People write languages to create a tool to solve a problem. You get problems when you choose a tool because it's the only one you understand.<BR>

</BLOCKQUOTE>

<BR>

The golden hammer.  Yes.  I view programmers who are comfortable with one or two languages with about the same respect as I view mechanics who only know how to use a screwdriver and a hammer.  (Hint: no respect whatsoever.)<BR>

<BR>

<BLOCKQUOTE TYPE=CITE>

    I don't buy 2, 3 or 4 - but I would add <BR>

        6. FUD. It looks scary.<BR>

</BLOCKQUOTE>

<BR>

Well, as I said, I definitely buy 3.  There are no functional programmers out there in numbers worth mentioning.  This means any solutions you use have to be accessible to the programmers you do have.  (This is why, incidentally, I don't sneer at Scala the way some Erlang fans do.  I think Scala is an interesting way to drag Java programmers into the world of functional programming and actor-based programming in baby steps.)  And 4 I definitely also buy because I'm someone who was driven off by a community's attitude toward newcomers.  I picked the messages I did for my examples for a reason.  It was messages like that (and a thousand others in comp.lang.lisp) that made me ditch Lisp when I first started looking at alternatives to the C++ ghetto I found myself in.  The whole assumption that people who don't do things the way you think they should be done are just stupid is off-putting and counterproductive if you have any intent of expanding a user base.

<BR>

<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">

<TR>

<TD>

-- <BR>

<B>Michael T. Richter</B> <<A HREF="mailto:ttmrichter@gmail.com">ttmrichter@gmail.com</A>> (<B>GoogleTalk:</B> ttmrichter@gmail.com)<BR>

<I>There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. (Charles Hoare)</I>

</TD>

</TR>

</TABLE>

</BODY>

</HTML>