Team Eiffel

Best wishes to Karine and Eric on the occasion of their wedding, from all Eiffelists.

I won't be able to post to this blog for the next two weeks, but I look forward to seeing some posts from other contributors when I return. Thanks for everyone's support and encouragement during the launch and first few months of this blog.

Roger Browne

Paul Bates (paulb at eiffel.com), in the EiffelStudio Development mailing list, seeks feedback on an alternative icon set that he has developed for EiffelStudio.

The top row shows the current EiffelStudio look, the bottom the new icons.

Paul encourages others to draw icon packs too, and solicits a set of Aqua icons for the Mac.

Further to the previous post, the filename suffix for EiffelStudio's new XML configuration files has been changed from .acex to .ecf (menmonic: Eiffel Configuration File). This change will help those using operating systems that work best with filename suffixes that do not exceed three characters.

Some examples of the Configuration File Format are online, as are other pages about EiffelStudio Configuration. These pages are primarily written for EiffelStudio developers.

The new mechanism is live in recent development versions of EiffelStudio 5.7.

In the #eiffel channel on irc.freenode.net a new user of Eiffel, LunarC, comments:

I'm amazed at how much easier it is to use eiffel than it is to use C/C++, everything just works the first time it successfully compiles =)

I'm sure this is the experience of many who have used Eiffel and other languages. With other languages you spend a greater amount of time debugging.

Nine years ago, in May 1997, Thomas Beale wrote a piece called Eiffel: An Industry Experience, in which he gave the reasons why his team chose Eiffel ahead of Java, after an initial assumption that Java would be used.


Thomas's points in favour of Eiffel were many, including:

As a design formalism, Java is missing Multiple Inheritance (MI), genericity, and assertions. We use all of these extensively in the design sense...

...the browsing mentality behind the ISE environment is superior in conception to what most other C-based language environments seem to offer...

The library is the real language you design and implement in, so it is (IMO) more important than the language itself. Consequently, extensive libraries programmed in a powerful formalism like Eiffel provide a more powerful language to work in. I have come to the conclusion that the use of formal software contracts in the library is the difference between a library you can trust and one you can't.

Thomas concluded:

In summary, two words differentiated Java and Eiffel at the time of taking the decision ... maturity and comprehensiveness.

The project team has not regretted the choice to date, and I don't see that changing.

If there is one thing to learn from this kind of experience (even if you are a diehard C/C++/Java person), it is: do NOT believe marketing hype. It makes fools of competent software engineers. Make a proper investigation, for YOUR project, with YOUR criteria, and decide using facts.

Sure enough, nine years later, Thomas is still using Eiffel.

Google has just released the Google Web Toolkit (GWT) for the development of rich AJAX aps, free for commercial or noncommercial use. Here are some live GWT examples.

You write the application using GWT's Java framework (using your preferred tools, such as Eclipse). You can run and test it using the JVM. For deployment, the GWT compiler transforms it into HTML plus JavaScript. The big advantage, of course, is that GWT takes care of all the browser quirks.

As Google says, "Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatabilities between web browsers and platforms".

It would be fabulous if someone would write an Eiffel wrapper for this...

Have you ever wondered what EiffelStudio is doing when the messages whizz past about processing items at Degree 6 ... Degree 5 etc?

In simpler times, we might have referred to "compiler passes", as the compiler processed the source code (sometimes more than once), then processed its internal structures to generate the object code.

EiffelStudio today has many different stages of compilation - locating classes, parsing the classes, checking inheritance, checking validity, generating "melted" code (suitable for interpretation), generating C code, building dispatch tables, dead code removal and optimization, and finally calling the back-end C compiler. Most of these stages are named by their "degrees", a cute pun that reflects the notions of "melting" or "freezing" the code.

At the EiffelStudio wiki there is a guide to what's happening at each degree - so now you know what the compiler is doing while you are waiting.

SmartEiffel users who work in the bash shell (probably most Linux, Unix and Cygwin users) can now have command completion for SmartEiffel.

Command completion makes it faster to enter command-line options and arguments (including class names) by enabling autocompletion for these items in the context of the 'se' command. If you're familiar with using the 'tab' key to auto-complete filenames, then you will find that this works the same way.

This facility will be part of the SmartEiffel 2.3 release, or you can just get misc/eiffel.bash from the version control repository and 'source' it.

The SmartEiffel wiki discusses Eiffel and Very High Performance Programs:

Eiffel is a beautiful method and language, based on strong and elegant principles. But, what interest (except intellectual pleasure) would you have in using a wonderful language with poor performance for writing your programs?

The SmartEiffel team have always been proud of how well SmartEiffel performs on the Computer Language Shootout benchmarks, and state that they...

