As someone who tries to read a lot about my field, I feel I have my "ear to the ground", so to speak. And right now, I'm picking up a lot of hype-rumblings about the Erlang programming language. I have a little bit of experience with it, having used it briefly about 3 years, and having made a few
minor contributions.
Why are people interested in it? Picking up new programming languages is fun for some people, but in general, unless it's something backed by millions of dollars of marketing and development (Java, C#/.Net) there needs to be a 'killer feature' to drive adoption. Tk and Tcl, ease of developing simple dynamic web content with PHP, Rails and Ruby, and so on. Erlang, in many people's eyes:
- gets concurrency right, or at least is a big improvement over existing models (threads).
- Makes distributed computing easier and does it naturally.
- Is a solid base on which to construct reliable applications.
That appears to be enough to have nudged Erlang into a position where it has a chance at the big time.
While I would highly encourage people to learn a bit of Erlang, and to seriously consider its use for the type of systems for which it was created, I have some doubts about it becoming that widespread. Please read the following as the thoughts of a critical mind, and keep in mind that it's far easier to zero in on defects than it is to create something from scratch, so do not misconstrue my writing as being "against" Erlang (I do use it, enjoy it, and recommend learning it!), but as an honest appraisal colored by my own view of the world, which might not be like yours.
To begin with the superficial, its syntax is a bit odd. For a professional programmer, that shouldn't present much of an obstacle, and indeed isn't after a few days of using it, but there are a few things that I do find a bit annoying despite being used to the syntax, first and foremost being the use of . and , to separate lines of code, rather than a newline, or ; (which is used elsewhere). They're like little mouse droppings - hard to spot, and they get in your way when you swap out bits of code here and there. The last line of a function must end with a ., but other lines are separated with commas, so when you're cutting and pasting lines from here to there, you end up having to recheck the line endings each time.
Erlang is a
functional programming language. Once again, someone with a wide exposure to many programming styles will not find this difficult after a week or so of practice, to wrap your mind around a different way of thinking. However, I have some doubts as to whether a functional language will be able to bring on board the numbers necessary to be widely adopted (see
Scaling Down).
One of the benefits of wider adoption is, indeed, having a wider set of libraries - it's a "positive network externality" in terms of economics. Other people have written about the relative lack of Erlang libraries to do various things, but it's actually not one of the things I'm worried about - it's something that will take care of itself if the language grows in popularity. After being spoiled by Ruby's gems, what I really miss, though, is a nice, simple, easy distribution mechanism.
Related to making it easier for J Q Programmer to adopt, the error messages are at times not the most helpful I've seen in the computing industry:
Error in process <0.29.0> with exit value:
undef,[ shell_default,sfdsf,[] , erl_eval,do_apply,5 , shell,exprs,6 , shell,eval_loop,3 ]
In English, that means that I tried to execute the function
sfdsf(), which doesn't exist. It seems that there ought to be a way to keep the nice, computer parseable error messages, and add in something that humans would find just a bit easier.
Other people have already covered the problems with Erlang's strings, so I won't belabor the point. Suffice it to say that, in my opinion,
is_list([foo, bar, baz]) and
is_list("hello") should probably not both be true.
Which brings us to another issue. Erlang is a language used in big, reliable systems like telephony switches. That's not the sort of environment where you want to break things, so I doubt that Erlang will ever see big changes that introduce incompatibilities, like Python has recently done. This one is a tradeoff - stable, reliable and backwards compatible is simply not compatible with rapid development of the language - it's a zero-sum game, you want more of one, you get less of the other.
Related, is the "open sourceness" of the language. It is open source, which for me is very nearly a prerequisite for dedicating my time to a language, but Ericsson appears to maintain firm control over it. This is another thing that's both good and bad. Having the backing of a large corporation means that developers are paid to work on and enhance Erlang, which is beneficial to everyone. On the other hand, as some people say, open source is just the start,
open development is important too. Random thought: I bet Erlang would make a nice Apache project, but I'm sure the bureaucracy involved would be a nightmare.
In terms of the language itself, beyond the syntax, it feels a little bit too verbose. Perhaps not as much as Java (that would be difficult, wouldn't it)... maybe I'm just used to Ruby, which is about as concise as I'm comfortable with while still being readable. Sometimes, though, there is a little bit more 'repeat yourself' than I would like to see. For instance, in this implementation of
string_join (something else that ought to be in the standard library, but still isn't), it's necessary to create the same function, with different arity, simply to work around the fact that it's not possible to say the default separator should be " ":
string_join(Items) ->
string_join(Items, " ").
string_join(Items, Sep) ->
lists:flatten(lists:reverse(string_join1(Items, Sep, []))).
Which is a lot more typing than
string_join(Items, Sep=" "). This is pure opinion, and very subjective, but Erlang to me feels like it falls more in the "systems programming language" category than "scripting language". It's a bit more verbose, it needs to be compiled to run it, modules need to have an entry point... it's not as suitable to quick throwaways as Ruby, Tcl or Python. Of course, it is certainly higher level than C, and leaner than Java, but still falls an the other side of an admittedly fuzzy line in my head. Its command line options reinforce that. Whereas "scripting" languages do the obvious thing first:
ruby foo/bar.rb
Erlang is a little bit more complex:
erl -noshell -pa foo/ -run bar
A minor detail, once you get used to it, but still, I prefer the "do the obvious thing first, and let the user have some say in the matter if they want to do something else" approach to systems design.
One of the wonderful things about Ruby on Rails, is that it uses Ruby throughout, templates included. Without getting into the merits of using templates vs other systems, my own opinion is that Rails gets them right, and demonstrates the flexibility of Ruby by using it as the language for the templates, rather than inventing some other solution. I don't see the same flexibility in Erlang, which is unfortunate, as it blows Ruby out of the water in terms of being a very solid solution to deploy on a server (no fiddling with proxies and load balancers and single threaded mini-servers + hot code replacement =
nice).
Of course, there are lots of good things about Erlang, as mentioned at the beginning of this article - concurrency and distribution, but also language features like pattern matching that are a lot of fun to use, a pleasant syntax for dealing with binary data, list comprehensions, first class functions, tail recursion, and lots of other goodies. However, if I had to try and predict the future, I could easily imagine another language grabbing some of Erlang's good ideas and running with them, perhaps being more "conventional" in other respects - this isn't uncommon in the languages field, as we've seen with things like Lisp and Smalltalk. On the other hand, one of the reasons I *am* quite happy with Erlang is that it is most certainly not a proof of concept - it is a very practical language that excels at solving certain classes of problem, and does so in many commercial settings. If you're the kind of person who enjoys new things, check it out!
Seriously. Now that we have been using the request tracker for quite some time, it’s even more obvious that the DSA team is not up to its task.
Use login “guest” and password “readonly” if you want to check the RT tickets linked in this article.
The facts
Just a few snippets:
Since the closure of SoFlow and adding myself
to LinkedIn, I've been thinking a bit about
Professional Associations and using
Social Networks (SNs) for business.
I've not worked out my answers, so
this is a "dear lazyweb, what pieces of this jigsaw am I missing?" post.
Much of the recent mainstream news has been
about the legal problems of SNs
- for example, see
While it's cute that 
My lack of posts lately left Planet readers without yet another yay,
GNOME 2.20 released post. I'm sure nobody missed it. However, I can report
what's going on in Debian regarding its packaging.
The executive summary is: the GNOME team rocks, and having much of GNOME
2.20 available in sid on the very same day it was officially announced was
possible thanks to the incredible work done by lool, Np237, slomo and other
restless team members, who spent the summer tracking GNOME 2.19 releases and
packaging them in experimental.
To get a better view on what's left to do, you can use the
Living really downtown and having a demonstration of 
I am helping to kick off the 
If anyone was wondering why I've been quiet / claiming to be busy for the last week or so:
So, I have just installed 
It’s nice to see people amazed on an iPod running something that’s different from the usual firmware. Now, both my iPod and PowerBook are not running Apple software, muahaha!
The other day, as I was putting a couple of pages of documentation together
for a company-internal development project, I got this terrible feeling of
malaise about what I was writing. "Why the hell am I bothering writing
this lot? It's a given that nobody's ever going to read it." Why?
Because nobody reads documentation.
Funnily enough, I tend to work the other way, too. While I will often go
looking for help through Google, checking for assistance in structured,
project-produced documentation (manuals, et al) is usually one of the last
things I'll try. Why? Because nobody writes documentation.
Now, given that I feel minimal motivation to write documentation because
nobody reads it, and I don't usually read documentation because nobody
writes it (probably because nobody reads it), an obvious question comes to
mind: did one of these states come first, which then caused the other? Are
we in an ever-deepening spiral of shite docs, the logical end of which is
just giving up and reverting to code reading and experimentation?
Working with subversion I’ve had a bit trouble making project wide search and replaces. 
to refer to a class of military robots that have no compunction about killing humans.
Among the fall-out of the SFWA actions was 