SmartEiffel 1.0 Released

Per Wigren writes "Today SmartEiffel, the GNU Eiffel-compiler finally reached 1.0! Eiffel is a very underrated language in the free software community for some strange reason.. Hopefully this will help to gain some interest in this extremely powerful, fast, easy-to-read, easy-to-learn, almost self-debugging language!"

Comments

is there

[mehfu]

an implementatation of the towers of hanoi in eiffel? is it free (as in liberty?)

Re:is there

[Theatetus]

Yes, but since Eiffel is French, it's called the Towers of Dien Bien Phu and bails out after 3 recursions.

Re:is there

[cscx]

France surrenders. Get it? No? You're hopeless.

Re:is there

[jayed_99]

I do have to point out Camerone Day. It is *way* up on the list of legendary-battles-that-really-happened.

Sure, it might be the French *Foreign* Legion. But there sure were some French guys there driving the train.

Yes, the vast majority of WWII was not too pretty...however, Dien Bien Phu -- while a failure, was not a surrender. And that difference is incredibly important. Dien Bien Phu would be impressive by itself. But Camerone gives the French, and the French military, something that no one will ever be able to take away. And if you don't understand what I just said, then I will never be able to explain it to you.

The day after Camerone Day, like the day after Veteran's Day, is a day that I will always manage to get off...because I'll be so hungover that I wouldn't be able to work.

-- An Anglo-American that spent many, many years in the U.S. Army (with a large amount of time being shot at in Panama, Iraq, Bosnia and Somalia).

Re:is there

[plumby]

Unlike the Americans, huh? Did they win the Vietnam war then?

Re:is there

[plumby]

There was no Vietnam war. It was an armed conflict between the US and the Communist influences in the area.

It may not have been declared a war by the US Government, but it was certainly a war as far as the Vietnamese were concerned, and the CIA consider it a war "His study shows that CIA analysts had a firm grasp of the situation in Vietnam and continually expressed doubts that heightened US military pressure alone could win the war."

there was no new expansion into South Vietnam

Huh? So who was streaming into Saigon (now Ho Chi Mihn City - named after the communist leader in the north - might give you a clue) as the US troops fled from their embassy? The entire country has been united under communuist rule since 1975. Or are you suggesting that there was no new expansion outside of Vietnam, such as in Cambodia, where the Vietnamese invaded in 1978 to fight the US-supported Khmer Rouge. (you might want to read "Heroes" by John Pilger for eye witness accounts of both events)

And are you seriously claiming that the US achieved their objectives in Vietnam? They must really teach you some strange things at school over there.

Re:is there

[jayed_99]

I'll skip the obligatory "though I never respond to an AC comment"...

The other two conflicts that I mentioned, WWII and Vietnam also result in the French having their asses handed to them. Let's not forget Algeria, either. If you take Napoleon out of the equation, there is a litany of stories that basically end in "...and the French got smacked down yet again."

What I wanted to point out is that France can lay claim to one of the most stunning, impressive, damn near unbelievable examples of "dedication to duty" that the world has ever seen. It's up there with the Alamo...and as a native Texan, indoctrinated from birth, I don't say that lightly.

Camerone is a shining example of dedication and a refusal to quit. So, the next time that you have a performance review...or the next time you need to convince your manager that you really *do* need a new server...remember Camerone Day! :)

what's it good for?

[brandonfpu]

as perl started out great for scripting stuff and has grown, java started out with the promise of write once, run anywhere, what is eiffel's main strength according to it's developers (any users out here?)

Re:what's it good for?

[_Spirit]

Forced OO, at least that's what I remember it by. It's good for teaching OO, as you *have* to do everything in an objectoriented manner.

Re:what's it good for?

[edhall]

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

-Ed

Re:what's it good for?

[J. Random Software]

Funny you should mention that. Eiffel's the only language I've seen that actually gets boxing right. Any class can be "expanded" when declared or even used, and then it's transparently handled by value instead of by reference.

Re:what's it good for?

[sporty]

How about ruby? I don't know what comes first, but ruby, you can do stuipd things like 1.toOctalString( ) or the equiv :)

Re:what's it good for?

[kingkade]

I'm pretty sure C# does this as well. In Java, if I remember correctly, they're boxed automatically or at least some SDK utility methods do it automatically. But they're immutable, which combined with no convenience in operator overloading becomes clumsy to work with, IMO.

Re:what's it good for?

[_Spirit]

It's been a while, but that sounds familiar.

Re:what's it good for?

[Jucius Maximus]

"Heh, like Java. Well, almost. You have to box some primitives."

It is possible to write something in Java that should be OO but it's instead done all in one class. I've seen CS students that were first taught basic C and then Java become totally lost with this multiple files, multiple objects thing. They tried to write all these tree objects, nodes, linked lists, etc all into one class file with their main program. They just didn't get it.

If it is true the Eiffel forces OO, then it would probably be a good tool for teaching such confused souls how they should take advantage of OO. Once you get it, it can be a time saver because you don't have to send pointers to the moon and back, and you don't have to deal with pointers to pointers to pointers to ... Of course I still become squeamish when I want to write int a[n];. If you were brought up on C, you know why ;-)

Re:what's it good for?

[edrugtrader]

writing valid code.

it has pre and post conditions BUILT IN to the system. so it isn't like a comment or an if statement in the function, you say, this function only accepts x if it is between y or z... or any number of boolean statements... if it fails, the system fails. it makes your code very solid.

Re:what's it good for?

[antis0c]

What's it good for? Choice.

If we didn't have a choice in languages we'd all be programming in our respective processors assembly. :)

Long Live mov!

Re:what's it good for?

[the_mystic_on_slack]

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

Re:what's it good for?

[g4dget]

One of the things people should learn about OOP is when not to use it. If you force them to, they'll end up using it inappropriately.

Re:what's it good for?

[jerdenn]

C# does having boxing support for its 'primitive' types...
-jerdenn

Re:what's it good for?

[HiThere]

What's it good for?

It lets you ensure that the program you write does what you intend. (This is called Design by Contract. It works better than any alternative I've encountered.)

It manages multiple inheritance and limited generics in a way that C++ can't even try to approach. (Ada can do it, but it's a lot more work.)

And despite what has been said earlier, it isn't a memory hog during compilation. Not compared with the current competition. (Unless you are comparing it with C, of course.)

It's got a built-in garbage collector. Many languages do now, but it was quite unusual at the time, and it's still one of only a few compilable languages (excepting gcj == java) that have a gc.

It's got a good documentation system. Better than javadoc. (But the presentation isn't as nice unless you purchase the ISE development platform...which I don't recommend.)

Re:what's it good for?

[IdleTime]

Ehhh. Eiffel studio is free?

Their webpage quotes the price as follows: Pricing for the Windows and Linux versions of EiffelStudio is US$ 4,799.00.

I have a problem understanding how $4,799=Free. Please explain!

Re:what's it good for?

[one9nine]

Two Editions

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

Re:what's it good for?

[larry bagina]

I have a problem understanding how $4,799=Free. Please explain!

gnutella, eDonkey2000, DirectConnect, Kazaa, your local warez BBS, etc. etc.

Re:what's it good for?

[larry bagina]

if it fails, the system fails. it makes your code very solid

So it's good if eiffel does it, but bad in Windows does it, right?

Re:what's it good for?

[J. Random Software]

Ruby seems to always box anything other than nil, false, true, and fixnums. In Eiffel and C++ (and C# within limits) you can choose whether to store user-defined types by reference or value; the cost rarely matters but sometimes it's crucial.

Re:what's it good for?

[J. Random Software]

C# has structs (expanded classes) and can box them to pass as a reference to System.Object or an interface, but they're kind of brain-damaged (no default ctor) and you have to copy and paste any type you want to use both by reference and by value, since neither the class nor the struct can inherit from the other.

Java makes you do it yourself (which a few convenience methods do), and other than simple string conversions, the common wrapper classes are useless--you have to choose some primitive type and unbox before you can even do math!

Re:what's it good for?

[joto]

The number 1 reason to use Eiffel is DbC (Design By Contract). Best explained as assertions on steroids. Obviously inspired by use of formal methods in academia.

Secondly, Eiffel is a reasonably clean OO language, with a mostly sane syntax, and it has GC. It is mostly the C++ model of OO (class-based, static typing, multiple inheritance is heavily used, focus on efficiency, etc...). Whether you prefer this, or something a little bit more mainstream, such as Ada is of course up to you, but DbC is a real winner.

Re:what's it good for?

[mentin]

You can do this in C# too:

1.ToString();
"abc".Substring( 1, 2 );

Re:what's it good for?

[TrixX]

Eiffel strength:
I don't have debuggers installed in my computer and no need for them since I use it.

Good enough for you?

Re:what's it good for?

[auntfloyd]

and it's still one of only a few compilable languages (excepting gcj == java) that have a gc.

There is nothing special about a "compilable language" (whatever that means) using GC. Lisp has been doing it for decades (and yes, most Lisp systems are native code compilers, such as CMUCL, Allegro, CormanLisp, SBCL, etc). Oberon-2 compilers use GC, including the open source OOC and Oberon System3 from ETH. Ada was designed such that GC could be implemented, but it rarely is. Many FP languages use GC, such as Haskell. Haskell compilers, such as GHC, NHC, and HBC all use GC.

If you haven't gotten the point yet, there is nothing special about implementing languages using garbage collection, and furthermore, there was nothing innovative when Meyer decided to use it for Eiffel.

Re:what's it good for?

[auntfloyd]

It was Ada that practically invented generics back in 95

Ada has had generics a lot longer than since 1995. They were in Ada83, the first standardized version of the language. Ada didn't get "full" object-orientation until Ada95, perhaps that is what you confused it with. It is interesting to note that Ada started with generics and added objects later, while C++ started with objects and added generics later.

Re:what's it good for?

[scrytch]

DBC: It has preconditions, postconditions, and class invariants. Am I missing anything astonishingly revolutionary here?

It has multiple inheritance ... How about a meta-object protocol? Or multimethods at least?

I do hear the FFI to C is supposed to be nice ... to the point of just importing the DLL and calling C functions like they were in eiffel. How's the C++ FFI?

Is there anything in Eiffel that makes it just plain feel better to use? God knows the ISE platform turned me off to Eiffel within about 15 minutes of trying to use it...

Re:what's it good for?

[HiThere]

Sorry. I keep forgetting LISP. Your point is well taken, but the commercial lisps are vilely expensive, and the open ones haven't been useful enough for me to use them. (Not that they don't work, but they don't easily work for what I do. Also, I don't like macros, even Lisp macros. But it does have a nice inheritance structure.)

