Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

EiffelStudio 5.3 for Linux 50

Posted by michael from the tower-of-babble dept.
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!"
This discussion has been archived. No new comments can be posted.

EiffelStudio 5.3 for Linux More

EiffelStudio 5.3 for Linux

Comments Filter:

  • Steep pricetag (Score:1, Insightful)

    by Anonymous Coward
    Priced at US$ 4,799.00, that IS a bit dear.
    • 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

  • non-free (Score:2, Insightful)

    by termos ( 634980 )
    Instead of seeing a NON-free [eiffel.com] version of Eiffel, I would like to se a free [gnu.org] version.
    There already is a free [gnu.org] compiler for Eiffel, you can download it here [gnu.org].

    • 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 [sourceforge.net], 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 [yorku.ca] is working on a BON plugin for Eclipse, but I don't really know anything about its status.

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

  • browsing and documentation (Score:4, Funny)

    by Galahad ( 24997 ) on Friday May 02, 2003 @07:27AM (#5861085) Homepage
    browsing and documentation facilities that even your dog would find easy use

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

  • 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)?

    • 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 b
      • 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 purel
      • We could solve this in C++ by making a new assert() that takes only function objects that return bool (like say, from <functional>)....that would probably end up looking much, much uglier, though. :)
        • 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() (Score:3, Informative)

        by __past__ ( 542467 )
        There is a DBC implementation for CLOS [www.muc.de], the Common Lisp Object System. It doesn't require a preprocessor, of course, Lisp is flexible enough to do such a thing portably.
      • the problem there is that you're allowing assignment in an expression context. ASSSERT wants an expression that evaluates to a boolean.
    • 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.
    • 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 routin

  • Mainstream languages (Score:3, Insightful)

    by Anonymous Coward on Friday May 02, 2003 @08:30AM (#5861384)
    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".

  • 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.
    • * 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.
      • 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 (Score:3, Insightful)

          by jovlinger ( 55075 )
          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.
      • 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?
    • 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.
      • 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 testi

    • Re:Eiffel features (Score:2, Insightful)

      by mattc58 ( 603979 )
      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.
    • 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 ha
    • What is the syntactic overhead? You mean you don't like typing "do...end" instead of curly braces? Or "feature {ANY}" instead of "public"?
  • 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

    • 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 con
      • 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<H

      • 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 [microsoft.com] There you are.
        • 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.

Slashdot Top Deals

Once it hits the fan, the only rational choice is to sweep it up, package it, and sell it as fertilizer.

Close