[erlang-questions] The Beauty of Erlang Syntax

[Joe Armstrong]

2009/2/25 Michael T. Richter <ttmrichter@REDACTED>:
> 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.
>

I disagree (a bit) - I've taught Erlang a few times to classes of very
mixed ability.

The bit they found easy was the non-mutable state bit.

I explained that

               A = 1,
               B = A + 6,
               B = 7

works, but

               A = 1,
               B = A + 6,
               B = 8

fails (obviously)

The beginners have no problems with this idea - nor with pattern
matching in lists and tuples.

What they *do* have problems with is SYNTAX. They forget a comma, or a
semicolon, they
write abc for a variable instead of Abc - then they spend a *long*
time staring at there program
wondering what went wrong.

I come over an see the error "instantly" correct the error - and they
are happy as new born lambs.

The *ideas* in FP are easy - the syntax is not.

I have *exactly the same problem* learning a new programming language
- *any* programming
language - I make small syntactic errors and stare at the program for
hours wondering what went
wrong.

<< a few days ago I was writing some javascript and called function
"new" (by mistake) it took
       a long time before I twigged >>

So the ideas in FP are easy but the syntax is a bit of a bother to learn.

Then there's the difficult bit (it occurs a bit later, when you getb
over the syntax problem phase)

You have to get the data you need, to the place in the program where
you need it - so
somehow it has to go through the argument lists of the functions that
get called to get to the
place where it is needed.

This involves a bit of planning - but becomes second nature after a
while (If you had global variables
this would be easy BUT this destroys all the nice properties that
non-mutable data has).

In OOPs life is easy - you have mutable state all nicely hidden in the
object, so you can pile
effect upon effect and mess around with state in any way you feel like
- this adds power, efficiency
and incomprehensibility.

If FLPs you can't do this - you have to plan your data structures in
advance and figure out
exactly what you want to do with them - the mental process of doing so
is identical in
all FLPs I've seen.

I've been learning Haskell from the new (excellent) Haskell book -
under the surface it's extremely
similar - (or the syntax is different, the type systems are different,
the evaluation strategies are
different) - but the problem of getting the data to the place in the
program where you need it is the same.

Thinks like Monads in Haskell hide this for you, just as processes
which store data in tail-recursive
loop in erlang. Same problem - different solution.

FP is no difficult - it is *different*

If you learn Erlang and change you mind and want to learn Haskell or
O'Caml half the work
is done (just like switching from Java to C# or python to ruby) -
learn the general properties of
the language *family* and you're laughing.


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

No - they do - at least my pupils did.

My generation learnt recursion at school

I learnt in school that

    sin(2A) = 2 sin(A) cos(A)

This stuff sits deep (I loved maths)

What they didn't tell me was that this was an Erlang program - rearrange a bit

    sin(X) = 2 sin(X/2) cos(X/2)

add an arrow stars and a dot

    sin(X) -> 2*sin(X/2)*cos(C/2).

And we have a program

So they taught me functional programming in school way before
microprocessors were even
dreamt of.

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

It *is* gibberish - my math teacher told me when I was 10 years old.

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

It gained a temporary victory

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

Just like people will feel comfortable moving between Haskell, Erlang,
F# O'caml

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

Same for FP -

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

Yes - this OOP stuff is *really* difficult - I just don't grok it

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

Not *then*

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

I think scheme is *beautiful* - *too* beautiful (like prolog) so
beautiful that when you see it
you think - I can't improve this - so there is nothing for you to do -
(but I found that scheme had
zero libraries, like prolog :-)

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

Yes - agree - we need *lots of good books* and we need to loose the
"academic" stamp.

Trouble is most of the really-good erlang/Haskell programmers are too
busy working
in companies that are totally smashing all competition to be bothered to explain
what they're doing.

Changing to FP is a big paradigm shift so takes more time to achieve than
an incremental improvement to an OO-language

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

I get Erlang to write the C for me :-)

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

But I might get Erlang/Haskell to generate the C/whatever code for the driver -

>
> 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)
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

/Joe Armstrong