Re:what's it good for?

[HiThere]

If you were turned off within 15 minutes, then you didn't learn it. ISE has a really nice development environment. Unfortunately, it has some really foul copy protection, so it breaks whenever you upgrade your system. And the documentation specifies the type size in a way that made it totally unreadable until I went in and hand edited the CSS specs.

I can't recommend ISE, despite the quality of their product. Other features make it quite undesireable.

DBC: You're missing check, and a few minor things. And some really dicey choices.

One problem with the exceptions is that they MUST be handled within the routine that detects them. Usually this is desireable, but occasionally it's impossible. If you detect them, you can handle them and then retry the routine. Nice. Except when you can't really handle them, because you can't propagate an exception, only an error. I've occasionally been reduced to dividing by zero in order to get the error to the routine that could handle it.

The FFI is nice, but it's not as nice as that in Ada or PL/1. It's more like the one in Python.

Nice language

[_Spirit]

I learned OO programming in Eiffel. It's nice and structured. Never made anything useful with it though, compiling was cumbersome (Eiffel > C > binary) and it was impossible to do any GUI stuff with the tools I had back then (95 or so).

Re:Nice language

[Per Wigren]

There are Eiffelbindings to at least GTK+, wxWindows and Fox widgetsets.. There are also bindings for OpenGL, SDL, Xlib and more if you want to do other kinds of graphics-programming...

Re:Nice language

[Aerog]

Are you sure you weren't just using EBench for a win32 environment? Talk about the motherlode of all crappy programs. I picked up EStudio and NetBSD in less time than it took to make EBench work. Which leads into the obvious comment, EStudio is a fantastic program for Eiffel. So much more intuitive than EBench.

Re:Nice language

[_Spirit]

When I learned this we only had a compiler that worked on solaris. We didn't have a fancy IDE or GUI toolkit. I don't remember what compiler we used but the tools we had were an eiffel compiler vi and gcc. Not really intuitive if you've never seen c code before ;-) (I did mention this was in 1995 or so, did I ?) I think with tools such as the one in this article it would be better suited for classes such as the one I took then. We were supposed to learn Eiffel and OO programming, not fiddling around with c makefiles, which is what we ended up doing. Ofcourse when we started in c++ after that, the fiddling we did seemed trivial.

This is news to me.

[ThogScully]

What's the amazing thing about this code and what are its faults? I can't find much info on their website. Some sample code to look at would be really nice just to get a feel for it. Is there a feature list somewhere? A comparison to C/C++/Java?
-N

Re:This is news to me.

[g4dget]

As a language, SmartEiffel is similar to Java or C#, but it has language support for genericity, operator overloading, multiple inheritance, lexical closures, expanded types, and pre/post-conditions. Eiffel's syntax is more similar to Pascal (probably the most annoying part of Eiffel's syntax is that you cannot declare variables at the point of first use).

What SmartEiffel lacks is good support for dynamic loading and reflection. Those are crucial features for many real-world applications these days, and given SmartEiffel's compilation strategy, they'll be very difficult to add.

SmartEiffel's performance was disappointing last time I benchmarked it--Sun Java beat it handily on equivalent problems. In principle, given its compilation strategy and static semantics, SmartEiffel should be able to yield very high performance code.

Holy cow, it's piggy flying time

[Johan Veenstra]

Eifel is simply the best language I ever saw on paper, and I looked at quite a few languages for my study.

I never imagined I could ever download a free compiler to actually compile the programs I jotted down during exams.

Re:Holy cow, it's piggy flying time

[berenddeboer]

You probably are not interested in an answer, but anyway: with SmartEiffel and boost mode, your hello world is probaby around 4-10KB or so. Quite comparable to C.

ISE Eiffel, a commercial implementation, if you compile hello world in melted code, the binary might be MB's. You can read about the advantages of melted mode on ISEs website. But if you freeze it, it's 160KB.

Read this post:

http://groups.google.com/groups?dq=&hl=en&lr=&ie =U TF-8&selm=3DDF4E65.6933E52B%40ifrance.com

It's just not Perl

[Shamanin]

"easy-to-read, easy-to-learn" ... and you think people who prefer perl obviscated code would really buy into something with these sorts of (negative) attributes?

Re:It's just not Perl

[Dom2]

Funnily enough, but the reason that I prefer perl over most mainstream languages (barring Python) is the fact that it's by far easier to read and understand what the code is doing. Larry Wall's background in linguistics has payed off handsomely.

Of course, there's a lot of bad perl out there. There's a lot of bad C, C++, and Java too. Yes, yes, I know you don't write any, but that doesn't mean that it's not there.

-Dom

Why?

[Anonymous Coward]

Maybe Eiffel's underratedness has something to do with it following the functional programming paradigm? Most programmers are still used to more conventional coding. I'm not saying this is a rational argument against the language itself, but when you want to get things done, you use the tools you know best.

Re:Why?

[J. Random Software]

Eiffel is a typically imperative OO language. It's not built on avoiding side effects, higher-order functions, lazy evaluation, or currying, which are hallmarks of modern functional languages.

Re:What is it?

[Johan Veenstra]

Then this link is for you:

http://archive.eiffel.com/eiffel/nutshell.html

Re:Who needs all these languages?

[zapfie]

Any computer program can be expressed in C... why bother with crap...

Yeah, right.. while we're going down that slope at all, any computer program can be expressed as machine code, so why bother with assembly, C, VB, or any of that? Why bother with Photoshop when you can just do stuff pixel by pixel? I think you get the point..

helloworld in Eiffel

[caternater]

For those, like me, wondering what Eiffel looked like, here is helloworld:

class HELLO_WORLD


creation
make
feature
make is
local
io:BASIC_IO
do
!!io
io.put_string("%N Hello World!!!!")
end --make
end -- class HELLO_WORLD

This was taken from http://www2.latech.edu/~acm/helloworld/eiffel.html

Also, this interesting tidbit from the comp.lang.eiffel FAQ:

QEIF: What is Eiffel?

Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software.

Eiffel is not a superset or extension of any other language. Eiffel strongly encourages OO programming and does not allow dangerous practices from previous generation languages although it does interface to other languages such as C and C++. Eiffel supports the concept of "Design by Contract" to improve software correctness.

Beyond the language aspect Eiffel may be viewed as a method of software construction. Eiffel is an excellent vehicle for software education, including for a first programming course.