...have many ideas for improving generated code ... The main areas for improvement are generated code for dynamic linking, flow analysis and [the] garbage collector.

They dismiss concerns about "lines of code" counts:

In Eiffel ... expressivity is in the power of concepts. For example multiple inheritance and genericity are very powerful concepts, as are static type and dynamic type. This means that properly designed programs will be made with small code, this is global code compactness. On the other hand, there is no local code compactness. The Eiffel spirit is to make your code as legible as possible, because it is written once but is read many, many times...

I couldn't agree more that Eiffel should be a readable language, but I do wonder sometimes how to reconcile SmartEiffel's "smiley operators" ("?:=" and "::=") with this ideal.

Bernd Schoeller and Till G Bay are writing about the progress of the EiffelStudio project and have compiled a questionnaire. Till writes:

It would be great if you could complete it, so we can gain a comprehensive overview.

The results will be published on the project page. Thanks for participating!

Google has released a new tool to plot search trends for any high-traffic search term. You can even plot two or more search terms at once, to compare trends.

For example, here's eiffel vs. java. Oops, that's not a pretty picture! How about eiffel vs. ada? Hmm, more encouraging.

Eiffel vs. COBOL? That's better:

Thomas Beale has made available some IS8601 date/time classes as part of the Open Electronic Health Record project. Some tests are available too.

Thomas writes:

The code is not by any means beautiful, and I am not generally into hand-built parsers, but it seemed a better way for this than the usual gelex/geyacc approach...

The longest thread in the history of comp.lang.eiffel was started by Object "Guru" Robert Martin at midnight on July 3 1995. The thread grew to encompass more than a thousand posts, and spawned dozens of follow-up threads. What was it that could have brought such life to the newsgroup?

Robert Martin had just read Bertrand Meyer's book "Object Success", and took exception to Bertrand Meyer's "Prudent Hiring Principle: Beware of C hackers", where Bertrand wrote:

A "C hacker" is somewone who has had too much practice writing low-level C software and making use of all the special techniques and tricks permitted by that language.

Why single out C? First, interestingly enough, one seldom hears about Pascal hackers, Ada hackers or Modula hackers. C ... typifies a theology of computing where the Computer is the central deity and its altar reads Efficiency. Everything is sacrificed to low-level performance, and programs are built in terms of addresses, words, memory cells, pointers, manual memory allocation and deallocation, unsafe type conversions, signals and similar machine-oriented constructs. In this almost monotheist cult, where the Microsecond and the Kilobyte complete the trinity, there is little room for such idols of software engineering as Readability, Provability and Extendibility.

Not surprisingly, former believers need a serious debriefing before they can rejoin the rest of the computing community and its progress towards more modern forms of software development.

The above principle does not say "Stay away from C hackers", which would show lack of faith in the human aptitude to betterment. There have indeed been cases of former C hackers who became born-again O-O developers. But in general you should be cautious about including C hackers in your projects, as they are often the ones who have the most trouble adapting to the abstraction-based form of software development that object technology embodies.

Robert wrote a detailed rebuttal, but cross-posted it to other groups such as comp.lang.c, comp.object and comp.software-eng, an action that was sure to stir up the hornets.

I'm not going to attempt to summarise the thread - that would be a major undertaking. Instead I've republished an editorial that Richie Bielak wrote for the last ever issue of Eiffel Outlook magazine, in which Richie distils the core argument into a single issue - Design vs. Code.

Emmanuel Stapf has announced a new intermediate release of EiffelStudio 5.7 (5.7.1005), containing binaries for:

• Windows 32/64-bit
• Solaris Sparc 32/64 bit
• Solaris x86 32/64-bit
• IRIX 32/64-bit
• Linux x86 32/64-bit
• Linux PPC 32-bit
• FreeBSD x86 32-bit

Binaries produced by this release are covered by the GPL.

You can use this release to compile the latest subversion development versions of EiffelStudio.

There is also a PorterPackage with which you can build EiffelStudio for platforms that do not have a binary distribution available.

There is a tendency to name Eiffel libraries with the word "Eiffel" in the name. For example there is EiffelNet, EiffelMath, and EiffelStore, all developed by ISE. There is e-Posix by Berend de Boer and ECLI by Paul Crismer. And there is EiffelMedia by Till Bay and the ETH team. And the list certainly doesn't stop there.

While these names couldn't be more technically accurate, they do not give justice to the effort put into making these libraries as great as they are. As the first point of advertisement, they fail to entice the non-Eiffel developer. For most of the programming community, 'It's developed in Eiffel' is perceived as a liability. We know it is an advantage, but they don't. I'm not suggesting you, the Eiffel library developer should lie, but rather stop parading a banner around that says, "This was developed in Eiffel!". Make it a footnote on a webpage.

