EiffelStudio Goes Open

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

Comments

Yep

[Shut the fuck up!]

I'm sure we'll all be programming in Eiffel in a few years. Yep.

About time

[imbaczek]

This was the #1 reason for not using Eifell.

Re:About time

[Eightyford]

This was the #1 reason for not using Eifell.

That, and it sounds French...

Re:About time

[x2A]

yeah it just quits half way through :-p

Re:About time

[papasui]

Thanks, I've been looking for a development enviroment that surrenders, drinks wine, smokes, and calls me `Ahmereecan Swine`. I'll give it a go.

Re:About time

[nofsinga]

So, is this language as stable as Paris currently is?

Re:About time

[Anonymous Coward]

And raises your taxes and burns your car.

Of course.

Info please?

[the-amazing-blob]

I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.

Re:Info please?

[Jello B.]

Wikipedia knows.

Re:Info please?

[jbolden]

The big thing is design by contract. Calling procedures specify what they will guarantee functions and what they expect, functions guarantee what they won't change and list what they expect. This makes code reuse actually practical, since global effects are spelled out.

For example a sqrt function will require x >= 0, that is the calling function must have checked. Since this is specifically listed in the contract your calling function is expected to be able to indicated how it knows that x >= 0 before computing sqrt(x).

The second big thing is that the language is pretty high level and you just give hints to the compiler about how to implement things (sort of like Oracle SQL) unlike Java or C++ where implementation details are definitely part of the program.

That's pretty much it.

Re:Info please?

[Coryoth]

I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.

Eiffel has been around for a long time, and is a mature language. What does it offer? A very clean and well designed Object Oriented language with a very clear and readable syntax and great support for Design by Contract. The principle behind Design by Contract is simple enough: objects, and methods provide contracts - providing you meet their stated requirements, the guarantee things in return. Statically typed languages offer some level of this already: you have to provide paramters of the right datatype, and it guarantees the datatype of the return type. Design by Contract essentially just extends this principle to allow for much more expressive contracts than just type signatures, and things like object invariants (properties of an object that are guaranteed not to change). The result is a much clearer statement of intention as to how code should work, and a powerful test harness that massively speeds up the test/debug cycle. In theory you can achieve this by liberally sprinkling assertions through your code. The advantage of having a language with explicit support for Design by Contract is that things like inheritance of contracts and invariants are all handled automatically and elegantly etc.

As well as this release of EiffelStudio as open source, there's SmartEiffel which is an open source Eiffel compiler (which supports a number of extra features beyond what is given in the recent ECMA spec).

Jedidiah.

Re:Info please?

[geekoid]

BUt can you write an Eiffel compiler in Eiffel ?

Re:Info please?

[geodescent]

Correct me if I'm wrong, but from viewing some of the presentation, especially DBC, it sounds like a more strict implementation of C header files. The compilation refuses to execute a routine unless the implementation explicitly follows the definition.

Re:Info please?

[Anonymous Coward]

That's pretty much nonsense. "you just give hints to the compiler"? How you wish. Eiffel is a procedural language at the same level as Java and C++.

Re:Info please?

[jbolden]

Well Java is from a different generation, its harder to compare. But C++ compiles native. Most early Eiffels compiled to C, and Meyers explicitly consider C to be the "p-code" for Eiffel (15.1.2). In 15.4.2 he outlines the higher level calling mechanism. I don't generally respond to ACs but you need to defend this point a little better.

Re:Info please?

[maxwell demon]

Shouldn't you be able to write a compiler for any language in any turing-complete language with file I/O and access to enough memory, provided it's possible to write a compiler for that language at all (which obviously is true for Eiffel)?

Re:Info please?

[Anonymous Coward]

Yeah, sure

In the real world, where I live, and where I encounter Eiffel folks, the old saying is still empirically proven true:

A skilled programmer can write Fortran in any language.

Re:Info please?

[rhendershot]

For example a sqrt function will require x >= 0, that is the calling function must have checked. Since this is specifically listed in the contract your calling function is expected to be able to indicated how it knows that x >= 0 before computing sqrt(x).

In this situation I prefer to throw an Exception. I've written the method to return a float but I've been asked to evaluate a negative number. This does not evaluate to a float. My 'contract' is the mathematical definition of SQRT, not some arbitrary business requirement that I first test the passed-in value. By writing the method to throw an Exception I'm signaling to the consumer (the *real* business requirement - the Controller in MVC) that I do not know how to do what I've been asked to do so I must ask you to please determine your own next step.

This requires a rational Exception hierarchy and to facilitate I used custom Exceptions that added Item and Severity tracking. The idea for this was push back to the consumer with a label for the processing step that was exceptional, and a relative measure of it's likelihood of recovery. I/O to database, for example, may very well succeed if retried, but a primary key issue would not.

These were used extensively where DTO's (Data Transport Object) provided the data on which the method acted. Yes, there was quite a bit of verification code in the methods to assure the DTO was complete (especially with Weblogic XMLObjects), and that might be simpler to do given a contractual-based language.

So my question is: isn't these the same thing?

In any case, in practice, in *most* cases, handling an incomplete DTO (contractual) or some kind of processing failure (procedural) really meant the same thing to my consumer (eg. we failed to do what you asked). And more often than not it punted back to its own consumer! And it may be noted that my consumer often threw a more generic form of the custom Exception. In cases where the interface design was more mature, though, it was expressively possible to map these against probable actions in my consumer.

Is this sort of thing handled well in Eiffel?

Re:Info please?

[jbolden]

n this situation I prefer to throw an Exception. I've written the method to return a float but I've been asked to evaluate a negative number. This does not evaluate to a float.

My example is a little simple to make it clear why this isn't such a good idea. Basically using your method (called function checks) you are often testing the same criteria N times. Lets say you have a function like:

A which will end up calling B which end up calling C which will end up calling D. D has criteria (x) shared by C,B and A. Then:
calling function checks (x), A checks (x), B checks (x), C checks (x), D checks (x). Now if its something like

x = (y >=0) then that's pretty cheap. But lets say it was much more complicated. Lets say for example a Neural Net with a million elements where you need to make sure the points are convex in 25,000 dimensional space.

That is if you have to test this as a function without global knowledge you have to:
1) convert each point into a 25k element vector
2) take all ordered triples of points (10^18) of them
3) do a simple computation on each triple of vectors. Something like 400k simple math operations. Total time on a modern pentium IV should work out a over a millisecond per triple which works out to a little over 30,000 years. Maybe you can improve and cut it to 1000 years if you are very good at assembly.

conversely if you check the points as they come in and can assure A,B,C and D of that you skip it. Otherwise you have to do this test over and over and over every-time you call function A. The situation doesn't have to be nearly as bas as the neural net for it not to be a good idea to be checking this over and over and over.

My 'contract' is the mathematical definition of SQRT,

Which mathematical definition? For example is (-3) a valid sqrt for 9? If the calling function only allows for the positive sqrt and the sqrt function returns either then you'll get flagged and know to call absolute value?

These were used extensively where DTO's (Data Transport Object) provided the data on which the method acted. Yes, there was quite a bit of verification code in the methods to assure the DTO was complete (especially with Weblogic XMLObjects), and that might be simpler to do given a contractual-based language.So my question is: isn't these the same thing?

No in the contract based language your weblogic routine would specify what a complete DTO meant and the caller would be responsible for making sure it met your criteria. You would never check. Eiffel would assume the lower level code between client and server checks to make sure the transport package is complete. That is you wouldn't have code dealing with network (did the database I/O complete) and code dealing with business logic at the same level. The database code would assure a complete transmission and the form code would know the original DTO was perfect so....

Oh Thank God

[bigtallmofo]

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

[shutdown -p now]

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.

Re:Oh Thank God

[IDontLinkMondays]

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 Eiffel ocassionally, but time and time again, it proves the wrong tool for the job. It's just too different from other languages to be able to meet my needs. I always fall back onto C++ with a widget toolkit (such as Qt). It is definately not because C++ is a better language. It is definately not that Qt is the ultimate widget toolkit. It is because there is a good balance of all 3 criteria being met.

I am 100% in favor of companies trying to sell us a new language, but what it really boils down to is that only a handful of people will use it and other than an ocassional interest article, this is probably the big hay day for the language since there is a open source news worthy article written about it.

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 an ocassional university project, the language stalled years ago.

The parent comment to yours was sarcasm... it may have been misinformed as you comment, but the fact is that he is right in his sarcasm.

Re:Oh Thank God

[civilizedINTENSITY]

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

Re:Oh Thank God

[maxwell demon]

It is old enough to drink.

I'm not sure that drunken languages are an advantage :-)

Re:Oh Thank God

[IDontLinkMondays]

Point taken... I admit my writing skills aren't as polished at they should be before writing on slashdot.

