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!"

Comments

Steep pricetag

[Anonymous Coward]

Priced at US$ 4,799.00, that IS a bit dear.

Re:Steep pricetag

[LeonardShelby]

That price includes the compiler, automatic dependency tool (like make, but way better), editor, debugger, CASE tool, metrics tool, profiler, etc., all in one fairly slick IDE. A GUI builder is also included.

And that price is for the commercial version, which means you can sell what you've created. The license on the free version says that you can't sell anything you've created. Also the GUI builder with the free version is simply a demo.

~Steve

Re:Steep pricetag

[Anonymous Coward]

Good tools don't come cheap in any profession.

With many software applications (databases, servers, etc.), you pay 10 times that amount or more per CPU!

Remember that you can create as many products with it as you want with it for the low, low price of $4,799.

Re:Steep pricetag

[Anonymous Coward]

For that much money, you can get a REAL development environment, instead of a little "designer" toy.

Eiffel had the shortest moments of fame in "over hyped programming language" history. It had the backing of a corporation (albeit an small one) and shipped with a best selling, Jolt award winning book. But made no difference, and all that is left of it, is "Design by Contract", which is NOT a language feature but a programming style.

Re:Steep pricetag

[Anonymous Coward]

And you are simply a homo. A fairly slick homo.

StiffelStudio for Webchat (of org)

[Anonymous Coward]

The new stiffel studio product produced by your favorite opers on Webchat (kc and ScattK)

New Features:

DNA Sampling (module)
Urine Testing (includes 8 cups)
Rape Kit (for help after these two rape you)
Cost Effective (it's free, well if you don't count having to take a barrage of insults and barratement as payment)

These statements are false until proven true.

#spiderslair Webchat.org (: be there

don't download it!

[Anonymous Coward]

Admiral Ackbar writes...
Why Eiffel's not classed as a mainstream language is beyond me.

It's a trap!

non-free

[termos]

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.

Re:non-free

[illusion_2K]

While it's certainly not anything I'm responsible for, a good friend of mine is the project lead/one of the project admins for EDT, which is going to be an eiffel plugin for Eclipse. You might want to check that out - there should be a release RSN.

Some other guy at our university is working on a BON plugin for Eclipse, but I don't really know anything about its status.

Re:non-free

[jjga]

Istead of seeing a NON-free [eiffel.com] version of Eiffel, I would like to se a free [gnu.org] version.

Yeah, too bad people has to eat some way. Those greedy bastards!

Re:non-free

[Scaba]

If it's like every other Eclipse plugin project, its status is and will remain what the RUP guys like to call "the inception phase".

Re:non-free

[illusion_2K]

So go browse the CVS and add a patch. Isn't that what open source is about?

Re:non-free

[Anonymous Coward]

just shut the fuck up, will you?

Re:non-free

[Anonymous Coward]

Shut up, troll.

Please go hang out in your local comic book store instead of bothering us here.

Re:non-free

[Anonymous Coward]

Er. Why would j.random internet guy have CVS write access? "Open Source" doesn't mean "anyone can patch our tree", it's "anyone can fork our tree and patch their fork if they want"

browsing and documentation

[Galahad]

browsing and documentation facilities that even your dog would find easy use

Not my dog -- he's still using Windows, even though it smells.

DBC using assert()

[neutralstone]

The whole Design by Contract concept seems like a very sane way to go about writing libraries (and functions/methods in general), no question about that.

But what makes DBC in Eiffel better than DBC in C/C++, where we have assert() (or exceptions, if you like)?

Re:DBC using assert()

[Per Wigren]

Because assert()s are ugly, clutters the code and it can introduce nasty bugs. That's besides the fact that it doesn't feel "natural" to add it.. Consider this stupid example:

int x=2;
assert( x=1 );
if( x==1 ) printf("x is 1\n");
else printf("x is not 1\n");

With debugging turned on it would write "x is 1" and with debugging turned off it would write "x is not 1". Yes, it's a very stupid example, but it proves that the code can behave differently in debugging/non-debugging modes. Not good.

