Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Why Eiffel Might Be Worth a Second Look

By Coryoth in Technology
Tue Oct 31, 2006 at 12:00:00 PM EST
Tags: Eiffel, EiffelStudio, Programming Languages, Software (all tags)
Software

Eiffel is one of those academic languages nobody uses right? Well, sort of. Certainly Eiffel has greater interest among the academic community than outside it, but then other languages like Haskell have far more academic interest due to their purity. Eiffel is a surprisingly pragmatic language, and as a result it does have a solid niche market in industry. Over the last few years, however, there have been some changes that make Eiffel a more interesting proposition - it might be worth a second look.


The Right Tool For the Job

Let's get this out of the way at the start: while Eiffel is worth a second look, it does depend on what you're looking for in a language. Eiffel fits in nicely as an alternative to Java or C++ for developing large applications. If you're leaving Java for more dynamic languages like Ruby then Eiffel isn't going to be for you - you can probably quit reading here. On the other hand if you're using Java for large scale projects and appreciate the discipline it imposes, then Eiffel is definitely worth more than just a glance. Eiffel was designed with a pragmatic eye toward the development and maintenance of large scale software systems, and is remarkably good at it.

What is Eiffel?

Eiffel is an Object Oriented language, akin to Java - If you know Java or C++ learning Eiffel is utterly straightforward. Eiffel has many of the same features as Java or C++, but often offers improvements. For instance Eiffel has garbage collection like Java, but has memory efficiency on par with C++. Eiffel's type system is stronger, more robust, and safer than either C++ or Java. Eiffel offers generics like Java (or templates in C++), but they are more naturally integrated into the language (Eiffel had generics from the outset) and much easier to understand and use. Eiffel has multiple inheritance like C++, but has a much more powerful system for dealing with the issues that arise - which is to say that multiple inheritance in Eiffel just works, and isn't something to avoid (quite the contrary, it is used regularly!). Eiffel also has some novel features such as expanded types (which offer a distinct improvement over primitive types and autoboxing), non-conforming inheritance (which allows for partial implementation interfaces, among other things), and agents, which allow for closures. The feature Eiffel is most known for, of course, is Design by Contract, which integrates pre- and post-conditions and class/object invariants into the language and aids in correctness and documentation of software. To get a feel for the look of Eiffel you can browse through some examples on LiteratePrograms, or this comparison of C++ and Eiffel for longer code samples. Eiffel has had most of these features for some time now of course - so what is it that makes Eiffel worth a second look?

Eiffel is Now GPL Software

A GPL Eiffel compiler, SmartEiffel, has been around for a while (and even sports a variety of interesting features not found in commercial Eiffel compilers), but recently ISE re-licensed EiffelStudio, their commercial Eiffel IDE, libraries, and compiler system, under a dual licensing scheme. EiffelStudio is now GPL software. The catch is that if you want to release software under a non-GPL license you have to buy a commercial license. Then again, given that a great deal of large scale software projects are bespoke systems that may as well be GPL, this isn't necessarily a loss for many cases. If you desperately need to sell your software and keep the source then EiffelStudio will set you back around $5000.

Aside from being free to use, making EiffelStudio GPL has also pushed development along. The upcoming release of EiffelStudio 5.7 (the first major release after going GPL) has a lot of significant improvements, and is, in my opinion, a much nicer system to look at and work with. The roadmap also has plenty of other new and useful features appearing in the not too distant future. EiffelStudio is a first rate IDE (download the preview releases of 5.7 and try it out), and GPL development has helped round it out and shave off many of it's niche quirks for a more mainstream audience.

Eiffel is Fast

One of the first things that Eiffel brings to the table over Java is raw execution speed. Eiffel compiles, via C, to native code, and in practice that means it has performance comparable to C. Compared to C++, Eiffel is on par speed wise, and uses less memory. Compared to Java, Eiffel is way ahead, both is speed and memory. And you get that sort of performance from a fully OO language complete with generics, garbage collection, and all the other sugar you would expect from a modern OO language.

The downside is that to get that sort of speed Eiffel uses C as an intermediary language, and that means compiling can be very slow. To compensate EiffelStudio has a very intelligent compiler system with so-called "melting ice" technology that means that you only need to recompile as much as was changed since the last compilation. That means that while SmartEiffel is slow to compile, from within EiffelStudio compilation (after initially compiling the project for the first time) is as fast (indeed faster in some cases) as any other compiler I've ever used.

Eiffel has Excellent Concurrency Support

One of the things that Eiffel promises to have in the near future is next generation concurrency support via SCOOP. Instead of implementing concurrency by traditional methods such as monitors, which were introduced by Tony Hoare way back in 1974, SCOOP is based on the CSP model of concurrency that Hoare developed through the 80s as a vast improvement over his monitor model. The result is an incredibly natural and easy to use concurrency system, with much stronger assurances, and amenability to static checking via CSP model checkers (which can verify the impossibility of deadlock, etc.)

How simple is SCOOP? It requires only a single new keyword: separate. The system works by allowing you to declare objects (or classes if every object of that class will always be separate) as being "separate". Objects that are separate may operate concurrently in different threads or processes (SCOOP is agnostic to the actual concurrency mechanism, and is thus also easy to port). Wait conditions are naturally expressed as preconditions on methods. That's essentially all there is to it - almost everything else is handled behind the scenes by the compiler: it just works. If that sounds too easy it's worth reading some of the papers about SCOOP to hammer out the fine details, or just looking at working examples, but in practice it largely is exactly as simple as I just described.

Given that computers are becoming increasingly multi-core, and concurrent programming is becoming increasingly prevalent, having a language with such powerful, yet simple and easy to use concurrency is a huge boon. Getting concurrency right has never been so easy. Unfortunately the full SCOOP system is still being developed. For now SCOOP is available as a library and preprocessor. SCOOP is expected to be integrated into the Eiffel compiler in the next year or so.

Eiffel Helps You Catch Your Mistakes

Eiffel's Design by Contract approach, with pre- and post-conditions is a great way of catching errors earlier by providing both a powerful test harness to isolate errors, and more explicit documentation of APIs. That, however, is just the beginning - once you start providing contracts for your code, you can get other benefits for free. The first major benefit is AutoTest. This is a new system (still being developed, but very functional already) that uses contracts as test oracles for completely automated randomised testing. You push a button and walk away, and AutoTest will fully exercise your code with randomised tests and provide you with a simple report of what went wrong. There's a pluggable system for generating test data, so you can use anything from purely random, to genetic algorithms, to systems designed to provide maximal coverage. And it really does work - AutoTest found several bugs in Eiffel's base libraries that had gone unnoticed for years. There is already an effort underway to integrate AutoTest into EiffelStudio itself.

