Programming Erlang 314
gnalre writes "Every day it seems there is a new publication of a book on perl/python/ruby. Some languages however do not seem to get that sort of attention. One of those under-represented languages is Erlang, however for the first time in 10 years a new Erlang book has been published. As someone who had a brief flirtation with Erlang long ago, I was interested to see how the language had evolved in the intervening decade. I was also curious to re-evaluate Erlang to see what solutions it offered to the present day issues of writing reliable distributed applications." Read on for the rest of Tony's review.
| Programming Erlang - Software For A Concurrent World | |
| author | Joe Armstrong |
| pages | 515 |
| publisher | The Pragmatic Programmers |
| rating | 8/10 |
| reviewer | Tony Pedley |
| ISBN | 1-9343560-0-X |
| summary | Parallel programming the easy way |
Programming Erlang — Software For A Concurrent World (ISBN 10193435600X) is part of the pragmatic programmer series. As with all the books in this series, it is available in paperback or for a reduced cost you can directly download it in PDF format (which is always useful if you spend a lot of time on the move and you do not like carrying around a dead tree with you). The book's format and layout as with all the books of this series are clear and logical.
The book is written by Joe Armstrong, who co-authored the first Erlang book a decade ago. He was also one of the originators of the Erlang language and has been directly connected to its development ever since. We can therefore be assured about the author's knowledge and insight into the language, if not his impartiality.
The book itself can be roughly split into three main sections: Getting started and Sequential programming, Concurrent Programming and Erlang libraries and advanced Erlang techniques.
In Chapter 1 the author sets out his stall of why Erlang is worthy of your attention. It's clear from this chapter that the author feels Erlang's strength lies in applications requiring an element concurrency and fault tolerance. Another emphasis is made of running Erlang on modern multi-core processors, something that was only a glint in a hardware designer's eye 10 years ago, but is rapidly becoming an issue in all areas of programming. From this chapter you also get a feel on how the author approaches his programming in that he states that he wants the reader to have fun with the language, which is a refreshing change to some language text books whose main purpose appears to be as a cure for insomnia.
Chapter 2 goes through installing Erlang and the Erlang shell (a command line environment similar to ones with languages such as perl). The chapter also starts us into the strange world of functional programming, where variables can only be given a value once (e.g you cannot do i=i+1), recursion replace loops and pattern matching replaces assignments. Fortunately the Erlang language is remarkably concise. For example there are only 4 data types. However to those coming from a purely procedural programming background the learning curve could be a steep one. Saying that the Author does a good job of leading you through the languages intricacies with examples being compared to code from languages such as Java to help keep your feet on solid programming ground.
The next 3 chapters move on to writing simple Erlang programs. As a quick aside, for anyone new to Erlang it is well worth examining the quicksort implementation described in chapter 3. Its conciseness and simplicity was one of the reasons the language won me over when I first met the language.
These chapters also cover error detection and handling. It's worth noting that Erlang has a philosophy of ensuring programs fail hard, so that bugs can be weeded out at an early stage. This idea very much defines how Erlang error handling is defined.
One criticism of the first section is Chapter 6, which describes compiling and running an Erlang program. I would have preferred that this information be covered earlier in the book or be placed in an appendix because it is probably an area you will want to reference repeatedly.
Chapter 7 is where things really get interesting and the true power of Erlang starts to come to the fore. This is where Erlang's concurrency credentials are explained. This chapter begins by providing some useful metaphors of the Erlang concurrent model, but chapter 8 is where the fun begins by describing the Erlang concurrency primitives that allow the creation of processes and the process communication methods. The author here highlights one of the language features, the Erlang light weight process. These are true processes (not threads) but take up very little in the way of resources. Indeed it is not unusual to have 1000's of such processes running in an application.
The next few chapters expand on the available concurrency primitives and how to move from concurrency on your local processor to concurrency utilizing the resources of multiple machines either on a local network or across the web. It finishes the section off by showing the example of a simple IRC application.
Chapter 12 starts the next section by looking at how to interact with the world outside the Erlang environment. First it examines how to interface an Erlang program to applications written in other languages such as C. It then goes onto to look at file and socket handling in Erlang. Chapter 15 looks at two important Erlang storage primitives ETS and DETS before we get to the OTP Erlang libraries in Chapter 16.
The OTP libraries are the standard Erlang libraries and tools. In fact the OTP libraries are worthy of a book in itself. The author highlights the section on the generic Server module as the most important section in the whole book and one to be reread until its importance has sunk in. This is because here are encapsulated many of the lessons learned in writing industrial fault-tolerant applications, such the updating of a running applications code without causing that application to miss a beat. The section is finished off by describing the Erlang distributed database (humorously named Mnesia) and then finishing it off with the example of a simple server application.
The book finishes off by looking at Erlang on multicore systems including its support for SMP. As the author states this is the leading edge of present day Erlang and is still under development.
I would like to thank the pragmatic programmers for publishing this book. Erlang's profile has been in need of highlighting for many years and hopefully this book will help. The book definitely provides a great starting point for anyone who wants to get to grips with the language and takes them to the point where they can start writing useful applications. This book is a worthy successor to the last book published and does a good job of both updating the material and explaining some of the later developments such as SMP. Anyone who has a need for writing fault tolerant applications should at least look at this book. If nothing else you will never be afraid of dealing with recursion ever again.
In many ways the book cuts off just when things are getting interesting. There are hints in the book about real world Erlang's applications and it would have been good if some of these experiences could have been expanded. Hopefully this book is the start of increased exposure for Erlang. If so then someone may get around to writing another Erlang book describing some of the advanced issues about generating robust applications. I just hope it won't take another 10 years this time.
Tony Pedley is a senior engineer specializing in real-time embedded systems. In his spare time he likes to tease windows programmers and confuse managers by telling them it would be a lot easier if we wrote it in Erlang.
You can purchase Programming Erlang - Software For A Concurrent World from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What's missing from Erlang... (Score:5, Interesting)
The design issue, for me, was a lack of namespaces. I think it might have been that I can't have an atom with a namespace, beyond prefixing, which is a hack for languages that don't support namespaces.
The implementation issue was that you had to choose between performance and being able to reload functions later. I would very much like it to be able to JIT or even compile down to binary (x86_64 too, pretty please?), then be able to just leave it running, and have it reload functions as needed.
I'll have to think of what else I didn't like, but I don't think there was much, aside from some odd syntax. I don't actually have a problem with the somewhat functional nature of it, just certain syntax that looks ugly, but that's a matter of opinion, and something I can live with.
Re:Possibly the greatest programming book I've rea (Score:4, Interesting)
Re:I know why it's been 10 years (Score:3, Interesting)
target = map (f . g) source_list
A minor shift in syntax, and dropping a lot of superfluous parentheses from the language and adding sugar (.) for function composition goes a long way to cleaning that up into something readable. =)
The main strengths of functional programming come when you start thinking about functions as first class values.
Here the function obtained by composing f and g became a new function that was usable just like the primitives you built it up from. To do the same in say c++, c#, c, java, etc. you'd have to fall back on building up a struct or class and overloading method invocation on that class to get a function-like thing representing the idea of "do this, then do that to the result".
Javascript gets the concept of closures right but the syntax for their functions is very verbose:
function compose2(f,g) { return function(x) { return f(g(x)); } }
vs.
compose2 f g x = f (g x)
Re:Wings3D (Score:3, Interesting)
Re:Try it out (Score:3, Interesting)
You are right on reasonably short time scales (a year or two) at a single organization. On longer time scales, new languages do get used and new programming teams are hired / trained to use them. Consider the adoption of C#. A couple years ago, there were zero C# developers in the world - today, it's mandated by many PHB's.
Sure, more drastically different languages take longer to be adopted. Consider how the adoption of OO programming languages occured in the late 80's and 90's. First, hybrid languages like C++ were created. Then, once C++ had already been adopted, we got stuff like Java. Today, OO is mainstream. I fully expect that any uptake of functional programming will occur the same way - with transitional languages and years of advance warning.
This will be interesting to watch. It looks to me like we'll get to 32 cores in a high end workstation (and 8 - 16 in a moderate desktop) before anyone seriously questions buying more cores any more than they already question buying faster hardware in general and that programmers are going to be suffering with locks and threads for a long time. If something significantly better comes along in the form of a new language, people may adopt it - the business case for saving programmer time and using existing hardware better is damn good. Erlang isn't that language for various reasons, but some sort of Erlang/Ruby or Erlang/Java hybrid might be.
Re:apropos erlang (Go Sweden!) (Score:3, Interesting)
Re:Lisp, you say? (Score:3, Interesting)
- Common Lisp was designed with a strong bent towards practical utility. It has a lot of features* and features that aren't necessarily clean**, but are included because of usefulness or backwards compatibility reasons. Scheme was designed first and foremost to be a very clean, pure language. It's easy to learn, and you can hold the whole thing in your head without much effort.
- Common Lisp is a big standard, which means practical code can be written without implementation-specific libraries. Scheme code tends to depend heavily on implementation libraries as a result of a smaller standard. In _practice_ there is a fairly substantial body of portable Common Lisp libraries. In _practice_, most Scheme libraries tend to be fairly implementation-specific, though some implementations (PLT, Chez) have rather extensive libraries. CL has Cliki and ASDF, which gives you CPAN-like installation of a fairly nice set of libraries. I don't believe Scheme has anything similar.
- Common Lisp is a multi-paradigm language. It supports functional programming, imperative programming, and OOP. It has really good iteration constructs (LOOP, Iterate package), and a good object system (CLOS). Common Lisp programmers tend to write code that's a mix of functional and imperative styles. Scheme is decidedly a functional language. It has no object-system built in, no fancy iteration constructs built in, and Scheme programmers tend to write code in a very functional style.
- Common Lisp is in practice faster. It has features like optional declarations to help out the compiler, and the native-code compilers for CL have had a lot of work put into them. Scheme is also quite fast, but I don't get the impression that Scheme implementations (except maybe for the commercial Chez Scheme) are in the same league.
*) Package (module) system, CLOS, generic sequences, LOOP, etc.
**) Scheme has one namespace for functions, values, and types. Common Lisp has multiple namespaces. In CL, you can name a variable "list", without worrying about it conflicting with the function "list". The syntax disambiguates the uses. Also, Common Lisp has a low-level, procedural macro feature. You can use the full language during macro-expansion (say to expand the macro differently based on the contents of a file). In Scheme, you get a weaker, but safer, template substitution-based macro system.
Re:Programming languages based on English (Score:3, Interesting)