Slashdot Mirror

available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).

You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!

Bertrand Meyer for his contribution to OO Software Engineering, Eiffel language and Design By Contract.

I think an honourable mention most go to Ted Nelson and Xanadu.

Bertrand Meyer for his contribution to OO Software Engineering, Eiffel language and Design By Contract.

I think an honourable mention most go to Ted Nelson and Xanadu.

Bertrand Meyer for his contribution to OO Software Engineering, Eiffel language and Design By Contract.

I think an honourable mention most go to Ted Nelson and Xanadu.

Ok, a plug for the Eiffel programming language. For cross-platform development of a GUI, you cannot really do better. Without a large development team, you will never get your software working on one system and then ported within a reasonable amount of time. Unless, your GUI development is cross-platform from the start. Eiffel is extremely quick and easy to learn (the goal of Bertrand Meyer is for every Eiffel programmer to be an expert Eiffel programmer). EiffelStudio is available for Solaris, Linux, and Windows. Same code compiles on all platforms. As for OpenGL, there of course exists EiffelOpenGL. If you are concerned about whether there is success with this language, Eiffel is used to develop all sorts of large systems, including CAD/CAM programs. Look into it. The widgets are so simple it's hard to not give it serious consideration.

There is definitely a free version available, though the executables created using the free version are not to be distributed commercially. http://www.eiffel.com, and click on Downloads. Then you will understand free.

The current version of Eiffel for .Net supports the full Eiffel language with no limitations whatsoever, free download available here

I learned OO programming in Eiffel also. It's nice and structured. Made lots of useful stuff though, compiling isn't cumbersome at all (Eiffel > bytecode) and it is extremely possible to do multi-platform GUI stuff now (EiffelVision 2) of which the EiffelStudio IDE is made with, here

It is definitely worth it, and a good IDE here is free in all various flavors of platform.

The free version of Eiffel Studio for linux is available here.

This is an example of an extremely well written Gtk application and provides gtk bindings as well as multi-platform libraries that allow applications to run on, if forced to, Windows with absolutely no change of code yet retaining full platform look and feel. Very cool stuff indeed

Two Editions

There is a free edition and an enterprise edition. I haven't downloaded it yet but it looks like the free edition gives you most of the features of the enterprise one.

Eiffel has been around for about 17 years, so a lot of people who used it a long time ago and haven't used it since moan about old problems with the language THAT SIMPLY DON'T APPLY MORE. Here is an up to date list of cool things about Eiffel:

- Compilation is not so slow anymore.

- It a full .NET language. Eiffel Software have made a Visual Studio plug-in, and EiffelStudio (previously EiffelBench, or EBench) can also be used to make .NET or non-.NET applications.

- EiffelStudio is the IDE for creating Eiffel applications was COMPLETELY REWRITTEN a couple of years ago, so previous uses of EiffelBench won't recognise it anymore. The new studio is better in every respect and has the best class browsing facilities you will find in any IDE ANYWHERE (I'm not kidding).

- EiffelStudio was written using Eiffel Software's Vision2 library - a 100% platform independent library meaning it is identical on Windows and *nix platforms. You can use Vision2 to make your own cross-platform interfaces with real ease.

- The .NET implementation of Eiffel adds some programming mechanisms that are NOT available in Java, C#, C++. Namely these are multiple inheritance of classes, genericity (true generics), design by contract (pre- and post- conditions/assertation to improve software reliabilty and greatly ease the debugging process).

- Eiffel Software provide a FREE version of EiffelStudio and Envision! (the .NET plug-in) from there web site.

There's loads more to this language, but aint got time to talk about it, so just check it out yourself.

wrong site. Check http://www.eiffel.com for ISE's web site.

wrong site. ISE's site is http://eiffel.com.

According to the main Eiffel website, a major aspect of Eiffel is EiffelStudio, their "more than just an IDE" that really makes everything go. They imply that this product is necessary to reap the major benefits of developing in Eiffel, but unfortunately it is quite pricey (not to mention proprietary): the Windows or Linux version will run you $4799. That price, and hitching your wagon to a proprietary star, are major barriers to wider acceptance.

If anyone strongly believes that learning Eiffel is worth the trouble even without a good free (as in speech) IDE, please let me know.