There have been 242 downloads of my secom library since the first beta release at the end of March. In comparison there have been 343 downloads of Gobo 3.4 since its release July 10th, 2005. These are the sourceforge numbers so Gobo has probably been downloaded at least as many times from Eric's webpage. Can it be that there are more Eiffel developers interested in secom than in Gobo? I doubt it. The answer to the discrepancy is that secom is attracting non-Eiffel developers. Notice the description of secom:

Secom is an object-oriented library of portable, reusable components for communicating over serial devices. With secom you can develop an application that will compile and execute on Posix and Windows, with little to no changes to the source code.

It's intended to entice any developer wanting a library for serial communication, not just Eiffel developers. But I'm not dishonest; if you scroll down the page just a little you'll notice the programming languages are C and Eiffel.

I'd like to think that there is at least one person that downloaded secom expecting a library of C++ or Java classes and, upon noticing their assumption was wrong, decided to try it out, or at least browse through the source, or at the very least know that Eiffel is providing what they need, even if they choose not to use it.

Let's open our arms to the non-Eiffel community. We know what's best for them after all, and don't want to make the same mistakes as the Java community (replacing 'J' with 'E'). Someday soon when Eiffel is the common choice, the word Eiffel in a title will be as redundant as naming documents "Document", or naming blog posts "Blog Post".

If you do a Google search for Eiffel, the top two results relate to the Eiffel Tower.

ISE's eiffel.com is at position three and the Wikipedia Eiffel article at position four. At position seven is the SmallEiffel (!) page, with Berend's Eiffel Cetus Links at position 10.

Further down the list we have Visual Eiffel at position 31, Eiffel for OS X at 36, the Eiffel Software Directory at 59 and NICE at 61.

But SmartEiffel is nowhere to be seen in the top 100 results. So if you have a webpage that still has a link to _Small_Eiffel, it's a few years out of date and it wouldn't hurt to change it to link to _Smart_Eiffel!

Here are April 2006's top search queries that landed at eiffelzone.com.

The usual excuses apply: limited sample size, only reflects successful searches, not all queries were seeking Eiffel content. The full stats are also available, except for a few days that were lost during an upgrade from Fedora Core 4 to 5.

1. lua
2. webshort
3. gote
4. fenestra
5. eiffel ide
6. ewg
7. bison
8. black tree
9. eiffel gui
10. eiffel software
11. empathy
12. hotbabe
13. eiffel zone
14. kniffel
15. eiffel opengl
16. eiffel compiler
17. eiffel mysql
18. lohan
19. eiffel applications
20. eiffel cgi

Greg C has posted an interesting article to the ISE Eiffel mailing list, suggesting that Eiffel should embrace metaprogramming rather than Aspect Oriented Programming, which Greg sees as a limited form of metaprogramming best suited to people who "don't get" metaprogramming. Greg writes:

I think it would be nice if we had better facilities for metaprogramming with Eiffel, and simply did not worry about AOP. There are interesting things we could accomplish by thinking of Eiffel source code as data, amenable to manipulation by other programs. And the relatively simple syntax of Eiffel lends itself to this.

For example, we might want to add contracts to all features that receive a string, to guarantee the string is not void. Or this could be generalized to all reference types in an argument list.

Or we could specify that all the classes in a given cluster only have dependencies on a known set of clusters. This would help support library maintenance and reduce code bloat when a new class unintentionally pulls in a new cluster.

John_Duh replied, voicing concerns that he didn't want "some sort of preprocessor", and suggesting a more dynamic runtime approach.

I'd rather see the provision for compiler plugins. These would be written in Eiffel and would validate or transform the Eiffel code after the compiler parses it but before validity checking and code generation. It would then be straightforward to implement the ideas that Greg offered. The catch is that Eiffel, with its "compile-the-world" approach, doesn't readily lend itself to a plugin architecture (although ISE's Dynamic Linking in Eiffel makes some headway in this direction).

Other tentative steps towards metaprogramming are the APIs offered by Visual Eiffel and Eiffel/S that enable the compilation database to be examined by Eiffel code.

If you have access to a network, it's possible to almost halve the time that ISE Eiffel takes to compile ("freeze") Eiffel applications.

Andreas Leitner explains how to use distcc as the back-end, so that compilation is distributed across multiple hosts on a network. He has tested his setup with ISE Eiffel 5.6 and gcc on Linux.

The diagram shows the speed gain (in seconds) on a 3-host network using distcc and ccache during 'finish_freezing'.

Peter Kehl has implemented Tuples and Agents for Java, based on Eiffel's model. There is also a Collector abstraction, of which Agent is a special case.

This is part of Peter Kehl's Reusable Object Graphs project (project home page, SourceForge development).