The Artima Developer Community
Sponsored Link

Java Community News
Cedric Beust on Programming Erlang

44 replies on 3 pages. Most recent reply: Oct 9, 2007 2:30 PM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 44 replies on 3 pages [ 1 2 3 | » ]
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Cedric Beust on Programming Erlang Posted: Sep 28, 2007 3:46 PM
Reply to this message Reply
Summary
Cedric Beust reviews Joe Armstrong's recent book, Programming Erlang, pointing out the good, and the not so good, features of the language.
Advertisement

Joe Armstrong's Programming Erlang book was published earlier this year by the Pragmatic Programmers. Erlang has benefitted from renewed interest in recent years, fueled in part by the desire to make better use of concurrent hardware, a task Erlang is especially suited to tackle.

Cedric Beust recently reviewed Armstrong's book, and gave Artima permission to quote at length parts of the review. The full review is available at Erlang.

Beust starts by observing that:

All variables in Erlang are final. Now, this is intriguing and it certainly urged me to read further in order to understand...

Erlang uses an interesting mix of Unification (also called "pattern matching" and used in Prolog, although Erlang doesn't have a "cut" operator) and of functional programming, as found in Lisp, Scheme and Haskell.

These names might be intimidating, especially when used in the same sentence, but I mean this as a compliment: Erlang manages to leverage these arcane concepts in ways that are actually fairly consistent and easy to follow. From that respect, Erlang might be a good language for beginners who want to learn more about unification and functional programming.

The features that generated the most interest about Erlang are related to the language's support for concurrent programming:

What I find interesting in Erlang is that its functional aspect is a means to an end. The idea is that by using standard functional constructs, such as strict evaluation and single assignment, there is no mutable state in Erlang programs, which makes concurrency much easier to implement: imagine being able to spawn thousands of threads without ever having to resort to locking... This is exactly the premise of Erlang...

Avoiding mutable state is one thing, but you also need to have a way to communicate to other processes. This is typically achieved by sharing variables and carefully locking around them so you can't thrash their value, but in Erlang, not only can processes not affect each other, they actually don't have any visibility on their peers, not even their read-only state. When you want to transmit an information to a process, all you know is the id of this process and the data you want to send.

Erlang's syntax to send messages is fairly simple:

Pid ! a_message

Pid is the process, a_message is any valid value (atom, variable, list, etc...). You receive a message with a structure that basically looks like a switch/case:

receive       % receive message sent to this process
   % This is a tuple of a type atom and some data
   {data, Data_content} -> do_something_else(); 
 end.

Erlang includes advanced functionalities to manage the most complex architectures made of hundreds of Erlang processes, among which: handling timeouts, spawning and finding processes, distributing them, notifying one or more processes when one of them dies, etc... Erlang also makes it trivial to send code and functions to remote processes, which opens up a lot of possibilities regarding hot-swapping or live upgrading.

Beust notes, however, that organizing larger Erlang programs can be difficult, because the language does not support classes and more traditional object-oriented constructs. While following a longer code example, Beust remarks:

But what really got my head hurting was the vast amount of repetition that I found in this code. Every listing is basically a clone of the original gen_server code with just a few lines added, removed or altered. This made it very difficult for me to understand what was going on and, worse, to understand the philosophy behind these changes. On the contrary, I found myself having to parse the entire listing over and over again and detect the subtle changes that had been made. And as I progressed through the chapter, I had a clear sense that I was drifting further and further away from the big picture...

This, in turn, led me to wonder what was going on, and I started to realize that Erlang was lacking a fundamental concept that might explain why this code looked so hard to read: Erlang doesn't have the concept of classes...

The problem here is not the absence of classes but of what classes enable, among which polymorphism, inheritance and in more general terms, reusability. As I was going through these repeated listings, I found myself trying to find various ways to refactor them so that only the important part would be shown in the next listing, instead of the entire gen_server. But I couldn't, and I don't believe that it's actually possible in Erlang.

This is a pretty big deal.

Fundamentally, these listings vary in their receive clause and in the various methods they implement. Refactoring a receive clause is like refactoring a switch/case: in general, not very convenient and even if you decide to replace it completely, you need to introduce polymorphism, which Erlang doesn't seem to support at all. Similarly, it doesn't seem possible to override an existing method and specialize it, nor is it possible to add a method to an existing module (or have a module extend an existing one). The closest you can come to with Erlang is by using multiple import statements, which is barely safer than #include.

In a nutshell: Erlang goes to great lengths to make it easy for you to distribute hundreds of pieces of code throughout an entire network, yet makes it nearly impossible to arrange this code in a meaningful way.

In summary, Beust notes that:

The main problem I have with Erlang at the moment is that despite the fact that it was created in 1998 (therefore, after Java, Ruby and Python), the language and its environment feel old. Very old. Most of the examples and listings are run from Erlang's shell and it doesn't seem that there is even a decent editor to help you. Besides the interesting functional/unification approach, the structure of the language is barely above that of C with hardly any means to organize or package your code in a meaningful way. For all I can see, an Erlang program is just a set of methods thrown in different modules, with barely any other interaction besides importing available to them.

No matter how much I admire Erlang's ability to distribute processes across machines, the lesson we learned in the past decade in software engineering is that it's easier to distribute data than code, and Erlang's obsession at sending tiny pieces of beautiful and self-updatable code over the wire therefore appears to be completely misguided. It's already hard enough to achieve this kind of distribution across a LAN, it's simply impossible to achieve in any meaningful way on today's Internet.

What do you think of Erlang?


alpha alpha

Posts: 8
Nickname: alpha512
Registered: Mar, 2007

Re: Cedric Beust on Programming Erlang Posted: Sep 28, 2007 8:59 PM
Reply to this message Reply
I'm sorry but Erlang appeared 1987, It is already very old, I tryed it and I liked the concurrent functionality as you said but yes it feels old and out of time. I really suggest to check Scala, Erlang Influenced in Scala design also Scala is strongly typed support object oriented and functional, concurrent programming and you can reuse all the Java api's and run with the JVM and also there is a plugin for eclipse to develop projects for Scala the only thing is still missing is the refactoring functionality but the team is working on it. I think the next best thing it will be Scala working on the JVM. I suggest check Scala at http://www.scala-lang.org/

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Cedric Beust on Programming Erlang Posted: Sep 29, 2007 12:43 AM
Reply to this message Reply
Erlang is not Java. Therefore it is bad.

Note that Joe Armstrong holds own views about OO:

http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

Just one question. I wonder what lessons people actually learned from distributed computing of the last decade? On Cedric Beusts resume CORBA is mentioned. Now we have RPC in XML fashion, called Web Services... Given that we are living in the dawn of massive parallelism on a single machine I wonder where this crap is going in a not too distant future. People are interested in runtime engines that migrate logical processes transparently across different CPUs. That's why network centric multi-processing solutions like Erlang keep so much attention and they are a more safe and reliable alternative to shared state multithreading.

My prognosis: migratable code will have a comeback but it's unlikely it will be OO. Erlang is kind of the Smalltalk of network centric languages and it will be superseeded by some Ruby ( i.e. a language that feels lighter, is less pure and designed to be a user friendly scripting language in particular ).

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: Cedric Beust on Programming Erlang Posted: Sep 29, 2007 6:34 AM
Reply to this message Reply
I have read the book myself and i have also read the complete review. However, the review told me more about the reviewer than about the book.

The focus of the book is clearly to describe the language, and demonstrate its strengths. It is not about tools, development process, etc. Erlang was designed for use in telecommunication equipment. Tradionally C and assembler would be used in such a domain, so that is probably the background that Joe Amstrong assumes, and he shows examples that demonstrate improvements over these languages.

Probably Amstrong comes from a completely different development culture. Agile development is probably not the philosophy of choice in the telecommunication industry, I would rather expect hardcore waterfallers with a taste for formal verificaton.

Next, the abstraction mechanisms that erlang provides are different from object oriented languages. But that does not mean that it is "nearly impossible to arrange this code in a meaningful way", just that different techniques will be required.

As a side note, I find it astounding that a professional software developer should have difficulties following a few lines of well-described, well-structured code. The examples mentioned are in the order of 30 lines.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Cedric Beust on Programming Erlang Posted: Sep 29, 2007 4:52 PM
Reply to this message Reply
> Note that Joe Armstrong holds own views about OO:
>
> http://www.sics.se/~joe/bluetail/vol1/v1_oo.html


I found his post hard to comprehend. From what I can tell, he wants everything to be exposed.

His Objection#1 - There are many good reasons for combining data and methods. I'm not claiming this solves all the world's problems, but instead of saying "data and functions are different" he should address the real issues. Besides, peanut butter is different than jelly, that doesn't mean one shouldn't combine them, so his basic claim just seems strange.

#2 - I guess he wrote this before Enum.

#3 - The ability to define all data types in one small file passed away about the time PCs burst through the 640K barrier. Nor is putting all data types into ONE file a very good idea. Having worked with some "brilliant" C #include files that redefined everything.

#4 - Maybe state is evil. If so, why not try to hide it away in a well constructed object? Exposing it forces programmers to deal with it, and, frankly, many aren't prepared to do so.

pat ludwig

Posts: 1
Nickname: patl
Registered: Jul, 2003

Re: Cedric Beust on Programming Erlang Posted: Sep 30, 2007 11:07 AM
Reply to this message Reply
I love how seemingly every discussion of programming languages bring out the language bigots hell-bent on either trashing the language in question or heaping praise on their favorite. Languages are tools that presumably are good for some application otherwise nobody would use them. All languges have their strengths and weaknesses, and Erlang has sweet spots in areas of concurrent programming and network distribution. It has not and probably will not take over the concurrent or network programming world as we know it.
But I would remind folks that however beautiful a language is and how useful it is for some purposes, the opportunity costs at learning yet another language that may or may not play well with other languages or platforms can be exceedingly high. I'm not sure I can offer much more than Martin Fowler's ambivalence http://martinfowler.com/bliki/OneLanguage.html about the cost-benefit trade-offs of using specialized or domain-specific language, but as engineer at one of the larger Lisp shops in the world, I can attest first hand at both the difficulties in finding qualified engineers to code in that language, and how it is misused for tasks that might be better executed in another language. And Lisp is one of the more widely used and accepted functional languages. What hope for Scala, Scheme, and Haskell in moving beyond their niches?

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: Cedric Beust on Programming Erlang Posted: Sep 30, 2007 11:35 AM
Reply to this message Reply
> Next, the abstraction mechanisms that erlang provides are
> different from object oriented languages. But that does
> not mean that it is "nearly impossible to arrange this
> code in a meaningful way", just that different techniques
> will be required.

The main abstraction techniques for functional programming that I know about include higher-order functions (functions that take functions as parameters, and which return functions as results). These can be very powerful, and give you much of the power that inheritance and polymorphism gives to OO programming. Does Erlang have this capability?

If so, then the repetitive code in the textbook was for pedagogical purposes, and probably could have been abstracted away.

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: Cedric Beust on Programming Erlang Posted: Sep 30, 2007 5:28 PM
Reply to this message Reply
> > Next, the abstraction mechanisms that erlang provides
> are
> > different from object oriented languages. But that does
> > not mean that it is "nearly impossible to arrange this
> > code in a meaningful way", just that different
> techniques
> > will be required.
>
> The main abstraction techniques for functional programming
> that I know about include higher-order functions
> (functions that take functions as parameters, and which
> return functions as results). These can be very powerful,
> and give you much of the power that inheritance and
> polymorphism gives to OO programming. Does Erlang have
> this capability?
>

Yes, it does. I guess it should be straightforward to implement polymorphism in erlang, since a tuple can hold arbitrary data, including functions. But classes/objects in the OO sense would rather correspond to an erlang process, and to invoke a method one would send a message to this process.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 9:46 AM
Reply to this message Reply
> Erlang is not Java. Therefore it is bad.
>
> Note that Joe Armstrong holds own views about OO:
>
> http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

I kind of have to agree with Morgan on this but even more strongly. He seems to really not understand OO at all. And on he makes some arguments that don't seem logical to me.

Objection 1 - Data structure and functions should not be bound together

I think Morgan already put this well enough but "Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage" is not more meaningful of an argument that saying "opposites attract" would be a good counter argument.

Objection 2 - Everything has to be an object.

"In an OO language "time" has to be an object. But in a non OO language a "time" is a instance of a data type."

Classes are types in OO and Objects are instances of those types.

"Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system."

So here the suggest is that objects in OO cannot be manipulated by any function in the system. That's clearly not the case. You can create objects with this property in most OO languages (AFAIK) but that's an option, not a requirement.

Objection 3 - In an OOPL data type definitions are spread out all over the place.

"In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some "time" object, where does this belong and in which object..."

This seems to demonstrate a complete misunderstanding. If this is really how he thinks OO works, then I can understand why he doesn't like it.

Objection 4 - Objects have private state.

[parenthetical statements removed]

"Mechanisms like monads and DCGs are used to hide state from the programmer..."

"The "hide the state from the programmer" option chosen by OOPLs is the worse possible choice..."

Basically the argument is that: 1. state is bad. 2. You can't avoid state. 3. You should hide the state from the programmer unless you can't. 4. OOP does these things and that's why it's bad.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 11:08 AM
Reply to this message Reply
> > Erlang is not Java. Therefore it is bad.
> >
> > Note that Joe Armstrong holds own views about OO:
> >
> > http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
>
> I kind of have to agree with Morgan on this but even more
> strongly. He seems to really not understand OO at all.
> And on he makes some arguments that don't seem logical to
> o me.

Just a few notes about the context of Armstongs OO criticism. These notes are a bit aged, namely from 2001, written on the peak of OO hype. It's not easy to see from the document itself. He might have felt the need at that time to justify his decision for FP, dated back to the late 80s where Erlang originated. It was the most consistent decision for a concurrency oriented programming language after all. In his latest book, reviewed by Cedric Beust, Armstrong uses occasionally motivating examples from Java, being translated to Erlang code. I didn't discover any polemical attack against OO and Java in particular. FP isn't that much under pressure these days. The whole situation has become a bit more relaxed and people are open for new ideas: FP ( Erlang, Haskell), DSLs, FP+OO (OCaml, Scala ) to name just a few.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 11:29 AM
Reply to this message Reply
> Just a few notes about the context of Armstongs OO
> criticism. These notes are a bit aged, namely from 2001,
> written on the peak of OO hype.

I don't have any problem with critiques of OO. What I do have a problem with is critiques about OO where the author doesn't know what he or she is talking about. I feel the same way about critiques of FP or anything else.

I can see where Cedric Beust's comments might possibly border on "critique from ignorance" but I can't really say for sure.

The critique about the lack of classes could be just that. When I read it, it seems to me that he's saying that there doesn't seem to be a way to create a template for an Erlang process (forgive/correct me if my terminology is off) so you end up with a lot of boilerplate. FP-developers don't seem to see this as an issue. Personally, I'd like to understand exactly why this isn't an issue because I am trying to learn and understand FP.

But these discussions where people fire claims back and forth attacks based on misunderstanding are pointless.

So let me rephrase the critique as a question from a position of admitted ignorance. How do you avoid repetition and redundancy in Erlang?

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 11:54 AM
Reply to this message Reply
No language or programming paradigm can solve all the problems in the most effective manner. Common sense dictates that a language like Erlang will shine in concurrent, small data chunk scenarios. So, with the OS threading ball-and-chain added to the soup, it comes as no surprise that Yaws beats Apache hands down.

That being said, using the same common sense, if there is not to be data sharing ever (i.e. everything is to be copied at all times), it would be really interesting to see how functional languages would perform dealing with enormous amounts of data encountered in many real world applications. Could that be the reason we are not seeing those in enterprise business domain?

Erlang is a niche language. And it does extremely well in its niche. It's a functional language, so it's unfair to judge it from OO standpoint. Just like Armstrong's bashing of OO is one-sided and unfair. Just like some OO zealots idea that everything is object is crazy. And the functional zealots idea that all state is evil equally so. There are many languages and many programming paradigms, each with its proper domain and respective up and down sides. And, then, there is also theory and practice. Which are same. In theory. But not in practice ;-).

BTW, Erlang is way older than '98. It'd be more like '87, making it significantly older than Java:

http://www.erlang.org/course/history.html

This fact could actually be a good base for a discussion on why the heck did Java authors not look at Erlang threading model. Or STL generics.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 12:38 PM
Reply to this message Reply
> So let me rephrase the critique as a question from a
> position of admitted ignorance. How do you avoid
> repetition and redundancy in Erlang?

This is an excellent question and might be rephrased again with a slightly shifted accent: how is Erlang code actually structured in the large? I do think there is no way around reading code and poke into OTP, since this is the largest Erlang code base available to a wide audience, written by real Erlang experts.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Cedric Beust on Programming Erlang Posted: Oct 1, 2007 3:38 PM
Reply to this message Reply
> > So let me rephrase the critique as a question from a
> > position of admitted ignorance. How do you avoid
> > repetition and redundancy in Erlang?
>
> This is an excellent question and might be rephrased again
> with a slightly shifted accent: how is Erlang code
> actually structured in the large? I do think there is no
> way around reading code and poke into OTP, since this is
> the largest Erlang code base available to a wide audience,
> written by real Erlang experts.

I would love to get an answer as well. And I also asked a few other questions (or rather, challenges) in a more recent post on Erlang which you can read here:

http://beust.com/weblog/archives/000464.html

Basically, I'd like to see some concrete evidence of the various claims that are usually heard about Erlang, such as "makes multiprocess programming easy", "fault-tolerant", etc...

--
Cedric

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 2, 2007 7:02 AM
Reply to this message Reply
> > Note that Joe Armstrong holds own views about OO:
> >
> > http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
>
>
> I found his post hard to comprehend. From what I can
> tell, he wants everything to be exposed.
>
> His Objection#1 - There are many good reasons for
> combining data and methods. I'm not claiming this solves
> all the world's problems, but instead of saying "data and
> functions are different" he should address the real
> issues. Besides, peanut butter is different than jelly,
> that doesn't mean one shouldn't combine them, so his basic
> claim just seems strange.
>
> #2 - I guess he wrote this before Enum.
>
> #3 - The ability to define all data types in one small
> file passed away about the time PCs burst through the 640K
> barrier. Nor is putting all data types into ONE file a
> very good idea. Having worked with some "brilliant" C
> #include files that redefined everything.
>
> #4 - Maybe state is evil. If so, why not try to hide it
> away in a well constructed object? Exposing it forces
> programmers to deal with it, and, frankly, many aren't
> prepared to do so.

Actually, his comments may be translated in various ways. I certainly agree with him, as I have not witnessed large improvements from OOP. Here is another approach:

#1 - some times I want to have one more function for a data type I don't have the source code; impossible with OOP, easy with the 'classic' approach.

#2 - the strict classification of data types into classes creates many problems in many real world problems. Entities may be customers, customers may be persons, but later customers can be companies, for example. Trying to model that with classes asks for trouble.

#3 - very true regarding inheritance. Why should I inherit from when all I want is to use something? Non OOP does not have the problem of distinction of 'is a' from 'use a'.

#4 - the problem is not private state but not recognizing what are the side effects of encapsulation. And hiding state is certainly a problem when you want to modify software.

As I have written many thousands of lines of object-oriented code, I have started to ask myself why I bother with all the class diagrams, patterns, encapsulations etc where simple datatypes and functions would make the code 10 times smaller and easier to comprehend...

Flat View: This topic has 44 replies on 3 pages [ 1  2  3 | » ]
Topic: 2007 JCP Elections Under Way Previous Topic   Next Topic Topic: John O'Conner Explains JavaFX Functions and Operations


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us