I had meant new as in new to the environment they are to be presented. Which in the context of the original post is more suitable. I was not meant to label the age of the language as new. I recall the early hub bub in Dr. Dobbs back when I was in elementary school reading the magazine in the library. If I recall correctly, it was during one of Dr. Dobbs articals predicting which language would be the logical successor to C in the modern world. They presented maybe 5 other languages as well, including D which I believe is not actually the D we are aquainted with now. I also recall that C++ was not given much merit (which as a c++ developer I would be forced to agree with when comparing the other languages I've evaluated) and that Dobbs called it wrong.

Regarding the Scheme remark, again my writing skills could have been better, but I was remarking not based on the syntactical merits which easily convey to LISP (mind you I've never been terribly fond of either of them after being forced to write AutoLISP ages ago), but more to the point that the clear superiority of Scheme (which does not convey to LISP) is that the compilers are the most optimized compilers out there because of the compiler researchers' affinity to the language (which as you point out is due to its simplicity). Theorically, there's not reason that Scheme could not be as main stream as Common Lisp since extensions such as FFIGEN and Header to Scheme are able to bridge the gap between Scheme and system libraries quite cleanly.

P.S. For all the others reading, this is a perfect example why writing a post on slashdot should be reviewed by 10 other people to close all loopholes in an argument before clicking submit :) If there are further holes in my statement above, let them stand, I've already spent far more time than legitimately budgetable backing up arguments that were written to back up a sarcastic remark, after all, we're talking about Eiffel, it's really just not that important.

P.P.S As for being old enough to drink, well, umm.... I've worked with enough compilers that can't seem to generate the same output twice, would this be the reasoning why?

Re:Oh Thank God

[Anonymous Coward]

Point taken... I admit my writing skills aren't as polished at they should be before writing on slashdot.

"FUCK YOU! I write as well or better than 90% of the assholes on this site, so just SUCK IT!"

Fixed that for you....

Re:Oh Thank God

[Coryoth]

You can get Design by Contract for Ada with SPARK. With the static analysis tools SPARK offers you've actually got a much stronger system with SPARK Ada than you have with Eiffel. If you're an Ada fan, check out SPARK.

Jedidiah

Re:Oh Thank God

[cgreuter]

So, yes, there are many good reasons to choose Eiffel over other OO languages.

Let me add another one. Eiffel has memory safety and garbage collection and also compiles your source code into standalone binary executables. I've had a lot of trouble finding a language that I can use for boring projects that combines those properties. Everything seems to either require a bunch of runtime files, has no user base or is C/C++. Eiffel appears to be a decent alternative.

Cost effective

[mr_mophead]

Alright! Another Eiffel story means I've now paid only $10 for each time I've heard or thought about Eiffel since school forced me to buy the book all those years ago. At least it wasn't Java, I guess.

Re:Cost effective

[schnits0r]

Are you at the University of Saskatchewan? I'm taking a class from Prof Cheston and he wrote the textbook....its everything about Eiffel, and I hate it.

Re:Cost effective

[Anonymous Coward]

cmpt 250 ?
Coundn't stand that class.

Re:Cost effective

[Anonymous Coward]

I took Eiffel at UoS. I think there are a few Eiffel ooks to come out of there. I am like like I bitched about eiffel through school. But now I often find myself making references to it, and wished other languages had features like it.

The DBC is more than assertions, as they are take into account during inheritances. For example, if a subclass overrides a parent's method, it can only strenghen the contract, not weaken it. If you are one dev. working a program this is not a big deal. But if you are writing an api that lots of people will be using, and you have to support, this is a great feature.

~S

Re:Cost effective

[lisaparratt]

An awful lot of computer science courses pick weird arse languages precisely because they act as a filter - an attempt to get those who either can't handle anything more complex than C or the favoured toy language du jour, or can't accept that the world's an exciting enough place for there to be room for more than those languages, to drop out. My uni, for example, taught Scheme as the first language, followed by Ada as the second, and didn't even officially teach C - if a course needed it, you were expected to pick it up yourself.

Sure, at the time I hated Ada (couldn't hate Scheme - it was just far, far too elegant). Now, after a few years of seeing what your standard C programmer churns out, I wish fervently and deeply that they were all forced to write in SPARK Ada, just so their awful code wouldn't be foisted on the world.

Eiffel Contracts

[j]

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

[ploss]

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:

http://www.eiffel.com/products/studio/

Also there should be a PDF warning on the ECMA standards link, just a thought.

Re:The Real Link

[zsau]

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 they don't, this is a pretty good fallback.)

Basically, you add the following exerpt to you system's CSS file, which is usually called chrome/userContent.css in your profile folder if you're using a Mozilla-based browser.

a[href$=".pdf"]:after {
                font-size: smaller;
                content: "[pdf]";
                line-height: 0;
                vertical-align: super;
                text-decoration: none !important
}

I got it from someone else at Slashdot, but I can't remember who.

flashback

[agendi]

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.

Re:flashback

[emjoi_gently]

Flashback indeed.
My Comp Sci classes back in 1993 tried to use Eiffel to teach OO. But the compiler was very clunky and slow and unhelpful to newbie programmers. So we went back to learning Smalltalk.

A nice enough language... essentially putting Asserts before and after your code in each function if I dimly remember. Which aint a bad thing.

At the time it got swamped by the far less elegant, and far more complex, C++.

Another smart language, but you know you aint gonna write anything longterm and large scale in it.

Re:flashback

[mikeburke]

UTS Comp Sci grad by any chance?

I remember the days - 40+ first years bringing a Sparc box to its knees. Didn't help that the Eiffel compiler actually got the job done by doing a translation to C, followed by compile + link-against-the-universe.

I pulled 2 all nighters in a row trying to get that first project done. Cup after cup of vended coffee, falling asleep in front of vi, waking up in front of vi. Finally going home on the train, falling asleep and waking up in the middle of nowhere (well, Beecroft).

Re:flashback

[civilizedINTENSITY]

"Another smart language, but you know you aint gonna write anything longterm and large scale in it."

I'm confused. It would seem that Eiffel is a Software Engineer's language, designed (like ADA) specificly for large scale programs. Like ADA, there are programmer constraint issues...but these are in place specificly for such longterm, large scale programs, yes?

According to the ECMA:

Eiffel users continuously demonstrate that they can produce between two and ten times as much software in a given amount of time as can be achieved using other IDEs and tool sets. Eiffel has thus gained prominence in challenging enterprise environments in the financial, insurance, manufacturing, and government sectors as well as among independent development teams.

Re:flashback

[afidel]

I think the quote is missing one key word CORRECT. You can produce much more correct software using a structured design by contract methodology then you can using traditional code, debug, fix cycles.

Re:flashback

[agendi]

Yup.. I had similar experiences - except I ended up in Macquarie Fields, not Bee Croft. Rob Rist - Where are you now?

Re:flashback

[civilizedINTENSITY]

Agreed that it is really about trying to (more so) bullet proof the process, rather than shooting oneself in the foot and then delevoping great band aid systems. I have to admit that when I saw ADA at University I was amazed and a little awed. Frankly, though, I've never choosen it when I grabbed a tool to make something happen. Most of what I do do is done in either Mathematica (which is available for linux at a great student discount,) or Python. I most certainly don't write anything resembling an application.

Differences

[Eightyford]

What are the differences between Eiffel and other free object oriented programming languages? What does Eiffel have that Ruby, Python, and Java do not?

Re:Differences

[Coryoth]

What are the differences between Eiffel and other free object oriented programming languages? What does Eiffel have that Ruby, Python, and Java do not?

Compared to Ruby, Python and Java the biggest thing Eiffel has going for it is raw speed. Consider the benchmarks and you'll see Eiffel is much much faster than Java, with considerably less memory use. You get that sort of performance from a langauge with an exceptionally clean, well designed and engineered OO system, and great support for Design by Contract, and a very clear readable syntax: learning Eiffel is very easy.

If you're doing very dynamic work that really calls for the flexibility of Python or Ruby, then Eiffel probably isn't for you. If you want something to build robust complex large scale systems then Eiffel is actually better than Java for producing robust, well documented, reusable, maintainable code - and its faster to boot. Java, of course, has its own advantages in terms of "run anywhere" and its huge standard library, but Eiffel is well worth acquainting yourself with.

Jedidiah.

Re:Differences

[Pxtl]

1) Designed for native compilation. Compare it vs. Common Lisp and C++, not the modern enterprise toys.

2) Design-by-contract. Think of it as taking type-safety squared. Just like static-typed languages are more verbose but compile-time safer than dynamic-type languages (don't argue static/dynamic, you know damn well what I mean), design-by-contract is moreso.

3) Extremely generic-oriented and had generics designed in, as opposed to the after-the-fact hacks that appeared in C++, Java, and C#. And it has multiple inheritence.

Plus, I'm also very disappointed by all the languages you listed being non-generic Algol family languages. That's like asking someone "what's your favourite beverage - Coke, Pepsi, or RC Cola?" The example languages you listed are all of the same line of descent (although Ruby pulls more from SmallTalk than the others). Plus, most of the languages you mentioned are just a mishmash of features. Eiffel is more like "Lisp" in the mentality of design, which is "keep the language simple but make it expressive enough that complex concepts can be expressed simply anyways".

Such languages tend to be much more intelligently structured, safe, and extendable, but also fall short in legibility.

Basically it is similar to Ada and C++, with a little functional programming thrown in. The problem is that most attempts to make C++ "safer" have focussed on ripping out language features like multiple inheritence and templates that made it "too complicated" but were important, useful features. Eiffel takes the alternate approach - instead of paring down the featureset, it pares down the language while actually expanding the featureset.

And if you've never coded with generics and still just typecast your container data: get out of my sight you disgusting hacker. OOP without generics is like a car that only turns left - sure you can go right, just do three lefts.

Re:Differences

[skeptikos]

It also has a well-designed, usable multiple inheritance mechanism. It allows removing name clashes by letting the programmer to rename features. It is such a simple a neat idea that I cannot understand why it is not present in more languages.

Re:Differences

[scragz]

". . .the biggest thing Eiffel has going for it is raw speed."

Wikipedia's entry gives the secret to this raw speed:

"Eiffel is generally closely connected to C: three of the four Eiffel compilers output no object or machine code, but only C source code as an intermediate language, to submit to a C compiler, for optimizing and portability."

Re:Differences

[Wolfier]

>Plus, I'm also very disappointed by all the languages you listed being non-generic Algol family languages.

I disagree here - GP listed Ruby, which definitely is not in the Algol family - having a syntax that doesn't look like Lisp/ML/Haskell does not mean it cannot be functional.

Every Ruby statement is also an expression that has a return value.  It basically means you can (and a lot of people do) use Ruby as a functional language.

Re:Differences

[DylanQuixote]

I'd like to point out statically typed languages don't have to be more verbose. With type inference, they can be as terse as dynamically typed languages. See o'caml, haskell, etc.

Re:Differences

[layer3switch]

"And if you've never coded with generics and still just typecast your container data: get out of my sight you disgusting hacker. OOP without generics is like a car that only turns left - sure you can go right, just do three lefts."

True hacker just make 3/4th circle to left to make single right turn. Hence 3/4 is more efficient than 1...

You bastard, you made me feel sad...

Re:Differences

[s31523]

Not too mention:
* Best support of any OO language i've seen for multiple inheritance, especially when dealing with repeated inheritance problems

* Fantastic CASE tool for viewing class heirarchy and architecture.

Re:Differences

[SanityInAnarchy]

Eiffel is more like "Lisp" in the mentality of design, which is "keep the language simple but make it expressive enough that complex concepts can be expressed simply anyways".

More than what? Ruby? Parent did list that...

Ruby is a very simple language, with quite simple syntax, and includes standard libraries that provide enough features that you think they're built into the language itself. Open up a Ruby shell, and it's as easy to hack around in as Perl, yet often looks cleaner than Python -- nice syntactic sugar. But dig deeper, and you find that the internals of just about any powerful idea are as transparent as they are in Perl.

Object-orientedness, for instance. Perl implements object-orientedness in such a way that if you want to pretend you've got properties of an object, the syntax for that will pretty much constantly be rubbing in your face that your object is, in fact, a blessed reference to a hash.

While Ruby does implement properties as some sort of hash, the syntax hides this from you unless you're looking for it. This is a good thing -- I can do at least as many cool tricks as I can do in Perl, but if I just want to do some mundane OOP, it will look and feel like Java/C++/Python, only less verbose and more readable.

And here, let me fix this one for you...

Statically typed OOP without generics is like a car that only turns left...

IMHO, statically typed languages cause more headaches than they solve. Generics remove some of the limitations of static typing, in very restrictive ways. It's like intentionally paralyzing yourself from the waist down, then bragging about your wheelchair. It may be insensitive to say this, but I'd rather have my legs than your wheelchair any day, even if it's theoretically easier for me to trip and fall.

Re:Differences

[Anonymous Coward]

"IMHO, statically typed languages cause more headaches than they solve."

