Team Eiffel

I have released "Amber for Parrot" version 0.4.2 (Argument):

Downloads: http://xamber.org/download.html
Release history: http://xamber.org/history.html
Project home page: http://xamber.org/index.html

"Amber for Parrot" is an Eiffel-like scripting language for the Parrot
Virtual Machine.

Changes since version 0.4.0:

- Argument count mismatches are now detected (by Parrot) and an exception is thrown

- The argument-count-mismatch test case is now activated

- Fixed some argument count mismatches in the kernel library

- Unfortunately, two of the examples are broken ('regexp'
issues some warnings, and 'amber-square' raises an exception).
I'm not sure yet if these bugs are on the Amber side or Parrot
side.

- Estimated progress towards release 1.0: language constructs 47%,
libraries 6%, documentation 4%, robustness 6%

There's a free programmers' editor called emacs. It's incredibly powerful, highly customizable and infinitely extensible. It's also a bit quirky in ways that are "better but different".

Berend de Boer is a confirmed emacs user. As he says...

why not use a single editor that allows you to edit everything under the sun, that you will be able to use with every language? Why not become proficient in a single editor, learn to master it and use it for the rest of your life? There's only one editor that truly does everything, and that editor is Emacs

Eiffel support is available for emacs in the form of an "eiffel mode" - a file containing customizations written in a variant of Lisp. With the eiffel mode activated, you can do syntax highlighting, auto-completion of Eiffel identifiers, etc.

Berend's article Editing Eiffel code with Emacs talks you through the installation and configuration of this incredible editor.

Design by Contract, how do I love thee, let me count the ways...

• DbC is a documentation tool. It specifies the behaviour of a class concisely and precisely.


• DbC is a design tool. The application is specified by means of classes equipped with assertions (I call this Contract Driven Design, or CoDD).


• DbC is an enhancement tool. Assertions can be added to existing code to make it more robust. I call this Contract Hardening, or CoHa.


• DbC is a maintenance tool. Assertions can be added to existing code to confirm (or improve) understanding of the behaviour of existing code prior to changes being made.


• DbC is a refactoring tool. Assertions make sure that desirable behaviour is retained even in the face of extensive refactoring. Eiffel code is so malleable when it is contract-equipped.