Real DBC could be implemented in other languages using a preprocessor though, but I've yet to see it implemented. (I admit I haven't looked very hard)

Re:DBC using assert()

[__past__]

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.

Re:DBC using assert()

[Ed Avis]

Design by contract is a design method, it doesn't necessarily need support in the language. assert() is just one way of checking the contract at run time; Eiffel's DBC support is a cleaner way of doing the same thing because there is special syntax for it in the language. But you could do design-by-contract in assembly language if you wanted.

I'd like to see 'fuzz testing' that generates random inputs to a function and checks it fulfils its contract for each. This would be easiest to implement in a purely functional language with strong typing, so you know that the function's contract doesn't depend on global state and the input values you generate have a better chance of meeting the preconditions.

Re:DBC using assert()

[neutralstone]

We could solve this in C++ by making a new assert() that takes only function objects that return bool (like say, from )....that would probably end up looking much, much uglier, though. :)

Re:DBC using assert()

[neutralstone]

Ok, that's pretty good. Would be nice if we could code contracts into pure abstract classes.

Re:DBC using assert()

[__past__]

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.

Re:DBC using assert()

[LeonardShelby]

You can in Eiffel. Contracts can (and should) go anywhere.

Re:DBC using assert()

[LeonardShelby]

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

Re:DBC using assert()

[dabuk]

We could solve this in C++ by making a new assert() that takes only function objects that return bool (like say, from )....that would probably end up looking much, much uglier, though. :)

Problems could still occur as the function could introduce other side effects. I think you can specify a pure function using __attribute__ ((pure)) (in gcc), which cannot have side effects.

Re:DBC using assert()

[jovlinger]

the problem there is that you're allowing assignment in an expression context. ASSSERT wants an expression that evaluates to a boolean.

Mods, -1

[Anonymous Coward]

Dude, go back to Fark.

Mainstream languages

[Anonymous Coward]

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".

Re:Mainstream languages

[Anonymous Coward]

"language of languages" case in point:

DBC in Lisp.

Re:Mainstream languages

[Anonymous Coward]

VB isn't a real programming language. It's on par with writing triggers and aliases in zMUD, but less useful.

Re:Mainstream languages

[Anonymous Coward]

Yes, and Linux is just a hacked-together clone of System V, or some shit.

Turnabout, fairplay, 'n all that.

Re:Mainstream languages

[Anonymous Coward]

Whatever. You're actually defending VB, you realise that? Not even MS does that!

Eiffel features

[0x0d0a]

I've been trying to get myself to seriously try out eiffel for a while now. It seems to be the language closest to what I want, from what I've read.

* It's fairly high level
* For such a high level language, SmallEiffel produces very fast output -- not like Java or C# compilers.
* It does what I thought ML did -- each function acts like a templated function, and when you use a function, it instantiates a new appropriate template automatically. Very, very cool.
* It's heavily object-oriented, much like Java. This could be seen as good or bad.
* It takes assertions seriously.

CONS

* The only big downside is that it has a hellova lot of syntactic overhead.

Re:Eiffel features

[kruntiform]

* It does what I thought ML did -- each function acts like a templated function, and when you use a function, it instantiates a new appropriate template automatically. Very, very cool.

I think ML is more 'templated' than Eiffel in the sense that all functions in ML are generic as possible, whereas in Eiffel, like in C++, you have to explicitly specify which parameters are generic.

Re:Eiffel features

[0x0d0a]

I'd say that functions in ML (not functors) aren't generic, since they're assigned a fixed type once the type is inferred.

Re:Eiffel features

[jovlinger]

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.

Re:Eiffel features

[jovlinger]

So is eiffel statically type safe yet? Didn't it use to have some funky covariance that was thought safe for a long time, but turned out not to be?

Actually that sounds exactly like the behavior you describe. The whole "mytype" business -- erm, perhaps that was LOOM -- same idea anyways.

Re:Eiffel features

[mattc58]

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.

Re:Eiffel features