I'm probably wasting my time here, but... if the only statically typed languages you've used are ones with a braindead or outdated type system (such as C, C++, Java, C#, or really any "mainstream" statically typed language...), you should really try a language with a more powerful type system. Try OCaml or Standard ML or (if you really want to blow your mind) Haskell. If you do try one of those, just keep an open mind at first. Some things will be hard to wrap your head around for a while. But if you work at it you will gain a huge insight into how powerful type systems can be.

You are going to have to maintain a typing discipline either way. The difference is that with dynamic types, you don't find out that you screwed up until runtime, and you have to manually figure out using debugging techniques what went wrong. With statically typed languages you find out that you screwed up as soon as you try to compile, and the compiler tells you exactly where the problem is. With crappier type systems, granted, it is painful to do some of what you can do with dynamic typing, and fewer errors will be caught. But with a good type system, 95% of the cool things you can do with dynamic typing you can do straightforwardly anyway (want to keep a (typesafe) list including both booleans and integers? Use variant types! etc), and you catch more errors.

Re:Differences

[pammon]

I'm probably wasting my time here, but... if the only statically typed languages you've used are ones with a braindead or outdated type system (such as C, C++, Java, C#, or really any "mainstream" statically typed language...), you should really try a language with a more powerful type system. Try OCaml or Standard ML or (if you really want to blow your mind) Haskell. If you do try one of those, just keep an open mind at first. Some things will be hard to wrap your head around for a while. But if you work at it you will gain a huge insight into how powerful type systems can be.

And if you work at it a little longer, you'll gain an even huger insight into how poorly strict, static typechecking gets along with polymorphism, and object oriented design in general.

Example: In OCaml, the only way to "downcast" an object to one of its subclasses is to call a virtual function which is implemented in each of its subclasses to throw a different exception, and to pattern match against the different exceptions.

So yeah, I wasn't impressed. There's a reason Smalltalk is, well, Smalltalk.

To make a long story short ...

[ScrewMaster]

In other words, Algorithms + Data Structures = Programs. I'll be damned ... that Wirth guy was right after all.

Re:To make a long story short ...

[Coppit]

Actually, algorithms + data structures + embedded specifications = correct software.

the "pet rock" of programming languages

[Speare]

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!

Re:the "pet rock" of programming languages

[QuantumG]

Harsh.

Re:the "pet rock" of programming languages

[Billly Gates]

Wasn't java based off it?

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

Re:the "pet rock" of programming languages

[shutdown -p now]

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.

Re:the "pet rock" of programming languages

[Speare]

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

Re:the "pet rock" of programming languages

[Tyler Eaves]

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.

Re:the "pet rock" of programming languages

[Speare]

Contracts are for ensuring compliance with the expectations of the interface. That's a far cry from documenting them. And code should not be documentation: document the strategy, not the tactics.

Re:the "pet rock" of programming languages

[Coryoth]

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.

Jedidiah.

Re:the "pet rock" of programming languages

[GileadGreene]

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

Re:the "pet rock" of programming languages

[YU Nicks NE Way]

Lisp environments had garbage collection by the middle sixties, and were working on optimizing it by the early seventies, when I first learned the language. Snobol had it earlier, though.

Re:the "pet rock" of programming languages

[swilly]

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 where Eiffel most influenced Java.

Eiffel's most notable features are Design by Contract, Multiple Inheritance, and Generics, and it's been doing all that for over fifteen years (as opposed to Java and C# which only recently figured out Generics). Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.

Eiffel's biggest drawback (to me) is the horrible Pascal like syntax. Some of Meyer's philosophy has also made the API a little clumsy in places. His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.

Re:the "pet rock" of programming languages

[Anonymous Coward]

Do people just make stuff up around here to amuse themselves with how easy it is to misinform people? snobol, invented in 1962, most certainly did not have garbage collection earlier than LISP, invented in 1958. The notion that LISP didn't have GC until "the middle sixties" is absurd -- LISP can't function without GC.

Re:the "pet rock" of programming languages

[Anonymous Coward]

"Lisp is the first language that I'm aware of to use it, but I bet someone else did it even earlier."

I wish there were a law that forced people who say "I bet" to actually put good money on the line -- I would be filthy rich, simply by having the brains to look things up: http://en.wikipedia.org/wiki/Garbage_collection_(c omputer_science)

Re:the "pet rock" of programming languages

[Anonymous Coward]

It's not a "far cry" at all; the contract is the specification of the interface, just as a contract in law is the specification of the obligations of the parties. Any additional "documentation" isn't binding, and is likely to be incorrect. And your comment about "code should not be documentation" is meaningless blather that suggests that you don't understand the difference between specification and implementation -- both "strategy" and "tactics" are aspects of the latter.

Re:the "pet rock" of programming languages

[DylanQuixote]

ML had garbage collection in the mid-70's, and is statically typed: http://en.wikipedia.org/wiki/ML_programming_langua ge But eiffel is still very interesting. :)

Re:the "pet rock" of programming languages

[RLiegh]

>It smells more of an abandonware goodwill gesture than anything.

I have no doubt that you're right; but I have to ask...so 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. I remember Tannenbaum's release, which essentially said "uh, here; have my teaching guide. do stuff with it, I dunno, maybe add it to a watch of something, I don't care". I figured "ok, minix is crap, and now it will go right down the toilet". For a long time, my attidue seemed to be vindicated -minix didn't do much (the compiler was opened, and the newsgroup got a few posts).

Now? I think it was last october that Minix 3 was released. By being opened, Minix found an appreciative audience and had a chance to grow and develop. Obviously had it just been forgotten and kept proprietary this would not have occured.

After what's happened with Minix, and looking at Eiffel; I'd say instead of griping and saying "so what" let's wait and see if something interesting doesn't eventually develop out of this.

Re:the "pet rock" of programming languages

[Coryoth]

Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.

If that's what you're looking for then I would suggest that you take some time to check out JML and ESC/Java2 which provides almost exactly that functionality for Java. It's not as clean as Eiffel as the contracts have be be kludged into Java as add-on annotation in comments, but all the functionality you'd want in a good expressive DbC system is there in JML, and ESC/Java2 provides a static checker/theorem prover that can attempt to verify contracts and provide warn you when they might fail. It also provides a number of other strong static checks based on JML annotations, allowing you to have high degree of confidence in well annotated code that passes ESC/Java2. Honestly, download JML, JMLEclipse and ESC/Java2 and try them out - you'll be amazed the number of subtle errors that can be quickly and efficiently caught!

His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.

It seems odd, but it does have nice aspects, particularly if you're used to a more functional perspective: it goes a long way toward isolating side effects and allowing better reasoning about the scope of effects that a given block of code may have. It certainly makes sense to me.

Jedidiah.

Re:the "pet rock" of programming languages

[penguin-collective]

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 sound software by picking a less flawed language to begin with. Furthermore, I think the last people you want to write assertions about how code ought to work is the programmers writing the code themselves; I suspect when code quality matters, contracts and assertions ought to be separated from the code (and the structure of the code).

Re:the "pet rock" of programming languages

[civilizedINTENSITY]

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.

Re:the "pet rock" of programming languages

[civilizedINTENSITY]

Agreed. Please excuse the following rant: unusual, unexpected, and bizzare side effects *suck* and anyone who has ever programmed with a team member whose simply named functions turned out to do unrelated things (to global variables!) knows that (since we can't just shoot them) a language that prevents them from shooting us in the foot isn't a bad thing at all.

If we could just shoot them, then we wouldn't need to...no, must not think bad thoughts ;-)

Re:the "pet rock" of programming languages

[civilizedINTENSITY]

Document the strategy, yes. Document the tactics, too, though. And document the implementation, also, for those who are learning maintence and must somehow see that the latter relates even at all to these former two...

Re:the "pet rock" of programming languages

[maxwell demon]

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.

Somehow I'm missing (5) ...

Re:the "pet rock" of programming languages

[jamshid]

Yeah, that Bertrand guy always seemed like a prick. Funny that he hated C++ so much and spent so much energy arguing against it, but Java is what has taken over. Of course, Java won't last much longer (as the language that most new projects use). Developers always want something new, something that fixes the crap that has grown on top of any development system, something that gives a feeling of a fresh start.

But, sorry, it won't be Eiffel. I don't know what is the answer to software engineering's problems, but it sure as hell isn't yet another language.

Re:the "pet rock" of programming languages

[mvonballmo]

Just because you, personally, don't happen to work on those projects, doesn't invalidate its usefulness for others who do.

Or, far more likely, "Just because you, personally, choose not to acknowledge that you work on projects that could benefit immensely from Design by Contract, doesn't invalidate its usefulness for others who do."

Re:the "pet rock" of programming languages

[Bob Uhl]

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.

Re:the "pet rock" of programming languages

[GileadGreene]

Lisp is the first language that I'm aware of to use it, but I bet someone else did it even earlier.

According to Wikipedia John McCarthy invented garbage collection sometime around 1959, specifically for implementing Lisp.

Re:the "pet rock" of programming languages

[civilizedINTENSITY]

Too late when I posted, too little sleep this last week, and frankly I get confused when I'm sleepy and perhaps I missed my thumb when I counted? ;-)

Eiffel is pretty fast...

[dudeX]

At least according to this website I found via the Artima.com 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 very pretty. However, for important projects I think Eiffel will be the right language for the job.

Re:Eiffel is pretty fast...

[gregarican]

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 dependencies precompiled is like watching paint dry. Not the "contract" I am looking for :-(

Re:Eiffel is pretty fast...

[Coryoth]

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 how wonderfully mantainable that is...

It all comes down to what is more important for the project at hand: flexibility, or maintainability. If flexibility is what is most important, Eiffel is probably not the best choice for that project. If you want maintainability though - that's when Eiffel, with it's very clear "One Way To Do It" syntax, clean OO design, and built in Contract support really start to shine.

Use the right tool and all that.

Jedidiah.

Re:Eiffel is pretty fast...

[gregarican]

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.

Re:Eiffel is pretty fast...

[geniusj]

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-like features, however it is definitely lacking in the native compilation/speed department and does not offer the niceities during development that an environment like Squeak will. The problem with squeak, is that after development, it sucks to try and distribute anything :)

Re:Eiffel is pretty fast...

[chromatic]

... we all know how wonderfully mantainable that is...

Of course, because we all know that the true mark of maintainability is when a programming neophyte can maintain a serious, important program.

Re:Eiffel is pretty fast...

[gregarican]

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 me seems the purest and has the most effective/efficient IDE. Essentially the IDE is the image itself. To be able to inspect objects during runtime, make changes to their coding in the System Browser while they are being referenced, etc. is all incredibly convenient. Especially for initial learning purposes. Shame that this language was overtaken by Java, as Smalltalk can be a powerful tool that doesn't leave the programmer caught jumping through syntactic hoops like in Java.

Re:Eiffel is pretty fast...

[TheRaven64]

If you like Smalltalk, then you might like to try Objective-C. It's about 80% (no blocks[1] and no GC[2], but most other things) of Smalltalk bolted onto C. The object syntax is very close to Smalltalk, although there are some extra square brackets added around each method call (which makes it easier to parse). Since it's a pure superset of C, you can drop back into C when you need to do messy things, but stay at a nice level of abstraction when you don't.

[1] One compiler that I know of supports blocks, but it doesn't work with any OpenStep implementations, and OpenStep is one of the nicest things about Objective-C (Apple's Cocoa and GNUstep being the two current ones).

[2] There is some garbage collection coming to Objective-C. GCC supports the Boehm GC and this is being integrated into GNUstep by someone. Apple have their own GC, but it doesn't yet work nicely with Cocoa.

Re:Eiffel is pretty fast...

[geniusj]

I've definitely used it, and I like it. Still lacking some niceities of Smalltalk, however. I like it a lot more than C++ though, that's for sure ;-)

Try reading.

[Homestar Breadmaker]

They already told you. If you managed to get to the "object oriented" part, how did you miss the "contract" part?

Talk about Situational Irony

[Jonathan]

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.

Re:Talk about Situational Irony

[jbolden]

You aren't remembering correctly, he went after all open source and free software. His biggest criticism of Stallman and Linus was for not distancing the free software movement from the NRA when Raymond tried to link the two (he held Stallman more responsible since Linus being a Finn might not have known what the NRA was...). He attacked FreeBSD explicitly for poor quality.

What is funny though he lists a whole bunch of reasons vendors turn something open source that pretty much amount to "it isn't worth keeping as commercial product for reason X" where he lists the possible X's. Anyway here is a reminder:

http://www.apostate.com/programming/bm-freesoftwar e.html

Re:Talk about Situational Irony

[Anonymous Coward]

It's funny that you accuse someone of misremembering and then provide a link that proves that his statement was quite accurate. e.g., Meyer wrote "The GNU license itself reads not like a license but like a manifesto against the evils of proprietary software."

Re:Talk about Situational Irony

[BaldingByMicrosoft]

Thanks for the link. Maybe you should read it. His summary seems quite balanced compared to your assertions:

11. A COURSE OF ACTION

What should be done? I will conclude with a suggested agenda for everyone, whether a commercial software developer or merely a computer user.

      1. Recognize the major contributions of the free software community, from Linux and GCC to TEX, LATEX and Ghostscript.
      2. Accept that both commercial and free software have a role to play, and that neither will ever go away.
      3. Be respectful of the authors of good free software.
      4. Try to convince them to apply the reciprocal goodwill (in some of the cases cited this may be hard, but one should try).
      5. Refuse and refute the moral defamation of commercial software developers. If you are a software developer, be proud of your profession.
      6. Call the extremists' bluff by questioning their moral premises. Re-establish ethical priorities.
      7. Refuse the distortion of moral values and the use of free software as a pulpit from which to spread ideologies of violence.
      8. Demand (in the spirit of faithful advertising) that the economic origin of "free" software be clearly stated, and that the products be classified as one of "donated", "taxpayer-funded" and the other categories described in this article.
      9. For Microsoft, whose unique position in the community creates unique responsibilities: promote a more open attitude towards the rest of the world; open up; be less mean. You can afford to be.
    10. For everyone: focus on quality. Work with every competent person--free or commercial software developers--to address the increasingly critical, and increasingly ethical, issue of software quality.
    11. Strive to combine the best of what the two communities have to offer.

Re:Talk about Situational Irony

[jbolden]

He doesn't talk about the NRA issue in section 11. He address that in "5. A SKEWED MORAL PERSPECTIVE". He mentions this again in item 6 from your list. Anyway I don't see what assertion specifically you are refuting.

Re:Talk about Situational Irony

[Anonymous Coward]

AAAAAAUUUUUUGGGGGGHHHHHHH!!!!

We do not have "loose gun laws with no equivalent in the rest of the civilized world." We actually have quite strict gun laws, but enforcing them isn't as sexy or newsworthy as the "war on drugs|porn|terror|bad-thinking", so busts rarely happen. The laws aren't the cause, and the guns aren't the cause. The media culture that shows blood and gore everywhere while refusing even to show breast feeding, well, make up your own mind.

Oh, and racial discrimination has been met with armed resistance, often effectively.

Meyer's a pompous ass. His shit is so over-engineered that it lectures the plumbers about the pipes it gets stuck in. Blech.

Re:Talk about Situational Irony

[Anonymous Coward]

Yes, indeed. Shame and double shame to you for your statement of 'his biggest assertion...' if his NRA links are a bit out of place, they are but a small part of a well reasoned and cogent piece. I echo the other sentiments - read the piece.

Re:Talk about Situational Irony

[jbolden]

I said biggest criticism of Stallman, not biggest assertion. The post was one paragraph.

Re:Talk about Situational Irony

[Da VinMan]

Anyway I don't see what assertion specifically you are refuting.

How about this one?

You aren't remembering correctly, he went after all open source and free software.

Can you show us where he "went after all open source and free software"? He didn't as far as I know. He went after the demonizing of commercial software vendors by OSS advocates to be sure, but that's hardly "all open source and free software".

I don't really identify with Meyer at this point, but I really don't appreciate unsubstantiated ridicule of industry icons just for the sake of a chuckle.

Re:Talk about Situational Irony

[jbolden]

I think you should read the context. The debate was whether the article could be considered "anti-Stallman". I.E. it was in the context of why it did or didn't matter if he choose thee GPL given his previous stances. My point was the attacks were generalized.

always wanted to try it

[goldfita]

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.

Re:always wanted to try it

[killjoe]

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 putting yourself into bondage like that. The super l33t programmers seems to prefer really fluid languages like lisp and smalltalk.

Re:always wanted to try it

[evil_Tak]

Ooo, a bondage language! Chain me up!

Back in the day, before C++ was the "winner"...

[IvyMike]

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.

Re:Back in the day, before C++ was the "winner"...

[Coryoth]

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 comparison was traction with C developers - that provided it with enough critical mass to win the mindshare market. If you don't know Eiffel then spend an evening reading about it some time. It's easy to learn, has very clear readable syntax, and a very well engineered OO design (far cleaner than anything C++ offers).

Jedidiah.

Re:Back in the day, before C++ was the "winner"...

[swdunlop]

Unfortunately, if the world had decided on using Eiffel for everything, it would still be compiling -- the compilers of the day were abysmally slow; more recent compilers have thankfully added incremental compilation.

Re:Back in the day, before C++ was the "winner"...

[Jugalator]

And yet game engines are written in C/C++. Guess OOP isn't everything.

And neither are game engines.

Re:Back in the day, before C++ was the "winner"...

[HiThere]

Actually, even Ada would have been a better "winner". I really dislike C++. I dislike it to the point that when I can I choose Python or Ruby. But C/C++ have the libraries. That's the downfall of all new alternatives. (So Python gets Pyrex, and has a HUGE collection of libraries, but it's still too slow for a large project where the limiting time isn't human reaction time. And Ruby gets RubyInLine, and has a smaller set of libraries, and IT'S too slow.)

Eventually I'm going to decide to use D and write C interfaces to get to the libraries that I need. I know it, but I keep refusing to take that step. (Well, D hasn't reached version 1.0 yet. So it's reasonable to not have committed to it. But I know that's the direction I'm headed.)

Object-Oriented Software Construction

[Anonymous Coward]

is the most lucid book I have ever read on what OO is all about, and how a language must be designed to support it.

It clearly indicates that C++ is not such a language.

I have always wanted to do a project in Eiffel, have never had a chance.

Read the book: It will change how you write C, whether kernel or application. Contracts are, IMHO, a lot of what Extreme programming is all about: writing (or, in Eiffel's case, building in) tests as you write the code.

Lew

Re:Object-Oriented Software Construction

[kiwipom]

Having read that book a few years ago, I can agree that it is an authoritative and exhaustive description of OO software construction. However it must rank as the dullest book on software ever written. BM has no idea about how to write to keep the reader reading and his vitriolic attacks on C++ and Java in the book, along with his extensive explanation of design by contract, show the book should be called 'Why Eiffel is the only true OO language' If you haven't read it, don't bother unless you suffer from insomnia.

Re:Object-Oriented Software Construction

[zanzi]

Meyer transmits a strong sense of intellectual excitement and the book is very fascinating. The subject is about the design of the perfect/ideal O-O programming language. He describes every choice balancing pragmatic and academic considerations and the result is one of the best designed programming language.

The book is useful not only for the final result, but also in the rational way used to solve the problem, that can be adopted in many other situation.

D programming language

[WalterBright]

If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language.

http://www.digitalmars.com/d/

Re:D programming language

[wysiwia]

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 your product and use it because it's state of the art in its area. But it's ridiculous to compete in any area where others have a 1000 or more times more developers. If possible compete in an area where others only have less than 10 times as much as you.

For the D language there is an area which it can easily become the number one, that's the small C-libraries area. D is perfectly well suited to replace C in this area. But someone has to start this process (sorry it's not me) else this change won't happen. There simply has to be enough sample code around until others start to use D also.

I'm quite sure that if D successfully tackles the libraries area it will soon become the chosen candidate for kernel development and after that for framework development, etc. But it won't become a successer for C++ before it hasn't become a successor for C.

O. Wyss

Re:D programming language

[Per Wigren]

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 would rock!

D is a really great language and I really hope it will catch on! It has a lot of potential to be the next big programming language in the areas where C and C++ rule today, and even in some of the areas where C# and Java rule. Unfortunatly I don't think it will happen because "the market" often wear blinkers but I'd love to be proven wrong. :)

Re:D programming language

[Onno Hovers]

D is doing OK. Just look at the programming language popularity index at http://www.tiobe.com/tpci.htm/.

Re:D programming language

[Anonymous Brave Guy]

Interesting page, but AFAICT "programming language hype index" would be a fairer characterisation of the information. It's based on the number of hits returned by popular search engines, rather than any objective metric to do with number of programmers currently using the language, rate at which new code is currently being written in the language, or similar.

Re:D programming language

[Onno Hovers]

FWIW:

The number of D projects on sourceforge is 32.
The number of Eiffel projects on sourceforge is 69.

You may have a point here.

.NET/Mono

[caseih]

From the product web site http://www.eiffel.com/products/studio/, 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 HP was using it for developing printer firmware since it was less error-prone and increased their productivity dramatically over using just C. Certainly as our apps increase in complexity we need tools that allow things like design-by-contract in order to save us from the inevidable bugs.

Re:.NET/Mono

[Coryoth]

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.

Jedidiah.

Now Eiffel too can have a stupid name

[Toby The Economist]

"ECMAEiffel".

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

When does the new Duke Nuke'm come out?

[Anonymous Coward]

Just a question.

Cut through the BS

[Expert Determination]

'Contracts', 'obligations' and a pile of other meaningless jargon that is so loose in meaning that it might as well apply to cooking roast beef.

Design by contract is essentially putting assertions into your code. You typically insert these as pre- and post-conditions. For example part of the contract for a real square root function might be the precondition that the argument is greater than or equal to zero. In C assertions generally cause program failure if they turn out to be false. And the support in C is pretty crude, simply a macro called assert(). In Eiffel this stuff is built right into the language and the language offers graceful recovery in the event that one of these conditions has failed. Most people I know who have used Eiffel hate these features. I've never used it so I reserve judgement.

Now you too can make up technobabble to impress people with your knowledge of contracts.

Re:Cut through the BS

[slashdotmsiriv]

Very well said my friend, spoken like a true engineer who cares about implementing solutions not writing crappy "research papers".

Re:Cut through the BS

[Anonymous Coward]

I didn't realize that assert() in C could detect non-local errors at compile-time:

foo.c:
    int foo(int x) {
        assert(x > 0);
        return 50 / x;
    }

    int num(void) {
        return 0;
    }

bar.c:
    void bar(void) {
        int n;
        n = num();
        foo(n); /* compiler error here: n can be zero */
    }

Now that you've clued me in I'll start using this handy C idiom everywhere. Thanks for saving me from having to learn anything about the useless pointy-headed vague academic B.S. that is design by contract!

Re:Cut through the BS

[polux2001]

it's false
because while pre/post-conditions are just assertion, you just can't code class or method invariants and variants in a classical language without making the code unreadable and unmaintainable. These invariants are what makes eiffel 'design by contract' a good paradigm for building robust programs.

Re:Cut through the BS

[nickleaton]

It is false. Consider a class heirarchy. To make it really noddy, lets say we have a sqrt class. We have two implementations, OldSqrt and NewSqrt. The method in the Sqrt class would include a precondition that X >= 0, and a post condition that abs (result * result - X) maxerror Without DBC, you have to repeat these assertions in every implementation. That goes against a programming principle that you only write the same code in one place. With DBC, the conditions get inherited. To really do DbC, you need help from the compiler.

Re:Cut through the BS

[nuzak]

> because while pre/post-conditions are just assertion, you just can't code class or method invariants and variants in a classical language without making the code unreadable and unmaintainable.

GNU Nana does class invariants fabulously, and it's eminently readable. Google for it.

The language that almost drove me from computer sc

[GamerGeek]

Oh yeah, thats right. My college used it in it's introductory CS classes. It was my first real language experience and it almost drove me from the field. I can't tell you why really but it was just too much. I struggled until I we got to C++ and then, well everything made sense. That seem crazy? It sure did to me. Looking at it now it seems rather wordy. I should download it and get to know it, if only to conquer something that frustrated me so much.

flashback-Engineering an itch.

[Anonymous Coward]

"Eiffel is engineered/designed - it is deliberately not suited if all you want to do is hack about."

Which is why OSS will never adopt it.

--
The "are you a script" word for today is overdone.

Sailing against the wind.

[Anonymous Coward]

I have bought the BM's book (Object Oriented Software Construction) a couple of years ago. Did it after hearing raving reviews in the USENET forums. Believe me, it was the absolutely worst $70 (I think it was $70) spent in my life. The guy is a hack. Eiffel is so bad it's not even funny. Contracts are neat, I give him that. But most everything else (including multiple inheritance ant the supposedly bulletproof type-system that aficcionados so like to rave about) is broken in more than one subtle but profound way. If static typing is your cup of tea, stick with Java or OCaml or Haskell or whatever. Heck, even C++.

Re:this is why /. is dead and digg triumphant

[Noodlenose]

I don't know what you had in your coffee this morning, but rants like this are not constructive.

Sure, Digg can deliver some news faster, but then I prefer the depth of the userbase on Slashdot, the moderation system, the fact that it is frequented by more than just 16 year olds and of course its lovely green.

If Digg is what you want, Digg is what you should get, so piss off.

Back in the day, before C++ was the "winner"...

[Anonymous Coward]

And yet game engines are written in C/C++. Guess OOP isn't everything.

3-5 years ago this would have been sweet!

[Anonymous Coward]

Seems kind of late right now. While you're at it, let the good folks at Compaq/DEC know they should relicense their Modula-3 work so that someone might pick it up and try to get it up to date with GCC. Both were bloody elegant and ahead of their time in ways.

Instead we'll reinvent perl several times with "dynamic" "domain specific languages" in Ruby and other hacks.

Maybe this will breath some life in to Eiffel.. I hope so.

Eiffel Contracts are syntactic sugar

[syousef]

You can do design by contract in any language. You can do the same thing in any other language but you have to always remember to call super methods when you are doing your pre and post assertions otherwise your subclasses won't adhere to the contract. What Eiffel gives you are contracts as part of the language.

Disclosure: I haven't used Eiffel since about 1998 when my undergrad degree software engineering courses were taught using the language, so I'm not complete current on the language.

Re:Eiffel Contracts are syntactic sugar

[egoots]

You can do design by contract in any language.

Thats akin to saying you can also write any program in assembler, so why use a high level language...

Also, dont forget that Eiffel gives enforcement of class invariants.

Re:Eiffel Contracts are syntactic sugar

[Anonymous Brave Guy]

You can acquire and release resources in many languages, too, but using the RIAA idiom in C++ you never forget the latter, while in languages that rely on finally or Dispose or whatever, you can.

Re:Eiffel Contracts are syntactic sugar

[syousef]

Actually all this is "akin to saying" is that one language feature does not a language make. What you've just demonstrated is a technique of argument called reductio ad absurdum. Check this out if you're not familiar with the term:

http://en.wikipedia.org/wiki/Reductio_ad_absurdum

Re:Eiffel Contracts are syntactic sugar

[syousef]

Actually dispose/finally language constructs are a convenience too. You can easily write and consistently call a routine to cleanup after yourself whether or not a particular routine fails.

The point I was making is that this idea of design by contract is not revolutionary or new to Eiffel. Eiffel just provides a language construct that makes it easier not to forget or blow your design by contract. That doesn't make Eiffel useless, but one language feature is never a good reason to switch languages.

Re:Eiffel Contracts are syntactic sugar

[Anonymous Coward]

ITYM RAII (Resource Allocation/Aquisition Is Initialisation) HTH HAND.

Re:Eiffel Contracts are syntactic sugar

[Anonymous Brave Guy]

Blockquoth the AC:

ITYM RAII (Resource Allocation/Aquisition Is Initialisation)

Sorry, I must have been spending too much time around here slagging off certain organisations. :-)

