Team Eiffel

The results for the International Eiffel Programming Contest 2005 are finally available. Congratulations to all participants, and many thank yous to the jury for doing the judging.

SCOOPLI is an ongoing ETH Zurich research project by Volkan Arslan and others to implement Meyer's "Simple Concurrent Object Oriented Programming".

SCOOP starts from the observation that the basic framework of object-oriented computation lends itself naturally to a concurrent extension. Objects are independent entities with their own state and controlled access to their mechanisms. Contrary to most other approaches to concurrent O-O programming, we do not attempt to make objects "active", an approach that quickly leads to contradictions such as the "inheritance anomaly". Instead, SCOOP makes explicit the notion of processor, implicit in usual views of computation. Programs apply actions to objects using processors:

The approach taken is to implement SCOOP as a library, and to provide a preprocessor to convert SCOOP programs (using the "separate" keyword) into compilable Eiffel programs using the SCOOPLI library.

Version 3.2 of SCOOPLI was released last month, and now supports:

• Declaration of separate entities
• Enclosing routines
• Separate feature calls
• Passing expanded objects as arguments and results of separate calls
• Passing separate references as arguments and results of separate calls
• Passing non-separate references as arguments and results of separate calls
• Wait-by-necessity

Duels have not yet been implemented.

A range of examples is provided, including the usual suspects (bounded buffer, dining philosophers, elevator, etc).

Links:

• SCOOPLI home page and downloads
• SCOOPLI project page at EiffelZone

Just created the install with the eposix libraries in it. It's installing now. If that's installed I can test it by adding Gobo Eiffel Compiler support to makelib. Then finishing the servlet documentation in eposix, so I have a new eposic beta. When that's done it is time to show the new installers to the world.

But first uploading the NICE results. Just before April. It was a long haul this time.

Julian Tschannen has released version 1.1 of edoc, a sophisticated documentation tool that produces richly-hyperlinked web pages from Eiffel systems and libraries.

• edoc home page
• edoc listing at EiffelZone

Because edoc uses the tolerant Gobo parser, it can also produce documentation for systems that contain errors and will not compile, or that have never been compiled.

Here are examples of documentation produced by edoc:

• secom
• EiffelMedia
• edoc itself

Over on comp.lang.eiffel, Daniel Moisset was asking if anyone had a copy of the Eiffel Gotchas that were posted to usenet and on the web.
I wrote those gotchas, but they fell off the web when the ownership rules for .tm domains were changed (they had been on eiffel.tm).

I've now resurrected the old Eiffel Gotchas for interest and amusement - bear in mind that subsequent language and library changes will have affected many of these.

Bernd Schoeller announced his Option Parser for Eiffel a few days ago, but he has continued to work on it and already there's an update: version 0.9.2.

The code no longer uses agents (which Visual Eiffel does not support), which means it should now work with any Eiffel compiler that is supported by Gobo. There's also a redesign of the parameter passing mechanism and beautification of the code.

As a result of this update, Option Parser is being considered for inclusion into the Gobo package.

The Option Parser home page and downloads are at ETH Zurich.

Brian Heilig has announced the inital release of the Serial Communications Library secom, which aims to provide a library of object-oriented components for portable serial port applications.

The major goals of secom are to:

• encapsulate the serial port APIs of Windows and Posix into a collection of classes
• ensure these classes conform to an interface that is common to both Posix and Windows operating systems

Secom requires Gobo 3.4 and compiles with SmartEiffel 1.0, SmartEiffel 2.2 beta 1, and ISE Eiffel version 5.5 and later. Visual Eiffel is not supported.

Secom has been tested on Windows (XP) and Linux (Fedora Core 4) but is likely to work on other Windows and Posix operating systems. Brian would appreciate your help by testing this package on other platforms and providing any feedback. You will need a loopback device (DB9 connector with pins 2 and 3 connected) connected to a serial port. You can test the package by executing the following command in the test directory:

   geant -Ddevice=your_device test_all

Links:

• project web site
• documentation
• secom package page at EiffelZone

The release of secom obsoletes Brian's earlier package "WEL Serial Communications".

Just completed an MSI based installed, written with wix, for SmartEiffel 1.2r6 and lcc-win32. All looks pretty neat. Will create a package that includes Gobo and eposix as well. And if you have any other libraries you think might be beneficial for Eiffelists to have, write them down in the comments.

There's no public release yet, but if you really want to see it, just send me an email.