The other option is ESpec, and in particular ES-Verify which, using a set of modelling libraries, allows Eiffel code to be submitted to automated theorem provers for verification. ESpec is in its infancy at this stage, but already looks impressive, and will hopefully merge with the Extended Static Checking project for EiffelStudio.

Miscellaneous Extras

Both inline agents and non-conforming inheritance are relatively new to Eiffel, and given how powerful and useful they are, they are worth checking out - if you bother to take a closer look at Eiffel be sure to read up on both. Eiffel also offers good multi-platform support: EiffelStudio is available for Windows, Linux, FreeBSD, Solaris, and even VMS (a MacOS X version is forthcoming), and because Eiffel compiles via C you can compile efficient binaries for whatever platform you wish (thanks to gcc). EiffelStudio also, conveniently, comes with an easy to use GUI library, called EiffelVision2, which supports both Windows and GTK+ (and MacOS X in the future). Alternatively you can compile Eiffel to .NET bytecode with EiffelStudio, or Java bytecode with SmartEiffel. In the case of .NET Eiffel is well integrated and you can easily use and inherit from .NET classes. In the case of Java you need an extra wrapper generating tool to use and inherit from Java classes, but it is easy enough to do.

It is also worth mentioning, at this point, that moving to Eiffel doesn't mean discarding an existing codebase. Eiffel has support for using C++ classes via Legacy++, support for wrapping straight C libraries via EWG, the Eiffel Wrapper Generator, can use Java libraries and due to .NET integration it can use C# .NET classes out of the box.

If all of this has piqued your interest, you can start with a quick introduction, a more in depth tutorial, or take a tour of EiffelStudio. It is well worth the look.

Please note that while this article happens to be about Eiffel, there are a lot of interesting languages out there that deserve a second, or in some cases even a first, look. Various other languages that I think are definitely worth the time taking a look at include: Ada, D, Lisp, Nemerle, OCaml, Scala, and Spec#. Seriously, all of those languages deserve a close look to see what they're really capable of, even the ones you may have dismissed in the past.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Scoop
o Design by Contract
o LiteratePr ograms
o comparison of C++ and Eiffel
o SmartEiffe l
o preview releases of 5.7
o Compared to C++
o Compared to Java
o CSP
o papers about SCOOP
o looking at working examples
o library and preprocessor
o AutoTest
o simple report of what went wrong
o ESpec
o ES-Verify
o Legacy++
o EWG, the Eiffel Wrapper Generator
o Java libraries
o a quick introduction
o a more in depth tutorial
o take a tour of EiffelStudio
o Also by Coryoth