Yes, I did indeed mean RAII.

Re:Eiffel Contracts are syntactic sugar

[Anonymous Brave Guy]

You can easily write and consistently call a routine to cleanup after yourself whether or not a particular routine fails.

Easily write? Sure.

Consistently call? There's a whole programming world of evidence to suggest not, which is a big part of the reason the RAII idiom evolved in the first place.

Re:Eiffel Contracts are syntactic sugar

[gedhrel]

"You can do the same thing in any other language but you have to always remember to call super methods when you are doing your pre and post assertions otherwise your subclasses won't adhere to the contract."

Hang about, that doesn't sound quite right. Subclasses can loosen requirements but only tighten outcomes. So your superclass has to call down when checking preconditions (that is, the subclass preconditions must entail the superclass preconditions). Postconditions work the way you describe.

(My Eiffel exposure is about 12 years more out-of-date than yours, but I think the DbC reasoning still stands.)

Re:Eiffel Contracts are syntactic sugar

[Haeleth]

You can acquire and release resources in many languages, too, but using the RAII idiom in C++ you never forget the latter, while in languages that rely on finally or Dispose or whatever, you can.

Of course, RAII breaks down as soon as your object lifetimes are not naturally nested (in C++'s low-level view, when you have to use heap allocation). You can go a long way towards solving that by using smart pointers, but all the implementations of those have their own flaws (reference-counting fails on cyclic data structures, etc).

In other words, it's questionable how much RAII actually gains you over idioms like C#'s "using", or the "finally" functions popular in various FP languages. Sure, you can forget to use "using". But you can forget to use a smart pointer in C++, too.

There really aren't any silver bullets.

Re:Eiffel Contracts are syntactic sugar

[syousef]

If you allow a subclass to loosen a pre-condition it's no longer a true subclass.

For example if you determine that for the class apple there is a precondition "be a fruit" then you subclass to green apple, the original precondition must hold otherwise you could have a subclass of apple called carrot. Very weak example/analogy but you get the idea.

Re:Eiffel Contracts are syntactic sugar

[Anonymous Brave Guy]

I take your point, but I don't think it's fair to equate the risks.

Programmers can, and often do, forget to use non-automated tools like using or finally. Moreover, it is rare to find code analysis tools that are smart enough to detect this in routine use.

In contrast, if the default way to use your resources is via a class supporting RAII, as is commonplace in C++ both in the standard library and in numerous other high quality libraries from other sources, then it's actually anti-idiomatic to make the mistake. There are also idioms that library designers can employ to make sure you don't accidentally allocate an object dynamically, if they wish to do so. Even if you can and do make the mistake, it's easy to look for all uses of new, and check that they're all safe, as a semi-automatic QA mechanism to enforce coding standards.

Bottom line, how often have you really seen someone (a) manage to write

ifstream *is = new ifstream("file.txt");

(b) then fail to ensure proper destruction of the stream object and closure of the file, and (c) not had this noticed during code review or other QA processes? Personally, I've never seen that, but I've surely seen a few dangling resources in languages that use the less automatic idioms.

I'm not saying the RAII mechanism is a silver bullet, I'm just saying it's objectively and measurably better. So it may be with any language feature that removes or actively discourages a certain type of programmer error, hence the link to the DbC features of Eiffel.

Re:Eiffel Contracts are syntactic sugar

[gedhrel]

I think your analogy is broken. Consider a base class, B, with a method f and an attribute x. B.f(x) has the precondition "x>0".

If a derived class, D, follows your precondition rule, then it would be possible to supply an overridden version of f such that: D.f(x) pre "x > 1". Note that objects of type D cannot now be treated as objects of type B, their base class, because they have tightened the preconditions. Preconditions can change - but they can only be loosened. (You can use a D in more situations than using a B; but you can treat a D as a B in all cases.)

So (and putting my statement the right way round: I think the precondition on a base class must entail the precondition on a derived class): your base precondition is "this is labelled as a fruit". The precondition on the derived class can be "this is labelled as a fruit or a vegetable". The precondition on the derived class is entailed if the precondition on the base class holds.

Of course, with your analogy your precondition is actually an invariant and can be applied as a postcondition too: and that is why your analogy appears to cause problems.

Re:Eiffel Contracts are syntactic sugar

[syousef]

Being able to loosen a pre-condition facilitates polymorphism but it also leads to situations like the one that I described, where a subclass losens the preconditions of a parent to the point where the intent of the pre-condition in restricting the class and enforcing the intent of the type is lost.

What this actually shows is that there are reasons for not allowing a pre-condition to be tightened (breaks polymorphism) and reasons for not allowing it to be loosened (breaks the intent of the pre-condition). What are you left with? A mechanism that's only theoretically useful since the only truely valid pre-conditions must be defined at the top of the class hierarchy.

Re:Eiffel Contracts are syntactic sugar

[gedhrel]

You have a precondition that you claim has the intent of preserving a type. If you intend type preservation, then you need NOT ONLY a precondition BUT ALSO a postcondition.

The precondition of a base class may be loosened. The postcondition, however, can only be tightened.

The result, if you permit precondition loosening, is that your example still works and you can still type objects correctly.

One might take the (erroneous) position of rejecting this argument and positing that you should only have to specify a precondition; in that case the intent of the precondition (type preservation) is clearly lost.

So in a nutshell I basically have to disagree: there are reasons to permit the loosening of preconditions, but no reasons to argue that they may be tightened by a derived class. You're still left with an important mechanism for specifying programs.

Re:Eiffel Contracts are syntactic sugar

[syousef]

We'll have to agree to disagree I'm afraid.

Open Source? GPL? Do they know what it means?

[Anonymous Coward]

http://www.gnu.org/licenses/gpl-faq.html#CanIUseGP LToolsForNF

If they don't allow using it (the environment, not the compiler) to develop commercial software, its license is not the GPL, unless I'm missing something.

Re:Open Source? GPL? Do they know what it means?

[jdennett]

It can be GPL without allowing use to produce non-free software, as AdaCore's GPL releases of GNAT are. The trick is that the runtime library has a license, and is needed to run any generated code. If that library is GPL, then you can't use generated code other than in GPL products. You *could* write a replacement runtime library, and then use the GPL-licensed compiler for non-free software -- but normally that's too much work.

Ocaml

[j1m 5n0w]

Thanks, I've been looking for a development enviroment that surrenders, drinks wine, smokes, and calls me `Ahmereecan Swine`. I'll give it a go.

In that case, you should also look into ocaml:)

