[erlang-questions] erlang *****

[Ulf Wiger]

2008/3/18, Matthew Dempsky <matthew@REDACTED>:
>
>  You'd laugh at someone who was concerned about adding recursive
>  functions to a language because a naive user might write "fibb(N) =
>  fibb(N - 1) + fibb(N - 2)" or that adding general looping constructs
>  means we can't ensure arbitrary programs will halt on a given input.
>  I see no reason to worry about similar arguments for disjunctive
>  patterns.

I think there is always reason to worry about such arguments.
I think that one of Erlang's strengths, both compared to more
"sophisticated" functional languages like Haskell, and to more
mainstream languages like C++, is that fairly average
programmers can quickly learn to write pretty solid production
code (perhaps not great, elegant or terribly efficient, but good
enough for industrial use, even with very high quality standards).

Great programmers can write elegant and efficient programs in
practically any language, and one of my main gripes about C++
is that great programmers are often able to use this to sway
policy decisions towards C++, not understanding (or caring?) that
such power tools can be disastrous in the hands of the "average
programmer" - after all, why should we base important design
decisions on expectations of how badly our design can be abused
by stupid people?

The main question is really: how easy is it to tell the efficient uses
from the horribly inefficient ones?

In the fibb example above, it is perfectly reasonable to teach
beginners (as we have done in Erlang for years) e.g. that a
recursive function will grow the stack if it has outstanding
computations when making the recursive call. This appears
to be easy to grasp for most programmers, and is immediately
obvious in the fibb() example. It is also immediately obvious
that it's exponential.

This is very different from allowing a subtle change in a complex
pattern match to shift evaluation from constant-time or linear
to NP - especially when programmers have learned to expect
and appreciate that pattern-matching is predictable in cost.

I am very much in favour of keeping Erlang's pattern-matching
both pure and predictable in cost. I don't mind having list
comprehensions, query comprehensions etc that are not.

BR,
Ulf W