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.
"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 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.
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.
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.
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!
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.
That's quite a knee-jerk reaction. The C# language and core runtime stuff is standardized - Microsoft can't do anything about Mono using them. The parts that are questionable are the extended base libraries - things like Windows.Forms and so on. But Gnome doesn't need to use those anyway - the core language and bindings for the Gnome libraries is enough, and is safe from Microsoft's meddling.
C# is a very nice language, and the Gnome project would be wise to adopt it. I had my doubts, but I've been messing around with it, and it really is a well-designed language.