Slashdot Mirror
EiffelStudio Goes Open
WeiszNet writes "Bertrand Meyer, the creator of Eiffel the language and CTO of Eiffel Software in Santa Barbara, CA has announced in his Software Architecture course at ETH Zurich that the company's flagship product - EiffelStudio was released under the GPL today. Here is the press release: and the project's page.
Eiffel is an object oriented programming language supporting contracts. Last year the international standard (ECMA) for Eiffel was released and now the initiative to go open has been taken."
Wikipedia knows.
The big thing is design by contract. Calling procedures specify what they will guarantee functions and what they expect, functions guarantee what they won't change and list what they expect. This makes code reuse actually practical, since global effects are spelled out.
For example a sqrt function will require x >= 0, that is the calling function must have checked. Since this is specifically listed in the contract your calling function is expected to be able to indicated how it knows that x >= 0 before computing sqrt(x).
The second big thing is that the language is pretty high level and you just give hints to the compiler about how to implement things (sort of like Oracle SQL) unlike Java or C++ where implementation details are definitely part of the program.
That's pretty much it.
I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.
Eiffel has been around for a long time, and is a mature language. What does it offer? A very clean and well designed Object Oriented language with a very clear and readable syntax and great support for Design by Contract. The principle behind Design by Contract is simple enough: objects, and methods provide contracts - providing you meet their stated requirements, the guarantee things in return. Statically typed languages offer some level of this already: you have to provide paramters of the right datatype, and it guarantees the datatype of the return type. Design by Contract essentially just extends this principle to allow for much more expressive contracts than just type signatures, and things like object invariants (properties of an object that are guaranteed not to change). The result is a much clearer statement of intention as to how code should work, and a powerful test harness that massively speeds up the test/debug cycle. In theory you can achieve this by liberally sprinkling assertions through your code. The advantage of having a language with explicit support for Design by Contract is that things like inheritance of contracts and invariants are all handled automatically and elegantly etc.
As well as this release of EiffelStudio as open source, there's SmartEiffel which is an open source Eiffel compiler (which supports a number of extra features beyond what is given in the recent ECMA spec).
Jedidiah.
Craft Beer Programming T-shirts
The link for the project page goes to a wiki page with not too much information. Not to sound too much like a slashvertisement, I'm sure they would want you to also link to this page, containing more information:
http://www.eiffel.com/products/studio/
Also there should be a PDF warning on the ECMA standards link, just a thought.
What are the odds that some idiot will name his mutex ether-rot-mutex!
It is true that Eiffel is not the only language with some support for OO out there. It is, however, the only industrial strictly object-oriented language with static typing enforced thoroughly on all levels. This is different from the much more relaxed model offered by the likes of Java and C#. Also, Eiffel is the only such language which fully incorporates Design by Contract (in fact, it is where it originates from) - and by that I mean not only in the language itself, but also in standard and all 3rd-party libraries as well.
So, yes, there are many good reasons to choose Eiffel over other OO languages.
I've heard of Eiffel a number of times. The contract by design feature intrigues me; I've always wanted to try it. Well, I guess now I have more incentive. I don't think there's anything like it in the more common languages - C, Python, Java, etc. When I'm coding, I usually try to force myself to make decisions about which objects/functions are responsible for what. But it never seems to work out that way. Things decay over time.
I've wondered just how much a language can compensate for programmer laziness, carelessness, or just lack of ability. This question recently came up in a discussion. I am somewhat confident that software or languages can be designed to force good behaviour and eliminate (certain types of) mistakes. After all, there are no memory leaks in scripting languages, right? And you can't write to memory that's not yours. In lisp, it's harder to make off-by-one mistakes than in some other languages. Java forces you to handle error conditions with checked exceptions.
Yeah, I'm going to have to try this eiffel thing.
For all of those hearing about Eiffel for the first time. Back in the mid 80's, when the OO paradigm was first starting to gain traction (but it wasn't obvious that C++ would become the first mainstream object-oriented language) there were debates about whether the big OO language of the future would be C++, Smalltalk, or Eiffel.
If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language.
http://www.digitalmars.com/d/
1) Designed for native compilation. Compare it vs. Common Lisp and C++, not the modern enterprise toys.
2) Design-by-contract. Think of it as taking type-safety squared. Just like static-typed languages are more verbose but compile-time safer than dynamic-type languages (don't argue static/dynamic, you know damn well what I mean), design-by-contract is moreso.
3) Extremely generic-oriented and had generics designed in, as opposed to the after-the-fact hacks that appeared in C++, Java, and C#. And it has multiple inheritence.
Plus, I'm also very disappointed by all the languages you listed being non-generic Algol family languages. That's like asking someone "what's your favourite beverage - Coke, Pepsi, or RC Cola?" The example languages you listed are all of the same line of descent (although Ruby pulls more from SmallTalk than the others). Plus, most of the languages you mentioned are just a mishmash of features. Eiffel is more like "Lisp" in the mentality of design, which is "keep the language simple but make it expressive enough that complex concepts can be expressed simply anyways".
Such languages tend to be much more intelligently structured, safe, and extendable, but also fall short in legibility.
Basically it is similar to Ada and C++, with a little functional programming thrown in. The problem is that most attempts to make C++ "safer" have focussed on ripping out language features like multiple inheritence and templates that made it "too complicated" but were important, useful features. Eiffel takes the alternate approach - instead of paring down the featureset, it pares down the language while actually expanding the featureset.
And if you've never coded with generics and still just typecast your container data: get out of my sight you disgusting hacker. OOP without generics is like a car that only turns left - sure you can go right, just do three lefts.
Programming by contract is essentially just writing twice as many unit tests, wrapped all around the code that is supposed to be doing the work.
Programming by contract is writing your unit testing harness as assertions while you write the code, and having those assertions respect inheritance elegantly, saving you considerable work if you actually have any sort of class heirarchy built up in your code. Programming by contract is about stating clearly how you intend your code to work so that it is much easier to determine whether the code you wrote actually does what is intended or not. Programming by contract is about providing clear and explicit documentation of the interfaces making code reuse and code maintainability far easier.
Programming by contract is not the right choice for every programming project. Sometimes you want flexibility. Sometimes rapid adaptability is more valuable than correctness or maintability. Sometimes, however, it is not. I don't draw up careful plans to build a treehouse, I hold the wood where I want it to go and cut it to fit: being able to adapt to the exact organic shape of the tree is more important than the strict integrity and finish of the treehouse. Likewise I don't build home by nailing 2x4's together and cutting the next chunk to fit: Having a truly solid structure, with all the walls and floors are properly aligned is more important than the speed with which I can get started building something. Different projects have different needs, and there are plenty of projects for which Design by Contract is a fantastic way to go. Just because you, personally, don't happen to work on those projects, doesn't invalidate its usefulness for others who do.
Jedidiah.
Craft Beer Programming T-shirts
Er... you don't recall correctly. Lisp had garbage collection in the early 60's (in fact, John McCarthy invented garbage collection specifically for Lisp). Eiffel isn't even the first OO language with GC - that honour goes to Simula (also the first OO language ever).
It's also worth noting that the GNU Eiffel com piler SmartEiffel provides a tool that can compiler Eiffel code to Java byte-code, so you can run Eiffel programs on a JVM too.
Jedidiah.
Craft Beer Programming T-shirts
Eiffel is kind of dated. Even its successor, Sather, didn't catch on, even though Sather has been out under the GPL since 1999. There are some great ideas in there, but the language was a bit too clunky. It's kind of like Ada and Modula in that respect; the concepts are sound but the syntax is too bulky to become popular.
On the other hand, all the languages listed here protect against buffer overflows without requiring an interpretive run-time system.
Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.
If that's what you're looking for then I would suggest that you take some time to check out JML and ESC/Java2 which provides almost exactly that functionality for Java. It's not as clean as Eiffel as the contracts have be be kludged into Java as add-on annotation in comments, but all the functionality you'd want in a good expressive DbC system is there in JML, and ESC/Java2 provides a static checker/theorem prover that can attempt to verify contracts and provide warn you when they might fail. It also provides a number of other strong static checks based on JML annotations, allowing you to have high degree of confidence in well annotated code that passes ESC/Java2. Honestly, download JML, JMLEclipse and ESC/Java2 and try them out - you'll be amazed the number of subtle errors that can be quickly and efficiently caught!
His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.
It seems odd, but it does have nice aspects, particularly if you're used to a more functional perspective: it goes a long way toward isolating side effects and allowing better reasoning about the scope of effects that a given block of code may have. It certainly makes sense to me.
Jedidiah.
Craft Beer Programming T-shirts