[erlang-questions] Erlang and the learning curve

[Morten Krogh]

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 
performance motivated.
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 
multicore programming?
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 
application programmers.


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<mk@REDACTED>  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 
that big.
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, 
but when?

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 
library.

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 
slower.
Erlang is 0.5 - 3 times more productive than C, and say 10 or more times 
slower.
(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.

Cheers,

Morten.













  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.