Slashdot Mirror
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!"
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
I've nothing to say here...
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.
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..
slashdot!=valid HTML
Eiffel is a fine example of a great paradigm which is living in shadow because of programmers' mental inertia. Logical programming could solve many maintenance issues of current software, yet Eiffel is simply ignored.
"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.
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 ;)
These languages are actually very useful in teaching. Everybody who has the slightest interest in programming has at some point looked into C/C++. But an unguided journey into this world can ruin the ability to create maintainable high quality software. That's why it is a good idea to pull students away from the mess that is C/C++ and have them rethink their way of programming in modern languages. Later on they will code C/C++ again, but hopefully the coding style which they learned with cleaner languages will stick.
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.
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.
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.
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 ;)
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
I've nothing to say here...
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.
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.
So it's good if eiffel does it, but bad in Windows does it, right?
Do you even lift?
These aren't the 'roids you're looking for.
I don't want to compile something in to C and then into object code. Why not an eiffel front end for GCC?
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.
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
Top that!
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 should we use it? ..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/?
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
I have acorns.
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).