Team Eiffel

Back in 1991, Eiffel was new and exciting. We eagerly awaited news of each new development - desperately keen for any information that would enable us to use Eiffel for our next project.

Most people did not have internet access back then. Believe it or not, people used papernet. They smeared ink on pieces of paper and got someone to carry those peices of paper to other people. One kind of "pieces of paper" was a magazine called Eiffel Outlook, and it carried the latest news about the world of Eiffel.

Eiffel Outlook was started by Rock Howard, of Rock Solid Software. The first issue was dated April 1991 and comprised 20 black-and-white pages. Subsequent issues kept the same format, although the page count sometimes reached 24 or 28.

Eiffel Outlook was published every two months, and there was certainly a demand for such a publication, for circulation soon grew to over five hundred.

In addition to news of Eiffel products, a bunch of talented contributors wrote about the techniques of object-oriented programming using Eiffel. There were also industry case studies and product reviews, along with conference programs and reports.

As circulation grew, Rock Howard signed up international distributors who would print Eiffel Outlook locally from PostScript files provided by Rock, and mail it to subscribers in their country. I added a page of UK Eiffel news, and had about 35 subscribers. Subscriptions were £29 per year. Frieder Monninger of SiG Computer in Germany (now Object Tools GmbH) was another distributor - if my memory serves me correctly he had about 200 subscribers.

Around January 1993 Rock Howard teamed up with Steve Tynor to form Tower Technology Corporation, with the goal of developing an Eiffel compiler to be sold as TowerEiffel. Unfortunately, Eiffel Outlook took a backseat to compiler development and the issues became spaced further and further apart, and the font size and white space increased as the content decreased. But still each new issue was looked forward to with great anticipation, and eagerly devoured once it arrived.

All good things come to an end eventually. After Volume 4 Issue 6 in September/October 1995, we waited for the next issue. Rock Howard promised strenuously that the magazine was still being published, but no more issues ever came. After a few months I sent a letter to my subscribers offering a refund on the balance of their subscriptions, and Eiffelists everywhere turned to the newly-invented World Wide Web for our Eiffel information.

The Ajaxian links to a post discussing the ideal AJAX server response format:

Once you’ve succesfully fired an AJAX request, what sort of response should the server give? An XML document? An HTML snippet? A JSON string which is converted to a JavaScript object? Or something else? In this entry I’d like to discuss the three formats, with examples, and ask you which format you’ve used in your practical AJAX applications.

With Eiffel we easily can generate the XML documents and HTML snippets by using the Gobo or eposix tools. There's no JSON support in Eiffel yet.

Neil Wilson suggested to the Board of NICE that it would be worth encouraging Eiffelists to contribute Eiffel examples to the PLEAC cookbook site, which got me wondering whether contributions to Ward Cunningham's wiki pages might not be more productive.

Then I thought of the "99 Bottles of Beer" site, which contains programs written in hundreds of languages that each print the words of the song. The FORTRAN entry is nine very readable lines, whilst the Eiffel entry is over a hundred lines - and I remember that in the past Eiffel has been criticised for the length and obscurity of this entry. My own entry for Amber for Parrot is 25 lines (using inline agents) and, although I don't often praise perl, its entry is a real work of art.

Frieder Monninger thought I wasn't being serious, and that it would be quite practical to write a readable Eiffel version in eight lines.

I don't think it's so straightforward. Any takers?

I was reading a draft writeup on Eiffel's Design by Contract, and I realized that the common approach for describing DbC is as a mechanism for finding bugs in the code you write.

Now how many people are willing to admit that they write buggy code? How many people have reached DbC in an exposition on Eiffel, and looked at the example stack trace, and had this visceral reaction: "this is wrong because when it happens it will be someone else's fault, not mine, and I don't want to waste my time finding someone else's bugs, because way deep down in the bowels of my psyche, I Know I Write Perfect Code"?

I don't think people would consciously make a decision to not use Eiffel because of this, but like strong typing and Single Entry/Single Exit, a lot of people are going to look at this and think that it's not for them, it's too strong a cup of tea, or its tea and not beer, and because they Write Perfect Code, so they deserve to get weak beer instead of strong tea.