Progress or abandonware?

[Animats]

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.

Re:Progress or abandonware?

[Anonymous Coward]

Tell that to the DoD. I've heard that if you admit programming in Ada, they come to you at night. HOW ABOUT THAT.

Re:this is why /. is dead and digg triumphant

[Hercynium]

Please mod parent up! That is all.

eiffel 1984 of programming languages

[zx-15]

I happed to take a course that taught among other things how to program in Eiffel, and the contract principle is in fact very nice. When you write a contract, you define exactly what you want want to pass to a feature.. err... function and exactly what you want to get from it. I know, every good programmer has to write down specification anyway, may be even in clever mathematical form. Still, contracting scheme helps to avoid lots of stupid errors, and when you are sure you're done, just turn off contract checking in the compiler. After some time, I started thinking in terms of contracts, and it would be great feature in next revision of C++. I'm writing this because there are many features that I do not like in eiffel, and in EiffelStudio (you can download free version for most of the platforms). In general, the language is very restrictive, and allows no freedom whatsoever - you can use classes, only classes and nothing but classes and you will use them exactly the way it's creators want you to, e.g. No break statements. Also it is slow - when developing applications - eiffel code is translated to C, then C code is compiled. So on average you'd get 80 Mbyte project for every 500K of code. And finally Eiffel has arcane Pascale-like syntax, it could've been much simpler. Adding insult to injury, EiffelStudio, the IDE if you ever try to program in eifffel(I know, RTFA), is very annoying, if you made a mistake in the code and attempted to save it, studio will make a pop up window informing you about it, if you try to look inside anther class while having an error inside the current one, the studio will abruptly return you to the line where you made a mistake, even if you need to switch to a different class to fix the error. It, also, doesn't have context menu, the right mouse button is used for other purposes, e.g. view single function from other viewer inside the studio in a debug mode (don't ask me why), or moving around the code - double right click on class declaration will move you to the class definition, this actually is really nice, except, why makers of eiffel never thought about middle mouse button?! Though, debugger is nice. I think Eiffel is 1984 of programming languages, and an attempt to popularize it would not help, anyhow free version of EiffelStudio has been around a while, and it is not like anyone would suddenly begin to develop many applications using it.

Syntax or Syntax?

[Anonymous Coward]

"It's kind of like Ada and Modula in that respect; the concepts are sound but the syntax is too bulky to become popular."

Unfortunately when a programmer tosses around the word "syntax". What they really mean is "Hey this isn't C/C++"! Even Python's whitespaces gets chewed up, and spat out. That's partially why Java has done as well as it has with it's "feels like" syntax.

Re:Syntax or Syntax?

[Anonymous Coward]

No, Python's whitespaces get chewed on because everyone who has ever used multiple editors on multiple
operating systems (or edits BSD/GNU make makefiles) knows from personal experience that having whitespace have
syntactic meaning is a truely horrible idea.

Re:Syntax or Syntax?

[HiThere]

I agree it's a bad idea, but it's not as bad as you are making it seem. At least now that they've got an agreement to not mix tabs and spaces at the start of lines in the same file. That DID cause problems.

OTOH, I remember the first time I opened one of my Python files with an editor that automatically converted tabs to spaces...and 8 spaces at that! (My default is 3 spaces/tab...and indent with tabs, but some of the code came from someone else, who used spaces to indent, and the editor assumed without asking that a tab was 8 spaces. OUCH! And I saved before I figured out what had happened. OUCH!) The editor was glimmer, it was several versions back, but I still don't use that editor anymore, for ANYTHING. I've stopped even considering it.

Still, with a decent editor, and the rule of not mixing tabs and spaces, Python's whitespace rules are only unesthetic, and not THAT unesthetic.

yeah? really?

[penguin-collective]

The benefits of Design by Contract include the following:

Ah, and this has been demonstrated how? Programming language designers like to dream about how their features are going to lead to fewer bugs, lower costs, and all that, but there is almost no acceptable experimental data to support their claims.

fully open source?

[penguin-collective]

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?

Re:fully open source?

[oriol]

Yes.
It is fully open source.
Everything has been put there...

As stated in the first message, one of the goals is also to have the students correct a lot of the things that they were complaining about...

Kinda "eat your own dogfood and it will become tastier"...

About Eiffel // JAVA relationship

[Anonymous Coward]

Here is what I've heard last year from my algorithmic teacher. I'm not saying it is __the truth__, but anyway here is the little story.

In the early 90's (not sure of the precise date), Sun microsystem was planing to create an object oriented language. They looked around and found eiffel quite interesting. So they contacted the guy who created it and asked him something like "we would like to work with you. your language is interesting". And the guy said "no" (don't mind him, he is french). So Sun said "okay, we will write our own".

