[erlang-questions] The Beauty of Erlang Syntax

[Steve Davis]

On Feb 26, 3:40 pm, Zvi <ex...@REDACTED> wrote:
>
> ...article "Erlang for Concurrent Programming" [1] there is a list of things
> for which Erlang tends to be not good.
>
> [1]http://mags.acm.org/queue/200809/

Took a quick look at that link to "queue magazine", and they seemed to
be scratching around a bit to find reasons to pad out their list...

First was...

" Concurrency more appropriate to synchronized parallel execution"

I guess that sounds good. But I'd need to see an example of what the
author actually means to understand and make any judgment as to
whether it's actually true.

"•  Code requiring an aggressive compiler (Erlang entries in language
benchmark shoot-outs are unimpressive — except for process spawning
and message passing) "

Does he mean "serial performance" here. If so see below, as this is at
the heart of most of the list items.

"•  Floating-point-intensive code"

Most code (in any language) isn't particularly "performance sensitive"
you gotta measure measure measure. Also, I think the author
specifically means "serial/linear code performance"... ok, but in
those rare bottlenecks (and they are rare) where beam/hipe are not
enough, there's always (easy to make) C ports for your escape
hatches.

"•  Code requiring nonportable instructions "

Why would you want this? *REQUIRING* when does code (rather than
managers/architects) *require* non-portability. Isn't non-portability
just a inconvenient compiler design fact for certain platforms? The
exception here could be embedded processors, so I guess that's where
this came from. However, I don't often code for embedded processors
(in fact, I never have and I'm unlikely to do so in the future).

"•  Projects to implement libraries that must run under
other execution environments, such as JVM (Java Vir-
tual Machine) or CLR (Common Language Runtime) "

I've noticed that Java isn't too good on CLR/Mono or on BEAM, and that
C# isn't so good on the JVM or BEAM.

"•  Projects that require the use of extensive libraries written in
other languages "

This isn't necessarily true. jinterface and ports are more than
adequate for 90% of purposes.

All in all, I find this list pretty unconvincing.

/sd