[erlang-questions] Erlang and the learning curve
Wed Jan 5 13:22:42 CET 2011
It is fine with me to claim that often performance doesn't matter, but
then the imperative languages
of relevance are perl, python, ruby, js etc. Functional languages are
not easier or more productive than these.
In some sense functional languages just constrain themselves by giving
up loops and other constructs that are useful.
But I still think that a lot of what I see in the Erlang world, is
Why not interface with other languages through the file system then. It
is very robust and easily debuggable.
Interfacing with some legacy code could be done by running the legacy
code in a separate OS process, make it write the
result to a file and have Erlang open the file. erlang could do with
sockets and file access.
Why aren't many of these libraries written in functional languages to
start with? Why hasn't the higher productivity in
functional languages led to all those libraries being available in
functional languages. Why is it more important for Erlang to interface
with C, C++, Java etc than with Haskell, Lisp, Ocaml. Same question for
them. Does Haskell care about interfacing with Erlang to get libraries?
Functional languages are old, there have been many functional
programmers, functional programmers are often very very skilled. Where
are all those libraries
that the imperative world doesn't have?
Henning, do you care to make an exact falsifiable claim about the
multicore scalability of Erlang? What will happen, say in 2020? What
kind of application is it that
Erlang will have but not C or any other imperative language? How exactly
will we recognize Erlang's victory over all imperative languages in
Personally, I don't see why C can not have threading libraries with work
scheduling and migration in a way that is approachable for many
Why is the Erlang environment even considered functional? There is a
runtime in C, there is ets, the process dictionary, nifs, lots of bifs.
The important parts of Erlang don't seem to be the functional syntax but
more many of the other parts.
On 1/5/11 11:45 AM, Robert Raschke wrote:
> On Tue, Jan 4, 2011 at 7:25 PM, Morten Krogh<> wrote:
>> And then the functional language is just a glorified C library.
> C is just a glorified Assembler library.
I don't thinks so. Let me explain where I see the difference. It is a
quantitative difference, not a qualitative one.
C is much more productive than assembler, and the speed loss in C is not
All higher level languages after C, are not that much more productive
than C, or they lose a lot of performance. C hit a sweet spot.
Some day, there will be a higher level language that displaces C, sure,
You can see the difference in how new algorithms are implemented. Say
someone invents a new type of data structure, an abc tree, say.
Then C programmers would write abc tree in ansi C and publish it as a
Erlang would almost certainly not write it in Erlang. The Erlang module
abc_tree would just be a wrapper to the C functions. Erlang people might
even write their
own C program instead of using the C people's library and wrap it.
I would make similar statements for other languages. Python would just
write a wrapper to C etc.
Erlang could have done something completely different. Made a small core
20 years ago, and then stayed within pure Erlang. The abc_tree would be
written in pure Erlang.
The thought of writing a wrapper in C could have been silly.
Someone invents a new cryptographic algottihm. C people would implement
it in C. Assembler would not be worth it. It is too difficult,
unportable, and the performance gain
is minor. Erlang, python, java?, perl, ruby, haskell etc would write a
wrapper to a C function.
The situation is not symmetric.
Some arbitrary numbers:
C is 20 time more productive and portable than assembler, C is 2-3 times
Erlang is 0.5 - 3 times more productive than C, and say 10 or more times
(Erlang speed is higher the more you use the wrappers to C of course,
but that is forbidden).
I am not picking on Erlang. The same is true for all other higher level
languages, and is, in my opinion, the reason that old C is still so popular.
In the productivity performance trade-off C has been extraordinarily
successful. No later language in my opinion has done that.
Probably almost no one will agree with me, but anyway.
so most code in written in C, and it is very rare to move into
assembler in order to
speed up C. There can be other unrelated assembler programs, but that is
a different story.
More information about the erlang-questions