Okay kids, now go to bed.

Eiffel

[MemoryDragon]

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 design by contract, but it is a dead fish in the water nowadays, like so many languages before it and afterwards, which were declared as the next big thing when they came out. Maybe it one day will see a revival like Ruby did recently, but for now, forget it :-(

Why did Dylan not make it to a Slashdot Headline?

[Anonymous Coward]

Dylan (invented by Apple for the "Newton") was open-sourced last year.
Well, the popular "Harlequin / Functional Objects"-Implementation in fact.
Comes with a nice IDE with object browser etc. and produces fast, _native_ code!
http://www.opendylan.org/

The many uses of Design by Contract

[ribuck]

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 confirm (or improve) understanding of the behaviour of existing code prior to changes being made.
• DbC is a refactoring tool. Assertions make sure that desirable behaviour is retained even in the face of extensive refactoring. Eiffel code is so malleable when it is contract-equipped.
• Dbc is a correctness tool. Assertions in parent classes help ensure that child classes (which inherit the parents' assertions) are substitutable.
• DbC is an error-handling tool. Assertions define the success or failure of a routine and direct its error recovery during exception handling.
• DbC is a concurrency tool. Well, it will be when SCOOP is fully-implemented, because preconditions play a key role in synchronization.
• DbC is a testing tool. It enables a tool like AutoTest to stress-test your code for you, based on the contracts that you have specified.
• DbC is a project management tool, for maintaining and enforcing specifications.

Have I missed any?

By the way, here are some useful links related to the newly-open-sourced EiffelStudio, and you can find additional Eiffel libraries and tools at EiffelZone.

Re:The many uses of Design by Contract

[Anonymous Coward]

DbC is a process governing tool that helps prevent runaway programs. It automatically slows that breakneck speed of your program as it evaluates all the pre and post conditionals. ;)

Oh my, oh my...

[marco_craveiro]

...how things change. for BM's earlier position on free software see The Ethics of Free Software . For a decent eiffel compiler (last time i tried, ISE's sucked hard. funny that, for a company made by the number one authority on software engineering), try SmallEiffel. and don't take me wrong, i think Object-oriented Software Construction is one of the great classics of computer science. but there is a gap between theory and practice.

Let's do the Checklist:

[Qbertino]

- 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 Eiffel bunch has me looking into their favourite PL with some quality time.

Re:Let's do the Checklist:

[TrixX]

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

Eiffel's not too bad, EiffelStudio is

[Craig Ringer]

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. A good gcc Eiffel backend (NOT intermediate-C based like SmartEiffel) or a standalone compiler combined with good integration into Eclipse, VC++, and so on would be much more interesting IMO. Add the ability to generate interface stubs for C, C++, and Java, and it'd actually start to look attractive.

Right now, though, Eiffel looks like the kind of language you use in isolated projects where you don't need to use too many outside componenents and don't expect to have others basing work on your code. Does that sort of project still even exist?

Re:Eiffel's not too bad, EiffelStudio is

[rrobbins]

Regarding: don't expect to have others basing work on your code. Does that sort of project still even exist?
This is exactly what I am looking for! I want to develop in a language where you absolutely cannot find anyone to take over or work on my code. In other words, I want job security!

tools for learning

[perfessor multigeek]

Would you be willing to extend that conclusion to other types of education? In parts of Europe they still have kids learn writing with fountain pens and study Latin to better learn the underpinnings of their first languages. Personally, I learned logic and protoboarding with TTY chips and resistors.

I mean, one could extend this to just about anything, though I'm curious as to how you would describe this technique in non-CS specific terms. Would you consider the relevant variables that the learning context be one that is less forgiving than the typical RL one? That it be more abstract? Would you consider obscurity itself a good thing as it avoids distraction by "mere" commercial applications or tool-specific hacks?

-Rustin

Re:tools for learning

[lisaparratt]

It's sorting the wheat from the chaff - those who have the ability to go beyond rote learning, and actually truly understand the field, embrace it, and then further it through research.

Yes, it's very elitist, but that's exactly what's a good university is about. Using the best people, best technology, and best information in order to better the field. If people want to learn a vocation and "graft" for a living, they can do that at a polytechnic (think the nearest equivalent is a community college in the US).

Memories....

[cprice]

Of 6mb "hello world" executeables while using eiffel in university. Sigh

It's true. The french name is really irritating

[gd23ka]

I'm not going to hold back on a secret here... I hate everything french for all the basic reasons most people hate the french which are all more or less deeply rooted in their insurmountable arrogance. I've been both to the heartland of frenchianity where I spent a couple of weeks in Paris and I have seen and forever turned my back on Quebec. La monde francophone, "The Frenchspeaking World" which the "Grande Nation" is so terribly proud of is shrinking while I am typing this. It's not that they're not painfully aware of this rapidly decreasing "mind share" and the "mind share threat" posed by les Anglais, we all know what kind of vile laws they have both in La France and Quebec to preserve their oh so precious culture. Let's not help them out by referencing their culture more than is absolutely necessary minimum. As far as the programming language is concerned. One would think that a clearly superior product could be called anything at all and it would succeed no matter what. This I strongly believe is not true because I think deep down most people feel as I do. What I've heard about Eiffel is very interesting which is why I am getting involved with it. However I do have a hard time fighting down the loathing I have for the french and it really hits me extra hard when I look at the box they have on the commercial Eiffelstudio page which clearly looks like "La Tour Eiffel", the Eiffel Tower. I have karma to burn, but if you're really thinking instead of giving in to the kneejerk reaction of perceived "hate speech" then by all means mod the parent up.

Re:It's true. The french name is really irritating

[Archtech]

Well, you opened this can of worms; so I'll close it. And by the way, I do not "hate America". On the contrary, I very much like and admire America, and almost all Americans. Which is why it depresses me so much when they write things like your last article.

"I hate everything french for all the basic reasons most people hate the french which are all more or less deeply rooted in their insurmountable arrogance".

Yeah, right. Those arrogant French, thinking they are God's chosen people! Don't they know that *Americans* are God's chosen people?

And they're a real bunch of chicken-livered, gutless surrender monkeys, too - right from Charles Martel who defeated the Arabs at the battle of Tours in 732 (preventing Europe from becoming a Muslim continent), to the heroes of the Resistance who fought on against one of the most viciously efficient repressions the world has ever known. By way of Joan of Arc, Napoleon and his soldiers who conquered Europe in about ten years (on foot), the Foreign Legion and many, many others. Not to mention Lafayette -

"In 1777, Lafayette purchased a ship, and with a crew of adventurers set sail for America to fight in the revolution against the British. Lafayette joined the ranks as a major general and was assigned to the staff of George Washington. He served with distinction, leading American forces to several victories. On a return visit to France in 1779 Lafayette persuaded the French government to send aid to the Americans. After the British surrender at Yorktown, Lafayette returned home to Paris. He had become a hero to the new nation. At home he cooperated closely with Ambassadors Benjamin Franklin, and then Thomas Jefferson in behalf of American interests". http://www.lucidcafe.com/library/95sep/lafayette.h tml

As for the "surrender" part, in September 1939 Britain and France declared war on Germany because it had invaded Poland. The USA did nothing. In 1940 Germany invaded France, launching one of the most inspired, unexpected, and vigorous surprise attacks in history. This defeated the large British and French armies, and compelled France to surrender. The USA still did nothing. At that time the US army (and other armed forces) were pathetic remnants. It took a full two years to get them up to a level at which the administration dared to enter the war. Had the USA been where France was in 1940 - right next to Germany, with a long land border - the Wehrmacht would have walked in, pulverised the US armed forces, and taken over the country with contemptuous ease. (Ask any competent American officer if you doubt this). With the Atlantic Ocean in the way, nearly two and a half extra years to get ready, about three times the population of either France or Germany, and far greater natural and industrial resources than both put together, the USA finally entered the war - but only when it was forced to because Hitler declared war on it.

As for "rescuing" France, don't be ridiculous. The USA was at war with Germany; to win, it had to invade Germany; and the only reasonable path lay through France. Taking credit for having liberated Europe, when the only reason the USA was even in the war was because the dictatorships attacked it, is the sheerest hypocrisy.

At least the French had the guts to take on Nazi Germany. The USA, which didn't dare take on Hitler, was happy to attack Saddam Hussein - a third-rate copy of Stalin, with a large army of disaffected, poorly-trained troops equipped with obsolete Soviet weapons. About as brave as a farmer going out with a combine harvester to cut a field of wheat.

Re:It's true. The french name is really irritating

[gd23ka]

Tell you what I agree wholeheartedly with what you're saying but I guess that's mainly because I'm not anglo at all, nor really much of a patriot for that matter. Now let's take a look at what you got here: Yeah, right. Those arrogant French, thinking they are God's chosen people! Don't they know that *Americans* are God's chosen people? Actually as we all know it's the jews who think they're "God's chosen people". As far as the French are concerned, it is mainly because they still believe they're in the same league with anglo culture. However, with the exception of maybe Africa and an island or two in the southern pacific, english and spanish will see you through most of the world and we're that is not spoken your safest bet is russian.

And they a real bunch of chicken-livered... Here let me condense this to: Karl Martell, La Resistance, Joan of Arc, Napolean and the foreign legion. An odd mix of french valor and scum you have here. With the exception of Martell (who for all purposes counts as a German) we have people here history would have done well without. Without Joan of Arc we wouldn't have this discussion here as you would most likely speak English and La Resistance is really mostly a bunch of tales invented post-war to take off the minds of people of the unsavory fact that most French eagerly collaborated with the Germans. Napoleon marched war all over Europe and the Foreign Legion are a bunch of criminals doing France's dirty work in exchange for protection from prosecution (They say otherwise, I know). As far as bravery is concerned, in a war bravery has little to do with language. There were just as many brave SS-Troopers as there were brave allied troops.

