Slashdot Mirror
Programming Erlang
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.
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.
The first chapter is avalable online to get a taste of the book (and the language).
I bought the book while it was still being written. I was able to download drafts, and (if I had the time) submit bug reports. When it was finally done, I got a printed copy in the mail.
I haven't had much time to play with Erlang (or the book) yet, but it was a really nice feeling to be able to get early access as long as I was willing to see unpolished content. Bravo, publisher.
Last I checked, there was an implementation issue and a design issue.
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.
Don't thank God, thank a doctor!
Perhaps it should have been given another name than a common statistical probability distribution (for some reason people who explore new programming languages are often interested in math and may therefore mix things up)
http://en.wikipedia.org/wiki/Erlang_distribution
The Ericsson Language, for those who have not been exposed to it, is a programming language meant to make concurrent (multi-process, multi-processor, multi-machine) programming really simple. It's used on many AXE telephone base stations world-wide. It has great message-passing support, and a pretty nice library. It is actually not a functional language, but a logical one. Basically a perverted version of Prolog.
I choose to remain celibate, like my father and his father before him.
This book is written by the language's creator, Joe Armstrong, and provides one of the best introductions to a programming language I've ever seen. The entire approach is nicely bottom up, with the idiosyncrasies of the syntax presented immediately so they are not confusing later. More powerful features are introduced, such as the tools for concurrent and distributed programming, with the book finishing off with the immensely powerful Open Telcom Platform and its associated tools, such as the "one server to rule them all" gen_server implementation and Erlang's distributed database, Mnesia.
All in all this is an excellent book about an excellent language and I would highly recommend it to any programmer, especially those concerned with the multicore future which will increasingly demand concurrent programming languages.
Strange that I didn't see Wings3D mentioned yet. ( http://www.wings3d.com/ )
It's an open-source subdivision surface modeler held to great esteem in the modeling scene
It is also an Erlang application....
One of the first alternatives as for the 'normal' jabber server implementation was written in erlang. Resulting in ejabberd people care :)
Support Eachother, Copy Dutch Property!
And in my opinion; If you are familiar with more common languages like C and Java you should take a deeper look into Erlang unless you prefer to study Prolog or Cobol. Just take a dip or a deep plunge, you never know when you end up in a project where knowing Erlang may prove useful - it is actually developed to be used in real applications and not as a theoretical study object.
And Erlang is designed to handle concurrent programming from the bottom, which is a real problem in large multi-user systems. You can of course use C or Java and solve concurrency problems with semaphores or synchronization, but the solution in Erlang may be much more elegant.
And for all of you that are familiar with the Eclipse development environment; There is a plugin called Erlide.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Lets look at these "sins":
1. Not a sin, not needed and shows you don't know what you're talking about wrt reliability. hard real time is irrelevant.
2. More FUD based on your lack of understanding of programming.
3. is a downright lie
4. Contradicts three!
5. Ok, now I'm thinking you're not just a troll but verifiably insane. Show us a language (one that exists outside your head) thats not "alkorithmic"
6. Contradicts itself- is it based on english or is it cryptic?
7. Asinine in the extreme, and of course contradicted by the other 6 points. erlang is not logo
Bottom line- you are just making assertions that make no sense. If you ever were a programmer, you never learned much about programming... and your constant bashing of erlang is just an attempt to get attention. COSA doesn't exist, except in your head, where it can be magical and change as is needed for you to make whatever "point" you want to make.
I guess its a sign that erlang is becomming mainstream that it has attracted a loon such as yourself.
I pulled this example from Wikipedia:
The first block of code is easy to understand. The second block, whoah, I guess I just have to take your word that it does the same thing as the first block. Can someone give me an introduction/explanation to Erlang / functional programming that I can understand? At this point, I don't even understand what situations this could be usefully applied to.
It seems interesting though...
Summary: "Erlang isn't based on my fringe pet theory, so it sucks".
My vote for best introduction-to-programming book goes to Structure and Interpretation of Computer Programs (a.k.a. The Wizard Book) by Hal Abelson, Jerry Sussman, and Julie Sussman.
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.
Beware of bugs in the above code; I have only proved it correct, not tried it.
I often judge the quality of something by looking at the quality of the criticisms of it. If that's the best criticism of Erlang that you can find (or come up with) then Erlang looks pretty damn good. Of course, if you could see your way clear to describing how to write programs without implementing algorithms instead of simply explaining in great detail that algorithmic software is bad, maybe I would find it easier to embrace your view of programming.
That is the same guy who says you can get artificial intelligence from the bible. He's a loon with a large vocabulary.
It's just another angry rant, quick to denounce anybody that disagrees. I can get those from deranged street people or by staying on slashdot.
I had my first encounter with Erlang at a Ericsson presentation back in 1994. It's amazing that more than ten years have passed since then, and only now is the language becoming more mainstream! This new-found attention is well-deserved, however: Erlang will feel right at home in those +80 CPU cores on the horizon...
As for other less conventional languages, OCaml also definitely deserves a look. It is functional, though also allows imperative features; it has a powerful module system, but also supports object-oriented programming; it has a certain academic feel, but real-world performance (check the shootout if you want: it's among the fastest ones, comparable to C++) and a very good and comprehensive repository of libraries (even for low-level stuff!). Definitely one of the best things to come out of France in recent memory!
the new programming language du jour.
A counter-counter-opinion: http://www.planeterlang.org/story.php?title=Erlang _vs-_Trolls
p ot
And don't forget: http://www.google.com/search?q=louis+savain+crack
Before you design for reuse, make sure to design it for use.
Well, thats it.
The blog you link (especially the authors reactions to criticism in the comments) show that he should really have been aborted when it was still possible.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
Overall, the book is very good: the examples are clear and useful, and for an old Prolog programmer like me, Erlang has a natural feel to it.
I have been disappointed that none of my customers seem to be interested in Erlang development - I proposed using it for one application where 'share nothing' asynchronous communication seemed like a very good fit.
Programming Erlang is the best intro-to-new-programming language book I've ever read. By far. While erlang is radically different than previous languages I've learned, this book goes a long way to making the transition smooth.
I'm still struggling, but I read the book with an application in mind, and have found its coverage is excellent... it brings you right up to the point that is needed for the other erlang documentation to be readable. (There are 60 some odd books on all the major components of erlang and OTP, including the major modules and APIs... they are downloadable from erlang.org)
So, this book accomplishes its goal and really well. ITs not a shallow marketing piece about the language (as most books written by writers rather than programmers are) its a real how-to-program in erlang book and it does a great job of showing how you solve very difficult problems in erlang. It even has as examples things like full text indexing and map reduce.
I think every programmer worth his salt should buy this and learn erlang-- the days of single core computing are over, and thus concurrency oriented programming is a critical skill to pick up, and erlang is the best language for it.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
Would a good analogy be that an Erlang process is comparable to an object instance, in that both are loosely coupled (ideally), focused on one task (ideally), but in Erlang they're all running asynchronously and the OS/runtime automatically handles the communications for you?
Chip H.
and his mother shot in the face during the procedure; you just can't be too careful in cases like this
Its surely a dumb idea for applications written in languages like C and Java... but not for erlang.
Remember, systems running this language have had uptime on the order of many years, and that's with in-place code modification.
You're rejecting what you don't understand based on assumptions that are true for other contexts.
Downtime is a sin, not a virtue!
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
You wouldn't *test* the modified code in the production environment, you do that in the lab. But it can definately be useful to modify apps on the fly without taking down the system.
In fact, the company that I work for has done exactly this for C/C++ apps on four different hardware architectures. (There are restrictions....its basically impossible to modify an inline function, for instance.)
Regardless of what the virtues of the language at hand, it is never a good idea to modify code directly in production without running a full suit of tests against the code. Businesses that rely on software applications running their systems must have well defined deployment processes. Code that goes into production must be tested against the specified requirements. While Erland (just like Javascript for example) supports dynamic typing, and while it allows (just like Javascript) updating functional code on the fly, it is still a terrible idea to allow developers to work on production systems directly without deploying code into testing and staging environments first. I'll just stop there.
You can't handle the truth.
your detractors are merely laughing at your complete ignorance of computation and your silly worthless pet project, it's doubtful you could do anything to get them actually mad, though your straw man argument about sorts is vaguely annoying.
"Hannibal's plans never work right. They just work." Amy/A-Team
You are talking about a partial deployment, this can be specified as one possible deployment process to update production, and it is still a bad idea because at this point it is not possible to say for sure that what is running in production was built from a specific source controlling system's tag for example.
So while it may work for some special cases, I am saying it is just a bad idea to do deployments like this as a principle, you can't be sure what is running in production at some point.
You can't handle the truth.
A great book on Erlang, but missing a few details on the usage of common libraries. In particular it could do with more information on how to drive the Mnesia database. I started programming Erlang a month ago and the shortage of implementation docs on the database and list libraries has been a problem for me.
:v)
Yes, I do know about the Ericsson Mnesia manual and http://trapexit.org/
Vik
Your criticism is completely irrelevant to the language feature. That the language (and runtime) allow for live updates does not mean that enforces (or encourages) live *edits*!
-josh
See, here's the thing: I can download Erlang and start to learn it right now. Where can I find COSA? That's right, it's vaporware.
Who knows, you may be on to something. I'd suggest writing fewer white papers and less name-calling of your detractors and get busy implementing your vision. Nothing will shut them up faster when you've got something that lets people develop systems that are more reliable for no extra cost.
Until then, you're in the same category as people who promise us perpetual motion machines and anti-gravity levitation.
It's worth noting that ejabberd is written in Erlang.
For those who haven't heard about it, it's an open source, distributed, fault-tolerant instant messaging server (Jabber/XMPP), modular and very configurable and is readily available in most Linux distributions' repositories.
It's one of the most promiment erlang-based projects.
It's worth looking at
h p?test=all&lang=hipe&lang2=hipe
http://shootout.alioth.debian.org/gp4/benchmark.p
for the general performance of erlang. It compares unfavorably in those tests to lisp and clean, two other functional programming languages.
Use the Firehose to mod down Second Life stories!
It is not irrelevant from my point of view, because I have seen people pushing this language forward on this particular merit, that the deployment can be done without a real deployment by modifying code in production on the fly. Since that (and the dynamic typing) was the main reason why I have seen people try and push the use of this language forward, I don't think it's irrelevant.
You can't handle the truth.
As somebody writing code in Erlang as a profession, I say, though it has strength, it's crap. It has strength in the efficient handling of many processes (faster then the OS when there are many many thousands of them), aand (re)loading modules on the fly into the virtualmachine is nice. But on the flipside Erlang is slow as it's a very high level language, with a not so clever virtual machine - much less so than java vms (well I have to admit I am an assembly&C fan). Also functional programming my ass. In reality it's more like very basic barebone declarative programming, where you can only use global variables (mnesia database, and in worse cases the process dictionary) and there are no loop constructs (you can only use ugly additional functions and recursion instead of a "for" construct). Well, at least this is my opinion.
to give you an example of something built in Erlang take a look at http://www.couchdb.com/ CouchDB is an Open Source (GPL) database back end. It is in some ways inspired by the database architecture of Lotus Notes, it is a non-relational document based store with strong replication ability. Don't bother bitching about Notes, the new UI is quite different to the old look (personally I liked the old style) but CouchDB doesn't have a UI, it has similarities at the architecture level which is where Notes is very very good indeed, and CouchDB is better.
Yep, it's definitely all the millions poured into Erlang development and publicity that made it the COSA killer it is today.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
From what I understand through a cursory look at your COSA web pages, I get the impression that you are pushing a graphical language that is somewhat like National Instruments' LabVIEW. Have you used LabVIEW? If so, how is it similar/different to your COSA "ideal"?
> So while it may work for some special cases, I am
> saying it is just a bad idea to do deployments like
> this as a principle, you can't be sure what is running
> in production at some point.
Decision Point:
Choose from these options:
1. Side with a Slashdotter who refuses to accept that
this isn't testing-in-production;
2. Trust telecoms companies who do this with Erlang
FOR REAL with MILLIONS OF DOLLARS on the line,
literally.
Well shucks I don't know....
I'll have to check it out again.
What are the options for compilation? Anything beyond simply distributing source code?
Don't thank God, thank a doctor!
Yes, that's right. I'm completely fanatical for a language I've never used. I'm rolling my eyes now... just in case the sarcasm went totally over your head.
Why do I have to fork up the money? You're the one with the extraordinary claims of dramatic reliability increases. If you're so much more brilliant than the rest of us, it shouldn't be terribly difficult for you to at least create something a little more sophisticated than something that looks like an OmniGraffle demo on stupid pills in a few weekends. I just want to know: Will COSA let us reprogram the Time Cube?
Before you replied, I wasn't sure if you were a complete crackpot. Thank you for resolving the question.
Seriously, is it? Because those criticisms are pathetic, and two contradict each other.
I'd actually like to read a serious criticism of Erlang. I finished "Programming Erlang" on Sunday, and like many folks, I'm mildly jazzed about Erlang. The syntax hurts somewhat, but then again I spend all day coding Python. And while I can think functionally somewhat, I have a hard time imagining larger systems without OOP, but that's probably my lack of experience.
I'm ready to do something good with Erlang, but I'd like more contrary opinions before I do so.
(The book was outstanding--a pleasure to read.)
The "download PDF first, get dead tree later" approach is a huge winner for tech books. I did the same with "Programming Erlang," and it allowed me to get through the first few chapters on my iPhone (Safari does some magic that renders PDF very well), then read the rest on paper. Then I read Chapter 8 online again because I'd left the book home. Very convenient, and closer to Instant Gratification.
I'm probably not the only one waiting (and waiting...) for djangobook.com to get published finally, but a 2/3 finished PDF would have made me 2/3 happy in the interim.
It's very different, but the big advantage is that it's higher level than the stuff you confess to understanding better.
The code in question (in Python? not a great choice for doing an example!) uses two very common higher-order operations in functional programming: map and compose. A map operation takes a complex data structure (most common example: a list), and a function that applies to elements of that data structure, and returns another structure, with the same "shape," where each element in the result is related to its corresponding element in the original structure by being the result of apply the function. Thus, if you have a list [2, 3, 5, 7], and a function inc that increments a number by one, map(inc, [2, 3, 5, 7]) evaluates to [3, 4, 6, 8].
In the case of a list, map is can be implemented by creating a new list of the same length as the original, looping over the list, applying the function to each value, and storing the result in the result list. This is a kind of task that imperative programmers find themselves doing all the time. The problem with this, however, is that if you're writing code like this all the time, you're writing at a much too low level, with the all the disadvantages of that:
Are you adequate?
3. Read carefully what the /.er wrote about special cases. In most cases this mode of deployment is unacceptable, like in most places I've worked as, which include telcos, utilities, banks, mutual funds, manufacturing and such.
4. Profit from selling Erland as another silver bullet that will save the day.
You can't handle the truth.
live code updates are an up-front requirement for the domain Erlang addresses. Google "nine nines" if you don't understand why.
Foaming at the mouth? No, you;re misunderstanding. we're either on the floor laughing at your stupidity or starting dumbfounded at our screens wondering how someone as stupid as you can possibly exist.
Please do continue posting as it's endlessly amusing, people like you are like digital clowns. After all every society needs a town idiot to make everyone else feel better about themselves.
man, I feel like mold.
I must assume it's actually trivial and obvious.
that of course was just a juvenile joke. and I really don't like Erlang or my nick would be Erlangcodez. LISP of course is the language that can do anything and everything, but who wants to squint at that offal?
I think it's worthwhile to point out you also say things like this:
"Kurt Gödel (how could I forget him?) is one of the gods of the voodoo science pantheon. Gödel is certainly the most often quoted yet inconsequential mathematician of the world. He is known for his incompleteness theorem, the most non-scientific, chicken-feather-voodoo nonsense ever penned by a member of the human species. In 1949, Gödel announced to the world that Einstein's general theory of relativity allows time travel to the past via "closed time-like curves." The only thing Gödel proved, in my opinion, was the incompleteness of his frontal lobe."
So your opinions are just so much loudmouthed nonsense.
Nobody live-updates a running Erlang (or Lisp, which does the same thing), without deploying the code into a test environment first. The thing that live-update let's you do is take a well-tested and well-debugged piece of code and inject it into a running service without stopping the service.
AT&T uses Lisp for some of their call routing equipment for the same reason. If you need to add a new feature to a switch, you cannot drop the call's it's handling to swap out the software.
There are also lot's of uses of live-updating in non-productive environments. For example, it can be used as a development model, drastically reducing the edit/compile/debug cycle. When I write Lisp code (I presume Erlang programmers would be similar here), I rarely restart the program I'm debugging to recompile it. For example, my current Lisp image has an uptime of about 2 days. That means for the last two days, I've been incrementally compiling and testing my changes into the same running process.
It's also very helpful when the test scenario for the software is complicated. I maintain some software that does data collection/analysis of spectrum traces. Testing the software involves hooking up an antenna to a big awkward machine and going outside. The program is unfortunately written in C, which means I waste a lot of time shuttling back and forth between the test environment and the compiler. If I could stop the trace in the middle, make small changes, and keep going, my testing time would go way down.
A deep unwavering belief is a sure sign you're missing something...
Here is a classic paper on the style and advantages of functional programming:
m l
u s.pdf
http://www.math.chalmers.se/~rjmh/Papers/whyfp.ht
Also, John Backus' Turing Aware lecture, "Can Programming Be Liberated from the Von Neumann Style?"
http://www.stanford.edu/class/cs242/readings/back
Oh, and in reply to your other comment about the amount of backing that Erlang had; the first version was written in Prolog in a week by two guys. It wasn't fast, but it was a good enough prototype to persuade people to invest in developing the full version. If you're looking for investment in your pet project, I suggest you do the same thing.
I am TheRaven on Soylent News
I am not arguing that some environments accepted this mode of deployment, I am insistant that in most cases this is counter-productive. One of the reasons is that you cannot know for sure what is running on production. Let's just hope that the author of every change that goes to production spent time adding the change to the source control system of the code and that the code is tested before it is injected into production. However beeing a contractor who is constantly asked to work on projects that have misplaced documentation and sometimes evens source code, I would hate beeing responsible for ensuring that what is in production is the same thing that is found in the source.
You can't handle the truth.
Obviously you "modify on the fly" your test server first, and then once you've tested it (as usual), you "modify on the fly" your production server. I fail to see the problem here.
-- The act of censorship is always worse than whatever is being censored. Always.
"Last" as in "most recent", not "last" as in "ultimate" or "final."
Program Intellivision!
You sir, have been trolled by the author. Congrats.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Talk's cheap why don't you just upload an implementation your quaint little language to a server and show us your parallel quicksort algorithm.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
An article on functional programming is the perfect time to introduce my new son, Nick, to Slashdot. Previous releases were in C, Perl, and Python. Since Nick's functional, this one is in Lisp.
Mod me up or my son will spit up on you.
Dewey, what part of this looks like authorities should be involved?
For my bachelor's I was required to take a Programming Languages course. Unfortunately, I'm finding many other students that went to other universities don't have the same requirements or the same type of professor I had.
The course covers different areas of programming languages: imperative (C, Perl, basic), object oriented (C++, Java, Smalltalk), functional (lisp, scheme), and logic (Prolog). My professor did the smart thing (or the thing he liked the most if you want to look at it from another perspective) and started the course by teaching Prolog. Everyone up till this point had been exposed to imperative and OO programming styles so Prolog even for me was very new. But it made the other thing CS students cringe on much easier. That other this is pure functional languages like pure Lisp and pure Scheme.
Very briefly, Prolog is a logic based language. What you're used to and what most of the world uses is some mixture of imperative programming and OO programming (though that's slowly changing). In those types of languages it's basically like coming up with a set of steps to execute in order to perform some operation of algorithm; you think in the order in which you would perform the operation most of the time. Prolog is completely different. Instead, you take a more mathematical approach and come up with a set of rules. A common problem that's easily solved in this manner is explaining a family tree with a grandparent relationship. In a logic based language, the procedure is something like:
Once that's completed, then you "ask" the program for rules that are true and it should return true or false. So in the above examples, I could ask "is John a grand parent of Amy, and prolog would return true, and I could also ask "is John a grand parent of Jane, and prolog would return false. There was never an instance of the programmer defining anything except logic based rules. However, because of this, the program can now answer all questions that fit within that set of rules. As you might imagine, when you are trying to implement not so trivial things like sorting lists, logic based programming gets really strange to think in.
But that strangeness pays off because at some point you will have learned essentially what you needed to get by in functional programming: recursion. Everything in functional programming is done by recursion and as you might guess functions. In "pure" functional programming, there is no such thing as a "variable". All functions operate on a list data structure with functions that only allow you to access the head item the next item because by definition, you could just keep taking the next item to traverse the list. Functional programming isn't actually that bad once you've gotten your head over how to use recursion to replace almost any loop.
For example lets take adding all the numbers in a given list with only functions. In the imperative style you'd probably use an accumulator just as you normally do when you physically add numbers:
However in functional programming, we have no variables and we have only have functions. Therefore, we need to define what it means to add the numbers in a list using functions and recursion:
Psuedo code aside, all I have are two functions, the first is basically the definition of addition. The second is the definition of adding numbers in a list in terms of recursion. In English, that is: the sum of a list of numbers is the first number in the list plus the sum of the remaining list of numbers.
Re
Oh my god, that's the funniest thing I've read today. "COSA killer." Duke Nukem Forever, dooood!
The problem is that you are left with a production environment in a state that is not supported by a production tag module in your source control system.
Who can guarantee that what is in CVS for example is in production? Obviously this cannot be guaranteed without some sort of a process. I don't doubt that there are situations when this is the best working approach to deal with deployments given the other choices, but for most production systems this will mean production will be out of synch with code in the code control systems. I wouldn't want to see that happen too widespread, I already have to maintain many things other people create, I don't want to be also responsible for ensuring that what is dynamically loaded into production is exactly what is in the source control.
You can't handle the truth.
"it is never a good idea to modify code directly in production without running a full suit of tests against the code" Nice dodge and weave there. You should have stopped before your first comment.
Why exactly do you expect me to care about Erlang, I've never even heard of it before today.
I love 6. It doesn't even make sense. Should we be using English or 6502 machine code for programming in the future?
6. It is a computer language (based on English). Why English? Why not Mandarin, Swahili, Romansh or Latin for that matter? Programming a computer should have absolutely nothing to do with one's mother tongue. Written code is notoriously hard to understand, even when it is your own code. Only programming nerds are enamored with cryptic code. It's a badge of honor to them. Truth is, the very fact that programming has to rely on a specific natural language is a sure sign that something is wrong with the linguistic approach. Not to mention the nasty little fact that languages are inherently sequential, which makes them ill-suited to parallel programming.
“Common sense is not so common.” — Voltaire
I am insistant that in most cases this is counter-productive.
I don't think you have enough (or any) experience with the feature to be able to make that sort of judgement. Live updates are a tool, like any other tool, they can be used poorly or well.
One of the reasons is that you cannot know for sure what is running on production.
It depends on the system. Commercial Smalltalk environments that support this feature let you introspect into the code running in the system. At the same time, proper configuration management tools can also be used to keep track of changes to live images.
Let's just hope that the author of every change that goes to production spent time adding the change to the source control system of the code and that the code is tested before it is injected into production.
The way these systems are usually used, the changes are entered into the source code of the system, and then incrementally compiled into the running image. Thus, you can SCM the change like any other source-level change. And yes, one would inject untested changes into a running system, but you have the same possibilities of putting untested changes into production even without live updates. You can't fix a people problem like this by eliminating an otherwise useful feature.
A deep unwavering belief is a sure sign you're missing something...
You're right, you'd have to enforce this with some sort of process. But for systems that absolutely must not go down, it seems like a small price to pay.
I'm not sure I follow -- I don't think the Erlang folks are suggesting that people upgrade some things and not others. Is your concern just that the upgrade from one tagged state to the next isn't atomic?
DNA just wants to be free...
Don't care about the entire comment, since the following is false
I don't think you have enough (or any) experience with the feature to be able to make that sort of judgement. Live updates are a tool, like any other tool, they can be used poorly or well.
- it is false simply because of my sig. And if you don't get why, I won't be explaining. Cheers.
You can't handle the truth.
"COSA is 100% reactive, that is, it is based on change."
Or would be if it... you know, existed.
lol
I'm sure you're taking the Internet crank world by storm. Best of luck to you.
Have you used live updates in a Lisp, SmallTalk, or Erlang environment? If not, then what the hell are you squawking about?
A deep unwavering belief is a sure sign you're missing something...
Dance for me, puppet. Tell me more about Erlang.
The informed know more about Erlang than you do. They know your opinion doesn't matter. But they also know your opinion is entertaining.
After all, I am strangely colored.
I've put some thought into this particular topic a while ago. I wondered what it would be like to have a computer language that didn't use english (or any human language) tags for it's keywords. The thinking was, what is easier to read or write: 1 + 2, or 1 plus 2? To me, the symbol form seems more natural.
An example of using symbols where you would normally have a keyword is in C's conditional expression, " x y ? z : n ", which is read as "(if) x y (then) z (else) n". What if this syntax was used wherever an if/else pair is used, would it be more readable? And, can it be extended to loops, so that you had an iterative inline conditional, such as "x y ?? z : n", which is read as "(while) x y (do) z (else) n", where the "else" clause is executed only if the initial condition started off false. So the entire expression returns eiter the final result of z, or n in the case that z never gets evaluated.
So to try this out, I started putting together an interpreter that used this syntax (it's on lang2e.sourceforge.net if any one is interested). So far it seems to be working out ok, but the one area that I couldn't get away from using english keywords is in the standard function library. But technically that isn't part of the core language definition, but it is included with the base interpreter.
It's still a pretty minor point, because it's really easy to write functions like map, to understand them, and to unit test them. In fact, this makes the functional program easier to debug. When you split out your "looping" into a generic higher order function to provide the structure, and an argument functions to provide the case-specific logic and transitions, you can test them independently.
Are you adequate?
I followed his link in that bullet point to his page describing his concepts for avoiding "algorithmic programming" (what I think he means is imperative or sequential programming). What is described there (as circuit programming?) kind of looks like pipeline programming, where you have modules that take input and deliver output just like a Unix pipe, but instead of only one input and one output you get multiple inputs/outputs. This is actually looks like a Hartman Pipeline, combined with a standardized (structured?) message passing framework.
Or, maybe I completely missed what he was saying, and that's the best interpretation I can come up with. My brain still hasn't kicked in yet.
No, people are suggesting that it is a good idea to update code in applications in real time without a complete redeployment, which should include storing modifications that are going to be applied to production within some sort of a source control system, then installing the entire code base that will be deployed in production to some testing / staging environment, then moving code to production.
I am saying that allowing deployments of a function or of a line of code to production needs to be done only in very special cases and controlled environments that have processes that allow for these kinds of modifications.
Situation:
1. Full deployment.
2. A new requirement is created.
3. Code is created to satisfy the new requirement.
4. Code is placed into production by deployment of a dynamic function without a full deployment.
Problem: ensuring that between the steps 3 and 4 there are more steps:
3.1 Code is stored in the code repository (for example CVS.)
3.2 The entire code base from the code repository is deployed to a test / staging environment.
3.3 The tests are done, requirements are handled satisfactory and without bugs.
3.4 The code in the code repository is tagged with a deployment number.
3.6 Documentation is updated to state that the newest code to be placed onto production can be found under the newly created tag.
If the steps between 3 and 4 are missed, then nobody will be able to say what is actually running on production.
Even worse, if the deployment procedure relies on developers modifying code in production without a full deployment, so that only some functions are updated in memory, then certainly there will be situations when the developers will have the opportunity and desire to change the code even more, so that quick fixes are introduced into the production environment skipping any testing and possibly losing track of the changes in source control.
Once this becomes the case, nobody can be sure that what is running in production is the same code that is in the code repository. I wouldn't want to maintain that kind of a system.
You can't handle the truth.
Blow me, any process that allows developers to add code to systems in real time may and will produce situations where the production code is out of sync with the code in the source repository. That is a nightmare to maintain.
You can't handle the truth.
ML, Scheme AND what you missed, you pompous buffoon, FF javascript modules in over 100,000 user installations.
You can't handle the truth.
I am (well, was, at least) an Erlang Programmer. I was toying around with Erlang for some small projects with distributed programming.
I've been looking forward to Joe's book for a long time, as he's one of the few big names in the Erlang community, and has done a lot of work (both code and, even more importantly, documentation) for the community -- first that jumps to mind is his important look at Yaws vs. apache.
There are serious problems with the Erlang language as a whole and the community, right now. The mailing lists are actually pretty good, but quite frankly, the documentation online is terrible and the Erlang interpreter is pretty rudimentary. Not to mention basic problems with the syntax and grammar of the Erlang language itself. When I was learning Erlang a few months back, I was pretty frustrated that about the only source of documentation was on erlang.org, and they.. weren't great. For instance, there needs to be a big warning right at the beginning explaining that atomic values always start with a lowercase letter and all other variables must begin with a capital letter. This must be a huge problem for other beginners (at least, I hope I assume I wasn't alone..) compounded by the unfriendliness of the error messages produced by the Erlang interpreter.
Now that I've switched over to doing as much as I can in Python, which has a great user community, wonderful docs, a healthy standard library, and a reasonably helpful interpreter.. I don't really worry about Erlang that much anymore. It would be wonderful if I could write, say, web crawlers (I work in web security) in Erlang. But the mysql support in Erlang looks alpha-quality at best, and AFAIK there's nothing even remotely similar to Python's urllib2 for basic web client functionality in Erlang.
I think it says a lot that so much attention is paid to a language that is so rough around the edges, unfriendly, and lacking in documentation. Even given all that.. the ease of use of the concurrency and message passing in Erlang is so fantastic that it almost makes up for the rough spots.
On a final note, I'd like to point out to anyone interested that I think there's a huge void out there for a language that's as easy to use and learn as Python, but with the concurrency and message passing in Erlang. It actually might not take that much work to build a network-transparent message passing interface as a Python module (I've looked into Pyro a bit.. it looks rather cumbersome and makes easy things too hard, correct me if I'm wrong). Also, modern languages need basic support for splitting up the workloads of map() or similar trivially parallelizable functions across multiple processors/cores (I know the Perl6 group was thinking about this.. not sure if this works in Parrot now or what). Basically, modern languages like Python/Perl/Ruby should really think more about making simple modules to mimic the message passing that Erlang has. Really, a little bit of code could go a long way. The Google team put together sawzall which looks kind of cool, on this note..
http://cltracker.net -- powerful craigslist multi-city search
slashdot exists for my amusement, I'm having fun sorry you aren't
What do any of these things have to do with live update in Lisp and Erlang? Look, I'm not questioning your experience in general here. What I'm saying is that unless you've worked with a live update system in one of the languages that treats live update as a core feature (Common Lisp, Erlang, and Smalltalk), you really are missing the perspective necessary to comment on the feature.
Much moreso than ML, Scheme, or JS, Common Lisp, Smalltalk, and Erlang are languages for practical production work. A lot of experience with real-world systems have gone into the implementations of these languages, at multiple companies over a period of over two decades. All of this time, live-update has remained an important feature of these implementations. Either the idea is not as bad in production use as you seem to think, or the Lisp/Smalltalk/Erlang folks at Franz, LispWorks, Ericsson, Xerox, Apple, IBM, etc, are just misguided.
A deep unwavering belief is a sure sign you're missing something...
I can only assume you meant that sarcastically. That archaic and non-relevant book almost turned me away from CS. It was the worst textbook I encountered in college. I held on to several of my textbooks from college, but this one went in the trash.
Protect your browser with the Force Safe Search add-on
Regardless of any feature provided by any language, any company that uses software for core businesses should have a deployment process. If the deployment process allows for real time updates of small portions of the code and all goes well because of the process every time and the systems are maintainable after all of this, then it works for them and there is no issue.
My point is that I have seen vendors pushing forward ideas that Erlang must be used specifically because it has this feature. However the businesses themselves would not allow this and for a good reason. Most businesses don't have processes and all necessary components for this to work without causing major problems down the road, specifically by allowing such a feature the updates to production cannot be controlled and verified that what is in production is exactly what is in the source control.
If it works for a business, good for them, it is only a tool to use for special purposes. Most businesses should stay out of this, because it will only bring them problems.
You can't handle the truth.
I think SICP is a good book, but some people don't think it's good as an introduction:
The Structure and Interpretation of the Computer Science Curriculum
What makes you think that?
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Erlang does not stand for Ericsson Language, it's named after the Danish engineer Agner Krarup Erlang. They say the duality is intentional, though.
xkcd is not in the sudoers file. This incident will be reported.
Why do Haskell, Erlang, Prolog, etc abandon the clean, easy-to-understand syntax of LISP? I was reading "Beautiful Code" and saw some Haskell and it looked like a mess just visually to the naked eye. A while back I tried to install a package written in Erlang and thought it was kind of ugly too. I wonder why the FP side of the universe hasn't stuck with the simple, clear syntax of LISP. The structured/OO side of the universe has standardized on C syntax (C, C++, C#, Java, Perl, etc etc etc) which may be quirky (like LISP is) but is standard and anyone who knows one can follow along code in the other. I know Common LISP and Scheme, but was so baffled by Haskell I wondered if the syntax was serious or a FP equivalent of INTERCAL. Some of these FP languages are incredibly marginal because they're inscrutable even if you've had some background in functional programming with LISP.
No I am not. The question was whether I have any experience with updating code on the fly in production. I said yes, I have, a few examples of that included code that does that specifically within FF browser. I am not talking about installing an extension either, just about injecting code into a live page and executing that code, that's what I had to do in that particular code.
You can't handle the truth.
It's about time, that someone posts a link to "Erlang, the Movie"! So here it comes:
http://www.youtube.com/watch?v=uKfKtXYLG78
Limiting creative, productive, activity to the young and fit.
How many voices are silenced because they don't have the academic sinecures, the foundation grants, that will allow them to contimue to work into old age without having to perform before an audience like a trained seal?
What is it about the Geek?
That he is the eternal adolescent who thinks himself immortal?
What gives him the right to say that the punishing pace of the concert tour is the only legitimate source of income for an artist. What makes hin think that you can build a house, raise a family, on the sales of a coffee mug?
I do, do you? If a browser goes down, who cares, if a switch goes down - that's an issue. I work for Bell ExpressVu through CGI right now, except for switches that probably do get updated in real time, there are thousands of other applications that do not use hot updates because the cost of maintenance goes up dramatically, especially if the production code gets out of sync with the code in the source control. The majority of applications in every business need to be maintained and for the majority of applications hot updates are not acceptable because they may lead to inconsistancies between the code repository and production and this is unacceptable. The level of involvement and the strictness of process for hot pluggable deployments has to be magnitudes higher than if hot updates are not used. Most apps cannot afford these kinds of costs and risks because most apps are not phone switches.
You can't handle the truth.
Wow I've never seen that TimeCube thing before... been reading a while but it just doesn't make sense. Maybe it was translated from another language by the same translator that produced this?
GIVE CONES CHANGE THE MACHINE!!!
Go hug some trees.
Again this is irrelevant to the language feature.
Systems which require reboots/restarts to update require testing and care to avoid problems on going live. This system which does not require a reboot/restart to update requires testing and care to avoid problems on going live.
The difference is that going live does not require you to become not-live in the process!
What is so hard to grasp here. You are complaining that this impressive technological achievement does not solve problems that it was not intended to solve, and that somehow because the process to validate correctness is not magically fixed, something is made worse.
Nothing is made worse, all the existing tools a quality-oriented software house can apply will work. The improvement is that the eventual update can be made without bringing the system down.
There are numerous *other* benefits to the language in question in terms of reliability, and conciseness which may lead to lower liklihood of problems regardless of this technological improvement. But you have yet to finger any actual problem other than your sense of worry over something you do not seem to understand.
-josh
Well, that makes total sense. The thing is that the Erlang/OTP Release infrastructure doesn't easily allow piecemeal updates; it's designed to enable full deployments with no (or minimal) downtime. You might be interested in reading about release handling principles under OTP. I'm sure the system can be abused, but it's not the free-for-all that some people seem to think.
DNA just wants to be free...
How to Design Programs is available online.
Great minds think alike; fools seldom differ.
Er...did you respond to the wrong person? I think my one-line post is in total agreement with what you said.
That's the funniest thing I've read in ages.
The author was joking, right?
Yes.
-josh