• Dbc is a correctness tool. Assertions in parent classes help ensure that child classes (which inherit the parents' assertions) are substitutable.


• DbC is an error-handling tool. Assertions define the success or failure of a routine and direct its error recovery during exception handling.


• DbC is a concurrency tool. Well, it will be when SCOOP is implemented, where preconditions play a key role in synchronization.

Have I missed any?

Longtime Eiffelist Colin Paul Adams wants to teach Eiffel programming to people who are complete beginners; who have no idea what a byte is, or a string.

Most existing tutorials for Eiffel seem to assume some kind of familiarity with computer programming, so Colin has decided to write his own material.

The first two lessons are now online at
http://colina.demon.co.uk/eiffel-tutorial/index.html

Colin invites constructive comments by email to the address on the lesson pages.

Peter Gummer, who is a regular over at comp.lang.eiffel, noticed that quite a few Eiffel users have been Delphi users too.

I'm also a former Delphi user. I once had the fortune to be contracted to develop the same application twice - once using Delphi and once using Eiffel.

I've dug out and re-published an old piece that I wrote (for elj.com) comparing my experience with the two languages on this project. Bertrand Meyer cited a comment from this article as impetus that led him to add creation expressions to Eiffel!

• Magic Browser: A Commercial Eiffel Application

A discussion about Data Structure libraries on comp.lang.eiffel reminded me about the Eiffel/S libraries, which have the highest "elegance to power ratio" of the Eiffel structure libraries that I know.

I managed to find an old Eiffel Outlook article about the design of these libraries. As Eiffel Outlook is out of print (and its publisher has gone out of business) I have taken the liberty of hosting the article online:

• Eiffel/S Libraries: A Fresh Approach

It's a little dated, but I hope you will still find it interesting.

There's been a lot of recent interest in AutoTest, an automatic software testing tool for Eiffel written by Andreas Leitner and Ilinca Ciupa as a research project at ETH.

The tool tests Eiffel code by repeatedly calling the code with input data that it has generated. If it finds that the precondition is met but the postcondition fails, then it has uncovered a bug.

Bertrand Meyer described the tool thus:

AutoTest ... is a test generation tool that has the almost unique property of requiring no preparation of test data whatsoever. "Test While You Lunch" is the idea, and the slogan is "We Kick Bugs!". You submit to AutoTest a set of contract-equipped classes, and let it test them automatically, generating objects and routine calls according to its own criteria, and trying to defeat the contracts. More precisely, AutoTest tries to satisfy the preconditions -- trying a routine outside of its precondition is a waste of CPU cycles, even if it happens during lunch time -- and to break the postconditions. It's really push-button: you specify the classes and do nothing else, other than giving AutoTest time to plow through the haystack and find a few needles (bugs). It's incredibly effective, having for example succeeded for EiffelBase in finding (shame) a number of real bugs, heretofore unknown. It's the beauty of contracts that you don't have anything to do to get these results.

Notice: users are responsible for their lunches.

Of course, this underscores the need to write good contracts.

Over the last couple of years, the Eiffel world has been torn in two by the schism that has developed between ISE Eiffel and SmartEiffel. Bertrand Meyer and Dominique Colnet found themselves unable to agree on the future direction of the language. Bertrand has codified his vision as ECMA-367, and Dominique has taken SmartEiffel in its own direction. Both are moving away from the closest we have ever come to an Eiffel common ground - the language described by ETL2.

Thomas Beale has contributed an insightful post to the ISE Eiffel mailing list. Here's an excerpt:

I think it would be reasonable to say that Bertrand and the Eiffel Software group want to go in a more semantically powerful direction, and to do this they have to forsake some of the simplicity of Eiffel; the SmartEiffel people are pretty wedded to the "RISC" ideal of Eiffel (which was certainly a stated ideal at the outset). When I initially read their critique of where official Eiffel was going, I thought that they were right - that Bertrand and Eiffel Software must indeed be mad (just reading a news item you understand;-); but when I took the time to read the theoretical underpinnings of the changes proposed, I found them very cogent and powerful indeed. I don't know whether they are "right" in a biblical sense, but I am convinced that languages of the future have to tackle the kinds of problems that Bertrand and others are tackling in their (possibly quite revolutionary) ideas. In the end, I felt that the SmartEiffel people were overly disturbed by syntax changes (as was I prior to reading about what was beneath them). Any language of the future has to be a "living language"; just as you can't forbid young kids to say/write "l8r" when the rest of us are still saying "see you later" (or in Shakespeare's time, "on the morrow, good friend"), you can't prevent semantic and expressive innovation in a programming language. Practically speaking, it is unfortunate that there will be no gnu compiler for the official Eiffel.

There's much more in Thomas's post.

It doesn't happen to everyone, but there is at least one person for whom working with Eiffel led to love and marriage!

Someone called Sam asked over on comp.lang.eiffel how one could exit an Eiffel program, similar to how one calls "exit(n)" in C.

I suggested to inherit or insert class EXCEPTIONS, then call feature 'die':

   die (code: INTEGER)
      -- Terminate execution with exit status code,
      -- without triggering an exception.

llothar commented that the equivalent feature for SmartEiffel was 'die_with_code' from class GENERAL. This puzzled me, because the excerpt that I posted was scraped from the output of the "se short" command - but I remembered that llothar is using a derivative of SmartEiffel 1.1 whereas I had used SmartEiffel 2.2, so I decided to look into this a little more.

It turns out that all recent versions of SmartEiffel (including 1.1 and 2.2) offer both GENERAL.die_with_code and EXCEPTIONS.die, with the implementation of 'die' being a call to 'die_with_code'.

Visual Eiffel and ISE Eiffel also support EXCEPTIONS.die, which is specified by the Eiffel Library Kernel Standard (ELKS) and is also present in the latest drafts of Bertrand Meyer's update to ETL.

So, in this case, we can achieve cross-compiler compatibility by using feature 'die' of class EXCEPTIONS.

Of course, this feature breaks structured programming as it can bypass cleanup code that follows the call to 'die', and it also bypasses any enclosing rescue clauses. Maybe you don't want to use it after all - but that's a different issue.

One of Eiffel's most prolific activists from the mid-90s to 2002 was Geoff Eldridge from Australia. He spent most of his spare time hanging out in places like comp.lang.eiffel spreading information to help people to use Eiffel.

After the demise of Eiffel Outlook magazine, Geoff decided that the Eiffel community still needed a magazine, but that it should be online instead of paper-based. With that in mind, he talked a dozen or so Eiffel notables into writing articles for the first issue, and he soon published it on a website at the University of Technology, Sydney.

The magazine was named "Eiffel Liberty", inspired by the fact that Gustav Eiffel had designed the framework for both the Eiffel Tower and the Statue of Liberty. The word Liberty also reflected that Geoff had visions of helping to "set Eiffel free" from the chains that were restraining it.

The first couple of issues of Eiffel Liberty were very popular, and Geoff moved them across to his newly-registered domain elj.com where he continued to publish a new issue every two months or so.

The increased webspace, and availability of scripting tools, allowed Geoff to expand the scope of the site considerably, and soon Eiffel Liberty was hosting a huge amount of content besides Eiffel Liberty Journal. Geoff's interest in Object Technology featured strongly, and as a result the site gained widespread readership beyond the Eiffel community.

As Geoff's interests broadened, he also covered scripting languages, methodology, functional programming, extreme programming, software quality and componentry. Geoff also latched on to the burgeoning interest in open source software and featured it strongly.

Despite these broadening interests, Geoff kept up the Eiffel content. He maintained GUERL, Geoff's Eiffel Resource Locator which had links to every possible resource useful to practitioners of Eiffel. In time, this overflowed into the OO Soapbox where links to other languages and technologies were featured.

As if this wasn't enough, Geoff also introduced ELJ Daily, a regular posting of the latest snippets relating to Eiffel and Object Technology. Today we'd call this a blog, but the word hadn't been invented yet. Indeed, Geoff was one of the world's first bloggers.

All this time too, Geoff was also writing open source Eiffel software and inspiring others to do the same. Talk about a powerhouse! He was also having to pay a sizeable chunk of his own cash for hosting costs and bandwidth. He never carried ads on the site.

As the site grew, Geoff and others referred to it good-naturedly by a number of alternative acronyms, including Extremely Large Jumble, which it had certainly become. It was a very useful and much-appreciated jumble nonetheless. The nickname caught on, and soon the homepage itself carried the new slogan.

But all was not well. Geoff felt that he wasn't getting much support from the Object community. He contrasted this with his other interest, photography, where he found the online communities to be highly engaging and supportive. His massive workload might have been getting him down too, and it wouldn't have helped that his girlfriend Jenny (later his wife) had cancer.

A major blow came in late 2000 after some people had strongly criticized the GUERL page as being full of disorganized rubbish. Geoff took this to heart, and erased the page, announcing that "This page has been retired ... I suppose no impression is much better than a bad impression". Many pleaded with him to restore the page, but it was not to be.

In a way, that was the beginning of the end. Although Geoff plugged away for a few more years, the zest was never there quite like it had been before, and Geoff was devoting more time to the newly-emerging hobby of digital photography. On 24 September 2002 Geoff took down the whole of elj.com.

No-one in the Eiffel community seems to know what Geoff is up to now - and quite a few of us have tried to track him down. The elj.com home page is still live, though it contains nothing more than an invitation to click through to Cetus Links. (Does Geoff realise that a three-character domain name can be sold for quite a lot these days?)

Geoff, if you're out there, why not post a comment and let us know what you're up to?

With Ian's permission, I have posted an HTML version of his introductory text Into Eiffel at EiffelZone.

This easy-to-read article was originally written for users of Eiffel for Mac, but is also applicable to users of other Eiffel systems.

Thanks Ian!

Since last year the domain name smarteiffel.com has been used by spammers, so I registered smarteiffel.org in case it suffered the same fate.

But smarteiffel.org is just sitting idle. Does anyone have a worthwhile use for it?

Concordia University's Dependable Software Research Group is studying the use of assertions in Eiffel, and invites developers of open source and proprietary Eiffel applications to participate in a quantitative research survey of the use of DBC and assertions in Eiffel.

Participation involves running a Perl5 script against your Eiffel files, generating some metrics which you then upload.

This has been discussed in several forums, where concern was raised about running someone else's script on your machine. Consensus seemed to be that the script is harmless. Joseph Kiniry endorsed the survey, describing it as "both interesting and useful", and encouraged everyone to consider taking it.

A user called 'left' asked (on the SmartEiffel mailing list) how to do robust stream output. None of the put_xxx features, being commands, report any error status.

Berend de Boer offered a solution that is applicable to any compiler supported by his e-POSIX package:

Use eposix. By default it raises an exception when an error occurs, but you can turn that off on a global or per object basis.

If turned off, check the object's errno.is_ok value. The errno.value property returns the last error, errno.first_value returns the first error that occurred. Be aware that errno.value and errno.first_value are system wide values, so check them as soon as possible.

Bertrand Meyer is a witty and clever guy, although his style can be so dry that people sometimes take it the wrong way. I intend to collect some examples of his wit to post here.

I'll start with an example from an exchange in the comp.lang.eiffel newsgroup during the early 1990s. The thread is no longer on Google Groups, so I'm recalling it as best I can.

Bertrand posted an announcement of an upcoming event, the Eleventh International Eiffel Users' Conference.

An Eiffel hobbyist posted a follow-up message saying that he hadn't realised until now that Eiffel had enough serious users to support an international conference.

Quick as a flash Bertrand posted a reply confirming that the use of Eiffel was indeed growing. Whereas last year there were only ten Eiffel users, this year Eiffel had gained an additional user and as a result of this the Eleventh International Eiffel User's Conference was being held.

I feel cool. Just finished persistent connections support in eposix. eposix still doesn't support multi-threading although I suppose one could extend the standard HTTP server to do that, and it assumes a well-behaved client, but otherwise a client can now send multiple requests through one connection. Internet Explorer seems to like that much better as well.

ETH, Bertrand Meyer's university, is seeking a research employee who would, in addition to teaching, work on a PhD in the field of object persistence, with special application to Eiffel. Requirements include:

• Excellent general computer science background, with a completed Master's degree
• In-depth knowledge of object technology, in particular familiarity with Eiffel and Design by Contract
• In-depth knowledge of database technology
• Excellent design and programming skills, taste for implementation and quality
• Taste for research on difficult conceptual problems (published papers a plus)
• Excellent writing skills, good command of English and willingness to learn German
• Good presentation skills and willingness to teach

"Assistants" at ETH Zurich are paid employees of the university who pursue a PhD. The salary is described as "extremely competitive".

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

1. lua
2. webshort
3. hotbabe
4. symbols
5. gote
6. goanna
7. keywords
8. kniffel
9. black tree
10. wxeiffel
11. bison
12. eiffel software
13. eiffel to java
14. smarteiffel
15. smarteiffel ide
16. swirl screensaver
17. digichip
18. empathy

Several years ago a computer magazine had a huge cover article titled: "C++: The Language Wars are Over!" The article that research into new programming languages was at an end. With the recent addition of templates, C++ was now the language for all purposes. Of course, a year or two later, Sun announced Java, and since then there's been a flurry of new languages, from PHP to C#, and development of new versions of older languages such as Perl 6.

The trend appears to be towards more dynamic languages with greater flexibility and an emphasis on components and tools. (I use Perl a lot, and I believe it would be a dead language if it weren't for the breadth and depth of the libraries and tools that support it.)

Why then, should someone be interested in a language like Eiffel, that seems to go against modern language trends? While the trend is towards dynamicism, Eiffel emphasizes static analysis of code. It's criticized as being too verbose, a "bondage and discipline" language with minimal features, and for lacking the components and libraries available to other languages.

Let me tell you what it is that I like about the language.

Readability. Unlike many programming languages, you can pronounce almost everything you see in an Eiffel program. Indeed, I've even written haiku that will compile in Eiffel (though it doesn't accomplish very much.)

What contributes to its readability goes beyond this aspect. Many choices of design add to the readability of Eiffel, even though they are seen as limitations when writing in it.

One example is the design choice of Single Entry, Single Exit. This means there is no goto, break or continue statement. Procedures and functions always enter at the top and exit at the bottom. The loop statement has only one form, and there's no way to short-circuit the logic to jump out of the middle.

With other languages, you have to very carefully parse what you see to make sure you understand the flow of control. It's much simpler to follow the flow in Eiffel, since what you see is what you always get.

Scalability. Eiffel is often criticized for being a verbose language. I think of it as being verbose in the small, but efficient in the large. Other languages may have a very terse way of expressing a loop, or of incrementing an integer, but because they don't handle multiple inheritance very well (if at all) or generics very well (if at all) expressing complex concepts and designs becomes very tedious and can require a lot of code. Java code has been notorious for being the language of "casts of thousands". Similar casting or type coersion is very rare in well-designed Eiffel.

In essence because of limitations imposed on the programmer by the language, non-Eiffel languages can much less efficient for expressing the architecture and design of a program. At the design and architecture level, Eiffel programs can be more expressive and can accomplish more, in fewer total lines of code, than can other languages.

The design concept doesn't even have to be very complex. Take a very simple function like
that takes two objects and returns the greater of the two. It's very easy to implement an efficient and typesafe max() function in Eiffel, but to do so in C++ takes significantly more code, and I'm not sure it's even possible to write a version that's typesafe.

I read Roger's challenge to write a brief version of the old "99 Bottles" program. If one isn't too fussy about formatting, it can be done in Eiffel in lessa than 20 lines.

class NINETY_NINE create make

feature make is
   local
       i: INTEGER
   do
       from i := 99 until i <= 1 loop
           print(i.out + " bottles of beer on the wall, " +
                 i.out + " bottles of beer!%NTake one down, pass it around, " +
                 (i-1).out + " bottles of beer on the wall!%N%N")
           i := i - 1
       end
       print("One bottle of beer on the wall, one bottle of beer!%N" +
             "Take it down, pass it around, no more bottles of beer on the wall!%N%N" +
             "No more bottles of beer on the wall, no more bottles of beer!%N" +
             "Go to the store, buy some more, 99 bottles of beer on the wall!%N")
   end
end

Of course, if the real point of this is to lampoon programming, and OO programming, then it seems to me that the original example (cited by Roger and over one hundred lines) doesn't go far enough! After all, it lacks a store class, and a wall class, and singer classes, and of course there the shelf class really needs to be a deferred class and the shelf variable dynamically bound to an ARRAYED_SHELF[ANY].

Or something like that.