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."
I haven't been watching the debate, but surely a top concern is developer pool? C# and Java are both widely used languages, Eiffel is rarely (although not never) seen outside academia. Surely a large OSS project can't afford to be alienating such a large % of the developer community? There is little incentive to learn Eiffel either - even if you don't know C#/Java, learning them will probably increasing your chances of getting more $ at your day gig, but Eiffel?
Read reviews of shopping cart software
I do believe a new language should be used for user applications, but I don't see Eiffel as a contender for a simple reason: syntax. People say they don't care about syntax, but they do. How do you explain the success of Java and C# if not for their C-like syntax? This is why I believe Mono/C# has the biggest chance of winning (also consider the fact that GNOME's big boys (de Icaza, Friedman) are Mono core developpers)
How about a language that people actually know?
C'mon, really, how many people know Eiffel as compared to Java or C#? Really?
Project requirements often dictate the choice of language.
A developer who knows only one language is not a developer, but a one trick pony; a single-purpose tool that is easily replaced with a cheaper, off-shore alternative, for example.
Learning the syntax of a new language should not be a significant challenge to an experienced, talented developer. And, it is experienced, talented developers who should be sought for this project. People who know (language X) and can not adapt to new requirements are not likely to contribute anything innovative, new, or original.
All that said, I don't know Eiffel, nor the particular requirements of the Gnome desktop. If a more popular language fits the bill, great, that's the language that should be used. However, if Eiffel offers particular advantaged, through inherent features not forthcoming in something like C++ or Java, then guess what? A decent developer will eat a book or two over the course of a couple of weeks, and hit the ground running.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
... Of the App. Make a good API, with clean cross-language compatabity, and let the app dev. choice a language that suites the application that [s]he is writing.
Wow, I should not post when knackered.
Look at the most popular current languages:
for "real" programming, we have C and C++. Java really hasn't made much of an inroads (most of its penetration is with compsci students), C# has barely made any impact at all, and that seems to be limited by those developers who are tied to the Windows platform and need to generate next-gen windows apps. Perl's been around for a long time and, although arguably the ugliest damn language in common usage today, is invaluable for website programming.
Considering the advanced features of languages like Java, C#, and hell, even Python, why, do you think, that their update and adoption hasn't been that rapid? You'd figure that if C and C++, with all their quirks, are so difficult to develop with, and time consuming, etc, that developers would jump on these new languages.
Here's what I believe is the biggest reason they don't: they're lazy. It doesn't matter if a language is hard to work with and has difficult syntax. If the developer knows it inside and out, that developer will prefer to use the older, less sophisticated language, regardless of any benefits the new one offers.
------- "From bored to fanboy in 3.8 asian girls" ----------
Why not Eiffel? How about why Eiffel at all? I have never seen Eiffel outside of my CS 101 & CS 102 courses. Seriously, go out and ask other developers what they know or what they have heard of. Chances are people have not heard of Eiffel. Doesn't the GNOME developers want to reach as many developers as possible? The FLOSS idea is that a user may become interested enough to then take a peek at the code. This peek may pique their interests and may eventually become a developer themselves. Doesn't GNOME want as many regular users to become power users to maybe become developers. So what if Eiffel can be compiled to C? Why have another layer of abstraction thus obscuring the picture.
More Do, Less Talk.
If the GNOME developers want more users, want more power users, want more small time developers, then these people have to get interested in the project/platform and must be guided and learn the ropes, or in this case the API. They need to get underneath the hood and understand how it works. IMHO, education, tutorials and documentation would be a great place to start.
However there are increasing signs that various contributers, most notably Novell at the moment, are looking to contribute things to GNOME core that are written in higher level languages.
And there's where the BFD lies. Do you refuse entry to potentially cool technologies because they add another dependency to the platform and/or have a bit more political baggage than C?
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Exactly, that's why there are only 11731 Java projects registered at Sourceforge, which is nothing compared to the 13174 C and 13225 C++ projects. That only makes it the 3rd most popular language for opensource projects. It's just laughable.
And no serious business applications could be written in Java, as we can see by the lack of things like application- and webservers for Java. It also barely has webservices support. If only that J2EE thingy could catch on, Java might have a chance. How could anyone write serious applications with it outside of academia?
If only I could come up with a good sig
If there were a desktop environment along the scale of XFCE or even Blackbox that was actually coded in Eiffel or C# and could be shown to actually be easier to develop for and less error-prone than a C equivalent, then there might be some converts... but someone needs to tackle the implementation problems first before trying to move such a massive program into a totally new environment.
That would be a start. Looking at developer.gnome.org I see a whole lot of unfinished API docs and tutorials from years ago. Bonobo - the component system nobody really seems to use - is hardly documented at all.
Also, finish up Anjuta and make it pluggable so that it is easy to add language support. Make it easy to develop in other languages, and the dominant alternative language will rise to the top.
Look at the most popular current languages: for "real" programming, we have C and C++
Do you have any data to back that up? I would guess that the largest number of programmers write in something like Basic (mostly VisualBasic), most cycles are spent on interpreted languages, and most LOC are probably still in COBOL.
You'd figure that if C and C++, with all their quirks, are so difficult to develop with, and time consuming, etc, that developers would jump on these new languages.
C and C++ aren't necessarily difficult to develop with, they are, however, difficult to develop with correctly. So, lots of C/C++ code gets written, but almost all of it crashes with regularity and has security problems.
One thing that I am sure has enraged many is the lumping of C and C++ together. I programmed primarily in C for about 5 years, and a couple months back learned C++ and now use that as my primary language.
I used to write code in gtk+, and it was quite painful. Function calls look ugly, you are casting things non stop, and constantly finding gross ways to wrap data into a void * which you pass with signals.
I've been writing apps with gtkmm lately and it is practically a sexual experience in comparison. I can write much cleaner apps, and do so much more quickly.
I don't mean to appear elitist, but anyone saying C/C++, and furthermore that they are both finished, sounds like someone who hasn't really used C++. And no I don't mean writing an app with methods instead of global functions, new/delete instead of malloc()/free(), and replacing char * with std::string (in C++ you use char * all the time! std::string is another entity altogether); no no no I mean using C++ paradigms (I'm _not_ talking about OO--C++ has a plethora of interesting methodologies which result in extremely fast and safe code (we're not just throwing exceptions and building abstract class heirarchies every time we want to move a bit!)).
What is important about C++'s heritage of C is _not_ the shared syntax--it's the fact that you can still figure out your overhead basically exactly (as well as you can in C, at least). But the rest is drastically altered. Go to boost.org to see what I'm talking about.
Note that this is not an anti-C post--that would be ridiculous as not only do I love C but furthermore there are great gtk+ apps (gimp for example--gnome is a bloated mess and doesn't really count IMHO!).
Remember: the rallying cry of OSS is 'show me the code'. If you think you have a nicer way to code, make it and then publicize. I'll stick to gtkmm for now, and recommend others take a look at it.
This article is a short evaluation of Eiffel as a language for developing the core gnome desktop platform.
I think Gnome has other things it needs to focus on than swapping around foundations again.
Afterall, is Gnome attempting to be useful or just a developers' theoretical playground?
If Eiffel were indeed to be used for a project such as Gnome, such a tool could greatly reduce the amount of work needed to access all of the existing Gnome libraries, which are AFAIK all in written in C.
EWG even comes with GTK 2.x bindings contained as an example.
PS: The above is a shameless plug, I am the main developer of EWG (;
Are the people who control Gnome even considering moving it to a new language?
.NET, and that the people claiming it are full of it. Naturally, once a story gets rolling, people happily continue to propagate horseshit.
.NET as an implementation technology. The headline from the Register is misleading, for a number of reasons:
.NET interest:
.NET and GNOME support for .NET is akin to a random KDE-related company (like The Kompany) working on a particular application. Miguel's *only goal* is to have an environment for Ximian to develop future applications for. That means that Ximian may produce an application or two written in C#. It is even possible that such an application could become a core GNOME application.
.NET, it is very possible that people were asking `Miguel wants to depend on Passport' or something just as bad as that.
No, but it makes good fodder around Slashdot, mostly among anti-MS advocates who want something to get riled up about and among a couple of vocal KDE trolls, so several rather misleading stories have slipped their way in. Miguel has been saying for something like two years now that GNOME is not going to be moved to
Here are a few choice quotes from Miguel, the guy doing Mono who also happens to work on GNOME:
The short story is: rewriting code does not pay off, and I agree with the thesis of the article. Rewriting GNOME in C# with the CLR would be a very bad idea, if not the worst possible idea ever.
GNOME is not adopting Mono or
* The headline does not reflect any statements I made on the interview (if you read the interview you will notice this).
* The only future plans that have been approved by the GNOME team (which has 11 voting members on its board) are found here:
http://developer.gnome.org/dotplan/
* I am not the GNOME foundation or control GNOME like Linus controls his kernel, I am just its founder and a contributor.
* GNOME is not built by an individual, its built by a team of roughly 500 contributors in many areas.
* Decisions in the GNOME world are done by active contributors and module maintainers. I have given
my maintainership status on every module I maintained to other members of the GNOME team as I got more involved with Ximian and later on with Mono.
So effectively I have no "maintainer" control.
and
GNOME had always tried to have a good support for multiple programming languages, because we realize that no matter how much we loved C as a programming language, there was a large crowd of people out there that would like to use the GNOME libraries from their favorite programming language, which might not necessarily be C.
This strategy has paid off very well. There are healthy and striving Python, Perl, Guile and Ada communities out there that use the Gtk+ and Gnome bindings to build applications. From rapid prototyping to robust applications: we wanted to empower developers.
The actual scope of
After much researching and debating, we decided that a couple of developers at Ximian will join me in working on a free implementation of these specifications. [.NET/Mono]
This means that there are a few developers who *also* happen to work on GNOME that work on Mono. Guess what? There are people that work on KDE that work on Java -- that certainly does not mean that "KDE is moving to Java". A couple of Ximian developers working on
Miguel has stated in the past that he is dubious about doing rewriting even GNOME-based applications maintained by Ximian -- primarily Evolution. I just can't understand why people have so much problem getting this into their skulls.
I am not sure what people told Richard Stallman about my plans. Given the confusion surrounding
My only i
May we never see th
Why, yes! That's a great idea. Here's why:
[1] simple, uniform syntax. Having programmed for $$ in C, Objective-C, Perl and Eiffel, it took me a while to get used to s-expressions, but once I did, I learned new ways of thinking about programs as data that can be manipulated. Now my old friends (ObjC, etc) seem clumsy by comparison.
[2] Common Lisp can be interpreted for fast prototypes, compiled for speed, and mixed -- core code compiled, and scripts that seemlessly interact with the core.
[3] It's dynamic. Design targets evolve quickly, and statically typed languages make one waste time deciding if a value should be a float or int or whatever, and re-writing if they didn't guess the future correctly. Once a type can be fixed, a simple declaration allows the compiler to optimize. Clean and quick.
[4] Common Lisp has macros far beyond the C-family, which makes for code that writes code in a seamless pre-processing stage. Macros are unbelievably powerful, and are possible a result of the syntax of s-expressions.
[5] Common Lisp is a multi-paradigm language, rather than a "one trick pony". It is object-oriented via CLOS, and more powerfully so than C++/Java/Eiffel. It has multimethods that capture more object paradigms. It is functional when you want that. It can be made declarative by writing a mini-language (e.g. Prolog) via the macro system, and procedural and reflective and whatever else you want. All with one simple syntax, though you can even alter that if you want.
[6] Common Lisp is fast -- it writes fast, builds fast, and even compiles to good machine code.
And, perhaps more importantly, it's for those who want to run apps written by people they don't trust to get the memory management perfect. Which, judging from all the memory leaks we see, is a fairly large number of them...
These days we don't expect programmers write directly to the file system; we have far more powerful and robust file system managers to do it for them. We don't let them do everything as the superuser; we have privilege managers to take care of that. So why do we expect them to do their own memory management?
Ceterum censeo subscriptionem esse delendam.