In 1777, Lafayette purchased a ship, and with a crew of adventurers set sail for America to fight in the revolution against the British. In the same conflict, thousands of more or less able-bodied Hessians were forced into uniform and sold to the british as Kanonenfutter - cannon fodder. Most of these people however stayed in the new world and thus "Hess" is a very common name in Pennsylvania. Nowadays the descendants of these people all speak english and think nothing of it. I don't think the same thing could be said of Lafayette's people had they chosen to stay.

As for the "surrender" part, ... About as brave as a farmer going out with a combine harvester to cut a field of wheat. You're right. They're a bunch of wieners.

Re:It's true. The french name is really irritating

[Anonymous Coward]

"And they're a real bunch of chicken-livered, gutless surrender monkeys, too - right from Charles Martel who defeated the Arabs at the battle of Tours in 732 (preventing Europe from becoming a Muslim continent), to the heroes of the Resistance who fought on against one of the most viciously efficient repressions the world has ever known. By way of Joan of Arc, Napoleon and his soldiers who conquered Europe in about ten years (on foot), the Foreign Legion and many, many others."

Ironic you bring up Nappy, who was heroic in attempting to enslave europe, while the Resistance was heroic in attempting to prevent enslaving europe.

"As for the "surrender" part, in September 1939 Britain and France declared war on Germany because it had invaded Poland. The USA did nothing."

France did nothing, too. France declared war on Germany, and did nothing but sit back for months, get drunk, and wait for Germany to invade. Woops, I forgot, they played loud music across the Maginot Line trying to annoy the Germans into surrendering.

"the USA finally entered the war - but only when it was forced to because Hitler declared war on it."

Good thing for France, too, because the USA saved France yet again. Unlike the French symbolically declaring war to save Poland, but not doing a thing to help them.

"Taking credit for having liberated Europe, when the only reason the USA was even in the war was because the dictatorships attacked it, is the sheerest hypocrisy."

It's not hypocrisy at all. The USA did liberate Europe. You should also look up "Lend Lease" - the USA was actively involved with fighting the Nazis long before Dec. 7, 1941, even sinking Nazi warships.

"At least the French had the guts to take on Nazi Germany."

No they didn't. They never did attack the Nazis.

Re:It's true. The french name is really irritating

[Anonymous Coward]

As for the "surrender" part, in September 1939 Britain and France declared war on Germany because it had invaded Poland. The USA did nothing. In 1940 Germany invaded France, launching one of the most inspired, unexpected, and vigorous surprise attacks in history.

Huh?

Re:It's true. The french name is really irritating

[Anonymous Coward]

You also hate jews, blacks, mexicans, chineses, neightbours, even your kids and your wife. Oh sorry no kids and wife since you are impotent...

In fact you hate everybody but yourself.

You are a scumbag.

Re:It's true. The french name is really irritating

[Archtech]

"...one of the most inspired, unexpected, and vigorous surprise attacks in history..."

Oh, I see. You are saying that after declaring war, the French should have been expecting to be attacked. Well, they were. And the attack came in, just as expected: through the Netherlands and Belgium, just as in WW1. Then the "inspired, unexpected, and vigorous surprise attack" arrived - a left hook through the Ardennes, country that nobody had thought passable for armoured vehicles. Moreover, it was pressed home with tremendous energy and speed, although even the German high command kept telling the lead elements to stop and wait for their infantry to catch up. The Ardennes attack was almost entirely the brainchild of von Manstein, although Hitler was quick to grab the credit when it succeeded. I think most experts would agree that any army in the world, as of 1940, would have been defeated in the place of the French and British. Most of them, for a start, were simply too weak to have any chance of resisting. The British and French weren't too weak, but they were outmanoeuvred. German strategy and tactics were generally superior to those of all their enemies throughout WW2. For instance, to win the critical battle of El Alamein, Montgomery needed something like a 10-1 superiority in tanks and not much less in infantry.

My point was that France at least declared war on Germany. The failure to invade right away was probably a serious strategic blunder. But at least the French government had the moral strength to declare war, rather than gazing in the opposite direction, filing its nails and pretending nothing was happening.

Re:It's true. The french name is really irritating

[Archtech]

Wow. After my initial post, I really didn't want to look at any replies. I was sure I would be buried by a torrent of abuse and unjustified rebuttals. Instead, I got two well-written replies full of sensible, factual, reasoned criticism (and a short one with a logical comment). It really reinforces my faith in Slashdot!

gd23ka, you did home in on several of the weaker points in my rant. Truth to tell, there are precious few nations or peoples that haven't, at some stage at least, believed they were "the chosen people". Tentatively, I think the Portuguese might be an exception - I know they set up a colonial empire, but they have always been fairly level-headed and modest. What I was trying to express was my sense of irony that an American would find French people annoyingly arrogant. (Pots and kettles). "Karl Martell" - a very neat way of reminding me that France and Germany had not even begun to emerge as nations back then. (This is a problem Americans don't face, as their nation only dates back 230 years). "Valor and scum" is fair comment, but a universal one - show me a war hero, and half the time I'll show you a latent violent criminal.

As for AC, I have to disagree. "Ironic you bring up Nappy, who was heroic in attempting to enslave europe, while the Resistance was heroic in attempting to prevent enslaving europe". I suspect you will not see it this way, but to my eyes Napoleon's role was analogous to that of Bush, and the French Resistance analogous to the Iraqi Resistance. Heroism is heroism, regardless of the justice of the cause. Incidentally, all the generals on both sides of the American Civil War idolised Napoleon. Perhaps you think they were all wrong?

"You should also look up "Lend Lease" - the USA was actively involved with fighting the Nazis long before Dec. 7, 1941, even sinking Nazi warships". I know about Lend Lease - for example, 50 obsolete WWI destroyers, which US sailors would never have been asked to take to sea, were "given" to Britain in return for 99-year leases on British bases in the Caribbean and Newfoundland. I also know that Britain paid back the last of its war debt to the USA last year. And before you ask, here's a US source: http://www.usnews.com/usnews/documents/docpages/do cument_page71.htm. Where you can also read: 'In the 1940 Presidential election campaign, Roosevelt promised to keep America out of the war. He stated, "I have said this before, but I shall say it again and again and again; your boys are not going to be sent into any foreign wars."'

Re:It's true. The french name is really irritating

[Archtech]

'...I do have a hard time fighting down the loathing I have for the french and it really hits me extra hard when I look at the box they have on the commercial Eiffelstudio page which clearly looks like "La Tour Eiffel", the Eiffel Tower'.

One last (mild) remark, and then I shall drop this. Apparently you detest the sight of the Eiffel Tower; do you feel the same way about the Statue of Liberty?

Re:It's true. The french name is really irritating

[gd23ka]

I think you're a pretty okay guy too... even though you're most likely one of those froggies. Tell you what, there are always exceptions and exceptions made so you're now listed in my book of cool frogs. You're not on page one though, it's got a couple of entries already.

Re:It's true. The french name is really irritating

[Archtech]

"...even though you're most likely one of those froggies".

British, actually, old man.

Extreme O-O

[Anonymous Coward]

To the extreme. On might think that the common funtions -- sine, cosine, etc, could at least be functions in an OO language. But in Eiffel, they are methods of the class of things that knows how to do common functions -- sine, cosine, etc. And everybody who wants to use those functions gets this by inheriting from this class. Is that good?

Re:Extreme O-O

[jbolden]

In the mid 1980s (really until about 1993) floating point operations were very expensive. This choice seems stupid now that floats are first class objects. But most languages today have vector operations in libraries even though most modern processors can handle them natively.

Not just an Eiffel Compiler