(http://omicron.felk.cvut.cz/FAQ/articles/a511.htm l)

Re:helloworld in Eiffel

[boy_of_the_hash]

Based on intrest in Eiffel, wouldn't this be a better example?

class GOODBYE_WORLD

creation
make
feature
make is
local
io:BASIC_IO
do
!!io
io.put_string("% N Goodbye World!!!!")
end --make
end -- class GOODBYE_WORLD

Re:helloworld in Eiffel

[g4dget]

Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software. [...] Eiffel supports the concept of "Design by Contract" to improve software correctness.

Of course, those are merely claims. Sure, Eiffel is almost certainly better than C/C++ in terms of reuse and correctness, but then, what isn't? But is it better than Java, C#, or O'CAML? Or Python, for that matter? Where is the experimental evidence to support those claims?

Eiffel strongly encourages OO programming and does not allow dangerous practices from previous generation languages although it does interface to other languages such as C and C++.

By now, Eiffel itself is, in a sense, a "previous generation language". The baseline these days isn't C or C++, it's languages like Java, C#, and O'CAML.

Re:helloworld in Eiffel

[ThogScully]

This is the first I've ever seen Eiffel code. Maybe it's just me, but I thought this review said it's supposed to be easy to read? I can't identify what half of those lines of code are for - I can identify the two lines that actually outpue Hello World, but even that would have been hard in a different example.

What's the point of this language again? I thought it was to combine the power of C/C++ with the ease of VB or something.
-N

Re:helloworld in Eiffel

[eyepeepackets]

#!/usr/bin/wish;puts stdout "Hello World!"

You can now rename your example to HELLO BLOAT!

Re:helloworld in Eiffel

[HiThere]

That's unfair. For one thing, Eiffel is a compiled language. For another, those don't all need to be on separate lines. And for the third, hello world doesn't represent the operations of any resonable program.

That said, Eiffel does suffer from name_length_inflation due to it's prohibition against overloading.

Re:helloworld in Eiffel

[evilviper]

echo Hello World
HA! Take that!

Re:helloworld in Eiffel

[Per Wigren]

You can't judge a language from "hello world", that is just plain stupid..

Eiffel is designed to write large bugfree object-oriented applications, not short "one-timer" scripts...

Re:helloworld in Eiffel

[Al Al Cool J]

That's what you think. I just created a new language called HelloWorld in which every program outputs "Hello World" by default, unless the first line is the special SuppressHelloWorld command. So now you can do a Hello World program in 0 bytes!

Top that!

Re:helloworld in Eiffel

[TrixX]

That's unnecessary. This compiles in my SmartEiffel:

class HELLO
creation make
feature make is do
print("Hello World!%N")
end -- make
end -- class HELLO

Anyway, Eiffel has morea dvantage for bigger systems. Code reduction in the large beats by far the verboseness in the small of the language.

I do all my "large programming" in Eiffel (and for small things, i.e. less tahn 50 or 100 lines i use C, Pascal or Python, depending on the job) (or Bash, for very short things).

It's not "the ultimte language for solving everything", But it's great to managing complexity. (and getting it right)

Re:helloworld in Eiffel

[jerdenn]

That's too funny!

-jerdenn

Re:What is it?

[SlowMovingTarget]

Eiffel is an object-oriented programming language designed to be replete with O-O-ness (no, really). For example, their are no primitives in Eiffel, everything is an object. Eiffel also has a singly-rooted hierarchy and garbage collection (like Java) and parameterized classes like C++.

Unlike Java, Eiffel syntax was designed to also act as a specification language of sorts, including syntactic support for contract specification.

Bertrand Meyer's book Object-Oriented Software Construction explains problems in modern software development, examines how object-orientation probably could solve them, then designs such a language. This language turns out to be Eiffel (sorry for the spoiler if you intend to read this > 1000 page book).

One of the points Meyer demonstrates is how a syntax to describe groups (classes) of solutions gets fleshed out into actual software that may execute. Eiffel, being that syntax, among other things, was intended to make you think in terms of types of objects sending messages to each other to get work done.

That said, I use Java. Why? Apache's Jakarta project.

Regards,

M. Murphree

found some more links

[EccentricAnomaly]

I don't know Eiffel, but I've heard of it... here's some useful links that I've found:

Why Eiffel: http://www.elj.com/eiffel/why-eiffel/
Other lins (including tutorials): http://www.cetus-links.org/oo_eiffel.html

I wonder what is meant by all of this "Design by Contract" stuff... I'm not sure yet if this is something useful, or just more buzz-buzz.

Re:found some more links

[SlowMovingTarget]

At its heart, Design-by-Contract is an API description mechanism (think assertions). For any given method on a class, you specify what must be true in order to call it (preconditions) and what it guarantees will be true once it has finished execution or has errored out (postconditions, exceptions).

In Eiffel, however, this kind of specification is given some heft in terms of compiler support. Design-by-Contract is especially useful when defining an interface between code bases (IOW: public APIs). DbC gives client programmers of a class insight into how to call the class, and gives the language a way to enforce and check for that.

Re:found some more links

[J. Random Software]

It's also an optimization hook. If the compiler can prove an assertion is fulfilled (because another assertion didn't fail, the caller's passing a value that's obviously correct, or nothing used in the invariant was modified) it can skip the machine code to check it.

Functional?

[jefu]

"functional programming paradigm" ?

Unless things have changed substantially in the last few (um) time-units-of-your-choice, Eiffel is Object Oriented, not Functional.

I've not codes much (only a few KLOC) in Eiffel, but it is a very nice language with lots of help for producing programs that run. My biggest problem with it was that it tended to be a bit on the verbose side.

Re:Functional?

[Nutello]

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

Re:Functional?

[Kashif Shaikh]

My biggest problem with it was that it tended to be a bit on the verbose side.

You mean like COBOL(*ducks*)?

Re:Huh?

[thebatlab]

The point of all these languages is, yes, to give choice to programmers on what to use. Eiffel doesn't do low level so you wouldn't want to code up a device driver in it. C doesn't do high level so mapping a design to C *could* be more work than mapping it to Eiffel. This is like asking why new cars? Lets just improve on the old ones we have. You want to be driving in a model T? A 300 ZX is a lot better :) I know the analogy isn't perfect but it's a starting point ;)

Eiffel = enormous memory hog still?

[myowntrueself]

When I was at Auckland university we used to dread when the guys doing the stage 3 OO programming course got an assignment.

I once saw 12 of them running the eiffel compiler each instance of which was absorbing over 100M of virtual memory on, as I recall, old DEC unix boxes...

This was back in 1993 so as you can imagine (with relatively limited amounts of RAM and VM in those days and in a relatively small and underbudgeted department) the whole system came to a grinding halt for everyone else. Heck, I couldn't even read usenet news and opening a smallish text file to edit in emacs took around 10 minutes. Which, for vi devotees, *is* unusually long even for emacs ;)

I think they went home for the weekend to leave their compile processes running, meaning that the rest of the comp.sci facility could barely use the unix servers for the duration.

Eventually, as I recall en-masse eiffel compiler processes were *banned* and they were told to spread out their compilation processes over a few days (ie not all 12 students at once).

Since the assignments were weekly this caused problems. I believe they turned to an alternative OO language. I wasn't doing the paper so I don't know which one.

Some infos about Eiffel

[DarknessInBlindingLi]

For those who are unfamilar with this language (I fear most of the /. crowd) here a basic overview of its advantages and problems:

Eiffel is a language with an minimal instruction set (sometimes refered to as RISC language), which is used mostly in environments that emphasize reliability and dependability. It's small instruction set (e.g. there is only one type of loop) make it easy to learn and understand but is taking away some of the fun of coding. Most of the work you put into an eiffel project is to find the right approache, because you don't have too many ways to implement stuff. Here in Europe it's used in mostly academic environments that like the grace of its simplistic approace and its 100% object oriented design.

Tradeoffs of this language are its high compilation time, as Eiffel source gets translated to C and then into a native form, the scarcity of available system libraries and the lack of dynamic features as shared objects and stuff.

If your going to invest some time in this language, a look at those open source projects might be worthwhile:
eposix - POSIX bindings for eiffel
gobo - a collection of tools and libraries to unify the development of applications on diffrent Eiffel compilers
mico/e - a CORBA ORB in Eiffel (DISCLAIMER: I am involved in the development of this project)

Re:Some infos about Eiffel

[thebatlab]

"which is used mostly in environments that emphasize reliability and dependability"

So true. I hear that a major stock trading application was made using Eiffel as it was the best tool for their needs. Kind of tells you something when a stock trading system uses this pretty much unknown language b/c of it's reliability. Design by contract anyone?? :)

Information on Eiffel

[Anonymous Coward]

Eiffel is awesome! Here are some of the most obvious benefits:

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

To learn more about Eiffel, read this and this and this and if you still have time, this.

Also, check #eiffel on freenode (irc)

Eiffel is the best,
DM

Re:Information on Eiffel

[thebatlab]

> Design by Contract (dbc)

Definitely one of, if not the, best part of the langauge. Others have tried to tack it on as an afterthought but it just didn't pan out well enough.

> Multiple Interitance

Is a great help but used incorrectly it can be a major downfall. I've even seen the libraries that my former university developed using multiple inheritance when it should have been single inheritance and then an instance within the class of the other type. Also, things get tricky when ambiguous situations arise although Eiffel provides all you need to disambiguate them.

> Static typing

There is somewhat of casting with the =? syntax (or is it ?=) though again, it does improve on the idea of casting. If you get a null back, the cast was unsuccessful and you carry on your merry way doing what your program should do after a failed assignment attempt. It's nice to know that your attempt failed right away than having to do a check other than object != Void

> Dynamic binding

Most OO languages do this so it's not really a benefit of the language so much as it is that if they hadn't included it, it would be the worst OO language ever ;)

Re:Information on Eiffel

[Doomdark]

java: int, Integer -- what the **** is that supposed to be good for?

Performance. To get same level of performance from boxed primitives as 'native' primitives, compilers and VMs need to do more work. Nothing impossible, but originally Java was KISS - oriented language (auto-boxing would make it bit simpler to use, but more complicated internally).

As to multiple inheritance... I don't quite see how you think interface makes anything into a semantic problem. The thing interfaces are missing (from MI) is the default implementation, and that's a practical, not semantic problem?

Eiffel is not a new language

[Earlybird]

• Why is everyone gung ho on creating new programming languages.

Eiffel is not a "new programming language". It's nearly twenty years old, invented in 1985 by Betrand Meyer, and a damn well-respected language at that.

Historically Eiffel has probably had more success in influencing other languages and in teaching software construction principles, than actually being used for commercial software projects, although it has seen some popularity in the finance sector. Lately, like certain other niche languages, it has seen its popularity further eroded through the emergence of Java.

Re:Huh?

[Jerf]

Real people don't depend on "teachers" to learn.

I was going to say "Real hackers don't depend on teachers to learn languages", but that's just a very isolated special case of the general principle.

If you honestly don't know anybody using something other then COBOL, Java, or a little C++, you are horribly, horribly disconnected from several exciting communities dedicated to increasing the power of the programmer. If you don't know the why multiple languages are useful, that is a grevious flaw in your education that you need to take immediate steps to rectify, and nobody's going to do it for you but you. Moreover, I don't mean to be offensive but you're so far behind you won't even understand the explanation of why you're behind; you need to be in the position of having used a couple of languages before you can understand comparisions!

Language differences are nothing like the difference between kde and gnome; it's more like the difference between GUI and CLI.

Don't wait for someone to teach you; you can't afford to while you're competing with people like me who know at least 10 languages well and can pick up a new one in a week (and I'm nothing special). I strongly suggest you rectify your ignorance.

'Course, if you don't, and you want to keep your attitude, no skin off my nose. That much less competition for me.

(*chuckle* I wish I could see you in an interview situation where someone asks about the differences between languages and you gave your post as the answer. They might not even bother to finish the interview.)

The whole point of this is you shouldn't be waiting for somebody else to look around for you, but here's some hints anyhow. I strongly suggest you spend a few months each on Perl, Python, a functional language like Haskell, and several APIs of some sort, like wxWindows or XML parsing. That's more educational then you might even think directly, since you'll get introduced to event-driven programming (though you may have seen it in Java), handling complicated data structures in general, and a lot of other useful things, not just "XML processing" and "GUI development". All of these things have great, free tutorials online.

serious limitation

[g4dget]

C, C++, Java, C#, and Objective-C, have extensive support for dynamic class/code loading and manipulating objects with types not known at compile time. These are crucial features in modern systems and applications programming languages because many modern software systems are built out of dynamically loadable components and have plug-in architectures. Support for these features is probably at the core of the success of these languages.

Java and C# are particularly interesting in this regard because they not only support dynamic class/code loading, they also support it safely and with full reflection. That's really the future.

SmartEiffel, on the other hand, takes a static, global program analysis approach to compilation and optimization. It provides almost no reflection or dynamic loading (if you compile to JVM, you may be able to rig something up). I think ultimately, that makes it a fairly unattractive choice for many applications. Even the commercial Eiffel systems only had those features retrofitted over the last few years, which probably accounts in part for the very limited success of Eiffel as a language.

SmartEiffel is a really great concept, and for some niche applications, it is very useful (I have used it for some prototyping). I would very much like to see a safe, batch-compiled language catch on for Linux system programming as an alternative to C/C++. But I just don't think SmartEiffel is it, at least not yet.

Re:serious limitation

[HiThere]

What I'd like is a version of Eiffel that both captured the flexibility of Python, and could link transparently to Static Eiffel for efficiency. But I'm not holding my breath. (On the other hand, I've seen this promissing language that appears to blend Python and C in a smooth manner. That holds much promise...but it's C, not C++, or Ada, or even Java. And I'm also contemplating Pizza for use with gcj...but it's not clear to me how calls are made between Java and C/C++ code. O, tempores, O documentation!)

Re:serious limitation

[g4dget]

On the other hand, I've seen this promissing language that appears to blend Python and C in a smooth manner.

I find the blend of Python and C anything but smooth: the Python C API is complex and error prone, and once you load a C module into Python, all bets are off when it comes to safety.

What blends very nicely is Python and Java: the mix is secure and safe and Python objects appear as Java objects and vice versa.

What I'd like is a version of Eiffel that both captured the flexibility of Python, and could link transparently to Static Eiffel for efficiency.

That isn't sufficient: that kind of mixture, in which only the Python-like part is dynamic, imposes too many restrictions on the static part; it basically means that all the efficient code remains inflexible, and all the flexible code remains inefficient.

While Java and C# have lots of warts as languages, I think their kind of runtimes are the future. If you don't like the Java or C# languages, you can use compilers like SmartEiffel to compile for those runtimes (although I think SmartEiffel itself is still not quite flexible enough for even that to be all that useful).

Re:serious limitation

[TrixX]

You are comparing C++/Java/etc. to SmartEiffel. That's comparing apples to oranges.

Compare C++/Java to Eiffel (languages)
Or gxx/javac to SmartEiffel (compilers)

Yes, the SmartEiffel compiler lacks now the ability of dynaamic loading. But nothing in the languaage itself discourages it (and actually, it would be very natural). So it's just a matter of time for getting it implemented, not a design flaw of the language (like C++ way of handling multiple inheritance or templates).

In fact there are (non free) Eiffel compilers supporting what you want.

Re:serious limitation

[HiThere]

I can't remember the name of the language, but it's routines were directly callable from Python. (Also, I believe, from C.) It could directly call either Python or C.

If you declared a variable with a type, then it created it hand handled it as if it were a C variable of the declared type. If you didn't declare a variable, then it would be created as a Python variable. Etc.

I never actually used the language, so I don't know whether or not it acutally worked. And I can neither remember it's name, nor locate the web page where I saw it described. Well, if it works, it will surface again. Even if it only works moderately well, this should be important enough to gain attention and support. But it might have been only someone's first design steps. I can't really say.

As for the future... it won't be Java or C++. I don't yet know C#, but I don't believe that will be the future, either. I think the future will be some language that partially compiles Python. Perhaps it will link to C, or it might be smart enough to just replace C (not a good chance, be possible). Note that I said "Paritally compiles". If Python were turned into a static language for the sake of efficiency, then it would loose many of it's most important features. If it isn't, then it will be too inefficient for many purposes. So what's needed is a compiler that can compile the parts that can be fixed at compile time in an efficient way, and interpret the rest at run time. It will, inevitably, result in large run time libraries, but a "Hello, World" in MS Access already takes up over 5MB. (I actually remember it as being 10MB, and I'm refusing to believe it.) The way to handle this is to have shared-versioned libraries so that common code doesn't need to exist in multiple copies. (This is already done, so I'm not proposing anything new here.)

Sather

[jefu]

Eiffel is a nice language, but for me the best part of Eiffel is that it spawned Sather.

Sather started as a free subset of Eiffel but then transmuted itself into a related but very different language.

Sather had great support for procedural pre and post conditions (not the aftermarket cheezy afterthought kind of thing that some languages seem to want to adopt), class invariants that could be automatically checked on call and return of a "public" method, class based iterators (not cursor classes, but built into the class itself), constrained genericity, simple (and relatively restricted) overloading ("a + b" became a.plus(b)), unboxed objects and so on....

Without formally measuring it, I'd guess that writing three more or less equivalent programs in Java, C++ and Sather would result in Sather having the lowest LOC count and the fastest development time. Though the tradeoffs were sometimes odd, good pre/post conditions saved me huge amounts of debugging and testing time, but required quite a bit more up front thought on what those conditions were - this resulted in much better code, but sometimes required interesting amounts of redesign.

Sadly, Sather, while still available here is GNU Sather is no longer being developed or supported AFAIK. Were I more of a compiler maven I'd work on it, but I doubt my efforts as a compiler writer would improve things much.

Re:Sather

[Animats]

I was a Sather fan once, and knew Steven Omohundro, who invented it. But it hasn't gone anywhere. Sigh.

In language design, we've pretty much settled on C syntax for executable code. No new language with non-C executable syntax has gone very far in the last 15 years or so. Python acceptance is held back by its indentation/no semicolon style, even though it has many good ideas.

On the other hand, we're still struggling in the declaration space. The current declaration syntax in C++ is a mess for historical reasons.

Re:Sather

[Daniel Phillips]

In language design, we've pretty much settled on C syntax for executable code. No new language with non-C executable syntax has gone very far in the last 15 years or so. Python acceptance is held back by its indentation/no semicolon style, even though it has many good ideas.

I'd call that wishful thinking. My unscientific observations suggest Python continues to grow exponentially, and there is Basic (not all dialects are as broken as VB) which still has a huge mindshare. Actually, a quick look into my crystal ball shows me fewer semicolons in the future, not more.

Re:IN SOVIET RUSSIA

[EggplantMan]

.... almost self-debugging language!

How can something be almost self-debugging? This stupid horseshit was obviously injected into the description to generate interest in something that is otherwise unremarkable.

Re:Huh?

[Waffle Iron]

What the hell is point of all these languages. I'm still learning cobol in college right now.

People create new languages in the hope that a lucky few won't be damned to program in COBOL all of their lives.

Not another one!

[pla]

Damn, people, can the collective computer geeks of the world *please* pick some sort of "standard" language (or at least a very small set of languages, like perhaps C++ for most things, Perl for scripts, and Tcl/Tk for GUIs)?

I personally like C. I consider myself fairly good at it. But honestly, I don't care if we decide "Everyone must code in Forth". Just *some* sort of standard. I'll learn it, and feel happy to "waste" a year mastering it, just to never have to learn another "fad" language.

I see people asking why Eiffel doesn't have more popularity - Why? I can answer that *really* simply. Because we already have too-damn-many languages to choose from!

Yes, a *FEW* choices make sense, because not every language has the same strengths and weaknesses. But really, how many people research all 250+ "major" existing languages to determine the best for each and every program they write? No one. People pick a language that has a lot of general-purpose power and flexibility, and *ONLY* deviate when their first choice literally cannot accomplish the task at hand.

Put out efforts toward making a few projects truly great, not having a huge number of mediocre projects.

Re:Not another one!

[ken_mcneil]

Put out efforts toward making a few projects truly great, not having a huge number of mediocre projects.

Obviously you don't get why people create programming languages in the first place, or most of the open source software for that matter. They do it "just for the hell of it" or to "scratch an itch". Their goal is not to take over the world with a massive project to create the language to end all languages. In fact, the idea of working on a massive project full of documentation, debugging, and huge libraries may not appeal to them (not the cast for SmartEiffel of course). They just wanted to experiment with somes ideas they've been throwing around.

That brings up my second point...experimentation. How are you supposed to come up with the "truly great" projects without messing around for a really long time. It is impossible for someone to just sit down and pull the ideal programming language for any given problem out of their ass.

