[erlang-questions] Erlang and the learning curve

[Robert Virding]

This whole dscussion reminds a little of the Paul Graham essay "Beating the Averages", http://www.paulgraham.com/avg.html , where he discusses the Blub paradox.

Robert

----- "Morten Krogh" <mk@REDACTED> wrote:

> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED