Become a fan of Slashdot on Facebook


Forgot your password?

EiffelStudio Goes Open 219

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 discussion has been archived. No new comments can be posted.

EiffelStudio Goes Open

Comments Filter:
  • About time (Score:5, Funny)

    by imbaczek ( 690596 ) <imbaczek&poczta,fm> on Wednesday April 05, 2006 @08:19PM (#15072184) Journal
    This was the #1 reason for not using Eifell.
  • by bigtallmofo ( 695287 ) on Wednesday April 05, 2006 @08:20PM (#15072191)
    Eiffel is an object oriented programming language supporting contracts.

    I was beginning to get concerned about the incredible lack of object oriented programming languages currently available.

    Fortunately, there's now another one to choose from that is now free.
    • Re:Oh Thank God (Score:5, Informative)

      by shutdown -p now ( 807394 ) on Wednesday April 05, 2006 @08:56PM (#15072374) Journal
      Mods, parent is not "Funny". It's "Uninformed".

      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.

      • When choosing the right tool for the job, you choose the tool that can meet a balance of three particular things.
        1) Best tool for producing the application
        2) The tool you can find people that know how to use
        3) The tool with the best support

        Well, there are tons of places that Eiffel is the best tool for the job. I would even imagine that there are circumstances where the support is there. Problem is finding the people that know how to use it.

        I've been goofing with
        • Re:Oh Thank God (Score:4, Insightful)

          by civilizedINTENSITY ( 45686 ) on Thursday April 06, 2006 @03:25AM (#15074071)
          "I am 100% in favor of companies trying to sell us a new language...", but since Eiffel dates back to 1985-86 [], I don't know what you mean.

          "Another great example of a language that is probably better but has never picked up steam is Scheme. Every compiler developer in the world loves scheme. It is by far the most heavily optimized compiled language on the planet. It has great merits. But the fact is that with the exception of the scheme compilers written in scheme and and an ocassional university project", which is what it was designed for: Scheme was meant to be simple rather than useful, in order to further the study of such things as program correctness (software algorthims studied as mathematics) by academia. The industrial version is Common Lisp.

          When discussing the right tool for the job, comments regarding the attempt to use a thermometer as a hammer (Scheme vs Common Lisp) make it hard to take your C++ vs Eiffel seriously, especially since you seem to think a 21 year old language is "new". It is old enough to drink.
  • Eiffel Contracts (Score:5, Informative)

    by j ( 2547 ) * on Wednesday April 05, 2006 @08:34PM (#15072255) Homepage
    I had to look up what Eiffel Contracts [] were:

    To be sure that our object-oriented software will perform properly, we need a systematic approach to specifying and implementing object-oriented software elements and their relations in a software system. This article introduces such a method, known as Design by Contract. Under the Design by Contract theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations -- contracts.

    The benefits of Design by Contract include the following:
    • A better understanding of the object-oriented method and, more generally, of software construction.
    • A systematic approach to building bug-free object-oriented systems.
    • An effective framework for debugging, testing and, more generally, quality assurance.
    • A method for documenting software components.
    • Better understanding and control of the inheritance mechanism.
    • A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.
  • The Real Link (Score:5, Informative)

    by ploss ( 860589 ) on Wednesday April 05, 2006 @08:36PM (#15072265)
    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: []

    Also there should be a PDF warning on the ECMA standards link, just a thought.
    • Re:The Real Link (Score:3, Informative)

      by zsau ( 266209 )
      Also there should be a PDF warning on the ECMA standards link, just a thought.

      Depending on what browser you're using, you might actually be able to have a reasonably accurate automatic PDF warning system. It's not perfect (it goes by the name of the link, so if you've got a download page in between it marks it as PDF, and if there's a file without a PDF extension that is PDF, it doesn't get noted), but it works reasonably well. (Obviously the best solution is to get the linkmaker to do it properly, but if t
  • flashback (Score:5, Interesting)

    by agendi ( 684385 ) on Wednesday April 05, 2006 @08:36PM (#15072266)
    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.
  • by Speare ( 84249 ) on Wednesday April 05, 2006 @08:42PM (#15072302) Homepage Journal
    This guy has had what, fifteen years? The language is a niche language in a crowded field of languages. It's not going to just catch fire and get more fans because you slapped the seal of Free Software onto it. It smells more of an abandonware goodwill gesture than anything.

    As a language, Eiffel doesn't make it more convenient to express a problem to receive a good solution, it just makes the programmer follow the public speaker's maxim:

    • First, say what you're about to say; then say what you came to say; then say what you just said.

    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. It's even easier to write bad tests when it's right next to the code being tested, so why bother?

    Bertie, give it up already!

    • Wasn't java based off it?

      Effiel was the first language with garbage collection if I remember correctly.
      • Uh, you remembered wrong. I doubt even LISP qualifies as the first.

        "For many people, Java is the first language they've used with automatic garbage collection. While it may seem like new technology, it's actually been around for a very long time and is a well studied field. This book is a good tour through all the gritty details of many GC algorithms and covers the tradeoffs that distinguish them." -James Gosling

        • Well as I recall it was (1) flipping switches (machine code), then (2) assemblers, then (3) macroassemblers, then (4) fortran, then (6) lisp. I'm pretty sure that the first 5 didn't have garbage collection.
        • Well, Lisp is the second-oldest language; the oldest is Fortran; Fortran doesn't have garbage collection; thus I would guess that Lisp does qualify as the oldest language with garbage collection.

          OTOH, I don't know if Lisp had garbage collection from the beginning or not; it may be the case that Lisp was not the first language to use it. But I'm pretty sure it was.

      • Wasn't java based off it?

        Bzzzzt. Java mainly followed in the footsteps of C++. Eiffel is quite different.

        Effiel was the first language with garbage collection if I remember correctly.

        Bzzzt. Lisp environements had GC by the early to mid '70s.
      • Effiel was the first language with garbage collection if I remember correctly.

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

      • Wasn't java based off it?

        Not even close. Java most resembles Object Pascal with C++ friendly syntax.

        Effiel was the first language with garbage collection if I remember correctly.

        Lisp is the first language that I'm aware of to use it, but I bet someone else did it even earlier. Most functional languages use garbage collection. Eiffel is the first statically typed language I'm aware of to use garbage collection (as part of the language itself, not implemented in a library). This is probably the area

    • If you think that DbC and unit tests serve the same goal, then you do not understand the point of DbC in the first place. Unit tests are for testing. Contracts are for documenting the interface.
    • by Coryoth ( 254751 ) on Wednesday April 05, 2006 @09:05PM (#15072427) Homepage Journal
      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.

      • Programming by contract is not the right choice for every programming project

        It seems reasonable that making formal assertions about how programs work ought to help create better software (along some dimension of "better"); even though that's never been rigorously demonstrated, let's just stipulate that.

        That still leaves the question whether design-by-contract is the right way of doing that, and whether Eiffel is the language to do it in. Personally, I don't think so: I think you're more likely to write so
    • >It smells more of an abandonware goodwill gesture than anything.

      I have no doubt that you're right; but I have to what? You make it sound as if this is a bad thing; I'd like to know what you'd have preffered.

      By releasing this to the public in this manner, Eiffel has a chance to stay alive and to be adopted by a community which will use and enhance it. Mind you, I can relate to your attitude of "what a kiss off, who cares?". That is exactly how I felt about the open-sourceing of minix years back.
  • by dudeX ( 78272 )
    At least according to this website I found via the website.
    It lets you compare any two languages that have compilers in Linux and it gives you a graph of speed vs memory usage in various kinds of programming patterns such as matrix math, branchy programs, etc.
    Eiffel (compiled with SmartEiffel) vs C++ (GCC 3.3.4) is actually slightly faster than C++ in almost all of the tests that the author came up with. And the memory usage is just as efficient as C++.

    I've looked at Eiffel, but the syntax isn't
    • From what I have seen Eiffel is like the B&D of object oriented languages. You have one polar opposite like Ruby, where you are free to do things using a variety of approaches. Then in the middle you have something like Python, where you are encouraged to do things using a certain Pythonic approach. Finally you have Eiffel where it's a certain way or else. Compiled the Eiffel code may be fast, but using their IDE makes Eclipse look like lightning. Creating a new project in EiffelStudio with all of the d
      • You have one polar opposite like Ruby, where you are free to do things using a variety of approaches. Then in the middle you have something like Python, where you are encouraged to do things using a certain Pythonic approach. Finally you have Eiffel where it's a certain way or else.

        Which is bad if you just want to bash out code, but great if you want serious long term maintainability. Let's face it the ultimate "There's More Than One Way To Do It" language (hell, it's their motto) is Perl, and we all know h
        • Agreed on all points, especially the Perl maintainability point. If my goal was long term project maintainability, but within a true OO programming language, I would choose Smalltalk over Eiffel any day. That is just my preference and everyone has their own preferences. It's just the syntax and philosophy behind Smalltalk jibes more with what's going on in my head.
          • I agree with you with regards to smalltalk, however I haven't found any free smalltalks that I've particularly clicked with. Syntax wise, they're all great of course. It's the other things. I'd like to be able to distribute an application outside of a VM image, for one (GST can do this, but AFAIK it doesn't support the benefits of having an image in development), and native compilation would be great. Eiffel offers the latter, which is very nice (and very fast).

            I love Ruby as well for it's smalltalk-lik
            • If you are willing to be bound onto the Win32 platform Dolphin Smalltalk offers the ability to distribute an application in the form of an executable and a couple of bundled DLL's. Essentially what you are distributing is the VM with a stripped down image that doesn't contain the workspace, system browser, etc. I have the DST X6 Community Edition and it doesn't have this distribution feature activated. That requires purchasing the Professional Edition. Agreed, out of the various OO languages Smalltalk to m
  • Doesn't anyone remember Bertrand's rant against Stallman and the GPL in 2000? It is pretty amusing that he finally chose the GPL -- I would have thought he would have gone for a BSD License just to save face.
  • by goldfita ( 953969 ) on Wednesday April 05, 2006 @08:56PM (#15072377) Homepage
    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.
    • The thing is that companies by and large don't want to hire great programmers because they cost too much. They would rather hire a bunch of mediocre or crap programmers and make them use a bondage language like java or eiffel. The idea is that you need one sort of smart guy to design the application (writing the interfaces, contracts etc) and then an army of easily replaceable monkeys to do the actual implementation.

      I don't think people will use eiffel for personal projects because there is no sense in put
  • by IvyMike ( 178408 ) on Wednesday April 05, 2006 @08:57PM (#15072384)
    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.
    • 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.

      And the more time has gone by, the more it looks like either of Eiffel of Smalltalk would have been far better choices. When it comes to clean OO design both Eiffel and Smalltalk are way ahead of C++. All C++ really had going for it in com
  • If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language. []
    • If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language.

      It's sad but I fear the D programming language will face the same fait as Eiffel: Not enough used! But I've several times said how this can be solved. I really hope people would listen to my suggestion since I think the D language is well worth the effort.

      In OpenSource no matter what you do, to become successful you have to be the number one in your area. Only then developers are faced to delve into
      • Also, GDC [] needs to become more stable and integrated into GCC, or at least appear in most Linux distros' package repositories. A 1.0-release with a stable ABI will also help. And the D-mangling patch for GDB should be integrated...

        A stable cross-platform GUI library is also needed. WxWidgets is good on Windows and UNIX but only "OK" on MacOS X. A stable release of WxD [] will do. DWT [] (D port of Java's SWT) seems promising also but AFAIK only available as a win32-only alpha release so far. D bindings for Qt 4 w
  • From the product web site [], it looks like Eiffel targets .NET. I know in the past Eiffel could emit C code which was them compiled. I'm not sure if the .NET "integration" is only in Windows or if it uses Mono on linux for that. I'm not able to determine this from a cursury glance at their web site.

    In any event, I welcome this move. I'm definitely adding Eiffel to my list of languages to learn. It is a neat language that has a lot of advantages. In fact at one time
    • Re:.NET/Mono (Score:3, Informative)

      by Coryoth ( 254751 )
      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.

  • "ECMAEiffel".

    That's a death knell if ever I heard one.

  • by Animats ( 122034 ) on Wednesday April 05, 2006 @11:12PM (#15073031) Homepage
    Is this one of those "we're not making money with it so we're going to GPL it and abandon it" deals, or is it real progress.

    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.

  • Is this fully open source? I.e., do you get the entire sources to EiffelStudio and all the libraries, compiler, and runtime?

    Or is this one of those pseudo-open source releases, in which a large body of code gets released under an open source license, but in order to compile and run it, you need proprietary tools from the same vendor that released the code?
  • As much as it was groundbreaking about 10-15 years ago, nowadays Eiffel is pretty much dead, same goes for Oberon (which was not even groundbreaking, sorry Nicolas Wirth, but I think it is the truth that a language is not groundbreaking if you just rehash the language = os concepts of the early smalltalks but not the geniality behind of having its minimalism, and only going oo the half way, and then nail the Pascal syntax on top of it. Anyway back to Eiffel, it really was groundbreaking by introducing desi
  • Design by Contract, how do I love thee, let me count the ways...
    • DbC is a documentation tool. It specifies the behaviour of a class concisely and precisely.
    • DbC is a design tool. The application is specified by means of classes equipped with assertions (I call this Contract Driven Design, or CoDD).
    • DbC is an enhancement tool. Assertions can be added to existing code to make it more robust. I call this Contract Hardening, or CoHa.
    • DbC is a maintenance tool. Assertions can be added to existing code to co
  • - OSS? Check.
    - Avantgarde Language known for neat concepts, hippness and good results? Check.
    - Compiled rather than the bazillion interpreted PLs I've got allready (Python, Perl, PHP, etc...)? Check.
    - No C/C++ suckage even though it's a compiled language? Check.
    - Comes with neat OSS IDE now costing 0 as opposed to the 4900$ last week? Check.
    - Zero fuss hassle free cross-plattform deving? Check.
    - Zero fuss ultra hassle free cross-plattform GUI kit? Dunno... gotta find that out.

    Mmmmh ..., looks like the Eiffe
    • It has a cross platform toolkit, using native look in Windows, Linux (GTK), and other Unices (Motif); I don't know about OS X. If you want to get into the guts of it, you can go through the abstract layer and work more closely to the native toolkit (at the expense of portability, obviously).

      I tried it a little some time ago, not too much. But it seems to be as hassle free as you can get (which is not "100% hassle free").

  • I've been using Eiffel - and EiffelStudio - a bit lately. Eiffel seems like a decent enough language, though it's most attractive for writing libraries etc, just where its less than fantastic interface with other languages makes it less useful. If I didn't feel some bizarre need to have portable code (what a silly idea!) I'd be interested in using it on the .NET CLR ... but that's not viable for me at present.

    EiffelStudio is nowhere near as nice as Eiffel. The IDE is clunky and in some ways quite antiquated
  • No one notes it here, but besides the Eiffel Compiler (anyways, we have had a GPL eiffel compiler [] for about 10 years), the guys at are releasing not just the compiler, but also one of the most complete IDEs you can find under a Free license.

    It has a project editor, integrated debugger, including browsing the object structure in run time, a class browser, an integrated documentation generator, and you can write your designs in BON (a graphical notation, UML-style) and flip back and forth from di

  • In addition to integrating the design-by-contract paradigm into the language, Eiffel for .NET is also the only .NET language that supports multiple inheritance via compiler-generated interface implementation.
  • by drew ( 2081 )
    Are we sure that this is being released under the GPL? I don't see any mention of the GPL on the press release or the product page. According to the licensing page ( []) it is only free if you agree to release all software written using it under a free license. If you intend to develop any commercial software, you still have to buy the commercial version. That doesn't sounds at all like the GPL to me. GCC certainly doesn't have that restriction. Moreover the

The intelligence of any discussion diminishes with the square of the number of participants. -- Adam Walinsky