Erlang questions on comp.lang.functional.

Shawn Pearce spearce@REDACTED
Mon Mar 3 00:40:15 CET 2003


Faust <urfaust@REDACTED> wrote:
>  ****************************************************
>  Forwarded from comp.lang.functional
> 
>  Faust wrote:
> > 
> > Erlang is a functional language.
> > Is there any reason to not use erlang ?
> >
>  I have never programmed in Erlang, just skimmed a few chapters of 
>  written material, so take this as an account of how good or bad the 
>  Erlang PR is, not whether Erlang is good or bad.
>  So, here's what speaks against Erlang (there are also a lot of things 
>  that speak *for* it, I'm omitting that because it would be off-topic):
> 
>  1. No static typing.

Unless your a lover of C++, I fail to see this as being a problem.  I only
see it as being an issue as far as performance optimization possibilities
go.  Perhaps a large number of bugs really do occur in programs as a result
of not having static type checking in the compiler, but in general my
experience has been that this only is a problem in Perl, and only when
checking that you spell structure member names correctly everywhere.
(As Perl structs tend to be just hashes with arbitrary keys used as
string constants.)

>  2. Bytecode interpreted (i.e. not compiled to native code).

Isn't this why we have HIPE?  And thus far, I have not seen HIPE improve
performance over code run in the bytecode interpreter.  Therefore I have
to ask:

	- is the rest of erts slow?
	- is the bytecode interpreter really fast?
	- do I just keep my mathmatical computation outside of erlang?

>  3. Possibly not "really functional", i.e. mutable stuff (message sends 
>  and state-dependent responses) play an important part when it comes to 
>  structuring and maintaining large programs. (Of course, you *can* do 
>  large parts of purely functional programming in Erlang.) (This is just 
>  an impression that I gained, something that somebody with personal 
>  experience in Erlang should confirm or deny. Hence the "possibly" in the 
>  first sentence of this paragraph.)

I think the reality is it is impossible to build a programming language
that doesn't have side effects.  Consequently, Erlang offers the best of
both worlds.  You can build code that is side-effect free when appriopiate,
but also build code that has side-effects when it is necessary for either
correct function (to do IO perhaps) or for performance (like using ets vs.
a pure functional datastructure).

>  4. Some roots in Prolog, which I find... er... disturbing (my personal 
>  encounters with Prolog were, say, unlucky... its strengths were less 
>  useful than I had expected, and definitely not worth the weaknesses that 
>  were the payment for its strengths - IMHO (I never became a Prolog guru)).

Er, I hated Prolog and had as much distaste for it as I think the author
of this forwarded message has.  But the Prolog roots is what I think I love
most about Erlang.  Everything is just pattern matching and message sending.
:-)  How could one not love that?

>  **************************
>  end of forwarded message.

Just my two cents (USD, currently worth less than two Euro cents).  :-)

-- 
Shawn.

  Things past redress and now with me past care.
  		-- William Shakespeare, "Richard II"



More information about the erlang-questions mailing list