[erlang-questions] The Beauty of Erlang Syntax

[Michael T. Richter]

On Tue, 2009-02-24 at 21:39 -0800, Richard Andrews wrote:
> 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. 


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).

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 my reaction was certainly one of gaping at the blatantly false
assertion.)

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 perceived
advantage) to imperative approaches that the functional didn't have.


> 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. 


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.)

But.

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


> 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.


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.


> 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. 


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
necessary.  Like, say, when you're dealing with a problem domain that
has states.  (You know, like registers in a peripheral device.)


> 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.


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.)


> I don't buy 2, 3 or 4 - but I would add 
>     6. FUD. It looks scary.


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.

-- 
Michael T. Richter <ttmrichter@REDACTED> (GoogleTalk:
ttmrichter@REDACTED)
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090225/6d7a3972/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090225/6d7a3972/attachment.bin>