Well, as a current student at the University of Notre Dame, Eiffel was used in our Data Structures course. We basically had two options, Eiffel or C++. Not a lot of people picked up on Eiffel simply because they were stubborn. But as a whole, the Eiffel coders had consistently better projects and overall success. It's purely O-O, so that takes some getting used to. The Design By Contract is an excellent tool for writing perfect code the first time, thus getting a larger systems to market faster. And the libraries that are available are excellent. The STL is simply not good enough relative to EiffelBase. Bertrand Meyer, founder of Eiffel Software, gave three distinguished lectures here this week, and another to our class, and he's very convincing when it comes to his methodologies. It's a great language for teaching O-O and Contracts. Additionally, the same code runs on multiple platforms, and EiffelStudio is available for free for Windows and Linux. EiffelVision also makes it possible to create GUI's that will compile on Windows and Unix too.

Eiffel remains inherently an object-oriented language, but in recent times it has borrowed some functionality typical of functional languages, through the new agent mechanism (think of iterators, map and for-all).

• Design by Contract (dbc)
• Multiple Interitance
• Static Typing (no such thing as casting)
• Dynamic Binding

Also, check #eiffel on freenode (irc)

Eiffel is the best,
DM

I'd not call it is "forced" Object Orientation, but rather it is OO plus pre- and post-conditions in a methodology known as Design By Contract.

-Ed

Design by Contract and BON (Business Object Notation) provide a very nice agile development methodology. Take a look at Eiffel.com for details.

Sure. I'll also recommend some books which are on the cutting edge of what's going on in these areas. By far the definitive guide is "Generative Programming" by Czarnecki and Eisenecker. They delve into Domain Engineering, Aspect Oriented Programming, Intentional Programming (being developed by Simonyi @ MS), and other topics in general programming. The book is great, and you can check out Czarnecki's website associated with it which includes source code and links to other online resources. Other literature currently close to my heart is "Modern C++ Design" by Alexandrescu, which deals with Policy Based library design (closely related to the idea of generative programming; it allows C++ to act as a 2-tiered language by giving the compiler the ability to make decisions on what should be compiled), and anything that you can find on the Eiffel programming language (I suggest The Official Eiffel Software Homepage) which implements Design by Contract (DBC). Basically this states that there are certain pre- and post- conditions which must be met by each part of your program and places constraints on the code based on the 'contracts'. As a side note, this can currently be spoofed in C++ by using the static assertion library. Wow, that was long-winded. In any case, hope that helps. If you want more info, drop another post.

...but little progress. I'd say that the one area programming has made leaps of progress is in functionality. But if reusability is the measure of progress, and it is a requisite, then little progress has been made since McIlroy formally introduced the world to highly reusable software components.

