Eiffel Language
Eiffel LanguageEiffel is a statically typed, Object Oriented language designed by BertrandMeyer. Eiffel features an AdaLanguage-like syntax, a robust type system, and direct language support for DesignByContract. Although overlooked by the mainstream programming community, those who actually use it are very excited about it.
See http://www.cetus-links.org/oo_eiffel.html for info.
Eiffel separates the developers from the hackers. The Eiffel language has no dark corners to be explored. There are no "Eiffel gurus". You can learn the language in a couple of hours, and master it in a day. Within a week, the act of coding in Eiffel becomes as automatic as the act of typing, and suddenly you no longer think of "programming" as being "the black art of convincing a compiler to turn out your desired object code".
Wow, this is condescending. Wrong, too, but mainly condescending.
Sure, but there's a big difference between 'learning' a language, and learning to program in that language. You can 'learn' CommonLisp pretty quickly, but learning to program 'the Lisp way' is a different story. Is Eiffel so un-mind-expanding that there's nothing new to bend your mind around? Or is it just so natural that all of the new concepts it provides are super-intuitive? Or what?
[Yes, since when do we learn programming languages in a couple of hours. I don't even know English yet, and I've been studying and using it for quite some years. i.e. It's my native language.]
Eiffel developers spend most of their time in system design, including design of software contracts. Little time, and almost no conscious thought, needs to go into producing the actual code which implements the design and the contracts. Then why have the code at all? Can't it be auto-generated from the contracts?
Which isn't to say that Eiffel developers don't learn something new about their craft every day. But instead of fussing over obscure quirks of the language, or how to trick the compiler into doing something, Eiffel developers are studying the available class libraries, investigating design patterns, and learning the ins and outs of writing solid software contracts.
Those who aspire to be famous as an expert in a language will hate Eiffel. Those who enjoy designing OO software and have grown weary of compiler-wrestling will love it.
"Eiffel separates the developers from the hackers." In which case, why is there virtually no finished software *developed* in Eiffel? And thousands of useful programs in C, C++, and Perl? Even exotic's like Erlang and Poplog have actually been used to achieve more.
I don't think your ignorance about Eiffel really consititutes as fact about the use of Eiffel, there is plenty of Development in Eiffel, only you know nothing about it.
What is the situation about case-sensitivity in Eiffel ? I once got a compiler error for not using ALL_UPPER_CASE in a class name?
As defined, Eiffel the language does not care what case you use. In fact, Eiffel is case-insensitive. Of the four main Eiffel compilers, only SmallEiffel (not Meyer's) is case-sensitive by default, and that option can be turned off.
Eiffel is designed for building systems by integrating components written by multiple third-party vendors and/or projects. A standard naming convention and SystemOfNames is vital for that to be successful. Look how messy C++ code becomes when you integrate libraries provided by different vendors, compared to Java code where there is has a standard naming convention. The same holds for Eiffel, having compiler support to help you is a boon. After all, the more tasks that a machine can do for me, the more time I have to actually design and build the system.
It appears that SmartEiffel in 2006 does require all class names to be ALL_UPPER_CASE and I have not been able to find the option to turn this off discussed above. I want to implement some code written in Eiffel about 1998 when this restriction did not apply. I have been searching for information about when Eiffel (or the implementations) changed in order to understand how to adapt the 1998 code. Does anyone know where to find this, or can anyone recommend a different (preferably free) implementation which does not have the restriction.
I have now had a look at a copy of Eiffel the Language (see lower down) from 1992 which on p.484 definitely gives a guide line that all identifiers, including class names, should be all capital letters. At some time this has become enforced, at least by some compilers.
-- JohnFletcher
I have heard most of the above argument applied to several languages. In the latest issue of "Linux Journal", Eric Raymond makes a similar argument for Python in the Python supplement. The same argument has been applied to Smalltalk & Java here and in several other places. In conclusion, this seems to be a matter of personal preference.
One might well assert, however, that it's not true of PythonLanguage, SmalltalkLanguage, or JavaLanguage. Certainly it isn't of Java; the API is immense.
That's a statement about the libraries, not the language, surely? I think it's good in general for a library to be big. (See LargeAndSmallLanguages.) Doubtless the Java libraries could be simplified somewhat while still providing the same facilities, but some degree of complexity is inevitable if you offer a lot of functionality.
Eiffel References:
(ISBN 0-13-247925-7 ).
(ISBN 0136291554 ).
Eiffel is also 600USD for the pro version, and 2000USD for the enterprise version, unless you're using non-Linux Unix, at which point it becomes 3000/5000. Embedded and VMS are even more...
I've never used Eiffel, but I've heard that sort of argument against Lisp, for example. I'm curious: how long would it take to recoup the cost of the development environment, if it makes the programmer say, 10% more productive? Perhaps FreeCompilersAreTragic??
There's a free Eiffel to C compiler, GNU Eiffel, usually known as SmallEiffel. It doesn't support (at least in version -0.79 didn't) loading dynamic libraries, but most of the other stuff was working pretty fine. It produces a really fast code in ANSI C, so it's very portable. SmallEiffel is written in Eiffel itself, and all the libraries are free. There's a home page at Loria, France[1].
The SmallEiffel compiler also compiles to java byte code and can call and be called from Java. It is possible to dynamically load java, though not eiffel, libraries.
IanJoyner's book ObjectsUnencapsulated takes a close, comparitive look at CeePlusPlus, JavaLanguage and Eiffel. It is meticulous and very instructive.
When I read ObjectOrientedSoftwareConstruction 2, I was struck hard by Eiffel's concurrency. It's really nifty. It's based on a distributed computing metaphor: you have a collection of nodes, each of which has a collection of local Eiffel objects and runs with its own single thread of execution. Since there is one thread per node, there are no local synchronisation issues - it's only inter-node ("remote") calls that require synchronisation. This is where it gets clever and interesting.
When you make a call to a remote object, its preconditions are interpreted not as "crash if they aren't satisfied", but as "wait until they are satisfied", so your call is queued until the object you're calling is in a position to answer your request. In other words, how does Eiffel handle synchronisation? In exactly the same way that it handles correctness. Very elegant.
For example, if you're asking for the top element of a remote QUEUE object, but it's empty and this query has the precondition not empty, then you have to block. Sooner or later, somebody else on another node calls that QUEUE's enqueue method, which has a postcondition of not empty. So now the queue isn't empty, so our query for its top element can finally proceed--and it does.
So what does your node do when its calls to other nodes are waiting on preconditions, sit around twiddling its thumbs and browsing RecentChanges? Surely not! As any devoted Eiffel programmer knows, each method does only one of two things: report information about an object (query), or change an object (command). If I've sent a few commands to a queue object on another node, there's no compelling reason for me to wait around for it to acknowledge them before continuing - I can run off and do a whole lot of useful local computation that's completely independent of the remote queue. So Eiffel uses a scheme called wait by necessity which says that commands can be dispatched asynchronously, and we just need to maintain an invariant: before a query is executed on a remote object, all of our previous commands must have already been processed, and in the same order they were issued. That just means that we're lazy about synchronisation, we only get our world views synchronised when there is an immediate need to do so.
That's how I remember it from reading ObjectOrientedSoftwareConstruction 2, anyway. It's very unfortunate that (as of a year or two ago) nobody has actually *implemented* this model in an Eiffel compiler. It's a very elegant model, but it's not obvious to this observer whether it would actually work or not.
If you're a bona-fide Eiffel programmer, please edit the above to better reflect reality. I particularly dodged the issue of synchronising multiple nodes, because I don't remember how it's done. -- LukeGorrie
Looking at it again now, I see that Eiffel's concurrency model, like Erlang's, borrows a lot from CommunicatingSequentialProcesses.
By the way, is still Eiffel type-unsafe because of argument covariance? And are Eiffel proponents still claiming it as "the purest of 'em all"? I'm just curious, because I don't have the money and the time necessary to further investigate myself.
Money is not necessary: SmallEiffel is free (as in beer and speech). Time is not much of an issue either: the entire Eiffel language can be learnt in half a day of programming, including all Eiffel-specific idioms.
Note: half a day of programming, not half a day of skimming language specs.
What's worse--in some implementations, at least, these type holes caused UndefinedBehavior as opposed to a controlled RuntimeException.
''For more info, see the Eiffel faq at http://www.faqs.org/faqs/eiffel-faq/.
In ObjectOrientedSoftwareConstruction, an interesting proposal (in some minds, a grotesque hack) called NoPolymorphicCatcalls? has been proposed. Essentially, the proposal calls for allowing method ("feature" in Eiffel nomenclature) calls of the form f.x(), where f is a reference to a base class object, only if there are no derived classes in the system which has redefined x() in such a way that a call allowed by the base class preconditions might fail (including undefining the feature), OR when it can be proven that the dynamic type of f is not one of the classes that redefine x() in the manner described above.
This has the unfortunate properties that a) an entire system must be analyzed to determine whether a call is legal or not, and b) adding a derived class to the system, even if not used (or used only in a limited context) can break existing code (i.e. cause it to not compile anymore.)
Why EiffelLanguage just doesn't specfiy dynamic typechecks in these cases (i.e, if a derived class feature has covariant arguments or reduced visibility, it automatically gets a runtime type check) is beyond me. BertrandMeyer analyzes several other solutions, but doesn't even consider this one in ObjectOrientedSoftwareConstruction. He seems to have an allergic reaction to dynamic typechecks of any sort (and is harsh in his criticism of DynamicTyping).
I am investigating usage of Eiffel for developing infrastructure software. I have read the documentation and realize that there is merit in the language features.
Is there any large scale product developed using Eiffel? for example a browser, or a network management system or perhaps a search engine. Is it just that people don't know much about Eiffel and hence don't write software using this *french* language or are there are some sound technical reasons why this cannot be done?
If one wrote a broswer (with equivalent capabilities as in HotJava Browser) in Eiffel vis-a-vis in C++, will the eiffel application run faster? have a better GUI? will have less crashes? will be internationalizable?
How does one implement Networking libraries in Eiffel if one wants to? Assume that I don't want to use Eiffel networking support, then is there a way to implement the same from scratch?
Are there any French software companies or research institutions that use Eiffel for their software development requirements?
I can't answer all your questions, but I can lend you my perspective, as I've played around with the language a bit. I really like the language, and its ideas, I just don't like the available implementations. The only free implementation (SmartEiffel) kinda sucks. With all the new languages coming out today which are built on technology such as LLVM, JVM, or Parrot, SmartEiffel's compiler which compiles to C code and doesn't support dynamic library loading is kinda an anachronism. You can link to C code and thus load libraries that way, but it's slightly ugly and unwieldy to do so, and the means of doing so is not standard across implementations.
I briefly experimented with Meyer's IDE, and it seems to have powerful features, but I don't like the licensing terms. I prefer free tools.
I think this is the main reason it hasn't caught on. It's a kick ass language, quite solid IMO, but nobody has come out with an implementation of it that makes enough sense to a large enough group of people.
There is a Modern Eiffel project now which I think seeks to address many of these problems.
If I had to sum up the language's strengths, I would say that it's a good clean sheet OO design which smoothly and logically implements a lot of more advanced OO techniques such as generics, multiple inheritance, design by contract, while implementing them in such a manner that the syntax is always kept clean and easy to read. This is actually the reasoning behind the "ALL_CAPS" class name convention (not a forced rule, but Eiffel code not in this style will look strange to you after a while), which is one part of a larger naming scheme. This does make the code much more uniform and readable IMO, and fits right in to the overall theme of simplicity and consistency leading to maintainability. The language is descriptive, and powerful, yet not verbose like Java. Its features definitely make it much more likely that you will spend your time churning out code and thinking about logic instead of fighting with the language, and will likely result in much higher quality code as well.
If someone comes out with a good Eiffel compiler for LLVM, with dynamic library loading and optionally a simpler way to call external functions, I would love to give the language a second look.
For free Eiffel resources try...
SmallEiffel is now called SmartEiffel and is available here http://smarteiffel.loria.fr/
Eiffel Software, Inc. http://www.eiffel.com/ As of April 5th, 2006, the compiler is released under a dual GPL/non-free license (in the same style and the same buisness model as the QT library)
From Object tools http://www.visual-eiffel.com/ Another free version of their Visual Eiffel.
See also EiffelSharpLanguage, EiffelUnit
EditText of this page
(last edited February 18, 2013)
or FindPage with title or text search