Bernd Schoeller has just released a very nice library for parsing command line options in Eiffel. It makes it easy to add full-featured command line parsing to any Eiffel application, without the need to use configuration files or run a preprocessor.

Object Parser for Eiffel is simple to use yet powerful, and is based on modern conventions for command-line options.

Features include:

• Different types of options: flags, strings, integers, booleans ...
• Long (--make-love) and short (-l) options are supported.
• Short form can be joined (-abc instead of -a -b -c), assuming that every one but the last is a flag (does not require an argument).
• Arguments to the short form can be added with or without space (-ltoday or -l today).
• Arguments to the long form can be added with '=' or with a space (--make-love=today or --make-love today).
• Option termination introduced by '--'.
• Usage instructions and a help text will be generated automatically from the options.
• An agent can be called every time a certain option is found.
• Good default values, minimal code is required for standard applications.

Option Parser is released under the Eiffel Forum License 2.0. It has been developed using EiffelStudio 5.6 but with portability in mind, and requires Gobo 3.4.

Links:

• Project home page and downloads
• README file
• Eiffel Software Directory entry

Whilst I was writing yesterday's article about Eiffel and C++ compared, I recalled some of the spirited exchanges of the late 1980s and 1990s between Bertrand Meyer and the proponents of languages from the C family. I found some old quotes that I had collected, and had posted to comp.lang.eiffel in 1998.

I've copied all of them to a page of their own, Quotes, mostly about Eiffel, where I will add new quotes as I come across them.

Here are some of the ones that relate directly to Eiffel versus other languages:

I do not think that in the long term Eiffel is really "competing" with C++. They have almost nothing in common in their aim and spirit. In my undoubtedly biased view, the real competitor to Eiffel is Ada.
-- Bertrand Meyer, 1989

You can have quality software, or you can have pointer arithmetic; but you cannot have both at the same time.
-- Bertrand Meyer, 1989

As for our grandchildren, only the paleontology professors among them will know what C++ was
-- Bertrand Meyer, 1990

Eiffel borrows quite openly from several earlier programming languages and I am sure that if we had found a good language construct in C we would have used it as well.
-- Bertrand Meyer, 1992

The belief is still widespread in the computing community that C and its derivatives are programming languages - languages intended for people to write programs in. This is a regrettable misunderstanding ... I wish Dennis Ritchie would come out and dispel the confusion once and for all.
-- Bertrand Meyer, JOOP July/August 1998

Tom van Cutsem has written an in-depth comparison of Eiffel and C++. From the abstract:

The paper discusses the object-oriented programming languages Eiffel and C++, comparing them among several of their Object-oriented features (inheritance model, type model, method lookup) and among other, interesting topics (metaprogramming, concurrency). There is no position taken into what language would be ‘superior’, only a comparison of the facts and principles underlying the design of both languages is made.

You can also view the slides for a presentation on the same subject that Tom gave in 2003. (Thanks to Tristram Brelstaff for submitting this)

There are other comparisons between Eiffel and C++ on the web. Victor Putz wrote up his experience with the Personal Software Process, in which he compared his experiences with Eiffel and C++ in terms of development time and defect rate, although the study is somewhat marred by the fact that he implemented each application first in C++ and then in Eiffel.

Ian Joyner's thorough book "Objects Unencapsulated: Java, Eiffel and C++" is out of print but readily available used (Dr Dobbs review). An earlier version entitled C++?? is available on the web.

Although there is an enormous installed base of C++ applications, the use of C++ for new projects is surely decreasing. I think this trend was cemented when Microsoft started pushing C#. Maybe Eiffel, sitting on the edge, will even outlast C++?

After the success I had with the transitional releases, I've upgraded the SmartEiffel port on FreeBSD to 1.2r6. The only issue is that the master site has some availability issues, so perhaps should have the sources on my site as well. Have to ask Daniel about this.

Perhaps the next task is creating a .msi??

Fifteen years ago this month the Nonprofit International Consortium for Eiffel (NICE) held its first official meeting. Rick Jones posted the meeting report to comp.lang.eiffel:

The first official meeting of NICE, the Non-profit International Consortium for Eiffel, took place in Paris on Friday, 11th March 1991. It was a small and friendly meeting, involving representatives from Interactive Software Engineering, Tetra Ltd, Enea Data, as well as Dr. Bertrand Meyer. This is not the total membership of the consortium, which at the current time also includes BNR (Canada), and Telecom Australia; however, these companies were not represented at the Paris meeting.

