Slashdot Mirror
Eiffel as a Gnome Development Language ?
Thomas Delaet writes "
This article is a short evaluation of Eiffel as a language for developing the core gnome desktop platform. Last month, there has been a heavy debate about a successor for C/C++ as the language of choice for developing the core gnome desktop components in. The debate has mostly focussed around C#/Mono and Java. This article tries to summarize the different requirements for a gnome development language and shows how Eiffel fits in these criteria."
Eiffel, indeed... What are the reasons for switching and won't it be totally painful to switch language NOW? Maybe the article author has been laid off from Ericsson, I believe they used (use?) Eiffel a lot in-house.
Money for nothing, pix for free
The fact that the Eiffel compiler can compile to C or java bytecode is quite interesting. Consider their disparity of features:
-C is not object oriented -Strict ANSI C is very limited as compared to platform-specific functions and libraries -C does not have Java's virtual machine features like garbage collection -C is not strongly typed like Java, nor does it perform all the boundary checks that the Java compiler does
I'm not saying that C is a bad language to program with...it's always about the right tool for the right job. I'm just questioning how the compiler can compile/convert? to both C code (is this compiling to C-source, or converting to binaries?) and to Java bytecode (where you don't need things like deconstructors and memory management built into your code) or Java-compatible class files?
Regardless of this, performance issues are almost always a matter of compiler efficiency. If one were to compare the Intel C++ compiler, Borland's, the Mac compiler, gcc, etc, you will have huge performance disparities depending on what platform you compile to, what compiler you use, etc. In my own limited programming experience, the only differences that can be absolutely noted between languages are when the performance differencies are atleast an order of magnitude apart...Like the benchmarks show sometimes, Java can vary wildly between fast and slow, and the own differences between different C++ compilers an be unimpressive.
------- "From bored to fanboy in 3.8 asian girls" ----------
Digital Mars D currently runs on Linux and MSWind. It doesn't, AFAIK, run on the Mac yet, but there's no intrinsic problem.
I like Eiffel a lot more than C, but I like D better than Eiffel. D is like C++ that got it right. (Well, it was designed decades later, so that's not too surprising.) D links easily with C code. Much more easily than Eiffel does. D doesn't have the wide variety of implementations that Eiffel does. Eiffel suffers from the problem that each compiler comes with it's own set of libraries. (It also suffers from functions not being overloadable, but that's on purpose. Still, I count it as a definite drawback to require different operators to multiply integers, floats, and I*F and F*I -- all require different operators in Eiffel, that that's just the start of the problem.)
I think we've pushed this "anyone can grow up to be president" thing too far.
The person has made very valid points, especially concering politics and "free"dom. But many of the points they made can apply to other languages, such as Ada (easy to read, compiles to C, small syntax set, free compilers, etc..) yet there just aren't enough people using it to make it a good language to move towards.
Don't they just:
1) Code the core stuff in C.
2) Let people that like other languages code wrappers to a well designed API
3) Allow the people that code their user applications in whatever works best for them.
I mean, holy shit! What's the BFD?
"Pointless" exactly sums up my reaction as well. I mean, pretty much every modern open source language fits all these criteria. Obviously, a major factor in the choice of language is how familiar it is to existing developers. Apart from C/C++, the most commonly used gnome language is python. So if at all the choice is something other than C#/Java, it would have to be python.
Sather whomps Eiffel on design and openness.
OCAML whomps all of the above on design and codability.
C# would be sheer madness. Java is excusable
because of GCJ, but if you're looking to maintain
code long-term, OCAML will allow you to avoid
spaghetti objects, where aspects are spread over
50 different classes.
-I like my women like I like my tea: green-
How about it? It's good enough for Apple and it's easily integrated with existing C and C++ code.
And personally, it think it's sort of UN*X-ish in it's attitude. The way you can fiddle with messages almost makes you feel like playing with a UN*X-installation as root.
Furthermore, Eiffel is hardly an open language standard in the same sense as C, C++, or C#; the evolution of the Eiffel language has been driven by Meyer's whims, not by any kind of independent community or standards body. The language definition had some serious problems (requirement for global type checking, covariance, lack of method pointers, etc.), some of which remain. Eiffel could have been a winner, a worthy successor to Pascal and Modula-2, back when those were still fashionable, more than a decade ago before Java, but its proponents blew it big time, both technically and business-wise. Let's not beat a dead horse.
In my opinion, C# is, in every way, a better-designed language than Eiffel, C# has better open source implementations, better open source libraries, better C/C++ interfaces, and more widespread industry acceptance.
I would very much like to see the Objective C bindings for Gnome updated, for it's a very interesting language to develop in. It is simple, elegent, and does not suffer from the featuritis of C++.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
I tried learning Eiffel.
.. so, of what I understood, you are force to debug/test each time you write a new class and function. If your project finishes - your app should be incredibly stable - so no more BugBuddies or CrashHandlers :)
... Java, C# and C++ (specially) just begs for crashing apps.
Really liked the concept, its not that hard.
And definitely much prettier/neater than the grotesque C# (which am not proud to admit is the language I program in most)
Eiffel code is heavily based on structured English, ok it won't go as far as Revolution whose syntax is 100% English.
Eiffel code is very object-orientated but not as bizarre as Smalltalk which vows to be easy but most people finds it the opposite.
Eiffel seems to produce very safe code, because of contracts
Eiffel's code seems like documentation, because of the tags.
Real shame I couldn't play with it more - but seriously, it's just a hunch, Eiffel is a very powerful language. And for many things it can make a difference
I am really pleased to see a major software development community leaving the C-like realm of programming languages. While C is still nice as assembler substitute, I never could convince me that it is useful for general application development. Same goes more or less for C++/Java, though I do not have much exposure to them myself and will try to keep it that way.
There are really neat languages to successfully code nice programs and all the C-like ones are clearly not belonging into that group. Being a Common Lisp zealot I strongly prefer its multi-paradigm style to anything else for most tasks, but I also see the benefit in using OCaml, Eiffel and other languages with way more abstraction than any C-like language so far manages to convey to the ordinary programmer. Having proper closures, and first-class functions, and a not-limiting OO implementation increases productivity by a order of magnitude.
Ok, but one must face reality: As software developer eventually you will have to code something in say Java, but Lispers have now a real advantage: LINJ :-)
For now I can use most of the expressivness of Common Lisp and still can pretend to hack Java.
The time required for STL to be finished really pissed off compiler designers. While C++ was mainstream in the late 80's, it took until 1997 (I believe) until STL was finished. STL was what was touted when C++ was initially released to save everyone from all the printf's, scanf's, strcmp's, etc., in a template fashion (so you wouldn't have to do downgrading or type conversions to get your values to work with your libraries). STL actually has done this, but due to its delay alot of proprietary libraries trying to do a portion of that have been created with MFC probably being the most famous (I'm not talking about its Document/View architecture or windows specific parts). Due to this, compilers even today aren't fully standards compliant with STL, including VCC and GCC. And since microsoft would rather see their MFC be sucessful rather than STL (which is portable), they have no real incentive to make it optimized. GCC has all the reason to, but GCC has always focused more on the systems side of programming (and hence C more than C++). Of course these aren't all the compiler makers, but others have similar reasons. Its too bad, because C++ is a powerful language, but with STL it becomes a very powerful language.
To follow your logic further, there is nothing that any language anywhere offers over assembly other than another layer of abstraction and a longer compile time.
In other words, you have no point.
You might as well argue that there is no reason to use anything other than raw machine code, because after all, that's what everything is ultimately compiled into, so there's nothing that C++ has over machine code "other than another layer of abstraction and a non-zero compile time."
The reason that you don't use raw machine code, of course, is that it's a pain in the ass, and in most cases a completely unnecessary one; not just in the sense that it takes multiple memorized instruction codes just to get anything done, but also in the sense that it makes it much more difficult to understand programs of any size or complexity than it is in a higher-level language, and consequently greatly increases the costs and labor involved in minor details such as testing, debugging, and maintaining. One could (and many have) argued that C++ also has significant deficiencies in these areas, because of non-existence, incomplete or ill-conceived implementations of features such as design-by-contract, exception handling, inheritance, etc.--in which case using a language such as Eiffel to provide a helpful "layer of abstraction" may very well end up producing better code that's more likely to be correct, easier to test, and easier to debug.
Whether Eiffel actually has the virtues often claimed for it, and whether these virtues outweigh its vices compared to other languages, is another question for another day. But the "tidbit" here cuts no ice; it's just irrelevant sniping at a particular compiler implementation.
Java seems appropriate here, if you can get the performance. It's a memory-safe language, and you don't have to obsess on memory management correctness. Garbage collection is acceptable. There's a big pool of Java developers. There's a hard-code open source compiler. Microsoft doesn't control the language or the environment.
Whether the rather clunky Java libraries add negative value is something you have to think about, hard. The language itself is OK.
Eiffel is not a realistic option.
I love Gnome, but I will forever banish it from my system if they adopt Mono/C#. I do not want to worry about how firm the footing is under Mono. It would be horrible to loose Gnome due to such a circumstance. The danger isn't in choosing to adopt it. The danger is in choosing it and it becoming more successful than it's Windows counterpart. Microsoft would be content for it to play a distant second fiddle. If however, it actually surpasses it, we will have "SCO vs. the world" part 2. If it is a core piece of Gnome, bye bye Gnome.
In short, a language which is not Eiffel.
Just want to comment on the memory leak issue. It's a whole lot _harder_ to leak memory in a GC'ed language, but it's still possible, especially when dealing with native interop issues (JNI, P/Invoke, or C-based extensions). Actually, the other major concern is reference issues. As far as I know, if a reference isn't nulled out, GCs often won't pick up the object. Things will still get cleaned up in the end, so the usual form of leaking is basically gone, but memory pressure during execution can get pretty bad.
.Net GCs, so any further comments would be appreciated.
I'll freely admit I'm not an expert on the topic and don't know the exact details of the Java and
Mark Erikson
I've seen this debate brewing for years, and as a developer on other platforms I find it plain silly. For years people around Gnome have said "Oh C, it's great, it is neutral and you can write your own bindings etc." It is quite clear that this is BS because you actually have to write that software with a language, toolkit and architecture that is structurally sound for what you are doing.
KDE solved this years ago by recognising that object-oriented development needed to be done, but at a reasonably low-level so that the base of the desktop environment was compiled natively and ran efficiently. Even at the time this meant C++, but C++ toolkits were never very good at all, even on Windows. That was the rational behind using Qt. This debate ended pretty much on the first day that KDE was conceived!
I laugh really, as the people who have whinged and whined have been proven to be, well; whingers and whiners.
Most of the computer languages that were invented in academia (Lisp/Scheme, ML, APL, Haskell) stayed there and never took off (at least in their original form) as commercial mainstream languages.
Eiffel was invented by Bertrand Meyer mainly for academia to teach the principles of OO illustrated in his book OOSC (Object Oriented Software Construction), and it wasn't driven by commercial needs. Therefore I doubt it will ever take off as a mainstream commercial language.
There's one reason GNOME should use Java:
Sun's Java Desktop runs GNOME exclusively. They will soon be one of the largest shippers of GNOME desktops thanks to WalMart. They already control Java.
Java and GNOME, a perfect match.
I don't know Eiffel that well, and can't judge the fitness of the language itself, but:
- Compiles to language X != As fast as X. Runtime helpers, higher level constructs etc. Eifel might be fast, but compiling to a language considered fast doesn't prove that.
- The language is relatively unknown. This was another advantage of C/C++ and things like Java and Delphi: everybody knows it.
I'm not going to learn a language for Gnome, one for KDE etc etc.
Ok, perl is not exactly everyone's favorite language. But it does have plenty of libraries, and perl6 looks as though it will clean up some problems with perl5.
It definitely does for speed. Testing ponie (a perl5 implementation on parrot, the perl6 generic bytecode engine), I saw at least a 20% improvement on every single test I tried with ponie vs. the official perl5 interpreter.
Don't thank God, thank a doctor!