Strengths of Erlang as a declarative language (was Re: Compiler bug)

[Chris Pressey]

James Hague wrote:
>Chris Pressey wrote:
>>In some ways, Erlang has always struck me as a bizarre combination of
>>extremely low-level (assembler-like) concepts and extremely high-level
>>(lambda-calculus-like) concepts.
>
>I don't agree.  If you look at how pattern matching works in Haskell and
the
>ML family of languages, it is limited compared to what Erlang offers.  You
>can't repeat a variable, for example:
>
>first_two_are_same([X,X|_]) -> true.
>
>In general, you have to use classic if..then..else statements more often in
>these languages, because the pattern matching and guards are _more_
>restrictive than in Erlang.

I don't disagree, and I don't think it diminishes my point... perhaps it
would have been more appropriate to have said
"declarative-logic-(ProLog)-like" instead of ^-c-like.  (Except that Erlang
is still a far cry from ProLog in that there is no backtracking and there
are quite a few more restrictions on source code order... all in all this is
not a terrible thing, in fact it's what attracts me to it as a (nearly)
general purpose language.)

My point being that one of Erlang's strengths is expressivity, so I don't
think it should be unnaturally limited by arbitrary restrictions on guard
clauses... (that, and evaluation order so strictly following source code
order, are what strike me as the lowest-level almost "imperative"-like
features of Erlang.)

While I'm on the subject of language criticism... more and more I am finding
myself disagreeing with the canon law that message passing ought to be
encapsulated in function calls.  I agree that it ought to be *encapsulated*
for the sake of abstraction, but I believe that a function is the wrong
thing to encapsulate it in!  Functions traditionally do not have side
effects.  If I have a piece of Erlang code like

  Z = some_function(X,Y).

then I cannot immediately tell if there are side effects involved.  There
may or may not be, and it might be appropriate to assume that there
"shouldn't" be.  However, if I have a piece of Erlang code like

  some_server ! {some_function, self(), [X,Y]},
  Z = receive
    Any -> Any
  end.

then I can *immediately* tell at a glance that there *are* side effects
involved, I'm not left wondering and relying on my iffy neural-net memory or
hunting through source code.

Of course, a good naming convention accomplishes the same goal.

Chris