Several key issues were agreed by the members present, and a number of actions tabled for urgent work. These included agreeing to accept the book "Eiffel: the Language (version 3)" as the definitive starting point for the language. The book is currently in final draft, but is expected to be ready for publication in a matter of weeks. ISE also agreed to transfer the ownership of the trademark "Eiffel" to NICE with immediate effect, thereby confirming the commitment to establish Eiffel as a non-proprietary language.

The meeting agreed to accept Bertrand Meyer as a lifetime honorary charter member, in recognition of his work in designing Eiffel and promoting the entire philosophy of software construction which Eiffel embodies. In this capacity he represents himself, not Interactive Software Engineering, his company. ISE is itself represented, and has an honorary membership only for a limited period. This is to compensate for both the costs of launching the consortium, and the transfer of rights to the trademark "Eiffel" and various other copyrights. It would be easy to be cynical, and believe that NICE is just a promotional exercise on the part of ISE. I can state categorically that it is not, that neither Dr. Meyer nor ISE have any special priveleges outside honorary membership, and that the other members are committed to ensuring that NICE is both independent and fair.

On technical issues, a committee was established to examine the problems of interfaces between Eiffel and other languages, e.g. "C". This was as a direct result of matters raised during the Eiffel User Group meeting only a few hours earlier, during which it became clear that the C language interface defined in the current definition of Eiffel is not sufficiently detailed for large-scale software projects. With the imminent prospect of other implementations of Eiffel becoming available, the members of NICE appreciated the urgent need to define an interface to C which is usable for major software projects, portable between implementations, and which does not hinder technical innovation in the development of Eiffel compilers. The technical committee will consult with all interested parties, especially those developing compilers, before making a final recommendation.

Further technical work of a high priority was agreed to be the definition of an external portable object format, allowing the interchange of object structures between different platforms and implementations.

The meeting also agreed on the need to have some form of validation suite in order to be able to certify implementations of Eiffel. This will be solicited via some form of tendering process, since it will be more effective to buy-in the required technology. A more specific invitation to tender will be published in due course; the principle reason for the delay is that the validation suite will need to test conformance to Eiffel version 3, and the definitive book for that version is not yet published.

The constitution of NICE prevented the formal election of a board and officers, since not all members were represented. This will be completed over the next few weeks via post or electronic mail. To enable the consortium's work to continue, temporary acting appointments of Chairman and Treasurer were made.

NICE is an independent organisation, and is determined to be an active and effective one. Although the consortium was created by ISE, it does not represent their interests and now operates independently. This is illustrated by the technical committee on C interfaces, which will not favour details of ISE's implementation over anyone else's. NICE will consult as widely as possible with the Eiffel user community over many issues, especially technical ones. The principle vehicles for announcements from NICE will be the Eiffel User Group newsletter, the independent newsletter Eiffel Outlook, and the USENET newsgroup comp.lang.eiffel. If you use Eiffel, you will want to know what is happening in NICE, and we are always interested in your views and other feedback. If you are serious about Eiffel, either as a committed user organisation, or as a developer of Eiffel compilers, tools, or libraries, you should consider joining the consortium. This will not only give you much closer insight into what is happening with Eiffel, but will also enable you to have a significant influence in shaping the future direction of the language.

I believe that 1991 may well be a watershed for Eiffel, with the much-improved version 3 language definition, competitive implementations across different platforms, and an increasing awareness of the language's ability to deal effectively with difficult problems in object-oriented design and programming. In the midst of this, NICE has the responsibility to act as an independent reference over what can be claimed to be Eiffel, as well as defining progressive enhancements through a consultative process.

The computer business of the 1990s is acutely aware of the need not only for standards, but for standards which do not stifle competition or true technical progress. Many "standards" are in fact proprietary, de-facto standards which give little scope for development by other than one company. The true de-jure public standards have often been the result of painful pulling-together of disparate threads, involving protracted arguments, and frequently resulting in less than ideal compromises. NICE is perhaps unique in this context, being a body with no commercial allegiance, and with the goal of building an evolving public standard before any divergence takes place. The result could be one of the most powerful, portable, and usable programming systems in the history of computing. That is my commitment to NICE.

Two more Eiffelists are getting married - Eric Bezault and Karine Arnout are "tying the knot" in Saint-Quay-Portrieux (Brittany, France) on 27 May 2006.
Eric is widely known in Eiffel circles for his Gobo package. He has also worked with Eiffel at ISE and in industry. Eric represented his employer AXA-Rosenberg on the technical committee whose work led to the ECMA Eiffel specification.