[TrixX]

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 Eiffel.com 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 diagrams to code seamlessly. You probably can compare it pretty well to Eclipse, but much lighter (it's written in Eiffel instead of Java).

Even if you are not planning to use Eiffel, I would love to see that GPL IDE being used for other languages...

usability deficiency

[Anonymous Coward]

thanks for the PDF warning, asshole.

Re:yeah? really?

[afidel]

Acutally Eiffelsoft has some great case studies from companies like HP that back up their claims.

secom

[bheilig]

Is this a good time to plug my open source Eiffel project secom?

Secom is an object-oriented library of portable, reusable components for communicating over serial devices. With secom you can develop an application that will compile and execute on Posix and Windows, with little to no changes to the source code.

Check it out
Check out the documentation

Brian

Not just contracts

[Swamii]

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.

GPL?

[drew]

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 (http://www.eiffel.com/licensing/licensing.html) 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 GPL doesn't allow adding additional restrictions to the license either, so I don't think he has any ground to say that you can only distribute it under the GPL if you only use it to write free software.

Not that I am opposed to the guy who wrote the software choosing whatever licensing model he sees fit, but let's not be misleading about this announcement, shall we?

Java programmers need to know the Eiffel concepts

[Scott.Simpson]

More Java programmers need to be exposed to Eiffel. I constantly interview Java programmers that can't tell me why Gosling added interfaces to Java. I virtually always get the answer "because they allow multiple inheritance". Then I ask them, "why didn't Gosling just add multiple inheritance to the class hierarchy and be done with it?". They can't answer that question.

Gosling added interfaces to Java because they represent abstract data types (ADTs)! The classes are implementations of the ADT behavior and are known as concrete data types (CDTs). They are an approximation of the abstract data types. For example, you can't represent an infinite amount of integers in Java. You can only represent -2^32 to 2^32. You can't have a stack of infinite size either. You can only approximate the "infinite stack model" in Java since you have limited memory.

Why is everything in an interface public, static, and final? Because you can't instantiate it and it is a specification of behavior! Gosling doesn't like multiple inheritance in the class hierarchy because of diamond inheritance (which he discusses in the Java book) but he allows it in the interface hierarchy because you are specifying behavior and there is no code to conflict. How do you connect the class tree and the interface directed acyclic graph hierarchy? With the "implements" keyword, a keyword for specifying that an implementation fulfills and ADTs contract.

Even Java programmers need to read the Eiffel book. They can't even program in Java correctly.

Re:Oh Thank God 23 year old can't drink

[Anonymous Coward]

So an OLDER one is better?

Re:this is why /. is dead and digg triumphant

[Swamii]

I prefer the depth of the userbase on Slashdot, the moderation system, the fact that it is frequented by more than just 16 year olds and of course its lovely green.

Laughing out loud!

The depth of the user base? Oh yes, the deep levels of trolls, flamebait posters, and GNAA members really add to the community here.

The moderation system? Abused by those same trolls and idiots; anyone with a dissenting view is modded off the page.

More than just 16 year olds? Ha, you've got me rolling on the floor now...

I'm with the grandparent. Digg rocks, slashdot is dead.

None

[MikeXpop]

. Bonded Labour, early and forced marriage, forced labour, slavery by descent, trafficking, worst forms of child labour.

2. Bonded labour is debt bondage. It is used in South Asia, Africa, the Caribbean and Southeast Asia. An estimated 20 million people are held in bonded labour.

3. Full time work, dangerous workplaces, excessive working hours, subjection to psychological, verbal, and sexual abuse, obliged to work by circumstances or individuals, limited or no pay, work and life on the streets in bad conditions, and an inability to escape from the poverty cycle; no access to education. 246 million working children between the ages of 5 and 17

4. Trafficking is essentially smuggling people for the purposes of slavery. It's impossible to know, but an estimated 600,000 - 800,000 people are trafficked across borders each year, not counting internal trafficking.

5. Kshatriya, Vaishya, Shudra, and Harijan. Varnas consist of many communities called Jats. Jats themselves can break up into further communities. Marriage occurs within the Jat. Anyone who broke this rule was outcasted. But it has exceptions, such as when female populations fell low.

6. 90% of the population was peasants. There were free peasants, and indentured servants. The unpaid lived on the land without paying any money, but worked for the Lord, earning their stay. Farmers were given a plot of land. They had the right to form their own courts, called halimotes. They made bylaws that governed the villager's actoins. The court was overseen by a representative of the lord. The lord had immense power over the peasants. He had economic as well as political control. The feudal system is similar to the caste system in that there are specific, strict roles for the citizens. It has less levels than the caste does though.

7. There is a definite poor area of town, and the surrounding areas are slightly less poor as well. There are definitive areas of wealth, and definitive areas of poverty.

8. The wealth seems to be concentrated in the Northeast, and Southern inland states are among the poorest. New Hampshire is among the wealthiest states in the Union. This could possibly be from the amount of taxes we have as a state.

9. The data the census presents seems to say that poverty in the united states is centralized mostly in the southern United States. What's interesting is that Arizona, New Mexico, Texas, and Oklahoma have rather high poverty, but Utah, Colorado, and Kansas have almost no poverty.

10. Stratification is promoted through the caste, class, feudal system and slavery. These systems and ideals separate people into certain sections, and as such, they are inherently

Re:None

[MikeXpop]

Death Penalty
        When discussing topics such as the death penalty, it's important to understand the functions and needs of punishment. Punishment serves many purposes. Prisoners may be rehabilitated into functional members of society, and then let go. Prisoners may be in jail or killed in order to keep them out of the public's way. Punishments such as prisons or the death penalty may deter possible offenders from committing crimes. And finally, prisoners may be punished as a way of "getting even" with them. In terms of the death penalty, it has been shown that in areas where the death penalty is prevalent, there is a much higher rate of death-penalty-worthy crime. With capital crimes, rehabilitation isn't even on the table. Capital crimes also leave the offender away from society with either the death penalty or life in jail. The argument concerning the death penalty boils down to a question of morality. Is it moral to execute someone in response to his or her actions of murder?
        The Code of Hammurabi, the rudimentary beginning of all laws, stated, "If a man put out the eye of another man, his eye shall be put out." While the actual laws varied a bit (just below that, it states that if a man puts out the eye of a freed-man, they only have to pay a small amount of gold), this law set an important precedent in that the punishment must fit the crime. It's more colloquially referred to as "an eye for an eye". In fact, this concept strongly resembles what we were taught about morality in Kindergarten. The Golden Rule tells us to treat others as we would like to be treated. It could be argued that the death penalty is a reflection of this culture. But is the death penalty truly equal to the crime that was committed?
        The simple fact is, very few people murder someone for absolutely no reason. People might murder someone for cheating on them. People might murder someone in their self-defense, or in defense of their child. People might murder someone for failing to pay them protection money. People might murder someone for murdering someone else. While it certainly seems that citizens might be more sympathetic to reasons for murder, there is a definite moral line-in-the-sand that's crossed in determining what deserves death.

Re:None

[MikeXpop]

Journal 1

Society of Friends: 2 hours

        On Saturday, the day before I went over to the Society of Friends, I went to the grocery store in order to get things to make dishes for the potluck lunch. I ended up making two dishes. The vegan dish was a three bean salad, with diced onions. The vegetarian one was more complicated. I boiled shells, and cut up cherry tomatoes, onions, and peppers. When the shells were done, I added mayonnaise, and garlic salt. I tossed the entire thing, and had my second dish. Seeing my two dishes side by side, I decided to eat a large breakfast before leaving for the service.
        When I arrived in Worcester for the Society of Friends meeting, Jesse and I had brought food, and yard work supplies. Matt, our contact, met us inside the house. He briefly went over some of the Quaker philosophy and then led us to a room where the service was to take place. This was a traditional unprogrammed worship. Jesse and I were in a room with about 25 other people, and we all bowed our head in silence. The concept of an unprogrammed worship is that when anyone is moved to start a sermon, they can -anyone who is worshipping. Sometimes lots of people will talk, and sometimes they go the entire hour in silence. In this particular example, it was 30 minutes before someone spoke up.
        The woman who spoke up talked about the newly translated Chronicles of Judas, and how it conflicts with the gospel. She said that in an article she was reading, Jesus laughs in the Chronicle, and that's when she realized that he never laughs once during the gospel. She explains how she believes that it's important to realize that Jesus had a sense of humor, and that's one of the main stems of his ability to forgive.
        After the worship, we all shook hands and introduced ourselves. I introduced myself and explained our project. Coincidently, there was a girl from Clark University there as well, who was there for her Peace Studies class. The potluck was eaten, and everyone was very kind and gentle. I told Jesse I wasn't used to amount of compassion, coming from Nashua High and Elm Street.
        After the potluck, Jesse and I went out to the back and started cleaning up the yard. We picked up twigs, sticks, and branches that had fallen over the fall and winter, and we picked up the various pieces of trash that had blown about.

I had to use Eiffel in one of Bertrand's lectures.

[Anonymous Coward]

Basicly, what you do is, you programm everything twice. Once in preconditions, invariants, and postconditions, and last in code.

You might want to read the licensing page

[johnchx]

Eiffel Software, Inc. has an interesting interpretation of the licensing it believes that it is offering:

* If you wish to earn a commercial benefit from your application and not release its source code, you must purchase the number of licenses you need for your development from Eiffel Software. After you purchase licenses, you are free to use and distribute your application the way you want.

* If you select the Open Source license, you must release your development under an Open Source license for the benefit of the community at large.

Source: http://www.eiffel.com/licensing/licensing.html

So, either the Eiffel folks don't understand the GPL, or there's a GPL'd runtime module that that has to be linked into your executable code.

Either way, this is more restrictive than, say, the licence for gcc.

Hahaha to think I didn't catch this... hey thanks!

[gd23ka]

Right. First you call your neighbor and tell him that you're coming over to smash his car, kill his dog, rape his wife and children and then rob him of anything you see fit taking and then finally to burn down his house and kill him and his family with a huge knife. Then you go into the garage and spend two hours looking for that bush knife you want to use on him... but to your surprise of the sudden there is this click noise and you drop everything you're holding in your hands because your neighbor is standing behind you with a shotgun in his hands and a grim look in his face.

Investment in Expertise

[rrobbins]

Last night I downloaded and installed Eiffle Studio 5.7 and wrote my first Hello World program in Eiffle. After careful consideration, I have decided to concentrate on developing my expertise using this programming language. It is a losing proposition to base your expertise on a common programming language or commonplace technology. I think I've wasted my time, effort, and genuis on developing solutions only to see my work taken over by some less experienced and talented developers because the company "has the software" and doesn't feel they need my expertise. Frequently this has disasterous results and significantly impacts work efficiency but management clearly does not value technical expertise or experience.

Past grandeur vs. modern pettiness

[gd23ka]

You were going to drop this before and so was I but regarding the Statue of Liberty, that doesn't register emotionally with me even though I know of its french origins. I think Archtech, you're confusing past grandeur and exploits with the ingrained pettiness of the average french(wo)man I am talking about. Here's an anecdote to give you to think about.

I don't speak french. Un petit peux mais but that is all. Back when I was twenty me and a friend of mine would put on a backpack get on a train and go places. We were on our way to England and if you're travelling to England by rail you, the easiest way to go is the connection Calais - Dover. So we arrived at Paris Gare du Nord (something or rather) and had maybe twenty minutes left before our train left for Calais. Now the thing about this railway station is once you get off the subway you do have to find your way to the trains. Usually in Germany they have pictograms all over the place so you don't need to know a single word of German to find your way to basic facilities but oh no, not the french and back then I didn't know for certain what train meant in their language.
So we tried to ask people. I would go "Excuse me, do you speak English?" and they would all respond with "Non! Non! Non!, I would then ask "Sprechen Sie Deutsch?" and they would again go "Non! Non! Non!". Not knowing the word for train but remembering something like "Chemin der Fer" which sounded plausible to me I asked them in french, "Ou sont les chemin de fer?" and they would look stupidly at me and say something like "La bas! La bas!" (over there! over there!). I repeated this at least 15 times every time with almost exactly the same result and this was in a hot summer and I was sweating like an animal wearing a heavy backpack and we did not make that train that day. However the real kicker is, arriving at the street level I asked a woman again the same questions.. "Do you speak English", she: "NON!". I then asked her if she spoke German and she went "NON!" again, this time even louder. With a sigh I asked her one more time in french for the "Chemin de Fer" and then all of the sudden this woman DID SPEAK GERMAN. Even though she had an accent she needed to work on she was fluent in German! She told me that "Chemin de Fer means Railway Company but I need to ask for the Grand Lignes to get to the trains".

I'm not alone with this. It appears the french are universally hated. Don't ask me how I got there or on what business but a couple of years ago me and a colleague of mine stopped at a gas station on I80 somewhere in Illinois. We went into the "restaurant" and we were talking to each other in German. All of the sudden I see this rapid movement to my left and this huge trucker jumps out of his chair dropping that chair to the floor and approaches us with his fists clenched. He wasn't pretending most obviously he wasn't joking. "Don't tell me you're french!" he roared, "Don't tell me you're french!". I just looked at him and thought of the irony that now I was going to get the shit beat out of me for the french. Then I got a little angry myself over that and told him, "We're GERMAN! DEUTSCHE! GERMANS! Wir sind Deutsche, verstanden! GERMANS! GERMANS!". After that they made us sit at their table and I had the worst Spaghetti Bolognese you could imagine. While I was shoving that Dreck down into my system the truckers told me they had to go through the Quebec to get to Ontario which is why they really don't appreciate to see any froggies south of the border.

I could go on and on and maybe even tell you about M. Voisin, the man I had to work with in Montreal who didn't have his intestines under control and would fart in front of me and make jokes about "Les Boches!" (derogatory for German) the nekulturny paysan thinking I couldn't understand what he was saying but I guess I have made my point. I get around a LOT in the world I have to say and NOWHERE have I ever been more insulted and abused than in La France and Quebec. Really for the most part people reciprocate friendliness and are

Re:yeah? really?

[penguin-collective]

"Case studies" aren't acceptable experimental data.

Wow.

[Anonymous Coward]

A Slashdot discussion on Eiffel. And it's intereting to hear people's views.

Well I should be careful of what I say becuase there's a non-neglible possiblity that others in my company will find their way to this discussion.

We've been using Eiffel ... well there are various opionions about that. But at least for some number of yrs.

Two of the programming powers-that-be seem to believe that this is the ONLY way to write an expert system. The ONLY, the UNIQUE, anything else is completely UNACCEPTABLE. You get the idea.

So I can claim that I've had a good deal of experience both in writing Eiffel. And watching how the language and the effort around it have operated within an organization.

Eiffel has made some progress within our organization, but that's at least in part becuase massive resources have been thrown at the effort. We've hired some significant portion of the better Eiffel programmers in the world (there aren't many).

I could go on with a lot of things. Let's take just one that people above have been discussing at considerable length.

Design by Contract.

This consists of three keywords: require, ensure and invariant. Require is the feature (routine/method) pre-condition and ensure the post-considition. Invariant (I think I used it once) takes an expression (or maybe body of expressions) and applies them every time there's been a state change in the object (object being the instantiated in-memory version of the class which, stricly speaking is just the source).

No one uses design by contract. And the simply answer is that it's immensely (impossibly) expensive in CPU cycles. Even with Moore's Law etc. And we do have the likes of dual Opteron boxes and Design by Contract is not even used there.

Design by Contract (IMO) might be used in some late stage of development for functional validation. But would almost certainly have to be turned off for the code released into production (again, for performance reasons).

It's a nice idea, but ...