Re:Not another one!

[lpontiac]

But honestly, I don't care if we decide "Everyone must code in Forth". Just *some* sort of standard. I'll learn it, and feel happy to "waste" a year mastering it

It shouldn't take a year to learn a language. Of course, with some monsters (I'm thinking C++ here), that's a problem with the language.

As for a "standard" language, most people already have settled on C++ and Java for most things, and Perl for scripting.

Re:Not another one!

[buggered]

In the past 25 years I have programmed in Assembler (for about 2 dozen different architectures), Fortran, Algol, Pascal, Bliss, Ada, Lisp, C, C++, Java, Perl, Python, SmallTalk, and probably some others that I can't think of at the moment. During that time I have always wanted something better. While Eiffel is not perfect, I can say that it comes the closest to my ideal language of any I have ever used.

I have found that Eiffel programs are very easy to debug (because of the "Design by Contract" the problem usually pops right out). Sometimes I have even had non-trivial programs work correctly the FIRST time!

When I have been working on C++ programs, it sometimes takes days or even weeks to find some of the problems. Most of the time in Eiffel I can find the problem in seconds or minutes. Rarely have I had bugs that took longer than an hour or two to find.

If I had to pick one programming language to use from now on it would be Eiffel.

Re:Not another one!

[CFN]

Hey, I really cannot understand your animosity towards the development of new languages. At the very worst, you can are free to bury your head in the sand, ignore their existance, and go on with your life. At the best, this might be the perfect tool for you to do your programming with.

Now, there are very good reasons why a programmer, even someone who will never in their career look at something other than C, benefits from this work.

Computer Science is a continually evolving field (thats why universites have CS departments, filled with people doing research in CS). Because some computer scientists study programming languages, programming languages are evolving as well. This means that researchers keep introducing new and different features into new languages.

Of course, the vast majority of these new languages never become popular (or ever get used for even a single real program), but this collection of ideas influences more "mainstream" language. Things like classes, type-safety, generics, etc., all began as research ideas and then migrated into production systems. (Of course, Eiffel is well beyond the research language phase).

So even if you never adopt a cutting edge language, eventually, a tool you use will exist, or have been made better, because of that language.

Point is, instead of bitching you should be appreciative.

Re:Not another one!

[Peaker]

My set would be:

Python for anything that doesn't require performance.

C for the rest.

My own Lisp variant for everything (when I get time to implement it, ofcourse :)

Now, use any set you like and quit bitching :)

Re:Not another one!

[HiThere]

Personally, I don't see how anyone can take a language with the kind of unsafe type casting requirements that C has and think that it's a suitable general purpose language. A portable assembler, yes. That was what it was designed for, and it does the job quite well. And C++ continued all of C's flaws. Intentionally. They originally wanted all C programs to be valid C++ programs with the same meaning, which meant that they couldn't fix anything.

With Java I still have complaints about the rampant casting requirements.

Python would be a good choice if it were faster. Ditto for Ruby. (Don't know Perl.) Etc.

Eiffel is another "nearly good enough" language. It's faults are that it can't be dynamic (in the manner of Python and Ruby), and it prohibits overloading of operators. Bad move. Tends to mean that you need to come up with several new names for functions that do the same thing just because their arguments are slightly different. So, e.g., there is no generic length operator.

But, depending on what you are doing, Eiffel may well be the best choice available. Or not. (And, unfortunately, the edges are sharp. If it's not a great choice, it's a terrible choice.)

Re:Not another one!

[be-fan]

I find that Windows users have the same problem when moving to Linux. They see so many features and scream "I need structure!" If you're finding the same problem with languages, just do what I tell those Windows people to do. Pretend no other languages exist and just use one. I'd even be happy to help you. You *must* use BrainFuck. No more options. Now, bend over...

Seriously, though, just because all these languages exist, there's no need to *learn* all of them. Just survey a variety of them and pick the ones that suit you. Personally, I use C++ for systems level stuff and Python for everything else. I'm looking into learning Prolog for AI type stuff. The important thing is to learn one or two in each catagory, and if you ever need the others, you can pick it up quite quickly.

Re:Not another one!

[Doomdark]

Yeah, I don't understand the popularity of screwdrivers... Why can't we all just get along and use hammers for getting screws installed, TVs fixed and kids disciplined! Why waste time and resources on developing and learning how to use multiple tools?

Re:Not another one!

[Daleks]

(read parent first)

Damn, people, can the collective musicians of the world *please* pick some sort of "standard" genre (or at least a very small set of musical styles, like perhaps rap, rock, and r&b)?

I personally like rock. I consider myself fairly good at it. But honestly, I don't care if we decide "Everyone must listen in rock". Just *some* sort of standard. I'll listen to it, and feel happy to "waste" a year listening to it, just to never have to listen another "fad" genre.

I see people asking why polka doesn't have more popularity - Why? I can answer that *really* simply. Because we already have too-damn-many musical styles to choose from!

Yes, a *FEW* choices make sense, because not every style has the same strengths and weaknesses. But really, how many people research all 250+ "major" existing genres to determine the best for each and every song they write? No one. People pick a style that has a lot of general-purpose power and flexibility, and *ONLY* deviate when their first choice literally cannot accomplish the task at hand.

Put out efforts toward making a few bands truly great, not having a huge number of mediocre bands.

Sometimes you people scare me, seriously. You have nothing without diversity.

Re:Not another one!

[nagora]

But honestly, I don't care if we decide "Everyone must code in Forth"

Well, that gets my vote.

TWW

Eiffel also has .NET support

[jerdenn]

Eifel also has plug in and compiler support for Microsoft's .NET initiative. It's pretty cool, actually, because although .NET does not have support for genericity in V1.0 (though it's planned for v2.0), Eifel.NET has overcome this limitation and allows for multiple inheritance and other cool stuff. Take a look here.


There's also an MSDN article.

-jerdenn

Re:Eiffel also has .NET support

[HiThere]

Eiffel# when last I heard had many of the most appealing parts of Eiffel stripped out. Unless it's been radically revised I wouldn't recommend bothering with it.

There's lots of languages that have been shoehorned into the .NET environment. Most of them suffer seriously for the exercise. Don't judge any of them by their .NET versions, and don't assume that your favorite language is available on .NET just because theres something with a similar name (even if it's by the original language creator). If you really like a language, you might want to examine the specs of the .NET version to see if it still has the features that you prize. But don't just assume that it will.

Re:Eiffel also has .NET support

[jerdenn]

Eiffel# when last I heard had many of the most appealing parts of Eiffel stripped out.

That's a pretty bold statement, but you've backed none of it up. What are the "most appealing parts of Eiffel" that have been stripped from .NET?


-jerdenn

Re:Eiffel also has .NET support

[Admiral Akbar]

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

Re:Eiffel also has .NET support

[HiThere]

Nice! When I last heard it they had removed, e.g., multiple inheritance. And I had also been under the impression that DBC had been restricted. It's good to hear that they got back in. Eiffel without multiple inheritance isn't Eiffel, and full DBC is one of it's main benefits.

If Eiffel# is really a full Eiffel (I haven't checked yet), and it's really as easy to get from language to language as promissed (again, I haven't checked yet), then Net may be worth looking at seriously. There's still the problem (for me) that none of the really dynamic languages support net (Python and Ruby are what I'm thinking of here), but if full Eiffel is reasonable, then that is only a matter of time.

Since you asked...

[eyal_bd]

Yes there is an example in the distribution. Just go to the example directory and compile.

Re:Huh?

[MeanGene]

People create new languages in the hope that a lucky few won't be damned to program in COBOL all of their lives.

No - people create new languages so that they can get new grants to do something that has already been done before... :-)

Eiffel versus Java

[hazzzard]

I've used Eiffel quite a bit;
actually, I was a TA in a class that used Eiffel.
Being an experienced Java programmer also,
I would say that:

