Team Eiffel

Emmanuel Stapf has announced Eiffelroom, an ISE-sponsored "one-stop page for everything Eiffel-related".

At Eiffelroom you will find links to Eiffel blogs, mailing lists, discussion groups, articles, tips, polls, tools, libraries, updates, FAQs, glossaries, and much more.

Manu writes:

Make sure to try Eiffelroom and watch it grow. We're sure you'll want to bookmark it as your premier Eiffel resource on the Web.

(Needless to say, you won't find too much about SmartEiffel there.)

Elliotte Rusty Harold writes in his blog The Cafes about proposals for adding Properties to Java 7:

...The proper design of properties was invented in Eiffel over a decade ago...

See: What Properties in Java Should Have Looked Like
http://cafe.elharo.com/java/what-properties-in-java-should-have-looked-like/

(via Tristram Brelstaff)

Labels: eiffel

I just converted an extremely small Perl program into Eiffel. That led me to ponder a few differences between these two languages. First of all the task: any time a line is received in standard input, write the current unix time (number of seconds since the epoch which is 1970) plus 7 seconds to standard output.

The Perl program is brief:

#!/usr/bin/perl
$| = 1;
while () {
    print time() + 7, "\n";
}

The Eiffel variant is considerably longer:

class

 TIMESTAMPS

inherit

 STDC_CURRENT_PROCESS

 CAPI_TIME
  export
   {NONE} all
  end

creation

 make

feature {NONE} -- Initialization

 make is
  local
   s: STRING
   future: INTEGER
  do
   stdout.set_no_buffering
   from
    create s.make (16)
   until
    False
   loop
    stdin.read_line
    future := posix_time + interval
    future.append_in (s)
    s.append_character ('%N')
    stdout.put_string (s)
    s.wipe_out
   end
  end

feature -- Access

 interval: INTEGER is 7
   -- Number of seconds

end

That the Eiffel program is much longer is due to the fact that it is written to be a bit longer, for example the number of seconds has become a constant, something that is good practice, but more naturally done in Eiffel.

Also in Perl many things are somehow available. For example access to standard input. Although they are in SmartEiffel as well, that would lead to code that is not portable. And one can argue that standard input should not always be available. What is the meaning of standard input on a mobile? For a GUI program? There is no such thing. So I have to pull those in explicitly using the STDC_CURRENT_PROCESS class. Just as well as for the definition to retrieve the Unix time using CAPI_TIME. Both are eposix classes by the way.

A couple of lines in the Eiffel program are taken up by building the string. Of course, I could have written:

 stdout.put_string ((posix_time + interval).out + "%N")

But that would have required the inclusion (and minor overhead) of the garbage collector. Because this program runs in a loop, is of minimal importance and should therefore not really bother the CPU, I didn't want to include a garbage collector. So I could not call a query like out which creates a new string every time it is called. I would run out of memory after a few months. So I had to use some SmartEiffel specific code here to very careful turn the integer into an existing string. This string s is created only once. No other objects are created in the loop, so no garbage collector needs to be included.

Perl probably creates new objects in its loop and has to garbage collect them. But the Perl interpreter contains a garbage collector anyway.

The readability is also different. The integer to string conversion in the Eiffel code is its most unreadable part, the other lines are self explanatory. But in Perl, what does the line:

 $| = 1;

do? From the Eiffel code we can learn it turns off buffering of standard output. Actually the whole story behind this line is rather long. It actually means to turn off buffering for the hot file handle. Insert rant here (see section "Bad documentation").

A line like

while () {

isn't also not immediately readable. It has something to do with standard input, and it looks like a loop that while there is something on standard input do something.

The run-time overhead is probably also different, but with todays CPU cycles not really relevant.

The last thing is installation. The Eiffel program has no dependencies except on standard system libraries. To run the Perl program the Perl interpreter must be installed on the target system.

So this particular program is perhaps not the best use case for Eiffel. But it is always fun to write Eiffel code, so the more lines of Eiffel, the more fun.

Labels: eiffel

Long-time Eiffelists will recall the TOOLS Conferences of the 1990s - eclectic but serious software conferences with a strong Eiffel flavour.

The ascendancy of TOOLS occurred during the Object heyday of the early 1990s, when OOPSLA ruled the roost but was criticised by some for giving too much time and space to C++. This led to some memorable and intense flamewars between Eiffel and C++ luminaries, although these may have been lost to posterity as they been deleted from the Google Groups cache. The TOOLS conferences picked up some of the slack, catering for those who had strayed from the mainstream of OO.

Anyway ... TOOLS is back. The Conference Chair is (as many times previously) Bertrand Meyer, and the 45th conference in the series takes place at ETH in Zurich, Switzerland on 24-28 June 2007. The theme for TOOLS Europe 2007 is Objects, Models, Components, Patterns.

The call for papers specifies yesterday as the deadline for abstract submission, and says that this is "firm", but you could try your luck on submitting a paper because another page says that the deadline was going to be February 1 with "no extensions" which obviously didn't hold. There is still time to propose workshops and tutorials.

Labels: conference

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

W H E N

February 21, starting at 6:30 PM.

W H E R E

The meeting will be held at the offices of AXA Rosenberg in Orinda CA.Directions there are at the end of this announcement.

A G E N D A

Business:

Should we be renamed the Bay Area Friends of ECMA Eiffel?

A few months ago I stopped monitoring the SmartEiffel project, and I don't know of any participant in BAFOEiffel who uses SmartEiffel. Much of our focus in meetings has been on EiffelStudio and ECMA. The Gobo Project has also announced support for an ECMA-compatible compiler, and is certainly of interest to the group. Are people also interested in news regarding SmartEiffel? If not, then I would propose a name change to make the ECMA focus of the group clear.

Recent Announcements:

These are largely harvested from the Team Eiffel Blog, so either attend the meeting or read other announcements in this blog to get caught up on recent happenings in the Eiffel world.

Presentation:

Ulrich Weiss will give a presentation on the Eiffel Logging classes he recently wrote. These have been incorporated into the SVN repository hosted by ETH:
http://elogger.origo.ethz.ch/index.php/Main_Page

Other Items:

Whatever you would like to talk about, plus appetizers and beverages. I bring
the cheap stuff. If that's not good enough for you, then bring the good stuff.

D I R E C T I O N S

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

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

A post from Roger F. Osmond on Why Eiffel deserves a wider audience than the ISE mailing list. It is copied verbatim below.

It is important to consider the tools, certainly, but we must also consider the whole process. I believe this is your point, in fact. In my experience, the best big-think benefit of using Eiffel as a tool, is that it's more than a tool. I have been responsible for some pretty big projects over the years and I have learned that Eiffel pays dividends beyond the initial phases of product development. With the Eiffel approach (and yes, the Eiffel tools), the real-world model you develop (the one in your head and on the white board) translates into Eiffel implementation without the semantic chasm that is inherent in all other mainstream approaches.

As good a tool as java is for slapping together something from parts (face it folks, it's popular for a reason), a huge problem with using it for anything non-trivial is in that the implementation doesn't reflect the real-world model. Even die-hard java folks will admit this (after some friendly persusion, possibly aided by beverage of choice).

The up-front sales pitch for using Eiffel includes all the quality arguments, the reuse and such, but the clincher for me is the fact that the product you build, all the way down to the feature signatures, reflects faithfully the problem you tried to solve in the first place. This is more than an academic nicety. It translates into real life benefits for your organization. It means that when the requirements or the problem change, you know where to go to make the changes in your design and code (they're the same thing in Eiffel of course). When there is an error in the code (a semantic error), you will know where and why because the product as implemented doesn't accurately reflect the solution you modeled, and you'll know what to do.

With every other tool/language that I have used, this just isn't the case. The best organizations might have some documentation to map the gap, so to speak, but you know full well that this documentation, by being out-of-band, is by defintion out-of-date by the time it is written. Eiffel well written really does give you what you need to sustain your product and your organization, better than the other tools available.
This is not to say that the other tools are without merit. Entity relationship diagrams, state machines and even DFDs all have a place, but they are not, nor can they ever be the in-band toolset that Eiffel is.

As for BON itself, it's a good notation, but it's still just a notation. I have found that using a subset of it (pretty much the bubbles and arrows) to describe relationships is very effective and requires no learning time. DFD folks might have trouble with the arrow direction at first, but that oinly lasts for a few minutes. If you're thinking in an object way, then it works very well.

In practice, I (almost) never go from diagram-to-code in estudio. I go the other way around, when using a computer at least. My design work is invariably done using a kind or BON-light and a whiteboard. This is true for every Eiffel practiioner with whom I have worked. It's whiteboard to code and back.

Having the diagramming built into estudio is a nice thing sometimes. When teaching beginners, I will use the class construction facility in estudio, but the rest of the time, I simply write the class in my (external) text editor. I take the same approach when building user interfaces, in Eiffel Vision or in HTML/js/java or whatever. I find that the graphical tools (the grunt-and-point interfaces) are great until you're comfortable, and then they get in the way. It's important to have such tools for ramp-up, but you and the problems you are trying to solve will quickly outgrow them.

Apart from maybe being ridiculed by the ignorantia, you will never regret moving to Eiffel. Even if you must work in other languages, your Eiffel experience will stay with you. It will make you a better programmer and a better designer. Let's face it, you will be a better person, and even your hair will take on a healthy sheen (OK, that was a little over the top). You will, however, never be content using other language tools again, so consider this fair warning (really). A good friend of mine once confided "How am I supposed to work with these other tools now that I have known Eiffel. I don't want to go back." He was quite serious. The cold truth is that you will have to use non-Eiffel, maybe most of the time. It can be frustrating, but that's why they pay you the big bucks. Despite this inevitable lament, it's worth it. It's like finally getting an eyeglass prescription that really works. Sure, you could get around OK before, but now, you can really see! Eiffel's like that.

Labels: advocacy, eiffel

Right-click context-sensitive menus are being added to EiffelStudio. "At last!", I hear from the back rows.

This won't replace the current right-click pick-and-drop mechanism. The first entry on each context menu will be "Pick", and the developers are looking at other ideas, such as auto-pick if the right button is held down for more than a certain (short) time.

The developers are asking for feedback, which you can provide at the EiffelStudio wiki.

Labels: eiffelstudio

Paolo Redaelli has announced the release of version 0.1 of the Eiffel Wrapper Libraries Collection, a set of SmartEiffel wrappers for many of the major Free Software libraries.

There's an incomplete yet working GTK+ library including the necessary Glib and Gobject classes, plus wrappers for libGlade (a dynamic interface loader for GTK+), SQLite and GnomeDB (databases), FFMPEG (a multimedia encoding/decoding library), Curl (a full-featured HTTP client library) and XMLRPC (a lightweight RPL library based on XML and HTTP).

The Eiffel Wrapper Libraries Collection project (EWLC) wants to break the chicken-and-egg vicious circle that has hindered the spread of Eiffel. Noboby is using Eiffel because there are no libraries, and there are too few libraries because too few people are using Eiffel. Ongoing development and downloads are at gna.org.

The license is LGPL.

Long-time Eiffelist and Mac evangelist Ian Joyner has updated his website and is now hosting his publications, some of which have for many years been mirrored around the web. Ian's documents include:

• Open Distributed Processing: Unplugged!
• Windows or Macintosh?
• Into Eiffel
• C++?? (a critique of C++ and programming language trends of the 1990s, which was later extended to become the book Objects Unencapsulated: Java, Eiffel and C++??)