Wednesday, March 26, 2008

More Erlang

I'm finding erlang to be a fun language to learn. One of the differences between it and other functional languages is that there is no type system. Well no extensible type system. we are really down to Atoms, Numbers, bytes, Tuples and Lists. With bytes generally being used as lists of bytes.

Even Strings don't get their own type, which is a little bit of a liability but can be muddled through for, at least for latin1 characters. Some people have hailed this as an advantage saying hay look I can learn to program and don't have to learn some complex type system.

So far my toy programs havn't felt the lack of types. But even there it seems to me that this could easily be added as with a preprocessor just like records where, if we take the perl approach of saying classes are modules then you can easily rewrite Var.doSomthing(...) to module.doSomthing(Var, ...) providing you know what module should be. which we could have declared at the time the variable was assigned to by writing Var~module (I picked ~ as it dosn't have any meaning that I'm aware of as yet.

The Question is then, is such syntactic sugar worth while and does it gain anything in reasability over the syntax that it is being written into? At the moment I'm undecided. It certainly seems like it would be doable, after all Lisp Flavoured Erlang is doing somthing much more complex then this. The key question would be how hard is it to write an Erlang parser in Erlang?

Tuesday, March 11, 2008


I've started messing about in Erlang, and so far I like it. At my current, very basic, understanding of this language it seems to be much closer to the original Object Oriented Model then most of the so called Object Oriented languages are. The syntax is purely functional and inspired by prolog, though the execution model is different as there is no automatic backtracking.

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:

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.

Thursday, March 06, 2008

The folly of Arc

Somewhat belatatly I learned that Arc had finnally been released. A few moments of excitment soon ended when I learned that what had been released was a set of mzScheme macros. Worse yet a set of MzScheme macros which require an old version of said language, because the latest version breaks something.

Having read 'Arc is Out' I have to say that I haven't seen anything is contradictory to good software engineering practice in a very long time, at least not outside writing which is meant to be satirical.

How Ironic that Paul Grahams Announcement of the language spends several paragraphs belittling attempts to not break existing code when releasing new versions of a language. Interestingly He pre-picked the two things that everyone would object to:

  1. Supporting ASCII only
  2. Shipping with a table based web framework.
On the first of these points. No wrong answer you should have supported UTF-8 to begin with. The ability to do character set conversions can wait, but at a base UTF-8 seems like the way to go. Right here a lot of programmers who need to use languages other than English will say, this isn't worth it, even to mess about in.

On the second point. This isn't just not Politically correct, its plain wrong. Tables are ridged structures which do not sport much in the way of experimentation. Do the same thing with Divs and Spans and you can experiment, shape and reshape, make things align differently. I don't know anyone at the W3C personally but I can respect that they have spent a very long time thinking about the problems of markup languages. Somehow I'm more inclined to trust them then a single person who is effectively saying I'm right and the rest of the world is wrong.

Looking at the rest of the Essay, Yes lists are good but lets be honest they are not always the best choice. In most programs I may not know exactly what I want but I'll have a fair idea, and no I wouldn't represent a point as a list, I'd use a tuple. Why? Because chances are I know that I need two elements, or three elements and that all my points will have that many elements.

Using the right data structure for the right job is frequently important. For the most part I prefer to do this early rather than late, and can usually work out where I need a List, or a Tuple or a Hash or a Set.

Where structures with named fields come into there own is that while experimenting I can add fields at any time. I f I used Lists or even tuples this becomes much harder. When you know your points are just lists it takes an awful lot of discipline to not treat them as such, and sooner or later doing so is going to come back and bite you.

I speak from experience here I've dealt with data structures which where just nested lists (something like seven layers deep) and it was not fun. Worse yet code which references things by field name is much easier to read then code which has indexes peppered all over it instead.

All in all I'm sad to say that I won't be looking any deeper into Arc, because if fails my basic tests on what languages are worth spending time on. Last time I ignored my standards I spent several weeks looking into newLisp, even though I had grave misgivings on the Authors memory management philosophy of one reference to any object (ever), and Dictionaries can exists as top level objects only.

One day there will come a Lisp to rule them all, but it would appear that Arc is not that language.