[CognitivelyDistorted]

Isn't the real difference that ML uses type inference while Eiffel uses declarations? If you wrote ML with type declarations for everything, would it be pretty much like Eiffel?

Re:Eiffel features

[AtATaddict]

Eiffel is purely object-oriented(in the same vein as SmallTalk or Ruby, but statically typed). Everything is an object. Strings, integers, floating point numbers. Yet they can be used with no less flexibility than primitive types in other languages, and have little negative impact on executables. Quite a feat.

Eiffel is no more verbose than it needs to be to express the concepts at work. Additionally, it does several things to cut down on syntax.

1. Semi-colons aren't required.
2. Parentheses don't have to follow routine calls which don't require arguments.
3. Groups of arguments to routines with the same type don't have to be individually typed.
4. Access qualifiers don't have to be individually applied(vs. Java/C#)

Re:Eiffel features

[p3d0]

It's not that it was thought to be safe and then turned out not to be. If I recall, what happened is that they had this one type checking scheme that was safe, but it was too complicated to be practical, and involved whole-system analysis. So they came up with this second, simpler, incremental scheme (relating to "CAT calls", where CAT=Changed Availability or Type). However, even that's too complicated to be practical.

So no, Eiffel compilers still aren't statically typesafe. From practice, I can testify that it doesn't matter. Personally I don't use covariance (which is the one type hole) because I just don't think that way, but even if I did, the reliability from DbC more tham makes up for any reliability lost via the lack of static type safety.

Re:Eiffel features

[p3d0]

What is the syntactic overhead? You mean you don't like typing "do...end" instead of curly braces? Or "feature {ANY}" instead of "public"?

Two Problems

[Euphonious Coward]

First, Eiffel's generic support is not strong enough to implement an equivalent to C++'s STL.

Second, the ability to, and habit of, multiply inheriting from the same type demonstrates a fundamental confusion about what types are for.

I went to a talk by Bertie Meyer back in '86 at what was then Oregon Graduate Center. I drove for 45 minutes to his one-hour talk. He spent 15 minutes on Eiffel, and then 45 minutes hyping his "Cepage" editor. Then I drove 45 minutes home. That 15 minutes turned out to be enough. Why pay attention to Eiffel, when its designer considered Cepage more interesting? Is anybody resurrecting Cepage?

Re:Two Problems

[AtATaddict]

Eiffel's genericity is far more powerful than that which C++ provides. In Eiffel it is possible to restrict the type that may be used. This becomes useful in cases like the DICTIONARY class, where the class provided for the key must inherit HASHABLE.

Yes, this could be done in lots of other languages by not using generics and simply ensuring that the key must be of type HASHABLE. Yet, how then do you ensure that every object bound to that key variable is of the same type? You can't.

So you must have constrained genericity. Eiffel provides this while C++ does not.

Re:Two Problems

[elflord]

Eiffel's genericity is far more powerful than that which C++ provides. In Eiffel it is possible to restrict the type that may be used. This becomes useful in cases like the DICTIONARY class, where the class provided for the key must inherit HASHABLE.

You can do this in C++ too, via creative use of templates. Basically, you take advantage of the fact that you can convert Base to Derived pointers. Off the top of my head, I think something like this should work (where you inherit from AssertDerivedBase<Hashable,T> )

template <typename Derived, typename Base>
class AssertDerivedBase
{
public:
AssertDerivedBase()
{
Derived* x; Base* y = x;
}

};

Re:Two Problems

[AtATaddict]

I think I still prefer "class DICTIONARY[V, K->HASHABLE]". ;-)

In C# 2.0

[Burb]

I believe Microsoft have announce intention to put this kind of functionality in a forthcoming version of C# (not the one in vs 2003, the "next" one whenever that is). You're all going to want a reference now, aren't you... C# Programming Language Future Features There you are.

Re:In C# 2.0

[AtATaddict]

Interesting, though I think I still prefer the Eiffel syntax, which sees no use for repeating "KeyType" later when the constraint is placed on its type.