Karine, too, has worked at ISE and was on the ECMA Eiffel committee. She is a post-doctoral research assistant at ETH Zurich, where her research interests include the componentization of design patterns, and automatic contract-based testing.

I'm sure all Eiffelists will join with me in wishing Eric and Karine all the best for their upcoming wedding.

Eiffel powerhouse Eric Bezault has announced that the Gobo Eiffel compiler is now able to compile all Eiffel code contained in Gobo CVS, and he invites people to try it on different platforms and with different back-end C compilers. It has already been used successfully on Microsoft Windows (XP Pro with msc 7.1 from Visual Studio .NET 2003), Linux (Ubuntu 5.10 with gcc 4.0.2), OpenBSD (3.8 with gcc 3.3.5) and Solaris 9 (64-bit with gcc 3.3.2).
So why yet another Eiffel compiler? Eric explains:

The goal of gec is not to augment the number of incompatible Eiffel compilers but to provide both the open source community and the industry with a compiler fully compatible with ISE Eiffel and compliant with the ECMA Eiffel standard. OK, so what is the benefit of having a clone of ISE Eiffel? First gec is not a clone of ISE Eiffel. It uses different compilation techniques which make the compiler and the compiled applications perform better in some contexts or in some parts of the development cycle. Then, gec also provides an alternative to ISE Eiffel for those who invest a lot in the Eiffel technology and don't want to be tied to a single vendor.

gec is the only open source Eiffel compiler that is released under a less constraining license than GNU GPL. To my knowledge it is also the first and only one whose source code can be compiled by all its major Eiffel compiler competitors, as is the case of all other classes provided in the Gobo Eiffel Project. However, note that although it is already able to compile all Eiffel classes included in the Gobo Eiffel Project, gec is still under development...

Here is a list (incomplete) of functionality that has not been implemented at the time of writing:

• Assertions
• Exceptions
• Garbage Collection
• Agents/Tuples
• deep_* features in ANY
• Storable
• User-defined expanded classes
• BIT types
• Unique constants
• Class INTERNAL
• Options and external declarations in the Ace files
• Multithreading
• Debugger
• Profiler
• Cecil (C to Eiffel interface)

You may also be interested to know that:

• gec is released under the GPL-compatible Eiffel Forum License (version 2)
• gec understands ISE-compatible ace-files
• gec can be compiled with ISE Eiffel 5.6.1218, SmartEiffel 1.2r6 (Daniel Moisset's "transitional vesion" fork), Visual Eiffel 5.0b, and of course with gec itself
• The C-code bootstraps for the Gobo Eiffel tools (gelex, geyacc, gepp, deant and gec itself) are now compiled with gec (previously, SmartEiffel 1.0 was used)
• gec uses the FreeELKS library which has been developed from code donated by ISE

You can keep up-to-date with Gobo Eiffel developments at the Gobo Eiffel mailing list, or closer to the cutting edge at the Gobo Eiffel Project on SourceForge.

The tiny C compiler, tcc, is a streamlined compiler that is blisteringly fast - it can compile the Linux kernel in ten seconds, for example!

For some years, the SmartEiffel installer has supported tcc as a back-end C compiler. Philippe Ribet recently timed the compilation of C code produced by SmartEiffel, using tcc and a number of versions of gcc.

Although gcc performance increased threefold between versions 3.2 and 3.3, tcc was ten times faster still, taking 2.6 seconds to compile the test file versus 25.64 seconds for gcc 4.0. Damian Dobroczyński confirmed that the performance of tcc was "incredible indeed", although the execution speed of the compiled executable was about 25% slower. Damian wrote:

I'm very interested in tcc as a compiler used to every-day developement, but IMHO the final product should be compiled under gcc

There's one problem though. Although the combination of SmartEiffel/tcc worked well in the past, current versions are generating an error (a value exceeding the integer range). Philippe doesn't know whether this is due to a change in tcc or SmartEiffel.

If anyone is looking for a small self-contained task by which they can contribute to the Eiffel community, tracking down the source of this problem would be most useful. Philippe Ribet writes:

If someone is interested in investigating this problem, I can provide some help.

This is an open invitation to a gathering of the Bay Area Friends of Eiffel, for people with an interest in the Eiffel programming language.

The meeting will take place at AXA Rosenberg in Orinda, on Wednesday, March 22. The meeting will start at 6:30.

Directions to the offices of AXA Rosenberg are here:
http://www.axarosenberg.com/axar-contact.htm/axar-location-orinda.htm

The meeting will be in building E, in the conference room near the lobby. As you approach building E from the parking lot, you'll see a large sliding glass door. This is the main entrance. If the main entrance is locked, you'll find a telephone in a box beside the door. You can dial extension 343 to get the attention of those in the meeting room.

A G E N D A

Recent Announcements:

Roger Browne has started the Team Eiffel group blog. Eiffel bloggers are welcome to join, and all Eiffelists are encouraged to drop by:
http://teameiffel.blogspot.com/

Roger has also released version 0.4.2 of Amber, his Eiffel-inspired scripting language:
http://xamber.org/index.html

Andreas Leitner announced the release of Autotest 1.1.0:
http://se.inf.ethz.ch/people/leitner/auto_test/

Andreas has also released a new version of EWG, the Eiffel Wrapper-Generator
http://ewg.sourceforge.net

Paolo Radaelli announced a project to publish wrappers for popular libraries:
https://gna.org/task/index.php?func=detailitem&item_id=3044

Daniel F Moisset has released V 1.2r6 of SmartEiffel transitional. This project is a fork of the SmartEiffel project, maintaining source code compatibility with an older version of the compiler while adding extensions that are appearing in the main branch, fixing bugs, and adding other improvements to the underlying implementation.
https://opensvn.csie.org/traccgi/smarteiffel12/trac.cgi/

Presentation:

Neal Lester will give a presentation on the many additions he's made to the Goanna Web Server.

Discussion:

In late 2005, BAFOEiffel discussed writing an introduction to Eiffel. I've made some progress on this, and will be giving the group an update. I should note that Colin Adams has also been working on an introduction, and Julian Rogers is planning to publish a book about the Eiffel Vision 2 library as well.

Request for Presentations for future meetings.

Other news people would like to share.

Afterwards:

I like to go out for dinner after the meeting, where I tell my Eiffel joke. I've recently refactored the joke to improve punchline delivery and to leverage popular culture.


For further information, contact Greg C gmc444 at yahoo.com.

Don't miss future announcements! Join the BAFOEiffel mailing list,
http://groups.yahoo.com/group/BAFOEiffel/
by sending an email to BAFOEiffel-subscribe@yahoogroups.com

Paolo "Tybor" Redaelli has applied to the Gna! Project for them to host his project to build a collection of wrapper libraries for SmartEiffel, released under the LGPL.

Paolo already has some code to start this project with - he has worked on wrappers for GTK+ 2.x and has partially implemented wrappers for the Gnu Scientific Library and the GnomeVFS filesystem abstraction library.

David Brown plans to add a wrapper for Sqlite3. Cyril Adrian has suggested that Paolo's project should use SmartEiffel's plugin mechanism because "users have less things to manually describe".

Paolo concludes with a couple of quotes that reflect his opinion that working but incomplete code is better than grand plans but nothing working:

one of my favorite mantras is "perfect is the enemy of good" [1] and the idea is that "good enough" is actually a lot more flexible than some idealized perfection -- Linus Torvalds

Had the first versions of other imperfect specifications such as TCP/IP waited ten years for those in disagreement to work out their differences, the Web might still be hiding somewhere in the back of inventor Tim Berners-Lee's mind -- David Berlind

SmartEiffel has been case-sensitive (at least on the first character of identifier names) since its inception. For example, the compiler has always treated Therapist and theRapist as distinct identifiers.

Upon the urging of Eric Bezault, a "-case_insensitive" flag was added in 1997. This aided compatibility with other Eiffel compilers, but the flag was removed with release 2.2 in December 2005. Furthermore, the compiler now enforces certain conventions: a class name must be written using only upper case letters, and a warning is issued if the reserved words "Void", "Current", "Result", "True" and "False" are not spelled with an initial capital letter.

What are the reasons for this?

The SmartEiffel website explains:

This allows us to have better error messages, better error recovery. Furthermore, we think it is better too for readability of our code.

The downside, of course, is that this behaviour is at odds with every other Eiffel compiler, and with every Eiffel standard, and with every Eiffel textbook. It also clashes with the quirky but legal non-standard capitalization used in the acclaimed Gobo package.

And (on a selfish note) it clashes with my own code because I like to write my reserved words in lowercase.

No doubt better error messages and better error recovery are possible with a more constrained language. Also, in a 1997 discussion, Wouter Scholten praised case-sensitivity when wrapping xlib for SmallEiffel - because xlib includes C constants that have the same lowercase mapping (such as 'XK_a' and 'XK_A'), and Wouter wanted a one-to-one mapping rather than being forced to use Eiffel's "alias" keyword for his wrappings.

In this 1998 comp.lang.eiffel thread, Joachim Durcholz pointed out that case-sensitivity means that you can't unambiguously read code over the phone without specifying every letter-case. Graham Perkins pointed out that in the real world British Airways and BRITISH AIRWAYS are the same airline.

Eiffel isn't the only language to have this dilemma. In 2001, Python's designer Guido van Rossum considered changing Python to be case-insensitive, which he considered to be superior. In the end though, he relented:

...never mind, I'm giving up on making *Python* case-insensitive. The hostility of the user community is frightening.

At the end of a long discussion on the SmartEiffel mailing list last year, Richard O'Keefe reviewed the possibilities, concluding that case-insensitivity combined with error messages or warnings was the best available option:

Let's consider several alternatives:

(1) 'A' and 'a' are treated like completely different letters. Each identifier must be cased consistently, otherwise it would be a different identifier.

It is argued that this is confusing for people because case does not provide any clue about what kind of thing you are looking at.

Some case convention rules (such as requiring constant-like macros or static finals to be UPPER_ONLY) are clearly extremely bad ideas because they highlight a distinction that the programmer should be ignoring.

It is also argued that it is confusing for people if names that are pronounced the same have different meanings.

(2) As (1), except that the compiler will not allow an identifier to be declared in a particular scope if a similarly spelled but differently cased identifier is used in that scope.

This fixes the "same pronunciation but different meaning" problem. It does nothing about the "case is no clue" problem, but then, it's not clear how case *could* be a clue for, say, Japanese.

(3) As (2), except that the compiler also enforces a style rule, like Prolog's "lower case = constructor, upper case = variable" or Haskell's "lower case = variable, upper case = constructor".

This is fine, except that it *can't* work for many scripts. For English, there's the caseless Shavian alphabet, but who uses it? More realistically, in Hebrew and Arabic and Indic scripts such as Devanagari there is no case distinction, so if there is one group of words that MUST be spelled with a particular case and another group that MUST be spelled with another, what on earth can be done for those scripts?

(What Quintus did was to say that "_" was an upper case letter, and that non-cased script elements were lower case letters, so variables in non-cased scripts just had to start with "_". Some programming languages, like C, make it hard to adopt such a rule, and others, like Java, strongly discourage the use of "_" anywhere. One has to wonder what the Java designers thought they were playing at.)...

(4) 'A' and 'a' are the same letter. You can write BEGIN, begin, Begin, beGiN, or any other case pattern that takes your fancy,

It is argued that this is confusing for people because the same identifier may appear in many different forms making it hard to recognise visually.

This is "case insensitivity" and it is hard to see how it promotes readability.

(5) As (4), except that whenever an identifier is used, the compiler checks that it is used with the same case pattern it was declared with and warns if it isn't.

This fixes the "same pronunciation different meaning" and the "same identifier but different looks" problems.

(6) As (5), but the compiler strongly (with error messages) or weakly (with warning messages) enforces some style rules.

As far as I can see, (6) would be the best choice for an Eiffel system.

+ Recognising the same identifier, however cased, would maximise compatibility with other Eiffel systems.

+ Warning when an identifier is cased inconsistently would tend to improve readability.

+ Warning about the violation of style rules would tend to improve readability (provided the style rules don't insist on bad things like IDENTIFIERS_IN_ALL_CAPITALS or baStudlyCaps) but would also allow any necessary deviations.

Anyway, SmartEiffel's case-sensitivity is not likely to change. Dominique Colnet has said more than once that "SE will not reverse this decision".

I released SmartEiffel 1.2r6 recently. This is a project that I started last year. It is a sort of manteinance branch of SmartEiffel 1.1 (not official, but approved by the official team) and fixes a handful of bugs without breaking backwards compatibility.

However, my motivations to start the project were not just mantainance and bugfixing (most of the fixed bugs were fixed in 2.x, anyway). I got frustrated trying to do three different things:

1. Using code that I had written for SmartEiffel 1.1 together with new SmartEiffel 2.x libraries and tools


2. Porting my libraries to 2.x, without removing support for 1.1 users


3. Writing new code, using SmartEiffel 2.x, using third party libraries that used to work in SE 1.1.

Both things have lots of difficulties because of not-so-minor incompatibilities between 1.1 and 2.x versions of SmartEiffel. So I started SE12 as a generic solution to the above problems. The idea is having a compiler which is 100% compatible with 1.1, but supporting enough of 2.x to be able to write easily software that works in both releases. Besides, I added lots of warning messages reporting things that still work in 1.2, but will not work in 2.x. With that you can achieve point 2. above, and ease the migration of own code or third party libraries required for 1. and 3.

This last release reached a success milestone: it is able to compile itself, 1.1 software, and it can be compiled with SE2.1. So the compiler itself has been used as a working example of its usefulness as a transitional compiler.

Besides the initial goals, there were some valuable lessons learned:

• Mantaining the compiler code, even when I didn't write it, is not hard. Without any specific compiler-writing knowledge and a few monthly hours to put into this, most bugfix or desired features were added in one of two days.


• Adding workarounds to compile code for two slightly different languages and slightly different libraries is certainly possible.


• Preserving compatibility makes some things ugly here and there. But I have received several thankful messages, and no complaint. So despite the uglyness, users like that a lot. And in my pragmatical point of view, it means that the ugliness was worth it.

The last points make me think that it is not unconceivable to adapt an existing Eiffel compiler able to accept most code from all the current Eiffel variants.

When the UK and Ireland Eiffel Interest Group was going strong in the early 1990s, we used to talk about the growth of Eiffel. Often, the conversation would end with someone making a comment like "of course at Apple, they're using Eiffel for multimedia".

None of us were multimedia developers, and we didn't really know what was going on at Apple, but we liked to spread the news. A few years later I looked into this in more depth and was fascinated by what I found. There's a whole community of multimedia developers using an Eiffel-like language called Key, and Eiffel-like techniques, to develop CD-ROM titles and media-rich websites.

Because these people think of themselves as designers, and we think of ourselves as software developers, there's almost no overlap between the two communities - but it's nice to see this specialist niche that has developed.

I previously wrote this up for comp.lang.eiffel in 1998, then later for Eiffel Liberty Journal. This month, when I checked for updates, I found that a whole new chapter had occurred, with a new twist.

See Apple's Eiffel-inspired multimedia language.

A few days ago, writing about Eiffel applications for non-Eiffelists, I said

Just imagine if ... Java programmers were using an IDE written using Eiffel!

Well there are some Ruby programmers that are using an IDE written in Eiffel.

Scriptolutions produces the Arachno Ruby IDE, a "professional Integrated Development Environment for the fantastic Ruby programming language". The personal version is $29, and there's a free 30 day trial available.
Arachno Ruby is written using SmartEiffel, which is credited (as SmallEiffel) in their FAQ:

We found that the best tool for writing large applications is a good high level programming language. Because of this we have choosen GNU Smalleiffel We also use the Open Source FOX GUI Toolkit for our User Interface.

The site includes screenshots and a full feature list. There are also IDEs for Python, PHP and Perl, apparently in a stalled state of development.

Scriptolutions was founded in 2005 by Arachno developer Lothar Scholz. It is a small, privately held company based in Beckum, Nordrhein-Westfalen, Germany. Many of us will know Lothar from his regular commentary in comp.lang.eiffel, where it is apparent that he is sometimes having a "rough ride" with Eiffel.

There's an update out for AutoTest, the "magical" testing tool by Andreas Leitner and Ilinca Ciupa that tries to find ways of breaking your postconditions.

This release adds the ability to integrate your own manually-written unit tests with the automatically-generated test cases, and bug-reproducing cases are now included in the HTML output.

AutoTest supports ISE Eiffel 5.6, and is available as source code or as binaries for Linux and MS-Windows. It's licensed under the Eiffel Forum License 2.0.

When your Dad is an Eiffelist, and you have a Science Project to do, it's just possible that you will end up using Eiffel for it.

That's what happened to Talia Lester, who undertook a science project using simulation to answer the question "How Many Kermode Bears will there be in 300 years with a certain starting population?".

To answer this question, Talia used Eiffel and created a program to simulate Kermode bear populations, which she submitted to the 2003 Eiffel Struggle competition.

So has the world gained another Eiffel programmer? I don't think so. Neal Lester writes: "my daughter doesn't care much about anything she did back in middle school [but] she did learn she doesn't want to be a computer programmer..."

I recently blogged about my experiences with Delphi and Eiffel.

It turns out that Berend de Boer has also written a piece - "Eiffel and Delphi Compared" - where he describes the language issues that make Eiffel better-suited for than Delphi serious software development.

There's also a Macromedia Flash presentation about Delphi and the Eiffel Language by Hal Webre over at eiffel.com.

Bert Verhees suggested, in comp.lang.eiffel, that the Eiffel community was too closed and that we should write "good and useful freeware" for people who don't already program in Eiffel.

It turns out that there have already been quite a few such applications written.

Last century, Loris Bindoni wrote DigiChip, a simulator of a TTL logic circuit "breadboard":


Mike Durian wrote TCL-MIDI, a TCL scripting language extension designed for creating and editing standard MIDI files.

Both of these were created using SmallEiffel, and were distributed as source code. Some users prepared their own binary distributions, and distributed them to those who were not in a position to install the SmallEiffel compiler.

To this day, both of these packages are popular downloads.

There are also some web applications written in Eiffel (although the users may not realise it). I'm thinking here of Andreas Leitner's "Doctor C" (which explains C declarations) and his Kniffel tool (first order predicate logic analyser and charter).

Jim Cochrane's Market Analysis System is used by share traders to chart and analyse stockmarket data. The MAS server is written in ISE Eiffel, and the GUI client is written in Java.

Then there are games. Hubert Cater's "Strategic Command" is a commercial game written in ISE Eiffel based around a WWII Grand Strategy.

A freeware game that has achieved minor cult status is Ken Stauffer's "Hotbabe Chess", a chess game where the computer opposes the player in the form of "hotbabe", an animated character who "loves to play chess and chat about random crap".

So, over the years there have been quite a few applications written in Eiffel that are used by non-Eiffelists.

But I fear the balance is currently tipped the other way. There are several projects to write an Eiffel IDE for the Eclipse platform, using Java. Just imagine if it was the other way around - that Java programmers were using an IDE written using Eiffel!

Andreas Leitner has released version 0.9.0 of his Eiffel Wrapper Generator, which wraps C libraries for use by ISE Eiffel 5.6, Visual Eiffel 4.1 and SmartEiffel 1.1. A selection of wrappings is bundled, including SDL, GTK 2.x and Berkeley DB.

Enhancements compared to version 0.8.0 include better GTK wrapper abstractions, cleaner build system, improved configurability, wrapper generation for arrays/unions/nested-composites, cleaner C glue code, support for some gcc and msc C extensions, and removal of all potential "catcalls" (via Eric Bezault's gelint tool).

This version also adds Mac OS/X support to the existing MS-Windows and Linux support.

Till G Bay has announced the release of EiffelMedia 0.8.0, the powerful open source games framework for ISE Eiffel. This is a serious piece of software for Windows, Linux and Mac.


EiffelMedia features movie support, collision detection, a widget library, theming, multi-player network support, highscore library, resource generator, settings management, audio, CD-ROM and joystick support - and there's also an installer-generator/packager.

There's quite a team working on it too.

The SmartEiffel team are holding a competition to design a new logo, although they haven't yet decided how they will choose the winner. I guess they will just "know it" when the ideal logo has arrived.

Already there are logos involving Star Wars, Russian dolls, jigsaw pieces, Gustav the koala, a working horse, geometric shapes, building blocks, stylised letters, the Eiffel tower (who would have thought it?), a swan, Agents 86 and 99 from "Get Smart", a gnu with Richard Stallman's face, and some toothed cogs.

Oh, and there's also an example of "what not to do":

"The Eiffel tower theme has been totally overdone, and the reference to another language is ... well, dumb."

Anyone can post directly to the wiki site, although you must register first.

Simon Parker sent me the link to this quiz. Can you identify which of the mugshots are serial killers and which are programming language inventors?

• http://www.malevole.com/mv/misc/killerquiz/

This has been posted to comp.lang.eiffel some years ago, but it may be new to many people.

Usual disclaimer: limited sample size, only reflects successful search engine queries that landed at eiffelzone.com, not all searchers were seeking Eiffel content.

1. lua
2. webshort
3. hotbabe
4. kermode
5. eiffel software
6. market analysis system
7. gote
8. mandolin
9. swirl screensaver
10. black tree
11. keywords
12. digichip
13. hipnotik
14. rubik's software
15. smarteiffel
16. symbols
17. x-plain
18. basic data structures
19. bison
20. conjunctive normal form converter