Software Development

I went to the Eiffel site and watched 4 of their presentations. Unfortunately, their presentations do not work under Opera unless you make Opera present itself as Mozilla. Also, the last demo is supposed to show demos in a popup window. I disabled my popup blocker in both Opera and Firefox and still no go. So that's where I ended the fourth presentation.

My first impressions are very good indeed. I like the structure of the language and I like the way they implement what they call Design by Contract. They even have that term trademarked apparently. They are quite corporate, so that may turn away some people who want to use an open language. Their web page and presentations are very geared towards managers and higher-ups rather than programmers. They are top notch presentations though.

When I started watching the first presentation, I almost turned it off immediately. It said that Eiffel code is very readable just like VB. Now, as someone who has used VB professionally for a several years in the past, I can tell you now that this is NOT a good thing. VB is horrible for readability. It's the worst language for it actually. But their corporate nature makes it clear who their target audience is. They have a version for .NET that integrates directly into VS. They also have a standalone version, but you can see they're following the money trail. It's too bad really, because at the very beginning, you don't know if the decisions they make are geared towards the consumer or towards getting the remains of MS clients. Personally, I was a bit disapointed at the corporate nature of the language. As far as their business goes, I wish them the best. They seem to deliver high quality products, even if the presentation did not work as expected.

Design by Contract is an interesting concept. Basically, it has a section to check inputs and other things before a function or procedure is excuted. This is also available after it has executed to make sure that values that should be changed indeed were changed and those that are not to be touched are indeed left unchanged. There's also more checks for the class as a whole.

Althought I haven't used it, I am certain that if not for the checks alone, it will make a developer think about exactly what each and every method does. Only experienced Eiffel programmers could say if this is too much micromanagement and if they really check everything. At the very least, it should trap a lot of errors normally missed. For me, this is not enough. It's like a forced alternative to try/catch, or worse extra work on top. While I appreciate the intention and kudos to those who do use this properly, it's another way to force error checking. Not that error checking is a bad thing (quite the opposite). My point is simply that it seems like languages are coming out with these constructs such as contracts and try/catch blocks to try and convince the programmer to actually and finally write the error-checking code. For me, I already do this anyways, so the benefits are moot. For beginners and intermediate, I highly recommend it. I'll keep an eye open for now in case I missed a critical flaw and need to retract my recommendation. But if not, then two thumbs up.

Another thing about this language is that it seperates functions that return a value compared to subroutines that do not. Functions are used to implement "features" and subroutines for "queries". If something does not return a value, then it's a feature and can modify the state of the class. If it does return a value, then it's a query and cannot modify the state of the class, or at least must put it back as it was before returning (if I understood correctly).

By nature, I'm against restritions, but it fits in very well with the ideas behind the language. For beginners and intermediates, I like this feature. For advanced programmers, I think a lot can be said for using this or at least keeping it in mind when writing your own code in whatever language. I wish I had more time to actually look at this feature as I can readily see the benefits.

I also liked that the presenter commented on the mathematical notations used in research papers and that this was perhaps not the best way to define a formal system specification. This is because most programmers do not use or even deal with those kinds of mathematical notations. On a personal note: "That's what I've been saying all along!" So kudos to the presenter and language designer(s) for recognising this.

Overall, I like the syntax. I liked it before when I saw it and after looking at the presentations, I still like it. If you're incredulous so far that I'm giving good comments on a programming language, read on.

I've been saying for a long time, and anyone who reads this blog knows, that learning to error check is a normal stage in every programmer's development. This is the cleanest way of doing this that I have seen so far (Note that I've yet to check aspect programming). Removing the error checking from the main code is a very good idea. Something I've considered obvious for a long time, but had not seen any real and usable ways of doing this. Even if only done at the beginning and end of methods, it should do plenty of good for learning and even experienced programmers to get this into their normal way of doing things. Anything to get them to error check everything. These are valuable habits to have.

Now all is not rosy. For advanced programmers, we already check everything. And we've already done plenty of organizing, planning and designing. So this basically comes back to what I've been saying that problems come about when people who aren't "real" programmers come around and try to update software. I believe Eiffel can help in this regard, but basically puts a straight jacket on the rest of us that know what we are doing. For advanced programmers, it's basically voluntarilly restraining ourselves for the sake of the less experienced. Are we at the point where we are required to do this? I'm also not saying that an expert programmer would not enjoy using Eiffel. Quite the contrary. I'm just asking is it worth changing language or learning it if advanced programmers are fine in their current language? Especially when you consider existing infrastructure and consistency. Adding a language may seem like an extra step for nothing to advanced programmers.

There are two final points that I want to mention. First, the presenter is obviously excited about Eiffel. But at one point, he compared it to magic. Or that it can seem like magic programming in Eiffel. I can appreciate this kind of enthusiasm, but I'm wondering if their marketing department didn't drop the ball on that one.

The last point is that Eiffel is either converted into C or into MSIL (.NET intermediate bytecode for the uninitiated). I understand the use of C for portability. In fact, I intend to use the same thing to get things started. But I must admit that I was disapointed it didn't have a genuine compiler. While this supports the notion that I was pushing in earlier blog entries that programming languages are more and more becomming grandiose macro languages, something in me did not want to have this confirmed in this fashion. It is true that C is low level and there is a C compiler available on most platforms, it doesn't make it an independant language much like Java is dependant on the VM. This in effect makes Eiffel not truly portable. I realise many disagree. It's simply a personal disapointment.

This may be the last corporate language I review. Although I will look at other languages that may be corporate, I will not review them. I'm making an exception here because I really liked the design. So all in all, two thumbs up on my initial impressions. Please take into consideration that this IS a first impression. Also, I will not be using this language personally because there is nothing new here for me, but have asked some people to get back to me on how they like it.