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!
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....
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.
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.
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 was actually named after the same guy.
a nguage
http://en.wikipedia.org/wiki/Erlang_programming_l
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
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
There is nothing in the second example that isn't completely familiar to anyone who has ever programmed in LISP, one the world's oldest programming languages.
Newbies, feh!
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.
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.
So, think, what are you actually trying to accomplish in the first block of code, in terms of the end-result.
... means a function that takes two parameters, F and G, and returns ... (note the return is implicit. In this case, the compose2 variable is assigned to a lambda that takes two functions F and G, and returns a third function that takes a value x and computes F(G(x)). Note that this is exactly the function we want to use to compute our list.
You're computing a list, target, where each item is computed by F(G(x)), where x is an item from source_list, taken in order.
Note that stuff like "iterating over source_list", and "appending to target" are not really important. They are certain necessary steps in one possible implementation of what you're trying to accomplish, but they're just incidental --- they're not part of the end result.
Now, map is a function that takes two arguments: a function that takes one parameter and a list. It constructs a new list equal in length to the source list, with each element obtained by calling the function on one element of the source list. Ie: if you do map(square_number, [1, 2, 3]) you get [1 4 9].
Now, let's look at the functional code. The first line is a function definition for the function compose2.
compose2 = lambda F, G: lambda x: (F(G(x))
lambda is a way of introducing a literal function, much like "1" is a literal integer. lambda F, G:
Now let's look at the second line:
target = map(compose2(F,G), source_list)
The code first calls compose2 with parameters F and G to get a function that computes F(G(x)). Note that this function is exactly in the form expected by map. Then it calls map with that function, and the source list. Map will internally apply F(G(x)) to each x in source_list, and retrn a list containing the results.
Note that usually stuff like compose2 will be a standard library function, because this sort of thing is so common. In that case, your original five lines of code, becomes a single line, that expresses exactly the end result you want, without being cluttered with incidental details like iterating over or appending to a list.
I should point out that I don't know Erlang, or whatever language that snippet is in. The second example is nonetheless easy for someone used to functional programs to understand, much like the first example is easy for an imperative programmer to understand, even one that doesn't know Python.
A deep unwavering belief is a sure sign you're missing something...
Well, functional programs have a lot of other restrictions, but it boils down to this: with very rare exceptions (such as file or socket handling), functions don't have side effects. That is, they don't modify a program's global state, and they don't depend on global state. You can call foo(args) 100 times in a row and each time the output will be identical. My C++ is rusty, but imagine something like:
Any code that calls foo() will find its internal state changed - both bar and baz have been altered. In comparison, this is almost impossible to do accidentally in functional languages.
So, great, what does that buy you? Well, the map() function in you example knows that it's supposed to call compose2() on each item in source_list. Because it's impossible for compose2() to have strange global side effects and it doesn't depend on external state, map() is free to fork() 10 times and let each child process munch through independent subsets of source_list. In the case of Erlang, map() is also free to hand off chunks of source_list to other machines and coalesce the results from all of those hosts at the end. As long as compose2() gets called on each item at some point, the order (and indeed the physical location) of each call doesn't matter a lick.
Imagine that you have 20 quad-core systems in a cluster. Replacing the imperative example above with the functional example gives your code an 80x performance boost, minus a little network overhead. Does that sound more interesting now?
Dewey, what part of this looks like authorities should be involved?
I agree partly with your sentiments on debugging - although I don't think it would be a huge problem. However, I don't think that the second piece of code is more difficult to understand than the first. I'm able to look at the second piece of code and easily understand exactly what's happening almost instantly. It largely depends on what you're used to. If you're used to writing only in an imperative style, obviously a functional style is going to take some time getting used to. The vice versa is also true. This doesn't mean that one is inherently superior to the other.
"A Lisp programmer knows the value of everything, but the cost of nothing." - Alan Perlis
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?
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.
Also next to impossible to maintain, debug, or understand.
Uh, if you don't know functional programming, then yeah. If you do, it's instant to understand, and can be maintained more easily because there is less of it to maintain.
Your argument basically amounts to "stuff I don't know is hard to understand". No shit. New notation and concepts have to be learned, yes, but there is a point to learning them. It makes things simpler and easier once you have learned them. Consider, why do people in signal processing do all sorts of Z transforms and Fourier transforms and whatnot on data? Surely it's _easier_ to just think of a sound signal as a series of amplitudes at discrete time intervals? The thing is --- it isn't. Once you learn all that math, you can do stuff with signals by hand that you couldn't even have dreamed off if you'd used a less powerful technique.
A deep unwavering belief is a sure sign you're missing something...
I agree partly with your sentiments on debugging - although I don't think it would be a huge problem.
It's not a problem, because no functional programming language has a buggy map. There is no need to debug into map, it's a primitive like floating-point addition (which actually abstracts a much more complex algorithm than map!)
A deep unwavering belief is a sure sign you're missing something...
The Haskell equivalent of the same thing would be:
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)
Sanity is a sandbox. I prefer the swings.
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
Yes, that's a reasonably good way to think of them, with the proviso that an Erlang process doesn't bind particular code to the receipt of particular messages like you see in OOP (where particular bodies are bound to particular methods). When an Erlang process receives a message, it's up to the process to decide what to do with it.
DNA just wants to be free...
Back to the point, you can do most of the OOP things you might want to do if you just think 'object equals process'. Erlang is really nice for some things (I had a project that wanted to run on a 64 CPU machine, and Erlang was great for that), but it could be a lot better. R11 improved things a lot over R10 though, so I'd definitely recommend learning it. Even if you don't use it much, I think knowledge of Erlang improves your ability to program in other languages, just as Lisp and Smalltalk do.
I am TheRaven on Soylent News
Actually FP code is an order of magnitude easier to debug/maintain/understand, once you get past the weird syntax and restrictions. The absence of side effects makes it easier to isolate a problem or to build up an understanding of what the code does. The human brain can focus on only so many things at once. Since you don't have side effects, a function's result depends only on its parameters, so once you understand it you can think of it as a black box and move up to the call chain. When you debug, you can move up and down the stack until you figure out what function returns a wrong result and then you know that the problem is isolated to that function (there are no global variables/outside environment that can affect that function)
If con is the opposite of pro, is Congress the opposite of progress?
Damn... those new programmers are too sharp, now they can count above 3 :)
"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.
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
Scheme and Common Lisp are both Lisp dialects, but both have very different cultures behind them. Major differences (very CL-biased):
- 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.
A deep unwavering belief is a sure sign you're missing something...
I kind of like what Donnald Knuth had proposed, which is using a typesetting system to display code. So you'd use regular ascii symbols that are close to what you want when typing it out, but they get converted to a more graphical symbol in your editor automatically.