On computer languages

June 4, 2008

Eiffel : tearful future ahead

As I explained some time ago, I spent quite some time doing financial simulations lately. At first, I was using python, which is pretty nice to do a simple and direct simulation, but I always feel it’s too toyish for serious use.

So I made my more complex simulations using eiffel, and more precisely smarteiffel’s compiler. This language has many good features :

  • it’s garbage-collected (wink),
  • does inheritance right (hint: no virtual keyword to make the concept half-stupid — yes, I know, optimisation : C++ is 0.001% faster in not doing the right thing!),
  • including multiple inheritance (undefining methods, renaming them),
  • allows determining which API parts of an object are visible to whom (not limited to a simple public/private or public/protected/private di(tri)chotomy of the world),
  • does pre/post conditions at the method and object level (and they do get inherited correctly, and you can refine them if needed : it’s not just a hack!) ;
  • it does generics with constraints (ie: you can tell your generic container will only accept objets of base class something — for example the compiler will let you use a SOMETHING[RECTANGLE] because you said SOMETHING[A->QUADRILATERAL] and RECTANGLE is a QUADRILATERAL, but won’t let you use a SOMETHING[HEXAGONAL]) ;
  • it does functions-as-values (called agents),
  • since typing is pretty strict (the only automatic/implicit ‘conversion’ is if you consider a descendant class as an ascendant), the compiler is generally able to pinpoint exactly where the problem is in the sources, so a compilable source is generally good,
  • but even if by a surprising accident it doesn’t, then the trace you get will tell you exactly where you made a mistake.

So what’s the catch? Well, it has a few shortcomings.

One of them is that you have to give each type explicitely, which can become cumbersome when you deal with something like a COLLECTION[PAIR[INTEGER, COLLECTION[STRING, STRING]]… even though the problem is a little dampered with syntactic sugar in the form of anchored types (ie: once you told it foo was of type FOO, you can tell it that other_foo is of type “like foo”, so if you change your mind about an api, it’s easy to just change one place).

Another one is that too few people know about it to reach a critical mass although it’s much much much easier and coherent to read and/or write than other more mainstream object-oriented languages (or claimed as such… wink).

This last problem has gotten worse recently (since 2005) when the smarteiffel (GNU compiler for the eiffel language) people decided they didn’t like the way ECMA (yes, that ECMA) was pushing the language, and forked it.

A few weeks ago, all smarteiffel-related debian packages got orphaned, and no other eiffel compiler is in debian anymore, which means it’s getting harder to install too.

Lisaac : future ahead (!)

There is another language, with many common points with eiffel, but still pretty different, since it’s a prototype-based language : you define base objects, by declaring “slots”, which you can either write for the new object or “inherit” from a base object. Again, multiple inheritance is no problem and you can export the various API parts an object has to whatever prototype-object you want.

An important difference with eiffel is that the compiler will do auto-casts for you. The main difference with C++ is that you will need to explicitly declare that casting FOO to BAR is possible (not at the place where you use obviously, or I wouldn’t call it ‘auto’), and it will only do one single cast, and not a series of them.

The compiler does a quite thorough analysis of the sources, so it can spot more issues and optimize more completely, which probably explains why it’s so well-placed in the computer language shootout.

Both the language and its compiler are pretty young though, so stability isn’t as good as with smarteiffel : I’ve seen it crash on some simple code (reported, of course).

OCaml : precious!

Well, I haven’t written financial simulations with OCaml : since I made some simulations with python, others with smarteiffel and others with lisaac, I do have a better view of how I should manage the little money I have! [no, I didn’t just write the same simulation in several languages over and over]

Still, I couldn’t blog about languages without mentioning that one! Again, it’s a garbage-collected language, it does inheritance and multiple inheritance (not as good as eiffel, even if it has constrained inheritance), unfortunately only with a public/private dichotomy (there are ways to offset that issue using ‘modules’). It won’t cast behind your back.

It’s time to mention the two main points of the language : it is a functional language, and it does type inference. The former is quite well-known, since hopefully everyone has heard of lisp and scheme, so I don’t need to tell that much about it : it’s pretty renowned to lead to terse and elegant code.

The type inference can be new to some. If you decide to write a prepend function which takes two arguments : the first is an object, and the second a list containing elements of the same type as the object, which will just prepend the element at the start of the list, you’ll just write (in the interpreter) : “let prepend obj lis = obj :: lis;;” (the ‘;;’ is unneeded if you do it in a file you compile — only the interpreter needs it), you’ll get back : “val prepend : ‘a -> ‘a list -> ‘a list = <fun>” which means : prepend is a function, which takes an object of unknown (polymorphic) type (denoted ‘a), a list of object of the same type (‘a list), and returns a list of objects of that same type.

Some say its syntax is hard : take a look at C/C++ code with an eye as fresh as you use reading OCaml, and you’ll see none wins.

Ekiga

I spent most of my spare time thinking about making more money by managing it better, so it has been quite some time since I seriously worked on it : I saw new things mature, bugs get fixed, little improvements here and there… exciting things I haven’t taken a serious part — hopefully they left some bugs for me to work on!

Leave a Reply

You must be logged in to post a comment.