If you walked into a roomful of your peers who've found Eiffel on their own (I'm lucky enough to be able to do this in the Real World; others might have to use a virtual room of some sort) you'll find that a lot of these people have grown out of the notion that they Write Perfect Code and have been so frustrated with other languages that they casted about and found Eiffel in their nets.

Not many people have the maturity to grow out of the illusion that they Write Perfect Code, but they do know that no one else does! When the program crashes, the thinking goes that "my code is perfect, I know the bug is in [insert name here]'s code."

So perhaps a better way of pitching DbC is to say that it finds the bugs other people write, when they use your code! Now the subconscious thinking is, "Ha! When the application crashes on my contract, everyone will know it's [insert name here]'s fault, and not mine, because in my Perfect Code, I have written Perfect Contracts!"

We can make a similar argument in support of other strong measures like Single Entry/Single Exit. In the fall of 2005 one of the Eiffel mailing lists had a nice flamewar over this, and in the end I don't think anyone was convinced one way or another. But I did not try the argument, "Hey you may be smart enough to understand a multiply-nested loop with the propositions scattered all about and about five ways of getting in and out of the innermost loop, but there's no way [insert name here] down the hall will be able to maintain this code and not mess it up completely." Or put another way, you may be clever enough to write and maintain Perfect Code that is that complex, but a lot of the people who will follow you into the code, or use it, may not be, or may not have the time to become that clever.

And unlike most other languages, Eiffel is just as much about readability and maintainability as it is about anything else.

Berend de Boer has released version 2.3 beta of eposix, the complete Eiffel to standard C and POSIX binding. In an announcement to the eposix mailing list he wrote:

Not too many changes, no significant new functionality. Mainly a few bug fixes and support to compile the eposix lib for ISE Eiffel on Windows with Microsoft Visual C: multi-threading option is now turned on by default.

New in 2.3 beta - 2006-01-17

• EPX_CURRENT_PROCESS: new feature effective_user_name
• EPX_HTTP_10_CLIENT: removed precondition post_data_content_type_recognized as this is not necessarily true
• EPX_SMTP_CLIENT: When reading capabilities should have used force_last
• WINDOWS_CURRENT_PROCESS: user_name: returns name of user associated with current thread.
• WINDOWS_BASE: raise_posix_error is redefined to get the error message from the Windows API GetErrorMessage() instead of the posix strmessage. The posix strerror() doesn't return anything for Windows specific error numbers. This is a bit annoying if you combine classes that don't descend from WINDOWS_BASE with ones that do. In that case make sure to undefine raise_posix_error on the classes that do not inherit from WINDOWS_BASE
• EPX_DSML_V1_WRITER: new class to write LDIF file in XML format, i.e. DSML v1
• EPX_LDIF_PARSER class to parse LDIF files
• STDC_ERRNO: clear_all: now clears both value and first_value (first_value wasn't shared among all STDC_ERRNO objects)
• ABSTRACT_STRING_HELPER: incorrect postcondition in case the STRING contained a NULL character
• EPX_XML_WRITER: (1) add_comment: didn't quote meta data properly, (2) add_attribute, add_ns_attribute, add_a_name_space: greatly increased speed when serializing XML and you don't want to change the value of the attribute at a later stage
• EPX_MIME_PARSER: didn't correctly validate dates
• POSIX_FILE_DESCRIPTOR is_closed_on_execute: new feature

Vorlath has blogged in detail about his first impressions about Eiffel after viewing four of Eiffel Software's multimedia presentations. Here are some excerpts:

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...

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...

[Design by Contract] 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...

Overall, I like the syntax. I liked it before when I saw it and after looking at the presentations, I still like it...

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...

Eiffel is either converted into C or into MSIL (.NET intermediate bytecode for the uninitiated). I understand the use of C for portability ... but I must admit that I was disapointed it didn't have a genuine compiler.

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...

Many Team Eiffel readers will have read Bertrand Meyer's masterpiece Object Oriented Software Construction. For some, it was their introduction to Eiffel; for others, their introduction to Object Orientation.

Peter Gummer has contributed the following comments, which originally appeared on the ISE Eiffel mailing list:

I bought OOSC2 when it was first published. I read it cover-to-cover ... well, almost, I got stuck half-way through the concurrency chapter. But I did read the rest :-)