If I may actually provide an opinion rather than just rant (I know, it's dangerous here at rant.slashdot.org)...

Design By Contract is an excellent step towards highly reusable components. In order for a component (in its loosest definition) to be reusable it must also be correct. But correct is relative. The requirements, or the contract, must be apparent to the user (client). The run-time should check the requirements for you, and this run-time checking should have the ability to be turned off. Furthermore, in the object-oriented case, the contract should be inherited providing a framework for more specified descendants. DbC is a good tool for providing these.

This is a .sig

Here you can download the Linux, Windows and Eiffel for .NET Visual Studio plug-in (known as ENViSioN!).

Look more carefully next time:
Here's a screenshot ;-)

I am not trying to dispute that Ada is a good language for critical safety related software... but it is only as good as the people and methodology/process being employed.

Consider the fact that the code for the Ariane 5 rocket which crashed because of a software problem, was written in Ada.

• preconditions. A precondition is a rule defining what constitutes valid state when the method is invoked (e.g., The parameter passed in to the called method must be non-null and fall within the domain 3,5,7 or 9.) The caller (client) warrants that all preconditions are true when the method is invoked
• postconditions. A postcondition is similar to a precondition: it is a rule defining valid state following execution of the method (e.g., The value returned by the method will be non-null and a positive integer between 500 and 1000 inclusive.) The supplier (called method) warrants that all postconditions are true on return from the method.
• invariant.An invariant is a rule asserting that the stated condition will be true at all times during the execution of the method (e.g., At no point during the execution of the method will the internal stack pointer belonging to the method exceed the stack size.) The supplier warrants that all invariants will hold true during method execution.

• preconditions. A precondition is a rule defining what constitutes valid state when the method is invoked (e.g., The parameter passed in to the called method must be non-null and fall within the domain 3,5,7 or 9.) The caller (client) warrants that all preconditions are true when the method is invoked
• postconditions. A postcondition is similar to a precondition: it is a rule defining valid state following execution of the method (e.g., The value returned by the method will be non-null and a positive integer between 500 and 1000 inclusive.) The supplier (called method) warrants that all postconditions are true on return from the method.
• invariant.An invariant is a rule asserting that the stated condition will be true at all times during the execution of the method (e.g., At no point during the execution of the method will the internal stack pointer belonging to the method exceed the stack size.) The supplier warrants that all invariants will hold true during method execution.

... is the only truly well-commented code. Literate programming was invented by Knuth. If you don't know who Knuth is: he's the author of the definitive CS work called "The Art of Computer Programming". Ask any of your friends who actually studied computer science about it.

Knuth wrote more than books. For example, he wrote the typesetting program, TeX which is to this very day the most popular way academics in the CS field employ to write their papers (especially using a macro package called LaTex). He just wasn't satisfied with the available ways to write mathematical books at the time (early 80s). He had a good reason - you can see the difference in quality between it and anything else - especially Word (Ugh).

To ensure you'll have the right idea about the quality of his work, note he's actually sending people checks when they find a bug in his books or his code. Of course people tend to frame them rather than cache them :-). Also note that nobody has managed to obtain such a check for a long time.

So, what is literate programming anyway? Instead of inventing yet another definition, here's a pretty good definition which you can find in the site, together with many others:

Marc van Leeuwen. "Requirements for Literate Programming" in CWEBx Manual, pg. 3-4.

The basic idea of literate programming is to take a fundamentally different starting point for the presentation of programs to human readers, without any direct effect on the program as seen by the computer. Rather than to present the program in the form in which it will be compiled (or executed), and to intercalate comments to help humans understand what is going on (and which the compiler will kindly ignore), the presentation focuses on explaining to humans the design and construction of the program, while pieces of actual program code are inserted to make the description precise and to tell the computer what it should do. The program description should describe parts of the algorithm as they occur in the design process, rather than in the completed program text. For reasons of maintainability it is essential however that the program description defines the actual program text; if this were defined in a separate source document, then inconsistencies would be almost impossible to prevent. If programs are written in a way that concentrates on explaining their design to human readers, then they can be considered as works of (technical) literature; it is for this reason that Knuth has named this style of software construction and description "literate programming".

Does it work in practice? All I can say is that I have used it in a real-world project with great success. The main downsides to it, and this applies to any type of documentation, is that it takes up-front time (even if it does save time later), and that you need to employ people with some measure of writing ability. It is surprising how many people can code well, but are hard-pressed to write coherent, readable description of their code. Especially if you write your documentation in English and the programmer's native language is Hebrew or Russian :-(

Oh, and it also is hard to do in IDEs like Visual Studio. And you won't learn about it in your university, never mind your VB in 3 days course. Just like design by contract and many other techniques, the problem isn't that humanity doesn't know how to write software well - it is that humanity doesn't want to.

The chapter on style, from Bertrand Meyer's book Object Oriented Software construction, is available for download in PDF. It has some good, general rules for readablity and format.

As compared to what language???

Take a look at Eiffel for a truly object-oriented implementation of generic containers. Eiffel's container library uses generic containers extensively in an intuitive hierarchy of classes representing many common containers.

The old joke, "if builders built buildings the way programmers wrote programs ..." is still frighteningly true; other engineering professions do not often have a commonplace equivalent of a blue-screen or core-dump.

There are several problems with this, and I tend to get ticked when I see this quote tossed around.

Firstly, software is only as reliable as the language it is written in. That may sound trite, but the reality is that your language (at least in computer science) limits your ability. This is why Perl and Python are taking off, why Lisp is returning, why everywhere you look we're fleeing from C and C++. It is much, much, much harder to write secure code in C than Python, Perl, Ruby, Java, or even C++ given the standard template library. x = raw_input() can't overflow, blow the stack, overwrite important memory locations or in other ways fuck my program. That kind of security comes at an incredible cost in C---but you get it for free in every other language. But we aren't brought up to value security like we value efficiency in school. 2% of us move on to assembly to optimize their algorithms, 80% stay with C because it's the first language they know, and the rest hurry up and use Java or Perl. It's a depressing fact that lazy people like myself, who program in Python, Eiffel, or C++ because we are simple-minded and dislike complexity, and who are quite often the only people who understand *conceptually* the ideas in CS, are also the ones who are ignored, who persist in our laziness despite the attitudes of those around us, and who have such difficulty selling our ideas to other people! It's embarassing that I can do in 50 lines of Python what it would take someone 500 in C to do, even if they had the appropriate libraries! Now ask them to make it secure, if you want a great laugh! They cannot... But when have you ever seen anything written in a language *other* than C segfault? (matlab doesn't count) Half of Lisp's good reputation, when it had one, was because it was cured of that. Python, Java, Eiffel, and C++ all have exceptions to help the programmer cope with EXCEPTIONal situations, why doesn't C sympathize? Instead we get "errno" and hundreds or thousands of EXXXXXX error code constants. Fuck that. The new generation wants a real solution; a solution that doesn't begin with C[++|#|objective]

Secondly, quality of code doesn't matter to the users anyway. If it takes 25% more C code to make something work in the last funky 2%, well it's got to be out by yesterday so forget it. C++ would be great if we could have more flexibility with the libraries; the Be people spent serious time and effort in making their system libraries expandable. (If they hadn't, we'd wind up with the MFC instead of the highly-praised BeOS model.) When Windows crashes, no one is surprised. When IIS drops a few hundred users, it's written off. When MS-SQL mangles a couple rows, it's rare. When I can't connect my modem to my ISP, the phone lines are too old. These are all excuses, but in reality, you can fuck people 2% of the time and it won't be a problem, especially on this scale. Everyone knows that Microsoft's software is shit, but can we prove it? Our bad experiences are usually buried in the last fractions of a percentage point that they can legally ignore. If a building killed 2% of the people in it, it would be a problem. Nobody dies if eBay loses one of my bids. How do we even diagnose these problems when they are that rare? It's not often that every test reality will throw at your program is available to you to know while you are designing or implementing your program. Even if they were, the people programming in inferior languages like C don't always have the luxury of doing extensive tests. There is "make" for building, CVS for versioning; where is the analog for testing? Saying quality control in programming is lax may not be an understatement, but what if we were in the towel profession? Would it matter if 2 out of 100 towels just were no good? Don't take yourself too seriously---where it is a life-or-death situation, they aren't using the same languages. They're using Ada! ;)

Third, the language you would want for this purpose has already come and gone. Eiffel had every feature it could to support the ideology of software engineering. It was a terrible flop in spite of the fact it was, and continues to be a great idea. Merely knowing these features exist in any language makes me unhappy that they don't exist in C++ or Python, or any other language people can actually use. ISE somehow remains profitable without any non-commercial interest. I have to wonder where they are used, because my only experience with it that wasn't purely motivated by my own interest was that Object Oriented Software Engineering was recommended to me by many people as a great book to learn about object-orientation from. I would be tempted to say government work if that weren't Ada's niche already. Perhaps it is education, but it certainly isn't popular around here. SmallEiffel hasn't been updated in how long? Instead Eiffel leaves the earth to be one with BeOS on the great hard drive of the sky. Or something.

To summarize: 1) it's C's fault, we all know it, and we're leaving it in the dust as of now, 2) you're comparing apples and oranges, and 3) learn Eiffel.

Remember, it's only as bad as it is today because people refuse to change. It doesn't have to be this way, and in fact, I believe it is changing for the better. Not everyone is drenched in their own anticipation of .NET or the common language mangler.

--
Daniel

An interesting read was linked off of that Gnome guys discussion about .NET that was all rage for a bit.

Interestingly, I didn't know he (Bertrand Meyer) has created a training course on .NET.

Who knows which came first, his interest in .NET or his training course?

Try this article by Bertrand Meyer.

Actually, Java is broken when it comes to multiple language bindings. Java (the language) was written with Java (the virutal machine) and they are designed to work hand-in-hand. It's easy for you to sit there and complain that someone should be re-coding Java so that it has Perl, Eiffel, Haskel, Visual Basic, and any other language's bindings; it's quite another for that to be done.

All this is very different from the Java approach, "use my language or die". Only three years ago, Scott McNealy wrote "Think Java. Write new applications in Java. Rewrite legacy apps with Java. Don't upgrade or downgrade. Sidegrade instead to a Java desktop device... I don't understand why anybody would be programming in anything other than Java" (in Open Finance, a Sun publication, Spring 1997). I'm not sure anyone would still dare speak like that today. .NET recognizes that the world is multi-lingual, especially the world of component-based development, and that the duty of a component model is to help interoperability, not force a language corset onto everyone.

Most of the criticisms of Mono stem from those who misunderstand dotNet and Mono (you included). Mono is not trying to integrate services with Microsoft's dotNet services, they are trying to write a good component model. If Microsoft decides to change the internals of their dotNet implementations such that it "breaks" compatibility with Mono, then we've still lost nothing. Do you understand now? This isn't the "Samba problem" re-hashed.

As a software developer I know uml reasonably well, and have tried to use it, but I find that I have big problems with it.

You aren't alone. The always entertaining and often right Bertrand Meyer has this to say about UML.

In 1999, the Ariane 5 launcher exploded a few seconds after leaving the ground. The faulty program, written in type-safe Ada, has been submited to a static program analyzer developped by Alain Deutsch at INRIA in France. The analyzer spotted the error right away! It was a number going out of range after too many iterations and wrapping back to 0.

Both of those indicate a conversion problem from a larger value type to a smaller value type. If that is what happened, then a "type checking engine" should find that. Perhaps indications of the problem were ignored (one of those links suggests that it was possible).

I doubt anyone would suggest that static typing is a panacea. It is not the answer to everyone's problems, but it does help every now and then.

Some of the assumptions behind the selected 1993 Space Station "Alpha" design and cost estimate of $17.4B now appear to be ridiculously optimistic.

The space flight software would total 500,000 source lines of code (SLOC).

It is now projected three times as high, tripleing the costs. And this is only to speak of the software onboard, the whole project software has 4M source lines it says later. Why do I think that in the majority of cases the software costs is the part which is underestimated mostly? Shouldn't they have learned from the Ariane V disaster?

What is the largest program you've ever written? Have you proved that it was correct? And I do not mean tested - but provided a mathematical proof of correctness?

In the real world programs are written to someone's requirements. Just figuring out what the requirement is probably the hardest part of the job - as everyone who has an interest in the program thinks he knows best.

What happens most often is that the requirements and the code are developed in parallel, as otherwise we'd never finish anything, and when things are left unclear programmers must improvise.

To be pedantic a bug is where a program doesn't follow it's specification. If no precise specification exits, there are no bugs!

If programmers really cared about quality of their code we'd all be coding in Eiffel (just a plug for my favorite language)...

...richie

I attended a TOOLS conference (sponsored by Interactive Software Engineering, the originators of the Eiffel programming language) a couple of years ago, and John Dvorak was one of the keynote speakers. While his talk was entertaining, one thing that he ranted and raved about was how ridiculous the DVD was in general, and how useless it was in a computer. He made a big deal out of how it was going to die quickly and disappear forever, that it was way too hard to use (huh?) and was useless because you couldn't write to it. So much insight!

So what is it with those French programmers, anyway? :)

When I was working on the Systems Requirements for the EELV program, I recall that the Ariane 5 struck us all with a horrific sense of dread. This dread comes about when you realize that, no matter how hard you try, you cannot simulate all conditions that software must function in and all situations that it must respond to. The SRS (Software Requirements Specification) tries to cover all the bases, but while you can specify environments for hardware (temperature, humidity, acceleration, vibration, etc...), you cannot often provide a spec for all that might happen to software. In the Ariane 5 case, they changed the hardware; I believe that they upgraded to a new main booster whose horizontal velocity capability exceeded that of the previous booster, but they decided to re-use the software from the old one. When the rocket started going sideways, the value exceeded the bounds and the s/w crashed. Ahhh, here.

I am writing this for a reason: Engineers and software developers often scoff at requirements, preferring to design rather than focus on What they are Designing To. Without a proper SRS, you really don't know if you've covered all bases. Even with one you don't.

But this stuff ain't web pages, man, it's Serious Stuff! And a big portion of the budget needs to go into Requirements Development, at least 25% (actually I once read that the Japanese put 40% into up-front requirements and conceptualization, thus eating our lunch in the automotive industry).

What you don't spend in up-front requirements development you spend in test and verification. What you don't spend in either, well, you spend that in environmental clean-up, insurance costs, and lives.

Sounds like the Osprey folks should have paid a little more attention to their SRA (Systems Requirements Analysis).

Incidentally, while I Understand the massive cost savings (up front!) available through Object Oriented Systems Analysis (emphasis on reuse!), remember that there are no easy shortcuts, and be aware of the dangers inherent in cutting and pasting!

An analysis of that disaster is here.

It's amazing how local transformations can introduce quality to systems with no conceptual integrity.

But to really be effective, you have to be aware of where you started and where you are headed. The big picture is a lot of little pictures, hopefully connected by a coherent architecture.

One of the best ways to move toward coherent architectures is to start thinking in terms of design by contract. Think of preconditions, postconditions, and invariants as part of the public interface, just like routines' signatures. If your language doesn't support them directly, you can probably get free 3rd party tools that will help. Even if you can't, put them in as comments. Program code is documentation of the write once, read many times, variety.

Learn and get comfortable with as many variants of as many patterns as you can. When you use them, mention them in your comments.

This anonymous coward is Tom Morrisette

I get tired of hearing about the "fight" between C, C++, and Java (and now C#), as if those are the only three programming languages in existence.

I concur. I'm especially tired of hearing comparisons between C++ and Java, as though they were the only object oriented languages around. I'm actually quite surprised that Eiffel has not seen more widespread acceptance in the OO developer community (www.eiffel.com is the "official", Bertrand Meyer-endorsed home page of Eiffel, but I personally prefer SmallEiffel, because it's free). Eiffel is a superbly well-designed object oriented language, and there are compilers available for pretty much every platform under the sun. The "compilers" are really just Eiffel to C translators, which then pass the resulting C code to a C compiler. The result is very efficient programs (probably not as efficient as actual C code would be, but certainly more efficient than Java or C++).

An excellent book on the subject is Objects Unencapsulated, by Ian Joyner. It's the only book I've ever read that does a blow-by-blow comparison of C++, Java, and Eiffel. It's pretty dry reading though, unless you're heavily into the OO stuff (as I am).

Not to malign Java, there are some good ideas with that language, but for a pure OO language, I've yet to see anything more impressive than Eiffel.

--

And if you follow ISE's announcements, you will find out that they are working hard to get more and more of Eiffel into Eiffel #.

In the light of that C# only looks like a crippled Eiffel# to me (;

Even so, the difficulty of finding bugs doesn't excuse much of the schlocky v1.0 stuff that gets sold.
There exist software engineering models that, if used, can improve the quality end products. For example, look here.
Also, the FAA has a particularly onerous protocol for use in developing real time life critical software.

Third chime's a tarm

t_t_b
--
I think not; therefore I ain't®

Maybe this is what I meant ;-)

t_t_b
--
I think not; therefore I ain't®

1. should have the notion of class as the central concept
2. must have assertions to check preconditions, postconditions, and invariants and produce documentation from them as well as check them at runtime
3. classes should be the only modules (i.e. no "namespaces" a la C++)
4. every type should be based on a class (so long C++ and Java)
5. it should be possible to specify which clients can access which features (i.e. finer granularity than "public", "private", and "protected")
6. the genericity mechanism should support constrained genericity (i.e. only classes with the method "sort")

Nope, he got locked up in the Eiffel tower, but was eventually cast into the C...
(not very funny, I'll post it anyway...)

Bertrand Meyer claims that Eiffel could prevent Ariane 5 crash, bashes Java, and warns managers against hiring "C Hackers" (in his Object Success) -- the latter bit is nicely rebutted by Robert C. Martin here.

Oh well. For the record: I don't like Eiffel. It's your typical "one idea" language. Inheritable contracts are nice, but the rest is mediocre at best.