Display: Sort:
Why Eiffel Might Be Worth a Second Look | 111 comments (86 topical, 25 editorial, 0 hidden)
too iffy (2.50 / 4) (#1)
by United Fools on Tue Oct 31, 2006 at 08:11:29 PM EST


We are united, we are fools, and we are America!
i prefer Lisp (nt) (3.00 / 3) (#2)
by circletimessquare on Tue Oct 31, 2006 at 08:48:00 PM EST



The tigers of wrath are wiser than the horses of instruction.

lisp is a slow memory hog (2.50 / 4) (#3)
by j1mmy on Tue Oct 31, 2006 at 09:05:12 PM EST

looky

[ Parent ]
depends on what you're doing (3.00 / 2) (#20)
by Delirium on Wed Nov 01, 2006 at 12:26:16 AM EST

Try implementing something heavily symbolic, like say, an inference engine for higher-order logic in each, and compare both the number of lines of code and the execution efficiency.

[ Parent ]
Lines of code (none / 0) (#21)
by Coryoth on Wed Nov 01, 2006 at 12:47:11 AM EST

Eiffel is going to lose out on "number of lines of code", although that's as much to do with style and formatting as comparative expressiveness of the language: Eiffel tends to make use of newlines as a separator more than languages like Lisp. On execution efficiency and memory use, however, Eiffel will do quite well.

[ Parent ]
how does eiffel deal with symbolic concepts? (3.00 / 3) (#23)
by Delirium on Wed Nov 01, 2006 at 01:48:33 AM EST

By lines of code I meant something more informal than literal lines of code. For example, introducing new symbols in Lisp is done by just writing them: If I have a function (assert) to assert things into a knowledge base, and (query) to query for a pattern, I can write something like (assert '(isa human foo)) and (query '(isa ?A foo)) and get back '(?A human).

I'm less familiar with Eiffel, but doing the same thing in C++ or Java requires some huge hackery. Probably the most straightforward from the caller's perspective is to just pass in "isa human foo" and "isa ?A foo" as strings, and have the assert and query functions parse the strings, look up the symbols in an internal symbol table and map them to some index (an integer or enum or something). But then the returned value is a string too, which isn't that useful to the caller. There are some even uglier ways involving the caller instantiating new enums or objects to pass in, but I haven't found any that's actually sane to use.

[ Parent ]

Yes, apologies (none / 0) (#24)
by Coryoth on Wed Nov 01, 2006 at 02:12:20 AM EST

I wasn't reading closely. If you're delving into Lisp metaprogramming then you're going to end up better off because that's something Lisp is ideal for. That comes back to the "Right Tool for the Job" issue - in this case, for that problem, it's going to be Lisp.

[ Parent ]
well, more just embedded mini-languages (none / 1) (#26)
by Delirium on Wed Nov 01, 2006 at 02:50:16 AM EST

Not necessarily Lisp metaprogramming, but embedded miniature languages, like first-order logic queries, or SQL queries, or runtime evaluation of arithmetic expressions. I've had it come up in a number of cases in C++ and Java, and my solutions have always seemed really clunky. The two I've managed to use are basically:
  • Use strings for everything, and parse internally. Can work okay if the return value is simple, so the caller doesn't have to parse the result too. For example, an arithmetic engine can take in the string "(2 + 3) * 5" and return 25. Less nice if the return value is also in an embedded language.
  • Have a valid expression in the embedded language be a class, like Exp, which can have structure and subtypes. Using the same example, the engine might take in "new MultExp(new AddExp(AtomExp(2), AtomExp(3)), AtomExp(5))". Return values can also have structure, since they'd be a class that the user can use.
The first is easier to type but programmatically opaque; the second has nice useable structure but is horrid to use for even moderately complex examples. I've used a number of C libraries that take the first (string-passing) approach, and a handful of both C++ and Java libraries that take the second approach. Both really seem like huge hacks, and for whatever reason it ends up coming up frequently in stuff I do...

[ Parent ]
to be fair (none / 0) (#37)
by j1mmy on Wed Nov 01, 2006 at 10:00:37 AM EST

and have the assert and query functions parse the strings, look up the symbols in an internal symbol table and map them to some index

this is the work lisp is hiding from the programmer. there may be no syntactic equivalent for languages such as Java and C++, but I don't expect they'd be performing any worse in terms of execution time.

i wonder if a language like python could be as usable as lisp for tasks like this. it has a built-in shell, can do lambda nonsense, and can define anything you want on the fly.


[ Parent ]

not really (none / 1) (#44)
by Delirium on Wed Nov 01, 2006 at 12:28:43 PM EST

Lisp's symbol type is internally basically an enum, and if known at the time, evaluated at compile time. So something like '(isa a b) is internally stored as a 3-element linked list of symbol-type enum values If I write in my code a literal statement like (assert '(isa a b)), the '(isa a b) gets parsed at compile time by the lisp lexer/parser and created as a list literal, not at runtime like assert("isa a b") would. To do the equivalent in Java/C++ would require defining a compile-time constant object of type Assertion or something like that, and then doing assert(foo), but as far as I know there's no way to write the list literal actually in the call.

Python is probably as usable as lisp, but about 100-1000 times slower for most common things, since it's a purely interpreted language.

[ Parent ]

That's because you don't know shit [nt] (2.57 / 7) (#9)
by debacle on Tue Oct 31, 2006 at 09:41:36 PM EST



It tastes sweet.
[ Parent ]
communist -nt (none / 1) (#40)
by zenofchai on Wed Nov 01, 2006 at 11:34:17 AM EST


--
The K5 Interactive Political Compass SVG Graph
[ Parent ]
Most concise troll ever. [nt] (3.00 / 7) (#43)
by rusty on Wed Nov 01, 2006 at 12:24:11 PM EST



____
Not the real rusty
[ Parent ]
seriously (none / 0) (#45)
by circletimessquare on Wed Nov 01, 2006 at 12:35:56 PM EST

i was just making a throw away stupid joke about using a boutique computer language

and look at the arguments now underneath


The tigers of wrath are wiser than the horses of instruction.

[ Parent ]

It should be canonized (3.00 / 3) (#49)
by rusty on Wed Nov 01, 2006 at 12:45:07 PM EST

"I prefer Lisp" is probably a great troll in almost any circumstance. I wonder if this has been discovered before?

____
Not the real rusty
[ Parent ]
truly a great day for Troll Science (tm) nt (none / 0) (#56)
by circletimessquare on Wed Nov 01, 2006 at 01:21:11 PM EST



The tigers of wrath are wiser than the horses of instruction.

[ Parent ]
Important List Question (none / 0) (#75)
by wiredog on Thu Nov 02, 2006 at 08:58:42 AM EST

What sick summbitch but the 's' in lisp?

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
Easy (3.00 / 2) (#79)
by BJH on Thu Nov 02, 2006 at 11:22:35 AM EST

It'th there to enthure that you don't have a lithp when talking about Lithp, becauthe that would be embarrathing for everyone involved.
--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]
What? I'm not really into Pokemon. (nt) (3.00 / 2) (#70)
by Scott Robinson on Thu Nov 02, 2006 at 01:35:36 AM EST



[ Parent ]
Lisp? (none / 0) (#87)
by Just this guy on Thu Nov 02, 2006 at 06:44:44 PM EST

Sorry, I'm not really into Pokemon.

[ Parent ]
Holy fuck, I failed that one hard $ (none / 0) (#88)
by Just this guy on Thu Nov 02, 2006 at 06:45:42 PM EST



[ Parent ]
Eiffel is (none / 0) (#104)
by discountpetmeds on Mon Nov 06, 2006 at 12:50:36 PM EST

Eiffel is a programming language created by Bertrand Meyer to be object-oriented; it introduced the now semi-popular idea of "Design By Contract", where the semantics of a method are declared to fulfill certain constraints if certain constraints are met by the method caller.

Unfortunately, Eiffel's object system is class-based, single-dispatch only. The contracts are not as expressive as one might hope, and are checked at runtime only (this may be fixable). Overall, the language just isn't impressive. What it has it does well (for the most part) but it lacks a lot. -- seaslug

    * The general documentation.
    * Eiffel's contracts.
    * Eiffel's inheritance semantics.

    * "SmartEiffel" (was "SmallEiffel")
    * "ISE": (Proprietary)

justin goldberg, an atlanta-based network and pbx engineer
[ Parent ]

Static checking of contracts (none / 0) (#105)
by Coryoth on Mon Nov 06, 2006 at 01:38:44 PM EST

ES-Verify, from ESpec, as cited in the article, has facilities for static checking of contracts.

[ Parent ]
ror (3.00 / 4) (#4)
by the spins on Tue Oct 31, 2006 at 09:05:49 PM EST

the more i learn about aeronautical engineering, the more i come to see that most of you programmers are doing some real amateur hour shit.

 _
( )
 X
/ \ SUPPORT THE DEL GRIFFITH MODBOMBING CAMPAIGN

IF PROGRAMMERS HAD THEIR WAY (3.00 / 6) (#5)
by dongs on Tue Oct 31, 2006 at 09:20:11 PM EST

WE'D ALL BE FLYING AROUND INSIDE GIANT HACKEY SACKS AND FRISBEES

[ Parent ]
So you're a college freshman then (none / 0) (#14)
by debacle on Tue Oct 31, 2006 at 10:10:40 PM EST

How quaint.

It tastes sweet.
[ Parent ]
amateur hour --> (3.00 / 3) (#17)
by the spins on Tue Oct 31, 2006 at 10:15:45 PM EST


 _
( )
 X
/ \ SUPPORT THE DEL GRIFFITH MODBOMBING CAMPAIGN

[ Parent ]

Where's our fucking personal flying machines... (3.00 / 5) (#30)
by BJH on Wed Nov 01, 2006 at 07:22:44 AM EST

...you lazy shit?

I WANT MY PERSONAL FLYING MACHINE!!!

Computers have advanced to the point where what I was using as a kid now doesn't even qualify as sufficient for a goddamn remote control, let alone something as advanced as a phone, whereas the planes I rode in as a kid seem to me to look EXACTLY THE FUCKING SAME as the planes I ride in now.

So get off your ass and give us our hypersonic supershuttles that carry 10,000 people in total safety between London and New York in 15 minutes, goddamit.
--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]

Indeed (3.00 / 6) (#42)
by rusty on Wed Nov 01, 2006 at 12:23:17 PM EST

That's because if aeronautical engineers hewed to computer development standards, the planes we'd have now would go Mach 12, use 0.3 gallons of gas per hour, and on average kill 65% of the people who rode in them.

____
Not the real rusty
[ Parent ]
Acceptable. Commence development. /nt (3.00 / 3) (#51)
by grargrargrar on Wed Nov 01, 2006 at 12:50:50 PM EST



[ Parent ]
NOT IF THEY WERE LINUX PLANES (3.00 / 4) (#53)
by Delirium on Wed Nov 01, 2006 at 12:54:22 PM EST

IT DOESN'T CRASH!!!

[ Parent ]
Should be spelled "LUNIX"... (none / 0) (#68)
by BJH on Wed Nov 01, 2006 at 11:29:40 PM EST

...for extra trolling goodness.
--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]
would you like to fund us? (none / 0) (#62)
by the spins on Wed Nov 01, 2006 at 04:10:15 PM EST

a vast portion of R&D work in the field is funded by defense interests in one manner or another. that's why the military gets all of the cutting edge hypersonic whizbang aircraft, missles, etc. in contrast, there just isn't any money in shuttling passengers from point A to point B at supersonic speeds -- witness the death of the concorde and the status of the now-defunct National Aerospace Plane program as basically budget cover for clandestine programs. the commercial industry, e.g., boeing and airbus, are much more interested in getting a bunch of people around more fuel efficiently, which means subsonic/trans-sonic flight.

as an aside, your "personal flying machine" has been around for quite a while; look up ultralight aircraft, many people build them from kits.

 _
( )
 X
/ \ SUPPORT THE DEL GRIFFITH MODBOMBING CAMPAIGN

[ Parent ]

ultralight aircraft (none / 0) (#73)
by o reor on Thu Nov 02, 2006 at 08:40:17 AM EST


> as an aside, your "personal flying machine" has
> been around for quite a while; look up ultralight
> aircraft, many people build them from kits.

Hmmm... how should I put it ? Oh yeah. Just as Bill G. told us 20 years ago that "640kb should be enough for everybody", you're basically telling us that "60 knots @ 3000 feet should be enough for everybody". YMMV.

[ Parent ]
well (none / 0) (#82)
by the spins on Thu Nov 02, 2006 at 12:30:12 PM EST

unlike computers, you have a very good chance of killing yourself and other people as the speeds and altitudes increase. if you had to be licensed to use computers, i think you'd see similar progress (not to mention that most software companies today would not exist because of quality control issues).

 _
( )
 X
/ \ SUPPORT THE DEL GRIFFITH MODBOMBING CAMPAIGN

[ Parent ]

It must be true, the man is an engineer! (none / 0) (#50)
by ksandstr on Wed Nov 01, 2006 at 12:46:28 PM EST

Oh lawd.

Fin.
[ Parent ]
you are correct (none / 0) (#76)
by GrubbyBeardedHermit on Thu Nov 02, 2006 at 09:07:30 AM EST

software engineering is many years behind other professions.  Give it time though, your children's children will be writing board exams and doing articles/apprenticeships.

In the mean time, for your own safety, I recommend

  1. pay cash
  2. do not fly or drive
  3. stay out of hospitals
  4. switch your computer off NOW!

GBH
[ Parent ]

Ha! From an aero, that's truly amusing (3.00 / 4) (#83)
by Bwah on Thu Nov 02, 2006 at 01:40:06 PM EST

Although I hesitate to dinify this with an actual response, I'm currently quite bored. Aeronautical engineering, until very very recently, was an empirically based voodo magic load of crap. :-) (And I say this as someone who has designed aircraft.) It can basically be summed up as "Well, we really don't understand how any of this shit works, so we'll just make a close approximation and then roll up everything else into a coefficient that you have to go determine empirically in a wind tunnel." With the more modern CFD techniques it's a bit less hackish, but still it's just as much trial and error as CS and CE. Actually more. The only thing that CFD is buying most aero engineers is the ability to not have to build a physical model. The aircraft design process taught in college is a joke. Pick up a copy of Raymer's book "Aircraft Design: A Conceptual Approach". (This IS a great book, I'm not arguing that.) However, if you actually look at the approach taught it's a joke compared to most other engineering disciplines. It all boils down to "look at how lots of other aircraft have done it and then use these general guidelines and coefficients to tweak one area at a time." Buncha 1930's style crap. Aircraft design cries out for a supercomputer running a large multidiscipline genetic solver ... :-) At that point we are talking true engineering - you know it's going to work before you actually build it.

--
To redesign an infinite ensemble of universes: what terrible responsibility, what arrogance ... It sounds just like the type of thing your average Homo sap would do for a dare. -- Stephen Baxter
[ Parent ]

Excellent article (3.00 / 3) (#19)
by terryfunk on Tue Oct 31, 2006 at 11:42:50 PM EST

on a programming language I never tried.

+1 FP I enjoyed it.

I like you, I'll kill you last. - Killer Clown
The ScuttledMonkey: A Story Collection

Concurrent objects (3.00 / 6) (#22)
by GileadGreene on Wed Nov 01, 2006 at 12:48:14 AM EST

It's interesting to note that Alan Kay originally conceived the OOP model in terms of concurrent interacting objects (actors really - in fact Kay's early work on Smalltalk inspired Carl Hewitt's work on actors). Which is why you often used to hear (somewhat misleading) talk about objects in OOP languages interacting by message-passing. So CSP-based Eiffel concurrency is in some ways a return to Kay's original conception of OOP. Of course, it's also a vast improvement over more standard OO concurrency models, since it keeps threads of control aligned with objects (and thus able to be composed in easily understandable ways), rather than allowing individual threads of execution to wander through multiple objects (Peter Welch's Wot, no Chickens? has a pretty good explanation of why this isn't a good idea).

I evaluated Eiffel and didn't like it. (3.00 / 8) (#29)
by i on Wed Nov 01, 2006 at 05:14:31 AM EST

  • Unsound typesystem
  • Nonlocal validity which is sometimes enforced by the compiler and sometimes isn't (you can't tell when)
  • Multiple inheritance that is broken beyond repair (yes I mean it)
  • Other stuff that I don't remember
  • A vocal community which insists that every language bug is indeed a feature (look! pun!) (MI being the primary example) or, alternatively, a minor issue not worth anybody's attention

In addition, reading Object Oriented Software Construction left me with a remarkably persistent impression that its author is a pompous douchebag.

You may find the following little fact interesting. The Eiffel concurrency system SCOOP was first described in 1993, and its integration into Eiffel Studio is promised RSN ever since.

That was my experience, yours may be different.

and we have a contradicton according to our assumptions and the factor theorem

What exactly do you mean by 'nonlocal validity'? (none / 1) (#32)
by BJH on Wed Nov 01, 2006 at 08:18:58 AM EST


--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]
I mean (none / 1) (#46)
by i on Wed Nov 01, 2006 at 12:36:53 PM EST

that in order to establish validity of a piece of Eiffel code, you may need to evaluate the entire program (because "polymorphic catcalls are invalid").

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Actually, there is a workaround (3.00 / 3) (#78)
by A Bore on Thu Nov 02, 2006 at 09:40:52 AM EST

Use the dimorphic screams of weasels. They are valid.

[ Parent ]
Depends on what you're looking for. (3.00 / 2) (#54)
by Coryoth on Wed Nov 01, 2006 at 01:02:14 PM EST

Unsound typesystem

You mean just like Java, C++ and C#? And it's worth  noting that Eiffel's type system is far more robust and safe than any of those - no it's not perfect, but given the popularity of Java, C++, and C# a sound type system isn't something that matters to a lot of people. If it really matters to you then Haskell or OCaml are the way to go.

Nonlocal validity

I'm honestly not exactly sure what you mean by this. A google search for non-local validity didn't help me much either. Can you give a better explanation of what exactly you mean?

Multiple inheritance that is broken beyond repair

I'm not sure what you mean by this either. Eiffel has multiple inheritance. It works. I haven't had any difficulty using it, nor found any reason to consider it broken. You'll have to elaborate.

Other stuff that I don't remember

Well I certainly can't help you with stuff you don't remember.

A vocal community which insists that every language bug is indeed a feature

Find me any language community that doesn't have vocal zealots who will claim such things. I think you'll struggle. Maybe for an obscure research language, or something else that hasn't picked up zealots yet.

The Eiffel concurrency system SCOOP was first described in 1993, and its integration into Eiffel Studio is promised RSN ever since.

What was included in the 1993 description was an outline of how a CSP modelled concurrency ought to work, and how that could e integrated into the language. It gave the rough idea, but didn't deal with the details. The details have been problematic. SCOOP is incredibly simple for programmers to use. It manages to e that simple by pushing all the complexity into the compiler. Behind the scenes there is a lot of hard work required, and a lot of sticky issues - in the late 90's a series of catches with what was described in 1993 were uncovered, and took a while to properly hammer out. That slows things up a it.

Is SCOOP coming RSN? Well yes. It's here right now in many ways. You can download a system of libraries and preprocessor that let you code using SCOOP's concurrency system right now. It works. And really, that's no worse than C++ which requires a preprocessor. If you want to write code using SCOOP right now, you can, and it works.

[ Parent ]

Some things. (3.00 / 3) (#57)
by i on Wed Nov 01, 2006 at 02:51:12 PM EST

  1. No, the Eiffel's type system is not really that robust or safe. It's not really different from that of C++ or Java or any other run-of-the-mill statically typed OO language. Virtually everything you can do with Eiffel types I can do with C++ or Java types -- modulo covariance of course, which is yet another bug-redefined-as-feature.

  2. Polymorphic catcalls are invalid. That's non-locality. It's polymorphic because of condition A, and it's "cat" because of condition B -- in some totally unrelated place in the program. Adding a new class to a program can invalidate existing code in unknown number of places. Eiffel aficcionados will tell you that it's not important in practice. I happen to think otherwise, for reasons I won't go into here.

  3. Yeah, MI in Eiffel works unless you have a diamond hierarchy (repeated inheritance in Eiffelspeak). Surprise: in every other language MI works unless you have a diamond hierarchy! Now, if you have repeated inheritance and you don't need to replicate anything, it still works. When you need to replicate, you're screwed. I'm not going to search those postings in comp.lang.eiffel, sorry, google is your friend. Now, it's replication that makes MI interesting. Without replication it's all trivial. In C++, you either replicate or merge an entire grandparent class, which is reasonable You need to decide on replication or merging too early, which is broken, but efficiency principles of C++ demand it. In Eiffel, you replicate or merge individual features. This is broken beyond repair. You can only reasonably do that if you control the entire hierarchy, and are intimately familliar with its inner working. Try to reuse third-party closed-source code this way. You can't. Again, replication is a bug-redefined-as-feature.

  4. It's all a matter of degree. Every community has vocal zealots, but Eiffel community seemed to consist of vocal zealots almost entirely. Or that was my impression when I tried to interact with it.

  5. I would love to try out SCOOP. It's one fragment of Eiffel I found interesting, and I like to toy with the idea of adapting it to other languages. However, its slow progress makes me suspect some very deep problems with either SCOOP itself or its implementors. I will be happy to be proved wrong.

Now, I'm not trying to convince people that E. is totally worthless or something because of these points. Just balancing your account a little bit, OK?

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Yes and no (3.00 / 2) (#59)
by Coryoth on Wed Nov 01, 2006 at 03:59:04 PM EST

Perhaps I should be clear on my target audience: I'm pitching more at the average Java and or C++ programmers who have never really taken much of a look at anything on offer outside of their language of choice. There are certainly plenty of languages that offer various benefits over Eiffel, depending on what you're looking for. Ocaml gives you a sound type system and functional programming for impressive expressiveness, along with very impressive performance. As someone pointed out above, Lisp gives you great performance on code that deals with symbolic manipulation. Haskell provides functional purity, a powerful and sound type system, and the ability to isolate state into monads. Epigram offers a language with an excellent dependent type system and impressive provability. The list goes on. Every language has its strong and weak points. My aim wasn't to imply that Eiffel is the perfect language (what does that mean anyway? I think the best you could claim is "best for a particular purpose" and even that is iffy), it was to, as the title says, point out that Eiffel might be worth a second look. Given that, it seemed fair to me to point out what its good features were and why you might want to look at it.

No, the Eiffel's type system is not really that robust or safe.

That depends on what you're comparing it to. If you compare to Haskell of Ocaml then yes, it is unsound and has issues. If you compare it to Java or C++ then, in general, it is slightly harder to screw things up in Eiffel.

Polymorphic catcalls are invalid. That's non-locality.

And, as far as I can tell, this is a mess you can easily make for yourself with Java, C++ or C# (though you might have to go about it slightly differently). Yes, it is an issue, but it's an issue most people are already facing. It's not like moving from Java to Eiffel is introducing new problems in this arena.

Yeah, MI in Eiffel works unless you have a diamond hierarchy...

This one I have to grant you - it is possible to make a mess here in repeated inheritance cases. I think "broken beyond repair" is a little harsh in that it gives te impression that MI just never works, which isn't true. It has an issue, however, which I'll grant you.

I would love to try out SCOOP. It's one fragment of Eiffel I found interesting, and I like to toy with the idea of adapting it to other languages.

Then try it. Grab the SCOOP libraries and preprocessor and have a go.

Now, I'm not trying to convince people that E. is totally worthless or something because of these points. Just balancing your account a little bit, OK?

Sure, and you should note that I'm not trying to sell Eiffel as a silver bullet with this article either (note the disclaimer at the bottom - there are plenty of languages that deserve an article like this, I just happened to pick Eiffel). I'm just trying to point out to people that Eiffel is worth a look. Perhaps it's not ideal for whatever you're doing - the Right Tool for the Job matters - but maybe it is. It is certainly a language that offers some strong points, particularly over the more mainstream OO languages.

[ Parent ]

What's wrong with Eiffel multiple inheritance? (none / 0) (#109)
by p3d0 on Thu Nov 16, 2006 at 07:59:28 PM EST

Count me among those who think Eiffel has it right.  What didn't you like about it?
--
Patrick Doyle
My comments do not reflect the opinions of my employer.
[ Parent ]
Can they do that? (3.00 / 3) (#31)
by creature on Wed Nov 01, 2006 at 07:28:20 AM EST

EiffelStudio is now GPL software. The catch is that if you want to release software under a non-GPL license you have buy a commercial license.

I thought you weren't allowed to impose such constraints, such are the wonders of GPL software. That was part of the deal with gcc - you're allowed to release software developed with it commercially (you don't have to GPL it).

I don't understand how they could GPL their software and impose this constraint.

Anyway, good article. +1FP when it appears.

Probably (none / 1) (#33)
by thejeff on Wed Nov 01, 2006 at 08:22:10 AM EST

the library licences. If you link in GPL code, the resulting software is under the GPL. Most GNU libraries use LGPL, which explicitly allows this.

[ Parent ]
Still not convinced. (none / 0) (#34)
by creature on Wed Nov 01, 2006 at 09:34:52 AM EST

See the GPL FAQ. What you say is true, but the article here is talking about an IDE, which probably shouldn't be linking in its own libraries anyway.

[ Parent ]
Not Just an IDE (none / 0) (#77)
by Fat Tony on Thu Nov 02, 2006 at 09:15:36 AM EST


It's an entire development platform, including an IDE, compiler and library set.  Akin to Visual Studio.

[ Parent ]
It's not clear what that statement is intended... (3.00 / 3) (#35)
by BJH on Wed Nov 01, 2006 at 09:35:20 AM EST

...to mean.

If they mean "we will let you license EiffelStudio under non-GPL terms for money", that's fine.

If they're saying, "we want money for you to develop non-GPL software with this application", that is not fine.

The only way that could be allowed under the GPL is if developing software with EiffelStudio actually links code from EiffelStudio into the resulting software.

Maybe it does - I don't know enough about EiffelStudio to say.
--
Roses are red, violets are blue.
I'm schizophrenic, and so am I.
-- Oscar Levant

[ Parent ]

Mmm. (none / 0) (#41)
by creature on Wed Nov 01, 2006 at 11:48:11 AM EST

I've just emailed them the following to ask:

Hello,

I have an inquiry about your GPL-licensed Eiffel Studio ("EiffelStudio Integrated Development Environment, Open Source Edition"). I am viewing the license at https://www2.eiffel.com/download/licenses/gpl.html which contains the following text:

"Eiffel Software grants to you a nonexclusive license to use EiffelStudio at no charge under the terms of the GNU General Public License (hereinafter referred as GPL) for the development of Open Source software."

I don't understand how you can impose constraints on the use of your software while simultaneously releasing it under the GPL. In particular, the GPL FAQ says that you cannot exercise any control over the output people get from your software (See http://www.gnu.org/licenses/gpl-faq.html#TOCGPLOutput). Possibly more relevant is the answer to the question "Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?" at http://www.gnu.org/licenses/gpl-faq.html#TOCCanIUseGPLToolsForNF . Both of these questions imply that I could use EiffelStudio to develop both open-source and proprietary software. By trying to impose your own restrictions, are you not violating the GPL yourselves?

Please don't think this is an attack - it's not. I'm curious to know if I've misunderstood something as I want to obey the license.

Thank you,

Creature.

[ Parent ]

it does link in code (3.00 / 2) (#52)
by Delirium on Wed Nov 01, 2006 at 12:52:07 PM EST

The Eiffel runtime library is GPL, not LGPL, and so no non-GPL program can use it. This doesn't happen with C/C++ because while gcc is GPL, it's runtime library, libc, is LGPL.

[ Parent ]
It is libraries (3.00 / 2) (#47)
by Coryoth on Wed Nov 01, 2006 at 12:37:16 PM EST

In Eiffel everything is an object; everything. That means no primitive types like in Java or C++. Instead Eiffel has what are called expanded types which can fill a similar role, but are more flexible (since they're still objects) and you can define new ones yourself. What does that have to do with anything? Well it means that you need the base kernel library that comes with EiffelStudio to do anything, because without it you don't even have BOOLEAN, INTEGER, etc. types and really can't do anything. That means that, inevitably, you will be linking to libraries included in EiffelStudios GPL license, and hence are necessrily linking to GPL software. So if you want to relese software under a different license you need to negotiate getting EiffelStudio under a different license, and for that they will charge you money (quite reasonably).

So yes, EiffelStudio is an IDE, and a compiler, and if it were just those two things and GPL then you would be fine. It is also the necessary base libraries that are required to be able t write anything in Eiffel, and those are also GPL, not LGPL. If you're really keen you can write some new base libraries (a big part of SmartEiffel is an alternate set of libraries) and license them under the LGPL and you'll be good to go.

[ Parent ]

You're right. (none / 0) (#61)
by creature on Wed Nov 01, 2006 at 04:09:47 PM EST

That's exactly it, so says the company.

[ Parent ]
so to sell software that uses eiffel just include (none / 0) (#72)
by newb4b0 on Thu Nov 02, 2006 at 03:42:32 AM EST

a file with the eiffel source.

http://www.netmoneychat.com| NetMoneyChat Forums. No Registration necessary. Ya'll.
[ Parent ]

also (none / 0) (#84)
by axus on Thu Nov 02, 2006 at 01:41:33 PM EST

include the source to your software, since its linking GPL stuff

[ Parent ]
blah. ignore that. any publicity is good publicity (none / 0) (#96)
by newb4b0 on Thu Nov 02, 2006 at 10:01:30 PM EST

its not like ur making money selling eiffel. your makking money selling programs that use the libraries.

http://www.netmoneychat.com| NetMoneyChat Forums. No Registration necessary. Ya'll.
[ Parent ]

QT is licensed that way by Trolltech (none / 1) (#74)
by wiredog on Thu Nov 02, 2006 at 08:56:46 AM EST



Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
Eiffel licensing (none / 1) (#89)
by trixx on Thu Nov 02, 2006 at 06:48:12 PM EST

If you prefer using Eiffel and have other choices for licensing, SmartEiffel (http://smarteiffel.loria.fr) is GPL but its libraries and runtime is MIT-licensed, so you can relicense your binaries as you prefer

[ Parent ]
So why would anyone use the commercial version? $ (none / 0) (#106)
by mr strange on Thu Nov 09, 2006 at 05:34:28 AM EST



intrigued by your idea that fascism is feminine - livus
[ Parent ]
So, a computer that ran only Eiffelware... (3.00 / 3) (#39)
by Russell Dovey on Wed Nov 01, 2006 at 10:56:24 AM EST

...a desktop computer, or server indeed, that ran primarily programs written in Eiffel, would be an...

EIFFEL TOWER! >.<

"Blessed are the cracked, for they let in the light." - Spike Milligan

Ba-dum. Tsh! /nt (none / 0) (#55)
by grargrargrar on Wed Nov 01, 2006 at 01:06:08 PM EST



[ Parent ]
-1, smells too much like fanboys. (2.37 / 8) (#48)
by ksandstr on Wed Nov 01, 2006 at 12:41:51 PM EST

"Compared to C++, Eiffel is on par speed wise, and uses less memory.", lol what. Unless you can run an Eiffel program without a stack, I hardly see it "using less memory" than a C++ runtime. What with the GC and all that.

Seriously though, what the other guy said about the unsound type system. Also, 1997 called, he's got a nice type inference regime he'd like to donate for y'all!

Far as I can tell, Eiffel is like Pascal, only wrapped in extremely verbose gobbledygook about contracts etc, and with heavier shackles and a cat-o-nine-tails with eleventy whips on it, and the safeword doesn't actually do anything. Snazzy name though. Too bad that the Eiffel Tower itself is an accomplishment that doesn't provoke oohs or aahs anymore.

While I don't disagree with invariants and pre- and postconditions as such, I feel that putting them at the language level and enforcing them with an iron fist results in a language that is painful, if not impossible, to refactor. What with the contract-declared internal APIs becoming huge, hairy scars as time goes by and more bits of the application come to depend on them.

Fin.

Right tool for the job... (3.00 / 3) (#60)
by Coryoth on Wed Nov 01, 2006 at 04:06:42 PM EST

If you are using Ocaml (which would be my guess given the nature of your points) then more power to you. It's a great language, and you'll note I include it in my disclaimer as another languge that is well worth checking out. Mostly it means you're not really in the target audience for this article which is aimed more at Java and C++ programmers who haven't really looked around at what other languages have to offer.

All I'm trying to say with this article is that Eiffel has some interesting points, and recent and upcoming additions make it worth having another glance at. If it isn't the language you're looking for then by all means, don't use it: use whatever suits your particular need; "Right Tool for the Job" and all that. Regardless of whether it is what you need however, it is still a good language worth looking at, along with all the others in the disclaimer: Ada, D, Lisp, Nemerle, Ocaml, and Scala (and I'm sure there are plenty more languages that could reasonably be added, such as Occam and Erlang and Oz if concurrency is really important to you).

[ Parent ]

Actually, similar memory use and faster (none / 1) (#90)
by trixx on Thu Nov 02, 2006 at 06:52:52 PM EST

In my experience with SmartEiffel you have usually faster code because the optimizer does a very good job with most dynamic call points making them static (even when all functions have semantic of virtuals in Eiffel).

Memory use is similar (one extra word per object), and may be better if you use well multiple inheritance (because you can merge objects together than in C++ would be apart). Something else that helps in memory use is the more similar handling of heap allocated and stack allocated objects.

[ Parent ]

I'm curious (1.33 / 3) (#63)
by ElMiguel on Wed Nov 01, 2006 at 04:27:13 PM EST

What exactly is "worth the time" about Ada?

wait lets just use fortran 97 (1.40 / 5) (#71)
by newb4b0 on Thu Nov 02, 2006 at 03:38:05 AM EST


http://www.netmoneychat.com| NetMoneyChat Forums. No Registration necessary. Ya'll.

Name one app/system implemented in Eiffel. (none / 0) (#80)
by shm on Thu Nov 02, 2006 at 11:36:07 AM EST

I'm curious. Would I have heard of it or used it?


You probably haven't heard of it (none / 1) (#81)
by Coryoth on Thu Nov 02, 2006 at 12:14:16 PM EST

Here's a list of representative customers of ISE which licenses EiffelStudio. Te list includes companies like Axa, Boeing, the EPA, Lockheed-Martin, and Northrop-Grumman among others. Eiffel's current niche, and where it has succeeded, is with finance, aerospace, and government departments that require large complex software systems and have a low tolerance for errors. That means Eiffel is used to develop mostly bespoke internal projects you won't see or hear about unless you happen to work at those companies. The lack of highly visible shrink wrap software isn't much of an indication of how often it gets used. Besides, as this article admits, right now Eiffel doesn't have widespread adoption - the point is that, given things like SCOOP for straightforward concurrency, maybe it is worth actually having a look to see whether Eiffel could be a good option for you. Maybe it is, and maybe it isn't, but it is certainly, at the least, worth a look.

[ Parent ]
Ada? (none / 0) (#94)
by kromagg on Thu Nov 02, 2006 at 07:36:03 PM EST

How does it compare to Ada, which seems to be popular in the same niche? Now there's an article waiting to be written. (though probably too specific to pass the queue)

[ Parent ]
Compare how? (none / 1) (#95)
by Coryoth on Thu Nov 02, 2006 at 08:21:01 PM EST

How do they compare as languages, or how do they compare in terms of relative popularity within their fields? The latter I can't really address, but I can speak a little as to how they compare as languages: in many ways Eiffel and Ada are remarkably similar, with fairly similar syntax and style and a lot of the same basic features. I'm not really that well acquainted with Ada (I know the basics, but that's about it), so I can't comment in depth. My understanding is that Eiffel has a little more of an OO focus, and of course has DbC built in. Ada has its own advantages for varying uses, hard real-time software being its biggest win.

[ Parent ]
that's what I meant thx n/t (none / 0) (#111)
by kromagg on Sun Jan 28, 2007 at 06:17:43 PM EST



[ Parent ]
What's debugging like? (none / 0) (#86)
by jmzero on Thu Nov 02, 2006 at 04:54:15 PM EST

With the C-as-intermediate compilation, is there still a capacity for breakpoint/watch type debugging?  
.
"Let's not stir that bag of worms." - my lovely wife
Re: What's debugging like? (3.00 / 2) (#91)
by trixx on Thu Nov 02, 2006 at 06:57:43 PM EST

Yes, there is (in all the available Eiffel environments). However in my experience DbC removes a lot of need for that kind of debugging: you normally use breakpoint and watchs to run the program slowly and see where things go wrong. Using DbC a lot of the things that go wrong trigger an assertion and raise an exception in the line of the bug or very close.

Note that Eiffel exceptions are usually related not only to runtime bugs ("array index out of bounds" "attempt to read a closed file"), but also semantic bugs "at this point of the execution, this list was supposed to be sorted" or "value of this variable should be a prefix of this other variable".

[ Parent ]

Debugging is good (none / 1) (#92)
by Coryoth on Thu Nov 02, 2006 at 07:16:02 PM EST

Most Eiffel environments come with debugging facilities. In the case of the EiffelStudio IDE you get exactly the sort of visual debugging you would expect with an IDE, replete with breakpoints, watches and all the other things you expect. Here's the debugging section of the EiffelStudio tour.

Of course as the other poster points out DbC alleviates a certain amount of the need for debugging by making errors show up faster, and closer to where things started to go wrong. That doesn't completely obviate the need for a debugger of course, so one is provided.

[ Parent ]

Watchpoint/Breakpoint? (none / 1) (#93)
by Fat Tony on Thu Nov 02, 2006 at 07:28:37 PM EST

Yes, I'm not sure how it does it.  I do remember there being two distinct compile phases, perhaps one interprets it (by calling the C functions it would have compiled to) and the other actually compiles it.

I think that might be it.  It's been a few years since I've used it.

[ Parent ]

Re: Watchpoint/Breakpoint? (none / 1) (#99)
by trixx on Fri Nov 03, 2006 at 02:52:45 PM EST

You don't need to do nothing special to implement a debugger for a platform that compiles to C. No more than what you need for a platform that compiles to machine language (like C or C++) or bytecode (Java).

You just need to insert metadata in the generated code to be able to map positions back to the original source and allow to set markers to capture flow control. This is done by all the Eiffel implementations, and is the same idea used in mostly any debugger.

[ Parent ]

Beats agile/XP voodoo, but... (none / 0) (#101)
by expro on Sun Nov 05, 2006 at 10:49:14 AM EST

Design by contract certainly beats agile/XP voodoo, but I'd be more enthusiastic about it with a C++-like const feature.  Many arguments have been made against const by Java and Eiffel advocates because they never got it, but none that seemed reasonable either in terms of why not or work-arounds.  Like all the Java arguments against templates, they should just fix it.

What do you want const for? (none / 1) (#102)
by Coryoth on Sun Nov 05, 2006 at 01:15:00 PM EST

The const keyword in C++ means different things in different cases, so what exactly are you looking for const to do? The combination of command query separation and only clauses pretty much cover all the functionality of const that I would consider useful. Do you need a fixed constant value that can't be altered? Well

pi : REAL is 3.1415926535

will declare pi to be a constant, and the compiler will object if you attempt to write to it elsewhere. Writing to arguments of procedures or function return values is permanently barred via command query separation. Blocking a particlar routine/method from altering data in the class can be done with an only clause, so that

ensure
    only att1, att2

will allow the routine for which it is a post condition to only alter att1 and att2, anything else is a contract violation. You can have whatever attributes you want, or even none (to signify a pure function). To be fair only is a new language feature that, while in the ECMA spec, isn't available in all Eiffel compilers yet.

What particularly did you have in mind in the way of const?

[ Parent ]

Const is more useful, IMO in static typing. (none / 0) (#107)
by expro on Sun Nov 12, 2006 at 08:56:47 PM EST

A post-condition only would seem to verify that given a particular test case the value was not modified.  It is far more useful to have the compiler watching out and verifying that there are no instructions which perform the undesired mutation of the value.  Checking one atomic value at a time also seems pretty worthless.  Sometimes you want constness of a whole network of referencing pointers.  That is the failure of XP, too:  you can't test everything.  The whole model of constness of arguments in C++ seems vastly superior in actual use.

[ Parent ]
Static checking (none / 0) (#108)
by Coryoth on Mon Nov 13, 2006 at 06:10:59 PM EST

Well you can do static checking of contracts via ES-Verify as noted in the article. And if that sort of thing is really important to you then you really ought to look at JML and ESC/Java2 which provide far more comprehensive static checking, as well as far more thorough and potentially fine grained control. In comparison const is a weakly checked kludge.

[ Parent ]
Another godlanguage article. (none / 0) (#103)
by 7h3647h32in6 on Sun Nov 05, 2006 at 02:47:16 PM EST

This is just another of the thousands of internet articles advertising the <insert language here> as having those: "Object oriented and portable like Java, and yet as fast as C" qualities that are the sure signs of having a homeboy author.

Truth is, I've never found a language that does both well.

Eiffel has no generics ... (none / 0) (#110)
by aos on Fri Nov 17, 2006 at 10:02:07 PM EST

Eiffel has templates, just like C++.

Java and .Net languages use generics, and yes, the difference between them are huge.

angel'o'sphere

Why Eiffel Might Be Worth a Second Look | 111 comments (86 topical, 25 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!