Before OOSC2, I thought I understood OO. OOSC2 showed me how little I understood. It explained OO in such a clear and entertaining manner, it completely changed how I thought about many things. I was programming in Delphi at the time (a language very similar to C#), and OOSC2 inspired me to make all of my methods virtual -- surprisingly with zero noticeable impact on execution speed -- and to abandon "private" in favour of "protected" -- which was amazingly liberating and which I've never regretted, apart from the interminable arguments it has provoked with other Delphi, Java and C# programmers. I still follow these practices today in C#, seven years later!

The main thing that OOSC2 taught me is that OO is quite simple. That's not to say that learning to use it well is easy, but the concepts behind it are not as complicated as most other authors make
it seem, especially the C++/Java/UML crowd. Smalltalk people also have a knack for making it seem simple; they approach OO in a very different way from Eiffel, of course. OOSC2 is not, as it might first
appear, a survey of OO; advocates of dynamically-bound languages like Smalltalk, for example, make good cases that get very little consideration in OOSC2. That's ok: OOSC2 is Meyer's exposition of
what he knows about OO. I was deeply impressed by the coherence of his vision, and his willingness to justify every decision made in the design of Eiffel.

OOSC2 introduced me to many big concepts -- command-query separation, uniform access, etc., etc., etc. --- all of which I found myself agreeing with. Some of the smaller decisions I was more dubious about -- e.g., the idea that case-insensitive languages avoided many programming errors, which struck me as quaintly obsolete given the speed of modern computers and the assistance we now get from IDEs -- but now that I've actually done some Eiffel programming my views have been swayed even on these little issues.

OOSC2 is the most important book I've ever read on software development. Well, maybe not: David Gries's "A Science of Programming" taught me De Morgan's theorem, probably the single most useful thing I've ever learnt; and Jensen and Wrth's "Pascal Report and User Manual" set me on the true and righteous path. So OOSC2 is definitely the best I've read in the last fifteen years.

It would be nice to be able to give people a more concise version. The thickness of OOSC2 can be daunting. Anyone want to write "OOSC2 for Dummies"?

In a recent comp.lang.eiffel thread, lee asked which Eiffel compiler would be best for embedded use on a variety of chip architectures running roll-your-own Linux. Important factors were efficient memory utilization, parallelization and speed.

I mentioned that Victor Putz had ported SmartEiffel to the Palm PDA, but lee pointed out that he only needed to use a new chip, not a new operating system.

Lee wondered how difficult it would be to port Eiffel to a new hardware platform.

In theory, porting SmartEiffel should require nothing more than a suitable Ansi C compiler. If it takes more than that, I think the SmartEiffel team would regard it as a bug.

Llothar suggested that the garbage collection could be an issue, but didn't see a problem provided the chip supported gcc 4.0 and the Boehm garbage collector. He offered Lee his own patched version of SmartEiffel, lamenting that the SmartEiffel team "is unwilling to see the importance of multithreaded programming".

EiffelStudio, on the other hand, is a proprietary product. It can be (and has previously been) ported to an embedded platform, but the porting would have to be a viable proposition for ISE, and would need to be done by them.

The discussion then moved on to the merits or otherwise of multithreading...

Usual disclaimer: limited sample size, only reflects successful searches reaching eiffelzone.com, etc.

1. lua
2. webshort
3. hipnotic
4. hotbabe
5. gote
6. hotbabe chess
7. smarteiffel
8. digichip
9. eiffel ide
10. eiffelzone
11. kniffel
12. pushdown automata simulator
13. swirl screensaver
14. symbols
15. wxeiffel
16. black tree
17. board game framework
18. eiffel code
19. eiffel compiler

This is a place for serious Eiffel users to post their experiences, opinions and commentary.

Do you use Eiffel at work? Do you work for an Eiffel vendor? Perhaps you have released an open source Eiffel project, or have written a paper about Eiffel, or taught Eiffel? If so, email me (roger@eiffel.demon.co.uk) and I'll set you up to post entries to this blog.

Anyone may post comments, of course.