Slashdot Mirror
EiffelStudio 5.3 for Linux
Admiral Akbar writes "It seems today is the release date of the best damn free IDE available today for Linux,EiffelStudio version 5.3, they have both a free and Enterprise version available. Why Eiffel's not classed as a mainstream language is beyond me, goodies include full concurrent engineering, amazing debugging, browsing and documentation facilities that even your dog would find easy use, plus a Mac OS X version is in the works with a beta available for download soon. Design by Contract here I come!"
Instead of seeing a NON-free version of Eiffel, I would like to se a free version.
There already is a free compiler for Eiffel, you can download it here.
Note to self: get smarter troll to guard door.
Not my dog -- he's still using Windows, even though it smells.
--jdp Maintainer of VisEmacs
Classification of computer languages into "Mainstream" or "not Mainstream" is subjective.
Not only that, it's mainly down to the attitudes of the language users, not the wider community.
Eiffel is always billed as "this far-out groovy different and better type thing" by its own users.
Fortran is clearly a mainstream computer language, if you're a mechanical engineer. But engineers regard it as one more tool. They don't care if it's mainstream or not, it's what they've always used, what they are trained in, and what they have to continue with to use their numerical codes that have been continuously refined for decades now.
COBOL is clearly a mainstream computer language, if you're a financial services provider. They don't care if it's mainstream or not, it's what they've always used, and what they have to continue using unless they want to bear the hideous cost of ripping out their 99.999%+ availability systems that have been performing adequately and continuously refined... yadda yadda
VB is clearly a mainstream computer language, if you're sitting in the mid-size company or SOHO space. It seems to matter to VB-weenies and Microsoft that they are considered "the mainstream". By repeating this often enough, they kinda make it true. Propaganda 101.
Lisp is clearly a mainstream computer language (ANSI-standardised even!), if you're an actual computer scientist as opposed to J. Random Developer. But Lispers' attitude is more like "Mainstream? Who wants that? We are better than that! We have been here since the dawn of time, never growing old! You mere mortals cannot comprehend the heraclitean fire that is the eternal truth of the infinite mutability of Lisp, the language of languages! Mwahahhahaha".
DBC-style assertions are also checked when the original method that asserted it is not run, but one that overrides it. For example, when you have a class A with a method doSomething that promises always to return an integer between 1 and 10, and a class B derived from A that overrides doSomething, you can be sure that you still get an integer between 1 and 10, while in C++, the assert()s would not run.
Programming can be fun again. Film at 11.
There is a DBC implementation for CLOS, the Common Lisp Object System. It doesn't require a preprocessor, of course, Lisp is flexible enough to do such a thing portably.
Programming can be fun again. Film at 11.
To start with, DBC in Eiffel is at the interface level. Asserts in C/C++/Java are part of the code, and are not visible when you extract just the interface. They are in Eiffel.
Second, DBC in Eiffel integrates with inheritance. Contracts are inherited along with their routines, and there are rules for how they can be modified.
Also, when contracting is turned on in Eiffel, the calls only go one level deep. That is, when a routine is called, it's contract is tested. If the contract contains a routine call, that routine will get executed, but the contract on that next routine will not. Saves time and eliminates potential infinite recursion. Not the same with asserts in C/C++, which will get executed until no more are available to call.
Finally, DBC does connect with exceptions. When they are turned on, and one fails, an exception is thrown and the IDE will kick in the debugger on that point. The DBC paradigm lets you determine whose fault it was (caller or callee), and lets debugging go much smoother. When DBC is off, no exception will be thrown, and behavior is technically undefined. There was discussion on the ISE Users Group on Yahoo recently about how exceptions and contracts relate, mainly from a Java/JML point of view.
~Steve
remember Sammy Jankis
yes, but that type can be polymorphic. So while not parametric polymorphism (what we normally call gerneric), or 2nd order $\Lambda$ calc (erm. Is this equivalent to system-F? I can never recall), they can be applied to arguments of differening type.
Hence they deserveto be called generic.
Just two comments on your otherwise good post:
* I don't see the syntactic overhead comment. It seems pretty reasonable to me.
* It's better than Java on the OO front. Much cleaner, without the C/C++ baggage.