Basically it's all about message passing. And having the kind of flexibility where any object can pass arguments to any other object. In the case of Erlang every object will be a process which has an event loop at its core. naturally by loop I mean a tail recursive function.
The only thing which appears to be lacking is any explicit mechanism for inheritance, however this can be addressed with small amounts of boilerplate code. It early days so anything I try to post up at present will probably look woefully amateurish, if not plain wrong, to anyone with more Erlang experience then me.
The big advantage being that each object (or process as Erlang calls it) can be executing on a different cpu or even on a different machine. This fact is essentially invisible to the caller. There are some syntax shortcuts for sending messages to local objects but they really are quite minor.
Coincidently there have been a number of Erlang posts on reddit recently:
- What Sucks about Erlang
- Response to What Sucks about Erlang
- Erlang get Unicode Strings
- Lisp Flavored Erlang
I'll get back to Unicode a little later but the first two deserve a little more comment. About the only thing I strongly agree with in the critisims of Erlang is that Records really do seem like bolted on afterthought.
having named fields is very useful, but we don't really have named fields only the illusion of them, but I guess that's what normally happens with macro features. Sun implemented inner and anonymous classes in Java in much the same way, and with some of the same warts.
The subject of Unicode support is another thing entirely, I recently bagged Arc for not having it. Now the interesting thing here is that Erlang does not differentiate between a list of integers and a string. So in theory at least you can represent any set of code points you like, as all existent Code points fit within the bounds of an Erlang integer.
What you don't have however is any indication of which of your lists of integers are stings, nor any indication of what encoding a particular string might actually be in at the present moment.
In practice things are nolonger so simple. In Ascii you could get away with treating a string as an arry of bytes and things just worked. but nowadays things are not so simple. With UTF-8 different characters take a different number of bytes. Even with utf-16 you still have the problem that the same visual string can be represented by several different byte sequences.
The same problem means that a lot of Python code I've written in the last year or so will break badly if I tried to migrate it to Python 3.0. The assumptions of binary / string compatibility are simply nolonger there. Such I guess is the price of progress, we can represent almost every language on earth, but even the basic case is now harder than it used to be.
And finally there is the promise of Lisp Flavored Erlang. On the face of it this seems fantastic, and I plan to play with it extensively. Not yet however, it may be valuable to learn Earlang before I start playing with alternative syntaxes. I believe the big thing that LFE adds is scheme like macros. Let us see what happens to LFE once the 'new shiny thing' hype clears a little.
No comments:
Post a Comment