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."
This was the #1 reason for not using Eifell.
Wikipedia knows.
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!
I'm having first year comp sci flashback! I remember at the time being taught Eiffel as my first OO langage used to teach OO techniques and design - I hated it back then it felt clunky, overly protective and claustraphobic. Now after almost 10 years as a programmer every so often I crack open the old textbooks and think "wow.. that is rather elegent and expressive". Eiffel is engineered/designed - it is deliberately not suited if all you want to do is hack about. It's funny, only yesterday I was using Eiffel as an example to my IT team as a language that forced strong contractual based interfaces.
I just can't be bothered.
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.
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