• Eiffel's syntax is a matter of taste. However, no matter what taste it is very clean and easy to learn, but sometimes trades this beauty for inefficiencies that ruin your daily life. For example, the semicolons between statements are completely optional, so you can write a:=1; b:=2 or a:=1 b:=2. This does not make the language ambiguous, but it means that you can only catch very few syntax errors at a time (usually, parsers can skip erroneous statements and report syntax errors even after them). The compiler we used to work with (ISE's Eiffel Bench) actually reported only one error at a time which was at some random place in the code. Just imagine the experience of writing a bigger piece and then trying to compile it.
• What I liked about the language is its consistency, especially in the library. The standard library is a textbook grade collection of container classes and there are standards for naming things. For example, to retrieve something you will always use the function 'item' and not like in Java get, getItem getElementAt and so on. This is at least useful if you don't have an IDE that shows all the possible functions while you are typing.
• Eiffel has full generics. This even includes bounded genericity, so you can do things like a sorted list of some sort where the sort has to be a subclass of Comparable. This rocks, especially when you compare it to the weak generics that Java is going to have.
• Full multiple inheritance, even with renaming functions. A matter of taste but it can be useful.
• Some features of Eiffel are debatable, one of which is covariance for parameters: This means that if you override a method in a subclass, you may make its parameters more specific. This means that you can get dynamic type errors even though the system is mostly statically checked. Also, you can throw out a function when you are inheriting, which also may lead to dynamic type errors. In practice, this won't hurt you (and can even be useful), but hardcore type system people can become upset about it.
• Overall, Eiffel is a great language for philosophers. In practice, Java is more convenient and even though it's not as consistent and pure it has a more useful library (I don't mean the collections but the other things it comes with). Another aspect is that Sun's Java licensing is nicer than ISE's (Bertrand Meyer's Company). Be careful with them, they are cooperating with the evildoers and integrating Eiffel into .NET.
• Even though some language features are debatable, there is a great book available that I would even recommend to non-Eiffel folks: Bertrand Meyers OOSC.

Re:Eiffel versus Java

[Daniel Phillips]

the semicolons between statements are completely optional, so you can write a:=1; b:=2 or a:=1 b:=2. This does not make the language ambiguous, but it means that you can only catch very few syntax errors at a time (usually, parsers can skip erroneous statements and report syntax errors even after them).

The usefulness of this is highly overrated. It harkens back to the days when programs were punched on paper card decks and you had to stand in line to submit your compile. You'd better catch as many syntax errors on each run as possible, for sure. But when you have fast compiler turnaround and tight integration to an editor, the equation shifts strongly in favor of one-at-a-time error correction. Simply put, the cursor should land on the first error, which you can typically correct in a few keystrokes, and resubmit. Your eyes never leave the source file.

This way of working is a *lot* faster than sifting through lists of error messages, where many errors often cascade off an early one. The time you spend analyzing such dependencies is 100% wasted. It's also annoying to have to keep shifting your eyes between the source code and the lists of error messages. Anyone who can keep concentrating on the original problem (i.e., not the syntax errors) while doing this is a freak mutant alien.

The compiler we used to work with (ISE's Eiffel Bench) actually reported only one error at a time which was at some random place in the code. Just imagine the experience of writing a bigger piece and then trying to compile it.

Ehh? I have worked on huge programs with one-at-a-time error messages, I don't have to imagine it. It's a far more efficient way to work, regardless of project size. It does depend on tight integration with the editor though, which for some inexplicable reason, is still not treated as a high priority by most developers.

The ideal system would always give you the first error in tight-editor-integration mode, and continue looking for more in the background while you are busy editing. That's what excess cpu cycles are for, right? On the rare occasion you're interested in more than one at a time, you can look at the full list.

Re:Yes another one!

[pHDNgell]

You pick your set, I'll pick mine. C++ is hopefully getting ready to die. It's just not pleasant to use. I'm also waiting for the day when the world wakes up and realizes the cruel joke Larry Wall played on it with perl. While some of my most crucial application code is written in C, I've spent more time on it, and trust it far less than stuff I've thrown together in Eiffel.

At home, I've got code I rely on written in Java, Eiffel, C, Objective C, python, bourne shell, smalltalk (although the smalltalk code that I actually use the most I didn't write), tcl, scheme, etc... I've got some perl stuff, too, but I don't maintain it anymore (it asked me not to). This is just the stuff I use day-to-day, and much of it is server code I've written that just runs on its own (Java, C, python, eiffel).

So, that's my set. Anyone who disagrees, make up your own set, continue to research and find better ways to do things, and help us continue to improve computer science in general. Every time I learn a new programming language, I learn a little more about programming, and apply that knowledge to everything I do.

Eiffel is not a functional programming language

[g4dget]

Eiffel is about as far from being what is referred to a "functional programming language" as any language can be. Until recently, Eiffel didn't even allow you to manipulate functions or methods as data. Eiffel should feel right at home to any Java or C# programmer: it's a fairly simple statically typed object-oriented programming language with multiple inheritance and genericity.

I think Eiffel's lack of success has to do with some serious problems and limitations in the early design of the language, which have only been addressed in the last few years in the main commercial Eiffel compiler. And SmartEiffel does not even implement the full, commercial Eiffel system.

Re:Yikes! an $80 book

[berenddeboer]

I found it really good. It's about what an ideal OO programming should look like. It asks and answers lots of questions. Well written.

Yo listen up, here's a story....

[cybermace5]

"About a little guy that lives in a blue world
And all day and all night and everything he sees
Is just blue
Like him inside and outside
Blue his house with a blue little window
And a blue Corvette
And everything is blue for him
And himself and everybody around
Cause he ain't got nobody to listen

I'm Blue da ba dee da ba daa
I'm Blue da ba dee da ba daa"

Well, Microsoft DOES have an Eiffel plugin for .NET! Any guesses what song rights they will buy, when they launch their new standard development language?

Re:Yo listen up, here's a story....

[sinserve]

Ooh man, you're bringing back memories :-)

I heard that song the first time -EVER- I got laid. The DJ was playing it
for my high-shool prom party.

Ahhhh, those were the days. I miss year 2000.

Re:Yo listen up, here's a story....

[sydb]

Ahhhh, those were the days. I miss year 2000.

So I'm guessing that was the last time you got laid, too?

Price of Eiffel's IDE

[majordomo]

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

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

Re:Price of Eiffel's IDE

[majordomo]

The IDE is free only for non-commercial use...

Re:Huh?

[Hornsby]

I strongly suggest you spend a few months each on Perl, Python, a functional language like Haskell, and several APIs of some sort, like wxWindows or XML parsing.

I agree totally. I just wanted to chime in and say that while you're out checking out new languages, give Ruby a try. It's a beautful language that falls in the same family as Perl and Python but has it's own charm all the same. I use it for all of my development in an environmental lab, and it's served me quite well.

If you want to explore functional programming, you also may want to check out SML.
There are several free implementations available, and it's easy to learn. It's very fast and quite powerful for a variety of tasks. Last but not least, check out ANSI Lisp or at least Scheme. Everybody serious programmer should know at least one dialect of Lisp because it's the original hackers language.

I believe ESR did a rant somewhere on how to become a real programmer or something along those lines. Google could probably dig it up rather quickly. It's worth a read as he outlines languages to learn to explore the various development methodologies(functional, OOP, procedural, etc).

Bertrand Meyer, originator of Eiffel

[Lucas Membrane]

Read OOSC. IDK if it's good or bad, technically, but it's a very entertaining read for a software book. Meyer is a human electron, going through the sage, zealot, and crackpot slits all at once in a fairly convincing style, mixing in witty asides that make you think that the average sermon would be a lot better if he had become a preacher.

He derives all the properties of Eiffel from first principles, convincing you that everything has to be this way or it would be a big mess. But then, you find out that Eiffel has this problem of CATcalls, ie changing availability of typos or something, and thus Eiffel also has serious skeletons in the closet down where it smells bad. Is he the Goedel of software? You be the judge.

open source gui/database project for SE ..

[elj]

The ELJ project - http://elj.sourceforge.net/ has been successful in providing much needed multiplatform libraries to SmallEiffel/SmartEiffel developers.

The wxEiffel GUI library provides a comprehensive interface to the wxWindows GUI. Database interfaces to Firebird, sqlite, berkeley db, mysql, postgres.

There are even libraries for Regular Expressions and for those who like the perl way of doing things - see Perlish.

The 0.5 release announcement in comp.os.linux.announce gives more details. The ELJ project is undertaking the necessary work to move from SmallEiffel to SmartEiffel.

There are many other open source Eiffel projects:

• GOBO - lex, yacc, xml, data structures, date/time libraries and
• eposix which aims to provide a a 100% complete Eiffel binding to Standard C and POSIX.

Eiffel has come a long way over the years. Misconceptions still abound. You can now develop multiplatform applications using open source Eiffel tools and libraries. There are small hurdles to jump as there are with anything. Give it a try and become involved if there is something about Eiffel which you find appealing.

Some generally unknown facts about Eiffel

[name_already_in_use]

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

- Compilation is not so slow anymore.

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

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

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

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

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

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

Re:Some generally unknown facts about Eiffel

[Lucas Membrane]

OK. It's wonderful. Where's the list of success stories -- big projects that have used Eiffel with these new tools and are big successes? There were a few claimed successes in years past, a pension fund here and there, embedded software for printers. But the list was short and didn't seem to be getting many new entries.

Better yet, where are the jobs? This language is around since 1985, and I just ran a search on www.dice.com for Eiffel jobs, and I turned up 1 job that might or might not really be an Eiffel job. Considering PL1 turned up 21 and awk 38, Eiffel's not a smash hit.

Bug in Eiffel Design

[Tom7]

> Some features of Eiffel are debatable, one of which is covariance for parameters: This means that if you override a method in

It's good that you mention it, but I wouldn't say this "feature" is debatable, it's just wrong. The only way they can recover static safety with this bug is to do whole-program analysis! If they really want to take a structured and pure OO approach to programming, I think it's important to have a consistent theory, not to just provide features that "seem" to be intuitively useful. (But have some serious consequences...)

FWIW, Java makes a similar mistake in treating [] as a covariant type constructor. This means that in general they have to do dynamic class checks on every array access! Eiffel is mostly a better-designed language than Java, in my opinion.

Eiffel sucks compared to Smalltalk.

[crovira]

So does Ada, APL, C++, J++, Java, Perl, PL/I, Set-L, and Simula (used them all & Basic, C, COBOL, JCL [I know, that doesn't realy count] & RPG,) and a whole bunch of language I have only seen the EBNFs for. (Okay Occam was & is in a class by itself. It must get lonely)

Now Smalltalk ain't perfect. It has a few major blind spots (specially concerning object relationships and instatiation in context,) but it has everythig else beat.

Try Squeak ( http://www.squeak.org ) and once you , uh, "get it," come back to anything else... You'll go YUCK!

Re:Eiffel sucks compared to Smalltalk.

[BitwizeGHC]

Try Squeak ( http://www.squeak.org ) and once you , uh, "get it," come back to anything else... You'll go YUCK!

Squeak is fun, but I always come back to Scheme...

AC?

[SuperKendall]

No joke, Mr. "AC". Evildoers is about right, and I'm using a real username to say so (where do YOU work, eh?).

I can't find the link for it but frankly I think Eiffel# has sold out and made some very disturbing concessions that cripple the language. From the looks of things, any # version is going to be a one-off of C# (the only truly native # language), and it's pretty much a one-way path to migrate users of language X to C# itself (especially as they will have to use C# libraries to do much useful work, and calls form most other languages are going to be more awkward). When I read of Bertrand Meyer's support of Eiffel# months ago, my first thought was "that's a shame, I rather liked Eiffel. Too bad it has to die this way".

Calling a spade a spade does not make one bratty, to borrow your acidic parlance.

Use TinyCC with SmartEiffel!

[Per Wigren]

If you're going to code in SmartEiffel, you should try using TinyCC instead of GCC while developing! TinyCC is an extremly fast and memoryefficient ANSI-C compiler that is 100% compatible with SmartEiffel! TCC generates code which is about as fast as "gcc -O2", but compiles almost 1000 times faster than "gcc -O2"!! I know these figures look unbelievable, but they are authentic! Just try it yourself if you don't believe it!

oggy gexace # time gcc -O2 -o gexace-gcc gexace.c
real 10m12.746s
user 9m33.227s
sys 0m4.897s
oggy gexace # time tcc -o gexace-tcc gexace.c
real 0m1.353s
user 0m0.472s
sys 0m0.061s
oggy gexace # ls -l gexace-*
-rwxr-xr-x 1 root root 1216938 Nov 29 18:27 gexace-gcc
-rwxr-xr-x 1 root root 994200 Nov 29 18:27 gexace-tcc

The gexace.c examplefile is from GOBO, generated by SmartEiffel and is about 2MB...
When your program is ready to be distributed you can compile it using "gcc -O3 -mcpu=i686 -fomit-frame-pointer -ffast-math" or similar to make it run ~10% faster, but compilation may take hours instead of seconds...

Re:Use TinyCC with SmartEiffel!

[Daniel Phillips]

try using TinyCC [tinycc.org] instead of GCC.

Thanks for that. I grabbed the source, which fails to build (on linux) with:

tccelf.c:382: `RTLD_DEFAULT' undeclared

Supplying the missing definition gets it to build, then I was able to get it to self-compile just by supplying a -I to the gcc headers and a symlink to the build directory for the libraries (I like it when I can evade sudo make install easily). Yes, it's instantaneous.

It's a recursive-descent one-pass compiler, i.e., inline code generation, as you might expect. There's little or no register optimization and no discernable global optimization, again as you might expect, so it's a slight exaggeration to say it generates code quality near the level of gcc -O2. The compile speed would way more than make up for this in the vast majority of development situations.

Without inline assembly or support for gcc's weird array of special attributes, you couldn't compile much of the kernel with this, but maybe with a little tweaking you could compile module code.

I'd like to see somebody take on the challenge of a tiny two-pass C compiler, with an intermediate parse tree. How much bigger would it be? Not much, and the extra time to build+traverse the tree would likely only add 20-30% to compile time, leaving it still several times faster than gcc (ever more so vs gcc 3.x). This design would open up the field for 'tiny global optimization', which would be fun to see.

time gcc -O2 -g -Wall -m386 -malign-functions=0 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc_g tcc.c -ldl

real 0m8.833s
user 0m8.120s
sys 0m0.140s

time bin/tcc_g -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc_g tcc.c -ldl

real 0m0.502s
user 0m0.430s
sys 0m0.040s

Re:Use TinyCC with SmartEiffel!

[Daniel Phillips]

Oh, to be fair:

time gcc-2.95 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl

real 0m3.058s
user 0m2.680s
sys 0m0.060s

time gcc-3.2 -Wall -m386 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl

real 0m5.991s
user 0m4.620s
sys 0m0.050s

i.e., tinycc does the job 6 times faster than gcc 2.95 does, and 12 times faster than 3.2. The tcc-compiled tcc takes 45% more time to compile itself than the gcc-compile version:

time bin-tcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl

real 0m0.521s
user 0m0.460s
sys 0m0.000s

time bin-gcc/tcc -I/src/tcc-0.9.14 -DCONFIG_TCC_PREFIX=\"/usr/local\" -o tcc tcc.c -ldl

real 0m0.360s
user 0m0.280s
sys 0m0.030s

Note: there's 4-5% variation in the various timings due to cache effects.

Fernando Poo question:

[smittyoneeach]

limited generics in a way that C++ can't even try to approach.
Can't believe a five-digit user number is trolling, so could you expand on this point, por favor?

Re:Fernando Poo question:

[smittyoneeach]

I guess my understading of STL is way off. Assuming a hierarchy of objects, with, say,

class vehicle {};

class sedan : public vehicle {};

class van : public vehicle{};

I thought you could say

std::vector<vehicle> carLot;

and put all of the sedan and van objects you want in the carLot... Admittedly, I've done more with composite classes than inheritance in C++, so I'll lay by my dish now...

Re:Fernando Poo question:

[HiThere]

There are many nice features. Others have mentioned templates, and I must admit that I'm not real familiar with them, so perhaps they do provide a way to do part of what Eiffel does. But:

Eiffel allows you to rename the procedure during the inheritance.
Eiffel allows you to inherit twice from the same class, with renaming used to prevent collisions. This allows two "instances" (not really. We're talking class definition time here, not run time.) of the same class to be used in ways that are quite different.
Eiffel allows you to undefine methods during inheritance.
Etc.

Eiffel's inheritance is nearly as flexible as Python's, and considering that Python classes can be modified at run time, that's quite a trick. (Well, Eiffel doesn't quite accomplish it, but it comes close.)

Re:Fernando Poo question:

[J. Random Software]

STL's templates work because they're completely generic. What you can't do is write a template whose type parameter must be a class derived from vehicle (so you won't call similarly-named methods from unrelated classes by mistake).

Why not a GCC frontend?

[AxelTorvalds]

I don't want to compile something in to C and then into object code. Why not an eiffel front end for GCC?

Re:Why not a GCC frontend?

[J. Random Software]

It looks like the SmartEiffel compiler proper is already GPL'd. Is redistributing the other files under GPL not allowed?

Sather-K

[haruchai]

This may be of interest to you.
http://www.info.uni-karlsruhe.de/~sather/dl. html

I can't say how much development is being done on this as my German is very basic but it doesn't seem to be a dead project.

It's not about using all the languages!

[Fefe]

It's about learning a new point of view, it's about expanding your horizon.

I don't use Eiffel, but learning it taught me some concepts I didn't know before.

And that's why we need even more new languages. Life (and work) is about learning. If you stop trying to learn you might as well drop dead.

Free Linux version of EiffelStudio

[Admiral Akbar]

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

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

more french slander

[solferino]

Yes, but since Eiffel is French, it's called the Towers of Dien Bien Phu and bails out after 3 recursions.

more french bashing by (i assume) an american poster which is moderated up on a site which has a largely american readership

why is this constant painting of the french as cowards so supported by americans? is it perhaps because france is one of the few countries that doesn't kow-tow to american imperialism?

i try to seperate the actions of the american government from the general american ppl, believing that they are as much victims of the corrupt machinations of the said government as the rest of the world, however constant puerile slandering of non-americans such as this causes me difficulty in maintaining my discrimination

in case you were wondering : i am australian of anglo-saxon cultural background

Re:more french slander

[Sivar]

Not unlike they did for us in our early history.

The U.S., of which I am a citizen, is the only country in the world which has decided to make itself the world's police force.
Defending other countries is bound to happen in-between oil rescues and terrorist witch-hunts.

France, BTW, is one of the most self-sufficient countries in the world. The coordinate system used to display graphics on your monitor was invented by the French philosopher and mathematician Rene Descartes--also the creator of analytical geometry, the precursor math which made Calculus possible.

Why don't you try to not portray Americans as ethnocentric, poorly educated bigots, because that reputation is passed along to more people than yourself. I am sure that was not your intention, but intention and interpretation are often completely different.

Re:more french slander

[maxpublic]

Well, the French might not be cowards, but according to a recent study they have less sex than any other Western European country. Certainly doesn't do wonders for their reputation as lovers.

Guess that's a load of hooey too.

Max

Re:more french slander

[jejones]

We just think french ppl are stupid, and rightly so.

<sarcasm>Yup...Cauchy, Galois, Laplace, Poincare, didn't none of 'em know diddly.</sarcasm>

Re:more french slander

[DrXym]

Nonsense. The US is only the world's police force when it is in its own interests to be. There have been plenty of conflicts where the US has conveniently looked the other way or marginalised its involvement when the region in question isn't rich in oil or strategically important.

As for other people not policing, that too is nonsense. Lots of countries including neutral ones such as Ireland send peacekeeping forces under the UN flag, as well as NATO forces. Even the likes of France has troops in Africa doing peacekeeping work at the moment.

Re:more french slander

[ecloud]

The coordinate system used to display graphics on your monitor was invented by the French philosopher and mathematician Rene Descartes

Figures. If it was an English-speaking dude at least it would have been a first-quadrant coordinate system rather than fourth-quadrant.

Why

[litewoheat]

While trying to, in any way to be a prick... Why is Eiffel cool? Where would it be an alternative to Java/C++? Serious replies (if any) please...

Re:absolutely nothin'

[jejones]

You forgot the "HUH...Good God, y'all!"

I can feel the carpal tunnel pain already...

[aquarian]

Damn that's a lot of typing!

Programming Environment for Eiffel

[willamowius]

For a nice IDE for Eiffel you should get the Eiffel extension for the SNiFF+ environment

http://www.willamowius.de/eiffel.html

There are free versions of SNiFF+ for projects up to 200 (?) classes which should be ok for starters.

Re:What is it?

[joto]

It's exactly the opposite in fact! ObjC is weakly typed, Eiffel is strongly typed. And the added safety of DbC makes it even more so...

Re:This is more of a philosophical issue ...

[J. Random Software]

Presumably that generic can only be used with shape or derived classes. That way when you call foo you know you're getting an override of shape's foo rather than some unrelated method with the same signature.

Re:Yes another one!

[pHDNgell]

You like C, but not C++? Bwaaa haaha ahhaa ahaaa.

I don't like C, but I occasionally write apps in it. I don't mind objective C. I don't understand why someone must like C++ just to like C, though.

Re:Yes another one!

[scotch]

Well, if you like objective C, then you obviously like to do things in an object oriented fashion. C++ makes this much easier to do than C, so I don't understand why one is acceptable and the other isn't

If you write large scale programs in C, you'll eventually find yourself inventing ways to handle things that the C++ language does for you. C++ does them better and makes it easier on the programmer.

If you're just writing small things in C, you can always do the same thing in C++ (almost a superset, and all), but even there, C++ provides some features that can make some small programs much easier to do.

What about threading?

[RockyJSquirel]

Last time I checked (years ago), the Eiffel's garbage collector didn't handle objects shared between different threads.

Does anyone know whether this was fixed and/or how what SmartEiffel's garbage collector is like?

Rocky J. Squirrel

Speed

[0x0d0a]

For a "modern", safe language, SmartEiffel produces very fast code. I don't know of any other imperative language other than C and C++ that beats it.

Re:Speed

[rplacd]

Both the free and commercial Dylan compilers produce code that reaches C/C++ speeds.

Dylan is OO from the ground up, and supports a variety of programming styles, including fp, inperative and, of course, oo.

Re:Huh?

[0x0d0a]

If you're trying to churn out useful software and not do research and want to learn ML, you may prefer Objective Caml to SML.

I really *hate* type inference, as it makes debugging a pain, and SML/NJ, the SML I learned on, has absolutely atrocious error reporting.

On the up side, it's quite an eye opener if you've never used a language with really strong typing.

Precisely

[0x0d0a]

This is very true.

If we went by the "hello world metric", Perl would probably be consider the best of all programming languages.

From what I've heard, the majority of eiffel developers do very large software applications.

Re:This is more of a philosophical issue ...

[plumby]

OK. I think you're wrong (or I've misunderstood you). The C++ STL (standard template library) works by type, not by method signature, e.g.,

vector <Shape> coll;

declares a variable called "coll", that contains a vector which can only contain objects of type "Shape". It does not allow any object that has the same methods as "Shape" to be included, just ones that are actually derived from "Shape".

K & S

[jefu]

For real fun, everything can be expressed using only S and K combinators. See unlambda (just one of many references).

Now there's a language that needs a .net binding. But even so there are others that need integration with .net first. Primary among these (of course) must be INTERCAL especially the revised version with the "COME FROM" statement.

Re:Huh?

[joto]

Why is everyone gung ho on creating new programming languages.

Because it is fun, mostly. But also because different languages shape our thoughts in different ways, and can be used for different purposes.

What the hell is point of all these languages.

Solving problems. See above.

I'm still learning cobol in college right now. I'm off to Java next, and will barely learn C++.

Good for you! You have already decided to stop learning once you are out of college. I applaud your decision, please remember to tell any future employer this before he hires you, so he can save your salary!

This is like gnome and kde, and for everyone who's gung ho about replying "these are what gives us choice ", free is free people the only thing different between kde and gnome is the developers, they're all just trying to be another mac os/windows clone.

No, they don't. Wine is trying to be a windows clone. While most of GTK and Qt is obviously inspired by other WIMP-environments, that doesn't mean that they are trying to be windows clones.

I disagree

[jtdubs]

Actually, you can judge a language from it's "Hello World." The books How to Think like a Computer Scientist comment on this as well, not that I endorse those books.

A "Hello World" program demonstrates very clearly how "simple" a language is. How much syntax and how much structure you have to use to get even the simplest of things accomplished. It also usually demonstrates the difference between an optionally interpreted language and a purely compiled one, as compiled languages, on average, tend to require use of more syntax to get up and running.

As an example, Java.

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

It's hello world program involves both a class definition and a method definition. Neither of these things are relavent to the goal of printing a string, but Java makes you go through the motions anyway. Java forces you to use OO for even the simplest of problems, and this much is evident from looking at it's solution to the simplest of problems, printing a string.

Perl, Python and other optionally-interpreted languages tend to be far simpler to bootstrap, allowing for things such as:

print "Hello World!"

However, this syntax makes you use a function to print the string, evidence of an imperative language rather than a functional one in this case. Although, to be fair, Python is very 'functional' and actually can do without the print statement. In a functional language in which you deal with expressions rather than statements, all values are self-evaluating and allow for "code" like the following in most functional languages:

"Hello World."

This string, being a value, evaluates to itself in most functional languages including, Python, Lisp and others, and results in the value being displayed back to you. If you want to be pragmatic about it, as this code won't do anything if compiled in a functional language (most of 'em anyway), you can change it to something like:

(princ "Hello World") ;; lisp
or
print 'Hello World' # python

This throws back to the notion of function calls, which are evidence of compilation in the case or most functional languages.

You can learn a lot about a language from looking at it's Hello World. Mainly it simplicity, or lack there-of in the case of languages like Java or, yes, Eiffel.

Eiffel makes you digest concepts like class creation and features (methods in this case), along with a whole lot of syntax, to accomplish the simple goal of printing a string.

The main problem with any syntax being forced on you, aside from making it more difficult to parse, is that it limits the languages flexibility in a practical rather than theoretical sense. You could practically never write a macro system as astoundingly powerful as the one found in most Lisp dialects in a language like Java or Eiffel. Too much syntax. Not enough closure.

While having a lot of required syntax won't prevent a language from being good at real-world tasks, in fact quite the contrary for reasons I won't go into here, it does limit it's simplicity and, in my mind, beauty.

Justin Dubs

What I would like to know is...

[henshin]

Why should we use it?
Im not trying to be a smartass by any means, or discredit the "ease-of-use" etc etc. I program in c (Windows and Linux) because it is widely used, and widely supported. Will this become ..dare I say.. mainstream? There are plenty of languages out there with plenty of advantages and applications but what does this bring to the table? Do any of you think this will be the next c/perl/php/?

Eiffel (& SML)

[C A S S I E L]

Eiffel is a very underrated language in the free software community for some strange reason..

One possible reason might be (correct me if I'm wrong) that for a long time, Eiffel was supported by a single vendor with a closed-source, commercial, proprietary compiler. Who is going to commit to a brand new programming language with a single vendor?

From this point of view, an open-source compiler is ideal. Perl and Python are effectively single-vendor (i.e. single development team) but at no risk.

Aside: at the time (commercial) Eiffel first appeared, we were working on a Standard ML language and compiler (in fact there were several different development teams building compilers, since the language had a formal semantics and definition). The New Jersey compiler was open-source from the start (around, oh, 1987?), and was self-compiling, generating native code for 680x0, Alpha, Vax and Mips architectures.

This was around the time that OO programming was getting trendy, and SML, despite being very-high-level, strongly-typed, memory-managed, having a superb modules system etc., wasn't really OO and so fell out of fashion. It's still around, though, and still being developed (see the link above).

Re:This is more of a philosophical issue ...

[J. Random Software]

That's just instantiating a totally generic template--it'll work with any type that has default and copy ctors and assignment.

Suppose you wanted a homogenous collection that's aware of the semantics of class shape. bounding_box<rectangle> and bounding_box<ellipse> should be allowed but bounding_box<company> should not, even if they all happen to have location() and size() methods. In C++ you can't specify that instantiating the template for a class that isn't derived from shape is an error, without some ugly circumlocutions.

Re:This is more of a philosophical issue ...

[Ayende Rahien]

template
class ShapeArray
{
};

Re:This is more of a philosophical issue ...

[Ayende Rahien]

template <bounding_box<shape> T>
class Bar
{
};

Opps

[Ayende Rahien]

Should be:
template <shape T>
class ShapeArray
{
};

Re:Opps

[J. Random Software]

That declares a template whose parameter is a value of type shape, not the name of a type derived from shape. And it's only allowed if shape is an integral, enum, pointer, or reference type. Class instances can't be template parameters because the linker can't be expected to call operator == to determine which instantiations are equivalent and should be merged.

Documentation?

[Cro Magnon]

One problem with a niche programming language is finding good documentation for it. Is there a good resource that tell you everthing you want to know about the language? Preferably online & free (beer), since there's almost zero chance of ever using it on a job.

Re:This is more of a philosophical issue ...

[J. Random Software]

That doesn't do anything to prevent you from instantiating bounding_box<company>.

Self selecting samples.

[TheLink]

Sure the Eiffel coders did better. But that's a self selecting sample right?

It's likely that the average befunge programmer would do better than the average programmer on many tasks, but that doesn't make befunge a good language ;).

Yeah Eiffel sounds good. Design by Contract sounds good - independent ways of constraining what a program can do = higher chance of it doing what it's supposed to do and only that.