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."

Comments

"Blue is the color of my Windows screen"

[tepples]

The Eiffel language may be a good choice for GNOME apps, but wouldn't running a Windows app written in Eiffel 6.5 result in the Blue Da Ba Dee Screen of Death?

Re:"Blue is the color of my Windows screen"

[Anonymous Coward]

What makes you think they're more painful than your jokes?

Pointless

[m00nun1t]

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?

Re:Pointless

[AKAImBatman]

I think that many parties have been using the recent news from Sun as an excuse to attempt to drive wedges in the developer community. Many academics hate Java for it being a successful, but very real world language. They would much rather see a more "elegant" language become popular, all while ignoring the realities of development that Java addresses.

Re:Pointless

[Anonymous Coward]

Actually, Eiffel is rarely seen IN academia - compsci academia, anyway. Eiffel is marketed strongly at "computing for business" types, you know, the ones who buy into the OO, software engineering hype, and write 30000 line monstrosities where a 12 line shell script would do, then go off and "refactor" for another six months and USD500000 budget to produce...the same thing, sliced slightly differently.

Compscis use stuff like ML and Haskell, while slagging off other compscis who use Common Lisp or Scheme for not having static typing (while the lispers slate the MLers for missing the point because all the interesting lisp programs don't _know_ what types are appropriate ahead of time in their view), and they all slag off the goons using Java to get funding from corporate types.

Re:Pointless

[arvindn]

"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.

Re:Pointless

[Samari711]

a fun tidbit about Eiffel, because one of the teachers at my school loves it: when you compile Eiffel code, it compiles into C++ and then into assembly, so there's nothing Eiffel has over C++ other than another layer of abstraction and a longer compile time.

Re:Pointless

[Anonymous Coward]

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.

Re:Pointless

[BasilBrush]

If you RFRA you'd see it compiles to C, not C++.

And anyway, C++ originally produced C code. C originally compiled to assembler. And assembler obviously produces machine code. So none of these languages have anything over the languages that preceded them, and indeed hand produced machine code "other than another layer of abstraction and a longer compile time", right?

Re:Pointless

[RadGeekAuburn]

a fun tidbit about Eiffel, because one of the teachers at my school loves it: when you compile Eiffel code, it compiles into C++ and then into assembly, so there's nothing Eiffel has over C++ other than another layer of abstraction and a longer compile time.

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.

Re:Pointless

[JohnFluxx]

Of course - haven't you heard of a little thing called turing completeness?
Any language can be mapped on to any other language.

Re:Pointless

[WeiszNet]

Your point that _just_ another layer of abstraction doesn't introduce anything worthwhile has been answered by other people. (Dude, why don't you program in assembly, or brainfuck, or whatever? :)

For what it's worth, please make a distinction between C++ and C, they are two very different beasts. Two of the most common Eiffel compilers ISE Eiffel and SmartEiffel do compile to C code, not to C++ code. You probably refered to one of those when making your claim that Eiffel compilers generate C++ code (which is a false statement). Also please note that conceptually an Eiffel compiler can generate assembly code as well. In fact VIsual Eiffel does it. And ISE Eiffel does compile to Microsofts .Net byte code as well.

Re:Pointless

[KingOfBLASH]

I haven't been watching the debate, but surely a top concern is developer pool?

I program for a living, and I really don't think a new language will be a problem. I have had to learn lots of new languages for projects at work (That's how I learned LISP, Java, Perl, Python, and PHP). Generally speaking, it's not that hard to pick up on a new language. I'll spend a couple of hours learning the basics of the syntax, then I'll start writing some code, and over a week or two I'll get competent with a language.

Really, most languages aren't that hard to learn. Even LISP, which was out of this world compared with anything I knew before. First I learned that everything in LISP is a List, then that a list is representated by objects in ()s. Then I learned that if you don't have any punctuation to show that the elements of the list are a string, then it's either a function or a symbol (the LISP equivalent of a variable)

Then code like this becomes readable:

(print "hello world!")

If you were following along, you will probably see that we have 1 list, or 2 elements, the first being a function, the second being the string to be used by the function. See, it wasn't that hard, was it? It's really easy for a developer to learn a new language. It takes time, yes, but it's easy

Re:Pointless

[Pfhreakaz0id]

I just have to laugh at these posts of jva being so real world. Yeah, a "real world" language that will only let you do a select-case on an int.

Re:Pointless

[Doomdark]

Yeah, a "real world" language that will only let you do a select-case on an int.

Yeah, as opposed to other real world languages such as C and C++.

Yes, C# allows using syntactic sugar, to do "switch of Strings". Other than that, it's mostly just scripting languages that allow it; mostly because most scripting language have no static typing.

I must admit this is amongst funniest "proofs" of "why java sucks".

Re:Pointless

[Pfhreakaz0id]

I didn't say it necessarily sucks. I just think it has a bunch of stuff that seems to be "we're making you do it the harder way because it's the RIGHT way".. also on the list is not being able to do stringVar == "this", instead doing stringVar.equals("this").. I must confess, I don't know c or c++, but even PL/SQL and on oracle stored procedures and javascript let you do a switch on a string!

Re:Pointless

[iabervon]

Or, in JDK 1.5, a typesafe enum. Perhaps it ought to also support Strings, but I think enums satisfy the biggest set of issues (plus, it automatically figures out the enum that your constants have to come from).

Really, most of the problems with Java are fixed in JDK 1.5; the biggest issue with Java being considered a "real-world" language is that features aren't included until they have been implemented and tested for useability, safety, and complete specification. This makes it move somewhat slower, but at least it's not broken all the time.

Re:Pointless

[ultranova]

a fun tidbit about Eiffel, because one of the teachers at my school loves it: when you compile Eiffel code, it compiles into C++ and then into assembly,

Oh good, then it might actually be suitable for building an efficient and responsive user interface; Java sure isn't.

so there's nothing Eiffel has over C++ other than another layer of abstraction and a longer compile time.

You do realize that all programming languages are just abstraction layers ? Even assebler is an abstaction layer over the binary strings which the machine actually understands...

Coming to think about it, in modern processors, aren't even the binary strings just a layer of abstaction over the microcode ?

Re:Pointless

[Anonymous Coward]

> Many academics hate Java for it being a successful, but very real world language.

I am an academic. I dislike Java. But I don't dislike Java *because* I'm an academic. I dislike it because it's an irritating language to code in; because the libraries are bloated; because it uses an order of magnitude more memory than it should; because Java applications all look horrible, and typically are even worse to use than they look; because Sun want to lock you into their weird dream. etc etc.

Putting my academic hat on for a moment and looking at what was known about OO languages, Java would have been a merely OK language in the mid 80's if it had existed then. In the 90's frankly it was past its sell by date, and in the year 2004 it's a joke.

A static type system that's a joke (at least there's going to be a weak-ish generics system in JDK 1.5, but there are other horrors too fundamental to change). A horrible mess between builtin and user types. No modules (classes and static methods do not a module make). Brain damaged name spaces (ever tried "import a.b.c" and then use "c.d"? No, why not do "import a.b.c.*" instead and polute everything!). etc etc. None of these help problems aid development.

If I a non-realist academic, so be it. Your coding reality is the 1970's. My coding reality is the 90's (there being no good imperative language for the year 2004 yet). Last time I checked my coding environment addressed a lot of realities, although I admit it balks at big collars and kipper ties. So be it.

Re:Pointless

[tigersha]

I can ensure you 100% that C does NOT allow you to do a switch on a string and, for that matter, also forces you to use the xx.equals(yy) thing. In fact, in C you use strcmp which is worse.

Besides, there IS a difference in == and .equals. The one compares the CONTENTS of (possibly) TWO strings while the other checks if the strangs are the same string (and works for any object, it checks the reference).

Re:Pointless

[Mike McTernan]

You can always use a Map and reflection to do a "switch of Strings". Sure it isn't as elegant as it could be, and you have to choose the Map type (Tree vs Hash) but the option is there.

Java could add syntactic sugar to do this for you, like some of the stuff in JDK1.5 I guess...

Re:Pointless

[Anonymous Coward]

Symbols are not the Lisp equivalent of a variable. Since you are peddling such non-sense I wonder if you even know Lisp.

Re:Pointless

[Chandon Seldon]

What I want to know, is what market place need does Java meet that isn't better met by Python or C++...?

Re:Pointless

[Pfhreakaz0id]

I agree. From looking at 1.5, I'm impressed with some of the stuff they are adding.

Re:Pointless

[AKAImBatman]

Java has several design decisions that are nods to reality. For example, many have complained that Java has primitives instead of doing everything via objects. This was a nod toward the realities of performance issues in the marketplace. Similarly, Java is designed to be easily compiled to native code at runtime for performance. There are now compilers for Python, but it used to be an interpreted language.

C++ has those dangerous pointers that invariably cause memory leaks. Also, C++ does not allow for plugin designs to be easily developed. If we were using C++, it is doubtful that Servlets, JSP pages, SPI plugins, and other dynamic code modules would exist.

Above all, Java had one of the most powerful core libraries ever seen in any language before it. Nearly all previous languages forced the programmer to write common functionality himself, jump through a variety of hoops to link in shared libraries, or simply hid the underlying implementations of data structures and functionality. The later was particularly annoying since language changes were needed for new functionality (*cough*Visual Basic*cough*).

Hopefully that at least scratches the surface for you. :-)

Re:Pointless

[afidel]

Yeah, nothing except true multiple inheritance, design by contract, strong typing, and a fairly sparse but powerfull lexicon (the reserved keywords are about the same as Pascal). Yep there are zero advantages there. Just because the language is mapped to C rather then directly compiled (by most compilers, I believe ISE has a native compiler available) doesn't mean it is somehow inferior to one with a native compiler, it just means it is easily portable without a lot of compiler work.

Re:Pointless

[damiam]

JSP pages

Are those like PIN numbers and UPC codes?

Re:Pointless

[AKAImBatman]

Sir, your ignorance is astounding. A simple search on Google would have given you a good familiarity with one of the most popular web development technologies in existence.

If that was a poor attempt at a joke, then I apologize. But please be aware that it neither is funny, nor does it make you appear particularly intelligent.

Re:Pointless

[damiam]

It was a grammar nazi comment. JSP stands for Java Server Pages. "JSP pages" is redundant.

That "whoosh" you just heard was the sound of an attempt at subtlety flying completely over your head.

Re:Pointless

[GuyWithLag]

Security, and specifically the Java Security Manager. It allows safe plugin systems to be developed, such that the container can be absolutely sure that the containee cannot execute exit() or fork/exec or read/write inappropriate files.

While some may arue that tis is a needed work-around when you have all your eggs in a single process, it is not a wart fitted on as an after-thought, it fits really well in the philosophy of java.

Re:Pointless

[KingOfBLASH]

No, they aren't. I was simplifying it for the purpose of explanation.

Re:Pointless

[Quattro Vezina]

C++ has those dangerous pointers that invariably cause memory leaks.

If you don't want to use pointers, then just ignore them and don't use them. Why cripple yourself with a language that doesn't have them? It's better to keep them around and not use them, just in case you need to use them in the future.

Re:Pointless

[AKAImBatman]

Talk about reviving a dead thread.

In any case, the core of the problem is that just because you know when and when not to use pointers, doesn't mean that the junior programmer next to you knows the same thing. In fact, he's probably writing absolute crap for what he perceives as "1337 performance". In Java, at least the idiot would be contained to his own code. (Exception trapping and all that.) In C++, he'll quite handily take down the entire system.

Even with Objects you can get in trouble. As the code gets more complex, it gets more and more difficult to decide when to release an object. Release it too soon, and you have a null pointer (sure to crash the entire daemon). Release it too late, and you have a memory leak. (Even worse as it will cause odd behavior as mallocs begin to fail.) In a perfect world, everything should be able to be released by the deconstructor, or automatically let go at the end of a method. Unfortunately, this is not a perfect world.

A new hot topic?

[GnuVince]

Is "what is GNOME's next language going to be" becoming a hot topic? You have people saying they should stick with C for all purposes, others saying that every user application should be in C++ or C# or Java or Eiffel. Next thing you'll know, people will be suggesting Haskell.

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)

Re:A new hot topic?

[GnuVince]

Oh, I forgot to mention, C# does not alienate Windows developers and independant software vendors, they don't need to learn new languages and new libraries to be productive under Linux. This is another point in favor of C# and against Eiffel

Re:A new hot topic?

[AKAImBatman]

Interestingly enough, the latest versions of Java come with a new Look and Feel for Swing. The GTK+ look and feel hooks into GTK+, and makes your Swing application look and behave just like all your other GTK apps; even if you change your skin! Thus one might argue that Java is a perfectly acceptable GTK+ development language. :-)

Re:A new hot topic?

[imbaczek]

Next thing you'll know, people will be suggesting Haskell.

Drat. I was just going to say that. (Well, almost. s/Haskell/OCaml/.)

Re:A new hot topic?

[The MESMERIC]

I tried learning Eiffel.
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 .. 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 :)

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 ... Java, C# and C++ (specially) just begs for crashing apps.

Re:A new hot topic?

[boelthorn]

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. :-)

Re:A new hot topic?

[Webmonger]

This isn't a discussion of what languages should be usable with GNOME. It's a discussion of what languages GNOME itself should be written in.

Re:A new hot topic?

[cubic6]

I've heard about the GTK+ look and feel, and it sounds pretty neat, but I can't figure out how to make programs use it. Is there a standard way to pick a look and feel and make programs (jEdit, specifically) use it?

Re:A new hot topic?

[Mithrandir]

If the program is written by someone else, then you don't really have an option on changing it without getting into some serious hacking (ie writing a wrapper class for their application that changes the default L&F before starting the real app).

If you want to see what is available on a platform, have a look at the javax.swing.UIManager class and specifically the getInstalledLookAndFeel() method. This will give you a list that you can then drop into a menu, print out to a command line or anything else you care to do. If you're builing an app that is supposed to be cross platform, then specifically setting a L&F is bad design. What you should use is

String name = UIManager.getSystemLookAndFeelClassName()
UIManager.setLookAndFeel(name)

In this way you'll always get something that approximates the local widget set look, regardless of whether you are running on Win32, Linux, Solaris or anything else.

Re:A new hot topic?

[koali]

The GTK+ Swing look is quite ugly; it only tracks a few Gnome themes, I think it does not support antialiasing and looks baaaaad. If you want to use it, anyway, check this.

If you want to develop Gnome apps in Java, there are Gnome/GTK bindings for Java.

There is also SWT, but I don't recommend it (it's a lowest common denominator for Win32, Cocoa, GTK and Solaris). Besides, it's selling point is 'cross-platform' compatibility. If you are developing Gnome apps, you shouldn't care much for that (I mean, you are following the HID and using Gnome apis -that's not crossplatform).

Re:A new hot topic?

[jdhutchins]

And how does Java alienate Windows developers? If anything, I'd say C# alienates Linux developers because the company that does everything for C# has a goal of destroying Linux (not that Sun does, but if they do, it's not nearly as controntational). There are good Java tools for Linux, and that's what counts for GNOME (linux tools).

Re:A new hot topic?

[sproctor]

hey, me too. But I agree with the sentiment of the original post: Haskell might be weird because everyone would need to learn to use monads. So I guess there would be a significant barrier there.

Re:A new hot topic?

[damiam]

GNOME is written in C. No one's rewriting it anytime soon. This is a discussion of what languages ought to be recommended and used for GNOME application development.

Re:A new hot topic?

[Webmonger]

No one's planning on rewriting all of GNOME either. That's why they're emphasising languages that can be used for icremental transistion.

Python

[richie2000]

Might as well use Python, then Gnome can use the Zope database for its filesystem, Plone to manage the calendar, document workflow and so on, and it's a sure fit with Gentoo. Well, Gentoo begins with a G, anyway. And portage uses Python. Am I right or am i right? Right!

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.

Re:Python

[GnuVince]

No, Ericsson uses Erlang, a functional, concurrent programming language.

Re:Python

[richie2000]

Ah, yes, of course. I knew it was something beginning with an E, though...

I sit corrected and wish to exchange the Interesting and any possible Insightful moderations I got for my original post for a few Funny and an Overrated.

Re:Python

[keesh]

Except that gentoo won't be using python for portage 3...

Re:Python

[bomblaster]

Well, Gentoo begins with a G, anyway

Wow!! Great reason dude... Shall we all start programming in Lisp?

Re:Python

[warrax_666]

I don't think they do anymore. I seem to remember something about them switching to something else. (Can't remember what, though).

Re:Python

[EachLennyAPenny]

Maybe the article author has been laid off from Ericsson, I believe they used (use?) Eiffel a lot in-house

No, what you mean is Erlang.

Re:Python

[alienw]

Great idea. Let's write core system libraries in a slow, memory-hungry, interpreted scripting language. After all, nobody cares if their desktop takes 10 minutes to process a mouse click, right?

Re:Python

[black mariah]

Only if you use Thuthe Linux.

Re:Python

[N1KO]

That would leave C#/Java out of the picture as well.

Re:Python

[OneEyedApe]

From what I have read, C#, Java, and Python all compile to byte-code (not machine code), which is then interpreted by a run-time environment.

Re:Python

[green_crocadilian]

Much as I like Python's clean syntax and extensive libraries, currently it's just too slow. I have used Python programs in system administration (Gentoo uses it for just about everything) and cgi scripting (ViewCVS); also, I have written a fairly large Python program with a Tkinter GUI (a frontend to a computational fluid dynamics package). The only things that unites those pieces of software are 1) Python; and 2) waiting long, long seconds for them to respond.

I don't want to start a flame war, but Perl seems quite a bit faster. Why is no-one even considering it?

Re:Python

[N1KO]

What do you mean? All three use bytecode interpreters. Which makes them slow and they consume lots of memory. C++ is faster, more popular and bindings for other languages easier to have than with C#/Java.

So if anything were to replace C for the core libs, it would be C++. Honestly, performance on the desktop isn't that great with linux. I'll wait to see if Xorg can make the X server better before I start running everything under Java.

Re:Python

[chez69]

you heard wrong. the bytecode is compiled to machine code for java and C#. that is what a just in time compilier is.

Re:Python

[Eric Moss]

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.

Re:Python

[richie2000]

1. I was joking re Python. Since Eiffel was brought up as a contender, I figured any language was fair game - Fortran, BASIC, Perl, Java and PHP all went through my mind, but I figured the Gentoo/Gnome angle would get a few more +1 Funnies out of the mods. I probably should have claimed Klisp, Koberon or InterKal was being considered for KDE...

2. Perl is a scripting language, not a compiled language. It seems to me a fundamental requirement for this kind of development is speed. Perl is fast for a script lingo but not compared to the compiled languages out there.

Re:Python

[CRCulver]

Do you have a citation for that assertion? Whenever people new to Gentoo insisted that portage be rewritten in C, the maintainers responded that most of portage is forced to go on in slow bash scripts, and a tiny speed increase wouldn't be worth working in a lower-level language.

Re:Python

[OneEyedApe]

What I mean by machine-code is instructions to be executed directly by the processor. Java and Python do not generate instructions for the processor, and the first time a Python script is run, a compiled version is generated. Next time, if the script has not changed, Python will load the compiled version instead. Perl, on the other hand, compiles the script into a binary format when the script is loaded, each time the script is loaded. This is what I would call a just in time compiler.

Re:Python

[Eric Moss]

I'm afraid I'm going to have to agree with you on this, Eric. However, you were selective in your endorsements. What about the following, huh???

(a) the variety of argument types: If you write a library function that takes two args in version 1.0, and you add a third in version 1.1, all you have to do is make the new argument an optional arg, and all the old code calling this function WON'T break. Or you can make it a keyword argument, so you can add all the new args you want and not break old code calling the new function. In other words, libraries can evolve more gracefully.

(b) dynamic runtime: If a function breaks, you are sent into an interactive environment where you can query the program state, fix an improperly set value, create a new function or fix a broken one, compile it and continue. It's like having gdb always available, but even better.

(c) Free implementations -- CMUCL for native code compiling, CLISP for scripts, Vanilla Lisp Shell for interacting with them in an emacs session.

(d) You didn't even mention garbage collection. Sheesh.

OK, joking aside. Why am I the only one responding to my own post? Does noone care enough to agree or disagree with these assertions? Did everyone have a bad first experience with a teacher that didn't really care about Lisp enough to teach it well? Are we going to use whatever an InfoWorld-reading suit tells us is the "best"? Is the look and feel of Lisp just "too different" to even contemplate? I hope not, because a revolution in results will need a revolution in thought and approach and tools. This is important, so I'll repeat it:

If we want a fundamental improvement in functionality, we will need a fundamental improvement in how we design, and that requires a fundamental improvement in the languages that frame how we think about design.

Keeping a syntax just because it's comfortable will strap us to whatever limitations that syntax enforces. Keeping an OO-only model will tie us to its limitations, necessitating a new set of hacks (excuse me, "patterns") to get around those limitations, however clumsily.

The same goes for memory abstraction, calling conventions and typing -- all of which are encouraging rigid top-down planning that produces brittle software.

Common Lisp is not the "ultimate" language -- something better will replace it, but not anything that's less capable, as are the popular languages. Until that day, Common Lisp can get us MANY steps ahead of where we are, just by not limiting design ideas nearly as much as they currently are.

A requirement he missed

[Anonymous Coward]

How about a language that people actually know?

C'mon, really, how many people know Eiffel as compared to Java or C#? Really?

Re:A requirement he missed

[Daniel Dvorkin]

How about a language that people actually know?

C'mon, really, how many people know Eiffel as compared to Java or C#? Really?

Well, of course, taking that attitude to its extreme, no new language would ever catch on, and we'd all be coding in ... I don't know, maybe the original FORTRAN or ALGOL 60, maybe machine code for whatever the most popular processor would be (and it wouldn't necessarily be x86, since everyone would have wanted to stick with "an architecture that people actually know.") New languages that offer an obvious and dramatic improvement over anything else that's available for the task at hand* ought to be adopted for widespread and long-term use.

That being said, of course there is a cost involved in adopting an obscure language, and it has to be measured against whatever benefits the language offers. This is particularly true for large projects. I may choose to develop one-off software of which I expect to maintain personal control for its entire life cycle in Erlang or Ruby or Dylan, but if I'm running a big project with lots of contributors, I owe it to developers and end users to weigh the costs and benefits carefully.

* As FORTRAN, and COBOL, and yes, damn it, C, all did. C++, maybe. We'll have to wait another decade or so to be sure about Perl, and another two to be sure about Java and PHP and Python, and longer than that for C#. I take the long view.

Re:A requirement he missed

[steve_1x0]

A language people acutally know... EXACTLY!!! That means we can get over this whole debate of a "successor" to C and C++ because there is no NEED for a "successor". The important question is (to steal Mr. Postman's line) "what is the problem to which [insert-new-fangled-language] is the solution". Exactly. Let's keep what not only works, but works well and has an enormous user base.

Re:A requirement he missed

[allanc]

Granted, but Eiffel has been around since the 80s and doesn't really offer much to compel me to use it. Looks more like a research toy than a language real people migh want to use.

(CS PhDs do not count as real people)

--AC

Re:A requirement he missed

[asb]

I take the long view.

Now who was the fool that said "Open Source does not innovate."

;-)

Re:A requirement he missed

[p3d0]

Eiffel is very easy to learn. Try it.

Eiffel is overly verbose

[Anonymous Coward]

That's the problem with languages developped first on paper (Ada being another, extreme). Just use Ocaml.

STL

[Anonymous Coward]

Most of the big complaints about the security of C++ come because people have little experience with STL and use their own proprietary container classes. In reality STL has given C++ a new life. C++ can be as security safe as C# or java if a comple of simple programming techniques are used: use the STL object classes--they are fast and safe though they require training to use effectively (Scott Meyers' Effective STL is a good start), use garbage collection or register major components (similar to what Mozilla does) to minimize memory leaks, and use exceptions safely (knowing the effect of what construction and destuction of objects will have when the exception is thrown). There really isn't a need to reduce the number of programmers and eyes by switching to Eifell. Just make sure everyone is trained to operate C++ to its full potential.

Re:STL

[beforewisdom]

Thanks for mentioning the STL. I had a friend say a few things about it as well.

When I finally get back to my C/C++ roots I will check it out.

One thing that does concern me is that I always here this comment that the GNU compiler is "optimized" for C.

What does that mean and why don't they support C++ ?

Steve

Re:STL

[Anonymous Coward]

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.

Re:STL

[AArmadillo]

I wholeheartedly agree. It doesn't make sense to switch languages unless there is a problem with the current language. If it ain't broke, don't fix it, and as far as I can tell ain't nothing broke.

Re:STL

[sploxx]

ACK. And another thing unrelated to that: Why is gnome now focussing on *one* language if one of the main purposes was language independence? (I.e. bonobo and stuff...)

I'm still using gnome, but I'm not so confident that it will stay the right desktop for me if "they" continue to
- remove user features 'which are only for nerds'. Most prominent example: The missing undo button.
- remove developer features from the foundation of gnome. I.e. language-independence.

Re:STL

[AArmadillo]

What exactly is your source for C++ being "too slow and inefficient to develop in"? This is a long perpetuated myth that seems to have no real backing in reality. Take a look at TopCoder -- http://www.topcoder.com. The vast majority of the highest ranked coders -- and therefore the fastest -- use C++. The problem is that most C++ developers have no idea what they are doing. Its like blunt scissors and sharp scissors: give the blunt scissors (Java and C#) to the people who don't know what they're doing, and let the people who want to use the sharp scissors use them (C++). Its a lot easier to stab yourself with sharp scissors, but if you know what you're doing you'll get the job done faster and better.

Re:STL

[OverCode@work]

STL has definitely made C++ more useful, and it's currently the language I used for work as well as my hacking on the side. Unfortunately, I don't believe C++ can realistically be as safe as C#, Java, or ML.

Here's an example that bit me badly a while back:

vector foo;
foo.push_back( baz );
foo.push_back( qux );
obj& farkle = foo.back();
foo.push_back( cwert );
foo.push_back( spqr );

assert( &farkle != NULL ); // see, it's valid!
farkle.do_something();

*boom*

In the actual situation, it was a pointer to an object in the vector, not a reference, and the vector was being added to throughout a large chunk of code. The reference makes the bug even more subtle.

(The reason this is bad is that pushing objects onto a vector causes the vector to reallocate. This took a long time to track down because it was not initially obvious that I had a pointer to an object stored in a vector, and I had no idea why my object was slowly being trashed as the memory was randomly reused.)

-John

Re:STL

[OverCode@work]

Grrr, /. stripped out the template type on the vector.

Re:STL

[BitchKapoor]

It looks to me that the real issue here is that the class-level interface in C++ is too weak. If you could specify object interaction policies (often called "synchronizers"), you could formally encode the constraint that the value returned by back() must not be used after a push_back() (or pop_back(), etc.). After all, this kind of thing is already specified informally in the documentation.

Re:STL

[WorldRimWalker]

Sure - the problem is not that C++ is a ridiculously overfeatured programming language that abounds with subtle gotcha's, it's that most programmers just don't understand it well enough.;->

Re:STL

[rjh]

the problem is not that C++ is a ridiculously overfeatured programming language that abounds with subtle gotcha's, it's that most programmers just don't understand it well enough

Exactly; thank you for stating it so clearly. C++ is the Hole Hawg of programming languages; it gives the programmer access to a lot of power, a lot of very powerful techniques, and a lot of responsibility for using those techniques wisely and correctly.

If I give a teenager a Hole Hawg and he proceeds to auger a hole through his thigh, that doesn't mean the Hole Hawg is a ridiculously overpowered drill that abounds with danger. It means the Hole Hawg was the exact wrong tool for the teenager to be using.

I'm a strong advocate of using the right tool for the job. After spending over a decade using C++, I've finally come to the point where I can use the majority of its features (even the advanced ones) safely, effectively and efficiently. And I've also matured enough as a programmer to realize that 95% of the time I should be coding in Java, C# or Python, instead. (Ah, if only LISP had a better standard library...!)

I don't advocate using C++ for everything. But I do take exception to people who say it's overfeatured and abounds with subtle gotchas. That may well be true. But it's the responsibility of the programmer to use the right tool for the job. If you don't know C++ well enough to spot the gotchas and to harness C++'s incredible power, then don't use C++.

I'm tired of programmers blaming languages for their own failings. Especially when that failing is something as simple as failing to know their limits.

Re:STL

[rjh]

The problem is you're making assumptions about the internal state of a container after you've made modifications to that container. When you get the farkle object, it's all good, because your assumption about the container's state happens to correspond to the container's actual state. Then you go and modify the container, and...

Moral of the story: when the STL documentation warns you that object references and pointers and everything else can potentially be invalidated after any modifying operation on the container, believe it.

I don't mean any offense, but it seems to me the problem is less with the STL than your understanding of it.

Re:STL

[Chris_Jefferson]

True, but in most other languages, one of two things would happen.

a) The pointer wouldn't have been invalidated
b) The program would have stopped.

I find c++'s single biggest problem is the fact thart when you do have dodgy memory corruption it can be almost impossible to track down, and almost all big c++ programs end up with this problem. What I'd really like would be a c++ compiler that runs on a virtual machine that can do complete memory and pointer protection :)

Re:STL

[OverCode@work]

You're absolutely right that this isn't a flaw in the STL. My point is simply that it's extremely easy to shoot yourself in the foot like this with C++. There are lots of things you absolutely shouldn't do (assume references remain valid after certain events), but unfortunately a lot of them are rather convenient and won't cause a noticeable failure 99% of the time. And when it does happen, the source of the problem may be extremely difficult to trace.

C++ is a powerful language with many useful features, but I'll be dancing on the rooftop when something better comes along. It is a mound of progressive hacks (vis: the fact that the 'typename' keyword exists) that has gained a certain level of maturity but also a significant, and not always completely necessary, amount of complexity.

-John

Re:STL

[jmccay]

You are correct, but I would bet that the real reason they want to switch languages is two fold. First, would be to draw in new developers who get excited about the kid-in-the-candy-store high of programming in a new, and popular, language. The second would be so that those developers that don't have experience developing in one of these languages under their belt can add it to their resume.
I really don't like the idea of switching to any of the languages mentioned so far. Python is nice, but it is a scripting language meant for scripting tasks. C# is to new and owned by Microsoft completely. History has shown that Microsoft doesn't play well with others. They have left a lot of handless feeders of them.
I know I will receive a lot of complaints and insults for this. Java is nice too, but it isn't a fully compiled language. In order to run it on most platforms, you need to run it through the Java virtual machine. It is not a native compiled language and would limit the number of platforms that gnome can be run.
For example, Eclipse appears to be great as far an IDE goes, but its performance on both my own system and my borrowed system for real development would be seriously slow responsively.
C, and C++, should be fine for the development of gnome. It is easy to embed scripting ability in applications written in C++, and C, using SWIG for languages Java, python, and etc. It can be a good way to work out the bugs in algorithms before writing them in C++.

Re:STL

[rjh]

My point is simply that it's extremely easy to shoot yourself in the foot like this with C++.

Heartily agreed. C++ has lots of sharp corners (including some corners in unexpected places--the erase-remove idiom is my favorite example). On the other hand, there are a lot of sharp corners which can be anticipated. Your STL container modification example is a good one--making assumptions about the internal state of an object after making modifying operations on that object is never a good idea, regardless of language.

And when it does happen, the source of the problem may be extremely difficult to trace.

Amen and preach it, brother. 99% of the anti-C++ rants I read really have little to nothing to do with the language (like a Greek chorus, hordes of Slashdotters shouting "C++ is slow! Templates are bloated! Objects are slow!") and completely ignore the difficulty of bughunting in C++... good Lord, could they have come up with a language more hostile to debuggers and programmers? I don't need 255-character-long mangled identifiers or five pages of compiler errors just because I forgot a semicolon in templatized code.

I'll be dancing on the rooftop when something better comes along.

For a lot of the problem domain they already have: Python, Java and C# all manage to get enough of C++'s functionality and speed to address a lot of the problem space. But for those circumstances where nothing less than the very best and very fastest will do, I think we're going to still wind up relying on C++.

Re:STL

[kraut]

"The end result is that undocumented C++ code is often unreadable. A lot of other languages don't suffer from that sort of problem."

Heck, the guy who sits next to me makes PYTHON unreadable;)... sometimes you can blame the tools, but sometimes you have to blame the workmen.

Re:STL

[ndogg]

They actually have the best support for C++ of any compiler out there. It's one of the most standards compliant C++ compilers available.

Re:STL

[juhaz]

ACK. And another thing unrelated to that: Why is gnome now focussing on *one* language if one of the main purposes was language independence? (I.e. bonobo and stuff...)

The simple answer to that would be: they aren't.

I don't know who is generating, submitting and accepting these endless FUDish "GNOME switching to this and that" stories but it ain't the Gnome folks.

Re:STL

[jejones]

Don't you think there's a little something wrong with a programming language that a l337 d00d like yourself, after over a decade, can only use the majority of (which, for all we know, is 50% plus epsilon) safely, effectively, and efficiently?

Programming languages are tools, and as such should be well designed, letting the programmer concentrate on the problem at hand, instead of being the problem at hand. Perversely, a poorly-designed language makes its users feel superior--it's not the language's fault that all those other people are too stupid to use it, right?

Re:STL

[rjh]

Don't you think there's a little something wrong with a programming language that a l337 d00d like yourself, after over a decade, can only use the majority of (which, for all we know, is 50% plus epsilon) safely, effectively, and efficiently?

No, I don't think there's anything wrong with the programming language. A surgeon spends a decade learning how to be safe and effective with a scalpel; does that mean there's something wrong with medicine?

Judging a programming language by only one metric--how long it takes to learn--is foolish. Programming languages need to be judged by more metrics than that.

For instance, ease of programming; C++ is a very easy language to program in, once you understand it. (The learning curve is steeper than the Matterhorn, but once you climb the learning curve, the language's ease is amazing.)

Or raw power. In skilled hands, C++ gives cleaner and tighter code than C. As a real quick example of this, compare C++'s sort algorithm against C's qsort. The C++ sort uses a slower algorithm (most implementations use either an introsort or a tuned mergesort) and yet it routinely comes in 250% faster than C's qsort. Why? Because of aggressive code inlining and the way C++ doesn't need multiple sets of (slow) function pointers to do the comparisons.

Or flexibility. In C, you only have one way to solve a problem--procedurally. (Anyone who tells me they can write object-oriented code in C will be summarily beaten. You can shove a rocket motor up a pig's ass, but that doesn't mean I'm going to smile and happily say the pig is now capable of independent flight.) In C++, you've got access to procedural, object-oriented, functional and generic paradigms, and I've even seen declarative logic done without an excessive amount of work. Now, it's true that C++'s implementation of some of these paradigms is weaker than in some languages specifically devoted to those paradigms--for instance, C++'s object model is less elegant than Objective C's or Smalltalk's, and C++'s functional code is less elegant than LISP's or SML's--but C++ supports plenty enough of those paradigms to be able to do some seriously heavy lifting in all of them. What's the usefulness of the multiple paradigms? Simply this: some problems are easier to solve when thinking of them in one way than they are when thinking of them in another. By being a pervasively multiparadigmatic language, C++ lets you mix and match from different styles of problem-solving at will, in order to best accomplish the task at hand. (As an example, I've asked undergrads to write me the Sieve of Eratosthenes in C... then I show them how purely-functional LISP can beat C's performance... and then I show them how purely-functional C++ even beats LISP's performance.)

Now, all that's a whole farking lot of major goodness. All that's incredible goodness, not to put too fine a point on it. And against this incredible goodness, you have one major, critical flaw:

Optimistically, it'll take you five years to hit this point. More if you have to learn by yourself without any mentors around, because then practically the only way you have to learn about C++'s sharp corners is by running into them.

But on the other hand, in the last few years some truly excellent C++ textbooks have come out--Scott Meyer's Effective C++, More Effective C++ and Effective STL, Koenig and Moo's Accelerated C++, Alandrescu's Modern C++ Design, Plauger, Stepanov and Lee's The C++ Standard Template Library, Josutti's The C++ Standard Library... none of these excellent tomes existed when I was learning C++. It's only since the draft standard became finalized that we really began to see the textbooks we need.

Is C++ worth learning? Absolutely. The payoff to you, the programmer, is immense. Is C++ easy to learn? No. Learning curve like the Matterhorn. Should C++ supplant other programming languages? No. When I don't need C++'s raw power, I use Java, C# or Python.

But when the chips are down and I need to crunch numbers like nobody's business... that's when I reach for C++.

performance is ALWAYS open for debate

[l33t-gu3lph1t3]

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.

Re:performance is ALWAYS open for debate

[CRCulver]

-C is not object oriented

No, but certainly libraries like GTK2 allow the programmer to perceive the library as object-oriented. Sure, things are going on deep down, but the level the developer actually sees is pretty OO.

-Strict ANSI C is very limited as compared to platform-specific functions and libraries

Who cares about "strict ANSI C"? The latest ISO C standard came out in 1999.

-C does not have Java's virtual machine features like garbage collection

C is perfectly capable of supporting garbage collection.

Re:performance is ALWAYS open for debate

[be-fan]

Compilers that compile to C use C as something of a portable assembler. Usually, the source constructs map only loosly to C constructs --- functions to functions, class references to void*, etc. Memory management is handled via a conservative GC, which can deal with C code.

Re:performance is ALWAYS open for debate

[black mariah]

That's nice, but none of that answers the question of 'How can a language compile down into another language that doesn't support half of its features?' You're talking about cetain libraries and programs, and not ubiquitous ones like stdio.h.

Re:performance is ALWAYS open for debate

[N1KO]

Considering most languages are written in C, i'd say C does support all of the features of Java or Eiffel. Only these languages do things at a much higher level.

Eventually everything gets compiled to assembler but nobody would want to go through the pain of programming in object oriented or functional style using assembly.

Re:performance is ALWAYS open for debate

[CableModemSniper]

Well in that case how can you compile C++ down to machine language? Machine language certainly doesn't support classes or templated functions or polymorphism. What exactly do you think a compiler does anyway?

Re:performance is ALWAYS open for debate

[TheRaven64]

I wonder if you've ever heard of a little thing called the Church Turing Thesis? It's one of the founding principles of computer science. It basically says that any language which meets a small number of conditions can express any algorithm. Since both Java and C are Turing-Complete languages (ones which meet these conditions) any algorithm that can be expressed in one can be expressed in the other.

Re: your sig

[Anonymous Coward]

I made a change to Wikipedia that sounds right but I know is wrong. It's been there since January 2004 unchanged.

And what was the point of that? Do you also go around vandalising bus shelters and then bragging about it.

Another alternative is D

[HiThere]

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.)

Re:Another alternative is D

[FooBarWidget]

One problem D has is that it has no stable ABI, which could make distributing binaries written in D a pain. Just look at the C++ ABI breakages between GCC 2.95, 2.96, 3.0, 3.1, 3.1.1 and 3.2.

Re:Another alternative is D

[HiThere]

There is that problem --- but work is in progress to add it into gcc. And it's only the code generation section that's hardware specific. (How fast do you think a new language would penetrate into Gnome, anyway?)

Re:Another alternative is D

[bheilig]

> require different operators to multiply
> integers, floats, and I*F and F*I -- all
> require different operators in Eiffel

This is totally false. You are ignorant of Eiffel and have obviously never even seen Eiffel code.

There is only one operator `*'

Operands are promoted to the highest type of the operation. (INTEGER_8 -> INTEGER_16 -> INTEGER_32 -> INTEGER_64 -> REAL -> FLOAT)

Operands are never demoted, but each numeric type has several conversion routines for explicit demotion.

Re:Another alternative is D

[HiThere]

Actually, I've written Eiffel applications, but it was quite awhile ago. I may have improperly generalized my memories...which really had to do with lots of function names for doing the same thing to different "types". I didn't ever define that many operators.

Let me check some old documentation...Ah, yes. To take one example io.put_string instead of put. Because put can't be overloaded to take a string as an argument. io.put_integer, io.put_line, io.put_character, ...

This is but the first of a HUGE number of examples! And B. Meyers has specifically said that this was his intent, and he never plans to change his mind. (He did, however, respond to my question on the mailing list, though this was several years ago, and he may no longer do so.)

Re:Another alternative is D

[bheilig]

You're right about that (io.put_string, io.put_character, etc.). This is slightly annoying but I recognize the benefit of readability. Basically the benefit is that while reading the code you know exactly which feature you are getting without knowing the type you are passing in. It's a close tradeoff but it makes the type system much cleaner, which is a major objective of Eiffel.

Er...

[sfraggle]

How about we dont? Seriously, does anyone really think that standardising the core of the desktop on a niche language that few people know is going to attract developers? The author seems to have missed a crucial factor in reasons for choosing languages: developer base. Python, C# and Java both already have large developer bases. This is one of the main reasons why they are interesting as languages for GNOME.

I dont have anything against Eiffel (infact I've heard it has some interesting features), but this is folly. Come back when you've convinced enough people to use Eiffel that there are some, indeed any large GNOME projects written in it.

Re:Er...

[steve_1x0]

Quick question: How does the developer base that knows Python or C Shudder.. err Sharp.. compare to the developer base that knows C or C++. C is the most universal programming language. It is also the most adaptable and effecient of any high level language. C++ is probably a close second. Python, Java, C#, and all the rest are niche markets...

Re:Er...

[sfraggle]

Because while C is used for GNOME currently, its generally accepted that it isnt an appropriate language for writing GUI applications. While the GNOME libraries are fairly nice to use, I've found that developing for them is still unpleasant because I was using C. While C is probably slightly faster than higher level languages like C#, when writing a GUI program this isnt really an important issue. Developer speed is and should be more important than execution speed. Writing applications in C wastes my time, time I could spend doing more important things.

Re:Er...

[sfraggle]

As an additional point, its worth noting that writing GNOME apps isnt just a matter of writing standard C. GNOME is based on the GLib library which provides some of the OOP features of higher level languages. There are probably more developers who can write code for Python, Java or C# than there are who can develop for C+GLib. So using a higher level language makes GNOME programming possible for a large base of existing developers while at the same time providing a more pleasant platform for developers to work under.

I dont see how you can call Python, Java or even C# 'niche' languages. Python has developed a large user base over the last few years, and there are thousands of CS graduates out there who have been taught to program in Java (and moving from Java to C# isnt much of a conceptual leap).

Re:Better learn C#, boys

[Anonymous Coward]

Actually, Eiffel is a region in Germany :P

Interesting points, but...

[skrysakj]

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.

Why the fuck

[Anonymous Coward]

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?

Re:Why the fuck

[arvindn]

RTFA. The discussion is about what to code the core stuff in, not about forcing a language on everyone else. And C is starting to show its age, even for doing the core stuff, in case you've been living under a cave.

Re:Better learn C#, boys

[Anonymous Coward]

Hey, I'm an American, all I care about is beer and titties, so don't talk to me about no geography.

God Bless this country! Iraq must be licking our ball sack right now, they're so thankful.

Re:Better learn C#, boys

[Anonymous Coward]

Actually, Eiffel is a region in Germany :P

Whereas France is only sometimes a region in Germany.

Eiffel? Bah!

[JanusFury]

Eiffel? Why bother? There is a much better language out there that's already being used heavily on the GNOME platform, along with other platforms like KDE.

What language, you ask?

English!

English is an easy-to-learn and powerful language. A large number of developers already know this language, and there are many tools available to translate it to/from other languages.

English is a robust and mature language, as well. It's been in use for hundreds of years and its capabilities are well-known and understood by many. Try and match that with some ten-year-old language created by hairy UNIX administrators!

Compilers and documentation for English are easy to get a copy of, and many are completely free or very affordable. Almost every college out there offers courses in English.

There are many powerful IDEs available for English - OpenOffice, Microsoft Word, the list goes on.

Unlike languages like Java and French, there is no central committee that says what English can and cannot 'do'. You're free to explore the potential of the language and come up with new instructions and invent new ways to use existing instructions.

I honestly cannot believe that English has been overlooked in this debate. It's a perfect fit for GNOME.

Re:Eiffel? Bah!

[HoneyBunchesOfGoats]

...there is no central committee that says what English can and cannot 'do'.

The Modern Language Association comes pretty close.

Re:Eiffel? Bah!

[flossie]

The Modern Language Association comes pretty close.

Surely the Modern Language Association of America is not really a central committee for the use of English

adj.

1. Of, relating to, or characteristic of England or its people or culture.

American English perhaps, but that is only a small subset of the true language.

Re:Eiffel? Bah!

[cide1]

You're free to explore the potential of the language and come up with new instructions and invent new ways to use existing instructions.

Strategery?

OTOH

[jabber01]

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.

Re:OTOH

[Covener]

Learning the syntax of a new language should not be a significant challenge to an experienced, talented developer

That would be great if we were porting 20 line ruby scripts to eiffel, but there's more to developing a language than syntax

Re:OTOH

[Anonymous Coward]

"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."

You oversimplify the complexities of becomeing a *proficient* programmer. While its true that understanding things like object types, polymorphism, encapsulation, etc., are important for any programmer, to become a proficient programmer you have to know how things are implemented. For example, which is better, an array of wchar_t's, a vector of wchar_t's or a string class in C++? Well it depends on the size of what you are going to play with and what operations you plan to do. Or how about passing references vice pointers vice the objects themselves? To a non-C++ programmer, passing the objects would probably sound the best but that would lead to excessive construction/destruction. Passing pointers would sound fast to some, but dereferencing pointers takes up processor time compared to using a reference. Of course, using the reference pretty much requires your object to be constructed in the heap. I hope these arguments make it clear why I would hardly expect a Java or VC, etc. programmer to understand the intracies of C++ (as one example). His/her code would (just like newcomers to C++) have tons of memory leaks, bottlenecks in processor usage, and various security errors as they use thier C knowledge (everyone knows C right?) to survive a short time in a C++ development process.

My point: You can't become a proficient programmer unless you know how your compiler is implemented. This requires time and experience (contrary to what most CS professors will say). Knowing basic CS concepts that are applicable to any language only lets you open the front door.

Re:OTOH

[|_uke]

Mind you, the world of C/C++ can be a lot more complex than a lot of other language. Things like learning how to deal with pointers and the most efficient way to utilize objects in C++ is something a developer learns with use. (A more real world example than yours would be: do you use virtual methods and inheritance, or Polymorphism with templates?)

There is a lot more to C/C++ than just pointers and etc. And even further, many of the patterns, ideas, and practices can all be used across different languages.

Odds are, the developer who can program in C++, Ruby, Java, Python, Smalltalk and (insert your fav language here)... will have a stronger knowledge of programming practices and syntax concepts, which will let him/her program in EVERY language more efficiently.

Even further. Once the programmer feels comfortable in programming for a wide range of languages and syntaxes, he/she will generally have a lot shorter learning curve when picking up a new language.

After a point, learning a new language is less about learning that languages syntax and specialized sugar, and more about learning what kind of new programming practices that language has to give you.

Probably the largest advantage to knowing multiple languages... is that you have a better understand to which language is the best tool for the job.

I'm not going to use C++ to develop my web application. I am probably going to use a language with stronger web development support. And while I might use C++ for developing the core components of a game, odds are I am going to use a language like python for scripting those components. Especially with the VERY nice python integration that the BOOST library provides.

On the same note, I'm probably going to lean away from C++ for developing a desktop application. (Especially applications which don't have large hungry loops.. and even then, I might just use C or C++ for just the intensive part)... I'm probably going to use Ruby or Python. (Ruby if I can find good enough bindings for what I need, python if I can't.)

Even further... for small unix scripts, I will probably use BASH + awk/sed/etc (and it will generally be typed into the shell, instead of saved to a file). But for larger scripts... I am going to use python, ruby or perl depending on what kind of library support I need. Obviously, if my script needs to cover a very wide range of territories... I will probably use perl... But if my script is mostly self contained, I much prefer ruby.

Re:OTOH

[Doomdark]

Learning the syntax of a new language should not be a significant challenge to an experienced, talented developer.

No, but syntax really is one of the easiest aspects of programming languages to learn. Learning new and differing semantics takes more time, and especially best practices with the new language.

But like others have pointed there's also the delicate balance between optimal tool, and availability of professionals knowing how to use the tool, or willing to learn how to use it. Further, languages themselves are not even so much tools but specifications FOR tools; that is, what matters a lot is quality of tools (compilers, debuggers) for language, as well as compatibility of programs written in language (if and how they can access code written in other languages). Many of reasonably popular "academic" programming languages (Smalltalk, Common Lisp, probably Eiffel too) have trouble with one or the other; either they need their "own" virtual machine, have only one de facto implementation of compiler and/or VM, or some other limitations.

Now, personally I think that as long as applications that use Gnome and its libs can be written in most commonly used languages, and implementation is efficient enough, I wouldn't greatly great about actual implementation language. But I have no plans to start developing those Gnome components either.

Re:OTOH

[jabber01]

When did I say "developing" a new language. Learning a new one should not be too painful for a competent programmer. Especially if the "sort" of language is already known.

Going from one imperative language to another should not be a matter of more than a few days, for the basics, and a few weeks for fluency. Mastery is another matter, but again, good coders can grok new languages very quickly.

Going from an imperative language to a (first) functional once can indeed pose a problem for a few months, as it requires a change in the way one thinks. But this is exactly why all programmers should have a working knowledge of Lisp as well as C - to exercise those mental muscles which make one a flexible, portable, non-offshoreable asset.

Developing new languages is not what is required when developing an application of a known sort, that has been previously and successfully solved using existing languages. In other words, there's no need to develop a new language, only to learn an already existing one.

Re:OTOH

[jabber01]

Quite right. The complexity of C/C++ is a "feature" of the language, and should probably be taken into account when choosing the language(s) for a major project.

Eiffel would be a inferior choice

[aminorex]

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.

Re:Eiffel would be a inferior choice

[GnuVince]

O'Caml would be a mistake. The prefered paradigm is the functional one, and many hackers do not like it (don't ask me why, I love it.) The best choice is C#: it looks like languages people know (C and C++), it's developping rapidly in the Linux world (the Mono guys are developping really, really fast) and you don't scare away Windows developpers.

Re:Eiffel would be a inferior choice

[hak1du]

Sather whomps Eiffel on design and openness.

Yes, but Sather, unfortunately is pretty much dead. So is another great language, Modula-3.

OCAML whomps all of the above on design and codability.

Not quite. I love O'CAML, but its syntax is too tricky for mainstream programmers and it lacks some important features (foremost, good support for efficient numerical programming).

Java is excusable because of GCJ,

Sun has complete control over what is and what isn't Java (they own the trademark, the specifications, and lots of patents). Gcj isn't Java, and if it were, it would probably violate some of Sun's intellectual property.

C# would be sheer madness.

Why? C# is an open, non-proprietary standard and a fairly decently designed language. Mono is an open source, high-quality implementation of C# with a full completement of open source libraries. Mono and its open source libraries are completely unencumbered by Microsoft or Sun patents, and they are based on APIs OSS developers already know well (Gtk+, Gnome, etc.). (Mono also happens to have a separate set of .NET-compatible libraries but if you are an OSS developer, you shouldn't use those.)

If you are looking for an open language with plenty of open source libraries, an efficient open source implementation, and no legal strings attached, C# is pretty much the only game in town right now.

Re:Eiffel would be a inferior choice

[AxelTorvalds]

Are any of the Sather variants alive? Last I had looked the newgroup was spam only, and it looks like Berkely and Karlsrhue have stopped any development and support. I'm not sure if anyone in the GNU world has picked it up or not. I agree that it was slick but it looks dead. Eiffel is a nice idea for this stuff, we just don't have a good compiler and I think that Meyer did enough damage early on that it will forever be a tainted language in many minds. I respect them both but I just can't see how sather or eiffel is a realistic choice unless someone is getting very serious about building new compilers.

I'd love OCaml, it's not nearly as difficult for uneducated programmers to use (meaning, you typically only see functional programming in academia..) as Standard ML and others. It has decent bindings and amazing performance. I'm not sure Inria will ever let it go though. THe more I use ocaml the more I fall in love with it; I wouldn't be against an effort to use it.

Save for Ocaml, I see us have 4 legitimate contenders: C++. Objective-C, Mono, and I'm throwing Gnat in to the mix only because it's an amazingly high quality compiler. Thinking long term, I think we have to factor the tool quality in to this as well as the free nature and the support the tools have. GCC stands far above the rest in this reguard. Python, Perl/Parrot, Ruby, etc. don't offer the native compiled code performance that is critical for desktop apps. Java doesn't really offer it either, mono may not.

What I don't understand is why a set of C++ guidelines couldn't be agreed to, Mozilla did, KDE did. C++ is incredible when done correctly, yeah you and do stupid stuff but it's supported, the compiler is good and there is a proven track record of big projects using it. Not optimal but it's there and it works. Come up with a solid set of GNOME coding guidelines and let it rip, it's an evolutionary change rather than a disruptive one and since all the technology is there and proven I trust that it can be made to work. If not C++ then I think you have to really rule out Objective-C, it's alive, serious dev is being done on Objective-C++ and Apple is using it.

The mono stuff looks cool, I just have reservations, seems like there should be an agreement with MS on it. Else, we're strapped in to playing catch-up all the time or sued for copying something. Something else and this affects Java as well; ANSI and ISO have good standards cycles, you can deploy a standard and it's there for a while. Sun and MS, really they started language versioning, have their own interests in mind and push the revs too quickly. Mono hasn't got to 1.0 yet and MS is already talking C# 2.0. Maybe it won't matter but we don't want to build a huge library of code up and then have the foundation technology stagnate or fall behind or become on available somehow.

Re:Eiffel would be a inferior choice

[TwistedSquare]

If you are looking for an open language with plenty of open source libraries, an efficient open source implementation, and no legal strings attached, C# is pretty much the only game in town right now.

I think you missed some more good points in there. Otherwise C, C++ and even FORTRAN fit that bill ;-)

Re:Eiffel would be a inferior choice

[hak1du]

Yet Microsoft patent encumbered so many aspects of .NET very few people know what, if any, parts of the C#/.NET beast is not so encumbered,

What patents Microsoft may or may not have on .NET don't matter to OSS Mono developers because OSS developers using Mono generaly don't use .NET.

OSS Mono developers use ECMA C# plus existing open source libraries like Gtk+ that have been given C# interfaces. ECMA C# is clearly open, because of ECMA's submission requirements. Furthermore, Microsoft has stated that they consider ECMA C# open.

Also, issues of ownership aside, use of existing open source libraries and APIs as part of Mono means that it's far easier to switch from writing Gnome apps in C/C++ to writing Gnome apps in Mono than it is to switch to Java or .NET. And the resulting apps also integrate much better with the Gnome desktop than Java or .NET apps.

and it's certainly raised equivalent uncertainty to sun's ownership of the java platform

Sun's ownership of the Java platform isn't at all uncertain: they own the trademark, they own the only implementation of key parts of the specification, they own the specifications themselves, and they own several key patents. They argue that this ownership is a benefit because it lets them enforce cross-platform compatibility (and they have demonstrated that they have the legal muscle to do that), but whether it's a benefit or not, their ownership is clear.

Re:Eiffel would be a inferior choice

[perlchild]

If I may, read that certain carefully.
I said their ownership of the platform CAUSED uncertainty, not that it was uncertain.
If you read up the thread, you'll see that Sun's ownership was spoken of as a bad thing...

Re:Eiffel would be a inferior choice

[chromatic]

Python, Perl/Parrot, Ruby, etc. don't offer the native compiled code performance that is critical for desktop apps.

I'm not sure that's a universal truth. In some cases, such as math-intensive data processing, Perl, Python, and Ruby's primitives are probably too heavy for very fast processing, yes. (I think Parrot has an amazing edge there, but time will tell.) In many other cases, the desktop apps I use spend a lot more time waiting for events than anything else.

What advantage does a "pre-compiled" program have over a "compiled from source every time" program in that case?

Re:Eiffel would be a inferior choice

[dolmen.fr]

You can do functionnal programming in C++ too.
See the Boost library and in particular this paper.

Re:Eiffel would be a inferior choice

[GnuVince]

Actually, I read that if Whidbey is delayed and Mono stays on schedule, Mono will be the first to support C# 2.0.

Re:Eiffel would be a inferior choice

[be-fan]

Functional programming in C++ is like pulling teeth with your fingers. It's not pretty. Boost.Lambda is completely impossible to debug. Lack of type inference is a major PITA.

I'm a big fan of C++. However, its being pushed into a domain where its just bursting at the seams. The STL, all the stuff in "Modern C++ Design," etc, is just a plea from C++ designers for a Lisp-like language.

Re:Eiffel would be a inferior choice

[hummassa]

I'm not sure that's a universal truth
And I am sure it's a universal lie. Use the libraries, Luke. In Perl, there is a load of very efficient libraries. In Python, besides the libraries, there are psyco and pyrex. They really rock.

The Langauge should be up to the Developer ...

[mlk]

... 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.

Re:The Langauge should be up to the Developer ...

[Webmonger]

Yeah. We're not talking about the app, though, are we? We're talking about the language the API is implemented in.

Re:The Langauge should be up to the Developer ...

[joshuaobrien]

Allowing the developers of each application to choose their own language defeats one of the purposes of an integrated Desktop Environment. For each application in a new language, you may require a new set of libraries or perhaps a new interpreter. Having everything in one language lets you cut down on the supporting packages that you have to include.

Re:The Langauge should be up to the Developer ...

[N1KO]

If you install everything from source you need extra packages. Since most people use binaries, they won't need any extra packages.

Re:The Langauge should be up to the Developer ...

[GnuVince]

Sure, but what about core projects? For example, the GNOME project decides to write a GUI log reader. Also, if they rewrite core components of GNOME and don't want to use C, which language are they going to use? What they want is a language that will be used for such projects, a standard language for the project. Take for example the GNU project, in their coding guidelines, they advocate the usage of the C language. The requirements for that language GNOME wants are as follow:

• High-level language
• Safe language
• Good programmer productivity
• Good library
• Widely known
• Reasonably fast
• Free software

The language that fits this bill the best so far is Mono with C#.

Re:The Langauge should be up to the Developer ...

[mrroach]

Well, that's all well and good, but the question in the Gnome camp has been which language to use to write the *platform* not which languages can be used to develop apps.

-Mark

Laziness will always dominate software development

[l33t-gu3lph1t3]

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.

Less Talk, More Do

[UnderScan]

GTK/GNOME is accessible to many users and developers (AS IS) via C/C++/python/perl/ and I am sure there are others I am leaving out.
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.

Open your mind

[fbrathwaite]

For goodness sake fellow developers can an open-mindedness towards this matter not be kept?. I get chills thinking of what the developer commnunity is becoming when I see such drone like responses. C#/Java?--maybe...but also maybe Eiffel, Smalltalk, objective-c, Ocaml, Rebol, Python, Ruby, Perl, etc. OSS is about choice so I see no reason why the same cannot be applied to development languages. If the project is done in Eiffel then so be it and I'll look forward to the challenge of learning a new programming language.

Objective-C?

[skurken]

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.

Re:Objective-C?

[pfafrich]

The one thing Iliked about objective C was that it didn't need a manual. The whole things could be described in a few web pages. No 700 page nutshell book just three or four pages. Now thats a neet language.

Re:Objective-C?

[don.g]

GC is nice. It's for people who really want to spend more time solving problems than thinking about memory managment. It's not an absolute requirement... but there's a reason I haven't written any non-performance-critical code in a language without GC in over two years :-)

Re:Objective-C?

[gidds]

GC may be for the lazy. But it's also for those who write large, complex systems and recognise that manual memory management can take an awful lot of work to get right, often causes subtle bugs that are a nightmare to find, and that their time is better spend elsewhere.

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?

I don't think so

[hak1du]

Last I looked, SmartEiffel...

• lacked dynamic loading of shared libraries
  
• lacked separate compilation
  
• lacked usable Gnome bindings
  
• lacked reflection
  
• failed to come even close to implementing the de-facto standard set by Eiffelstudio (no compatible thread implementation, no method pointers, incomplete library implementation)
  
• failed to come even within an order of magnitude of equivalent C++ code in terms of performance
  

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.

Re:I don't think so

[Lysol]

For real.

I have no idea - and I've worked on some C# stuff in the past - why anyone outside the m$ world would consider C#. I 100% agree with the parent - it's a ticking timebomb waiting to explode. I think the fact that, for example, IBM is not using C# and doing very well is quite telling. Don't expect them to (ever?) use it anytime soon. In fact, who besides Novell is really investing anything in C#?

Exactly, the same people invested in VB. I rest my case.

Re:I don't think so

[hak1du]

Once open source software becomes dependant on C#, Microsoft will pull out their submarine patents and start shutting down open source projects. [...] Even if the ECMA demands Microsoft license their patents under ECMA standards,

ECMA not only demands RAND, they first of all demand disclosure of patents. Therefore, there are no "submarine patents"--the set of patents related to ECMA C# is well known. Furthermore, any patent enforcable on ECMA C# would have had to be filed at most a year after publication of the first draft and would be public by now, so even if Microsoft was lying through their teeth, we know by now the complete set of patents that could possibly be relevant.

Claims like yours that there are some mystery "submarine" patents related to ECMA C# are pure FUD.

Microsoft is not stupid. They didn't ask Ximian to use C# for nothing. They have something planned.

I see: so, according to you, the reason people are working on Mono is because Microsoft "asked" them. And, according to you, everybody is stupid except for Microsoft: stupid people investing their time in Mono, stupid companies investing millions in it, etc.

Dream on. The Mono developers are exercising an exruciating amount of care to make sure they have their legal bases covered. One only wishes other OSS developers were so careful.

What you should really worry about is what happens to all those OSS Java projects as Sun either goes out of business or gets more and more into bed with Microsoft. You see, while Microsoft clearly doesn't own ECMA C#, Sun owns the Java platform and large chunks of its implementation, with no free alternatives.

Re: I don't think so

[gidds]

Agreed. It's sad how many people come out of the woodwork to say how wonderful C# is.

I won't repeat all the disadvantages that have been mentioned elsewhere. I think it comes down to one simple question: do you trust Microsoft? Because by using C#, you're handing them on a plate the opportunity to pull any number of nasty tricks. And they've shown, time and time and time again, just how able and willing they are to do so.

Java, for example, is in many ways a better language. It may not have the name of a particular standards committee behind it, but it does have a very successful Community Process steering it, keeping it stable and yet improving it in a democratic manner -- which is far more than can be said for C# and its completely unstandardised libraries.

Java's mature, it's powerful, it's being used in countless enterprise systems. It has the big investments from IBM and many other big names. It works on umpteen different platforms right now -- while for all the catch-up that the Mono guys are doing, C# doesn't even work effectively on two. And M$ can keep them playing catch-up forever.

When M$ is mentioned here in any other context, they get roasted (and mostly, though not always, with good reason). Yet developers here seem perfectly happy to roll over and take whatever M$ gives them, putting all their work at risk.

I really don't understand it. Is this astroturf? Are people stupid? Are they letting the words 'standard committee' blind them to the real truth? Have the few shiny bits on M$'s cheap knock-off enticed them into overlooking everything they believe in? WAKE UP, PEOPLE!

Re:I don't think so

[LarsWestergren]

You see, while Microsoft clearly doesn't own ECMA C#, Sun owns the Java platform and large chunks of its implementation, with no free alternatives.

No free alternatives? Who is spreading FUD now?
http://www.kaffe.org/
http://www.japhar.org/
http://www.blackdown.org/java-linux.html
http://www.gnu.org/software/classpath/classpath.ht ml
http://gcc.gnu.org/java/

Sure, a lot of these projects are far behind the official Java in version and capabilities today, but if Sun would suddenly change the licensing or start to charge people for using Java, there are a huge amount of companies (IBM, Oracle, BEA...) with too much invested in Java, and a huge number of experienced Java programmers. Don't you think they would sponsor these projects to quickly get a viable open source alternative up and running?

Re:I don't think so

[hak1du]

No free alternatives?

As I was saying: there are no free alternatives to large chunks of the Java implementation. For example, there is no usable, free Swing implementation.

Sure, a lot of these projects are far behind the official Java in version and capabilities today, but if Sun would suddenly change the licensing or start to charge people for using Java, there are a huge amount of companies (IBM, Oracle, BEA...) with too much invested in Java, and a huge number of experienced Java programmers. Don't you think they would sponsor these projects to quickly get a viable open source alternative up and running?

It's not clear that they legally can. IBM, Oracle, and BEA all have specific contractual obligations to Sun. Even if they didn't, Sun takes the position that everybody that implements Java has to pass compatibility tests. That's their condition for having the right to use Sun's intellectual property contained in the Java specification (a right, one might add, that they can probably revoke at any time).

Sun can enforce these restrictions because they own the copyrights for the specifications, because you agree to their license agreements when you access their specifications, and because they own numerous patents related to the Java platform as well, which you only get a license on if you play by their rules. Sun has demonstrated that they will go to court to enforce those provisions when it suits their business needs, so there is even a precedent.

So, if Sun suddenly starts charging people for using Java, presumably, they wouldn't let their business be destroyed by free competitors, they would also tighten the requirements for licensing, and free competitors probably wouldn't need to apply.

Face it, Java just isn't an open platform. It is intrinsically impossible to have an open platform with enforceable compatibility standards. It's one or the other. Sun has chosen the latter and so have you apparently. Live with your choice, but don't pretend that it's something it isn't.

Re:I don't think so

[hak1du]

By the way, just to clarify:

http://www.kaffe.org/ http://www.japhar.org/ http://www.gnu.org/software/classpath/classpath.ht ml

The above are not implementations of the Java platform. They don't even come close in terms of features. They haven't passed the compatibility tests. And Sun hasn't approved them or permitted them to use the name "Java".

Furthermore, Kaffe and Japhar probably violate at least one of Sun's patents (related to byte-code checking), and probably more.

http://gcc.gnu.org/java/

gcj is a useful compiler for a language kind-of-like Java, but it is even less close to a full Java implementation. Among other things, gcj by itself is a batch compiler that has little of the reflection and dynamic capabilities of Java and gives you programs with significantly different semantics. In order to achieve more bytecode compatibility, it relies on another JVM (gij or kaffe, I forget which).

http://www.blackdown.org/java-linux.html

Blackdown's implementation is a port of Sun's Java implementation. It is in no way, shape, or form an open source implementation, and Sun owns most of the code.

In fact, there are no independent implementations of the Java 2 platform at all as far as I can tell: anything that is even close to implementing the Java 2 platform depends on lots of code licensed from Sun. That is, IBM, Oracle, BEA, Blackdown, Borland, Apple, etc., all take Sun's source code, alter it to varying degrees, and then ship it.

Furthermore, any of the developers at any of those companies who have worked on Sun's source code are likely unable to ever work on an open source Java implementation because Sun could claim ownership of the open source implementation as a derivative work with fair probability of success.

Re:I don't think so

[LarsWestergren]

Thanks for pointing out the facts about Blackdown, I took these links from a bookmark folder I had named "open-source java", it would seem I need to split it into two folders, one named "java under linux".

Even if they didn't, Sun takes the position that everybody that implements Java has to pass compatibility tests.

I believe that Sun allows people to clone Java...as long as they don't call it Java. Some parts of .Net for instance is big blocks of Java code with just ReCapitalizedMethodNames.
Same with Kaffe ... it has been around since...1998? If Sun is so eager to shut it down, why haven't they?

Sun has demonstrated that they will go to court to enforce those provisions when it suits their business needs, so there is even a precedent.

What precedent? If you are thinking about Microsoft, they broke the contract with Sun which specifically stated that they if Microsoft wanted to add something to Java they had to do an external jar like everyone else. Microsoft started changing classes in the java.* package which broke the standard and made it Windows exclusive.

With regards to the rest of my links, you seem to exclude them because they "are behind". I already said they were behind, I said I believe that will change if Sun starts to behave like an asshole.

Face it, Java just isn't an open platform. It is intrinsically impossible to have an open platform with enforceable compatibility standards. It's one or the other.

As was pointed out in another topic today, the first versions of the GNU tools and Linux were written with proprietary tools, on proprietary OSes. Things can move in the direction towards more free, the fact that they come from a less free environment doesn't mean they are tainted forever.

Sun has chosen the latter and so have you apparently. Live with your choice, but don't pretend that it's something it isn't.

Hey, no need to get snippy. I may be mistaken, but accusing me of lying is unfair.

Java is the language I am most productive in, but I am learning C/C++/Python too just to be on the safe side (and because it's interesting!)

Re:I don't think so

[hak1du]

Same with Kaffe ... it has been around since...1998? If Sun is so eager to shut it down, why haven't they?

My guess is that Sun isn't eager to shut down Kaffe: Kaffe is so incomplete that it is no commercial threat to them, and they don't like antagonizing the OSS community unnecessarily. Besides, it would cost legal fees and it would destroy the "Java is free and open" illusion.

Some parts of .Net for instance is big blocks of Java code with just ReCapitalizedMethodNames.

Oh? Like what "big blocks of Java code" did Microsoft incorporate into .NET? If you know of any, please share that information.

Significant chunks of the .NET API are very similar to Java, but that mostly represents commonly used names anyway, or it arguably represents "fair use". I'm sure Microsoft's lawyers looked at that very carefully (as did Sun's). Of course, with the Sun/Microsoft licensing agreements, Sun probably couldn't say anything at this point even if there was something actionable.

What precedent? If you are thinking about Microsoft, they broke the contract with Sun

Well, and even if contracts were all we had to worry about, all the major players have contracts with Sun that limit what they can do, so the same kind of concern would apply to companies like IBM, Oracle, etc.

Furthermore, Sun made several arguments against Microsoft (in several separate lawsuits even, AFAIK). One was based on contract law, but the other was a business practices lawsuit based on an argument that Microsoft was destroying WORA, quite separately from any contract. Even if they didn't have any IP (and they have plenty), they could continue to make such claims against, say, IBM.

With regards to the rest of my links, you seem to exclude them because they "are behind". I already said they were behind,

But they aren't just "behind", they aren't Java. Java is a well-defined thing: it is what Sun puts the Java label on. They aren't Java and they probably never will be Java.

As was pointed out in another topic today, the first versions of the GNU tools and Linux were written with proprietary tools, on proprietary OSes. Things can move in the direction towards more free, the fact that they come from a less free environment doesn't mean they are tainted forever.

The situation is not really the same. Linux is based on open standards (e.g., POSIX, BSD). UNIX itself was developed at a time when software patents effectively didn't exist. And UNIX changed hands so many times and had received so many outside contributions that the intellectual property just kind of got lost in the process. And even with all that, SCO claims Linux as a derivative work and is causing a lot of people some pain.

Java, however, is not an open standard at all. Unlike UNIX, Sun has gone through great pains to retain ownership of whatever they could conceivably retain ownership of: the specifications, patents, licenses, etc.

Hey, no need to get snippy. I may be mistaken, but accusing me of lying is unfair.

The general attitude in the Java community is "yes, Sun has control, but it's benign control, hence we are justified in calling 'Java' open and free even if it is licensed differently from what people understand 'open and free' to mean". It sounded to me like you were buying into that.

The problem with that view is that it is both wrong and misleading. It is wrong because, whether or not Sun's control is benign now, there is no guarantee that it will remain so; as long as Sun has the legal means to control what is and what isn't Java, they can use that for both good and bad. The more they run into financial difficulties, the more likely it is that they'll use it for bad. And it is misleading because people will incorrectly assume that Java is indeed "open" and "free" in the more commonly used senses of the word.

So, I was assu

Re:I don't think so

[p3d0]

...lacked dynamic loading of shared libraries...

I wrote a proof of concept with dynamic loading of shared libraries almost 6 years ago. It was intended to allay the Perl 6 Port team's fears about the practicality of the language. It didn't work.

It also failed to generate any interest among the SmartEiffel developers, so it never got incorporated into that compiler.

Re:I don't think so

[bheilig]

Just to bring you up to date:

Has reflection since they adopted the Eiffel Library Kernel Standard. This standard proposes the strictest and most comprehensive interface for reflection of any other OO language.

You're right, EiffelStudio is still far beyond SmartEiffel.

SmartEiffel did very well in the The Great Language Shootout back in 2001. I haven't seen any recent benchmarks but I do know that efficiency is a very high priority.

Eiffel is very much an open language. The ECMA committee is about to finish the written standard. Furthermore there has been NICE since about 1991. To say that it has been driven by Meyer's whims is to say that C++ has been driven by Stroustrup's whims. Sure they are instrumental in driving the standard, but they are not whims. Most people complain about Eiffel's lack of whims! The development of the Eiffel language has been the most structured of any I know.

I thought requirement for global type checking was a good thing.

Since when is covariance a serious problem! Covariance allows a lot of expressiveness and power. I think what you are referring to is CAT calls (Changed Availability and Type). Eiffel has an extremely tight type system, and this is a current hole in it. The hole is about half as wide as providing the ability to type cast.

Eiffel has method pointers and so much more. It has agents(chapter 25 from OOSC) which are functions treated as objects. Agents get all the benefits of objects including static typing, introspection, copying, comparison, etc. Furthermore agents support deferred parameters.

I do think C# is good, most likely because it has learned a lot from Eiffel. You won't see any direct mention of Eiffel in this article. However the style of generics and contracts are both Eiffel originals. Also Bertrand Meyer is part of the C# ECMA committee.

Objective C

[Xpilot]

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++.

Re:Objective C

[sfraggle]

The GNUstep project already made that mistake. Nobody knows Objective C.

Re:Objective C

[Zobeid]

So how long does it take your typical C coder to learn Objective C? A couple of hours? Even if you begrudge a couple of precious hours gone from your life, that's still less time than it would take to learn most other new languages we might contemplate.

That's unless we simply plan on sticking with C and C++ from now on. . . But speaking for myself, I detest C++. Nothing would please me more than a widespread acknowledgment that C++ was a mistake from the beginning.

Re:Objective C

[chadruva]

I Agree, Objective C is easy to learn and very flexible. However the downside of it is that there us no Graphical Toolkit for it besides GNUstep, the GTK Objective C bindings are soo old! (from Gtk 1.0).

I was working on a library for creating database oriented applications, i used Objective-C all the way, added transparent access to various databases (protocols are great), however the problem was the GUI, i tried to make a more current wrapper for Gtk, however Gtk2 is horrible complex!!!!

Why the hell do i need to get the GtkTextBuffer from the GtkTextView and later use 2 GtkTextIter to extract some text from the GtkTextBuffer. All this because that little multiline text widget...

The same thing happends wide spread in all Gtk2, you need to create a ton of objects from objects to do anything. As previously mentioned somewhere, is just the API bloat.

Now back on topic, i think they should enfocate more on providing bindings for all sort of languajes so everyone can use Gtk/Gnome instead of focusing on one languaje that *has* the majority of developers out there.

Come on!, we want Objective-C Bindings!

Re:Objective C

[tyrione]

Are you for real?

The entire ATT Wireless Call Suite (Axys Project and its various incarnations past version 4) was developed with NeXTSTEP/Openstep. Until Siemens came in and wanted to rip it apart that Nationwide Suite of MCCA when it became complex was not due to Objective-C's flaws but the Architectural flaws in design by Humans.

United States Postal Project was all Objective-C, Merrill Lynch has tons of Apps for its Enterprise that use Objective-C.

When Apple finally makes its Software Consulting push, firstly in the Federal Markets and later the general Fortune 1000 you will feel real smart about the comment, "Nobody uses Objective-C."

I could build a list of customers but that isn't my place.

Re:Objective C

[GnuVince]

So while we're learning, why not go with something like Smalltalk, O'Caml or Common Lisp? In Objective C, you still need to do your own memory mangement.

Legislating nature

[beforewisdom]

A lot of people have already made the EXCELLENT point how it would be smarter to choose a language already known by many people.

I agree.

Legislating an offical language will not make people learn that language.

Look at GNU. They made Scheme the "official scripting language" for GNU/free(dom) software.

How many people do you see falling over themselves to learn LISP?

Learning a language......and keeping it learned...takes a significant investment in time.

Many of us have day jobs, famlies, lives etc.

Why not do GNU/Gnome and the developers they want to attract a favor?

Make the official language something would be developers can reap a double return on their educational/time investments?

Make it a language they can take back with them to their jobs.

Steve

Re:Legislating nature

[perlchild]

Hmm, Because most languages people think they "know" they know not as much as they think they do, and what they do know is often inefficient/misadapted to writing a large, platform-independant, network-distributed set of API's?

Re:Legislating nature

[OneEyedApe]

(eq 'lisp 'scheme)
NIL

or to put it in plain English:
Common LISP is not Scheme

Re:Legislating nature

[voodoo1man]

Why not do GNU/Gnome and the developers they want to attract a favor? ... Make it a language they can take back with them to their jobs.

Between the .com orgy and subsequent bust and lessons (not) learned, and the overwhelming successes of Free Software and the Java/C++/PL/1 human wave "software engineering," there won't be any (programming) jobs to go back to unless you're in India or the Philippines. Quite frankly I'd be glad for that. Ship all the monkey work overseas (we are supposed to be living in the age of automation innovation productivity growth, after all!), and let the hobbyists use whatever language they want. Many people forget that the interactive computer was invented by a bunch of crazies, and that the PC industry was started by a bunch of crazy hobbyists. They didn't need or want the shit that businesses love to shovel onto their customers, or right now you'd be punching COBOL on a cardboard IBM card.

Re:Legislating nature

[beforewisdom]

I am a programmer and I love what I do. Short of moving out of the country I am prepared to do what I have to do to remain a programmer. I find my vocation being called "monkey work" offensive. Yes, the hobbyists started things. They also did a lousy job of bringing computing into the mainstream. Thats why companies like M$ and Apple exist in the first place. Popular ( popular and *useful* to most non-ubergeek types ) OSS software produced completely by geeks 100% free of any business input are in the minority. Steve

Sather

[jefu]

If a change is really a good thing, why not Sather? It is roughly based on Eiffel and has many of the same good features (and rather a few more as well). available.

It is one of the finest languages I've ever used and I'd love to see it more widely available and used. I'd bet that my development time in Sather is an order of magnitude less than in Java, C, C++. And while I'm very fond of Python I'd bet that development time in Sather is still less than half of what it is in Python. Sadly, the biggest part of that is compile time. But the support for programming by contract cuts debugging time almost to nothing. Thats a tradeoff I'll take any day.

A really stupid question

[beforewisdom]

I have a really stupid question to ask. Are the people who control Gnome even considering moving it to a new language? Steve

That's what they currently do

[Chuck Chunder]

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?

As a would-be Gnome developer...

[RichiP]

I don't care what the next core and/or applications development language becomes the official for Gnome so long as it's easy to learn, effective for its purpose, is elegant and will make Gnome programming truly powerful (capable of doing almost anything apps should be able to do).

Most object-oriented languages are easy to pick up. Java, in particular, is easy to learn because most IDEs help in the syntax (auto-completion) and has great code-to-documentation facilities (Javadoc). In contrast, Glib-GObject is really hard to pick up (not just because of the syntax, per se but because there is very scarce documentation and very few books).

I'll look at Eiffel. If it's something I can pick up in a day and master in a week, then by all means.

Re:As a would-be Gnome developer...

[RichiP]

Oh .. I should probably add "has a fast implementation". Java may be an easy language to pick up, but dang! Most apps I develop on it feel like its wading in molasses. If they're going to run core subsystems in that language, there's a potential to increase the latency for every application that uses them.

C++ is probably out as a choice

[beforewisdom]

C++ is probably out as a choice to migrate gnome into.

A desktop written in C++? What would be the point, KDE is already doing it.

Steve

Re:Laziness will always dominate software developm

[MemoryDragon]

Sorry... but java has made lots of inroads, aroudn 40% of all projects currently are implemented in java and basically most of the server side stuff is done with it.

Re:Laziness will always dominate software developm

[cxvx]

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.

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?

Proof of Concept?

[Gactaculon]

Considering how much inertia is behind C in the developer community as a whole, just talking about all these modern language alternatives is going to get absolutely nowhere unless some of these language proponents actually get together and code "proof of concept" desktop systems and Gnome tools to show that their alternative actually _works_.

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.

Re:Laziness will always dominate software developm

[steve_1x0]

Actually, the reason people haven't abandone C is that they are NOT lazy. When it comes right down to it, all of the "features" of more "modern" languages are nothing but shortcuts that do more of the work for you. The fact that programmers are not willing to give up performance and effeciency in order to use an easier language is not a sign of laziness.

How About Good C Documentation?

[mrcparker]

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.

Re:Laziness will always dominate software developm

[hak1du]

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.

Replacement for C

[Eadwacer]

I thought that since C got it's start with BCPL that the replacement was going to be P.

Re:Replacement for C

[tepples]

B, C, P... The first letter in "Plus Plus" is indeed P.

Re: your sig

[m00nun1t]

The point is well intentioned people can put in factually incorrect information and it may not be corrected. Wikipedia is a nice toy but can't be trusted.

Re:Laziness will always dominate software developm

[starm_]

I agree. C++ is not that much harder than Java. And it creates code that is much more efficient. I have seen implementation of complex math algorithms than ran in hours in java, and in like 15 seconds in c++.

I rarely code in c++.I use Perl because its faster develloping an d Java sometimes because of the foudation classes. But my application suck, they are bulky, slow, and only mean to be run by me for a school projects.

Those who think Java can be as fast as C++ don't make any sense. Don't you realize that the code must be compiled during the execution?

I don't mind running a few java apps on my system. They use a lot of ressources but thats ok just for a few apps. There are dozens of processes running on my machine. If they were all running Java it would take all my ressources.

I use JEdit as a text editor. It runs flawlesslly in java. But text editors don't need lots of power. I mean text editors written in C ran perfectly on a 386 with 500k ram. For people who say Java is fast, do you think Jedit would run on 386?

C/C++?

[matusa]

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.

Re:C/C++?

[sploxx]

ACK (again). Too often I hear people taking about "C" if they really mean C++. It's still hard to believe for me, but it seems that C++ is considered old and impractical and C++ programs full of nasty pointers. But... the only relation of C++ to C is that C is more or less a subset of C++.
Also, if you know java: C++ is a superset.
Also, if you know C#: C++ is a superset.

Yes, C++ has pointers and all the stuff C has. But you need not to use them - you have, you can use the STL. Garbage collection is there in the form of libraries, if you need it. ETC.PP.

After all, all the languages discussed are turing-complete, so why the fuss? :)

Re:C/C++?

[duder]

ACK (again). Too often I hear people taking about "C" if they really mean C++.

So true. Half way through my first C++ class the professor announced to the class the he felt we knew enough C++ to say we knew C. I had did never used C and was skeptical so I tried to get the C compiler to compile my simpler C++ programs and change it the programs as the compiler hinted. I never got those C++ programs to compile in C. Back then I did not know pointers so I really did not know C. The idea that knowing a little C++ means you C is too wide spread- even in academics.

Are you kidding?

[Isldeur]

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?

Re:Laziness will always dominate software developm

[Pengo]

"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. "

This blather goes to show how little you know what your talking about.

Groovy port to Gnome?

[ninejaguar]

What of the merits in porting Groovy to Mono/Gnome? Would there be an advantage to having this as the language to develop Gnome in?

Looks like Groovy has been voted in unanimously by the JCP Executive Committee. Sun, in particular, seems enthusiastic about it by their comment.

If the rest of the process goes right, it appears to be on its way to eventual adoption.

There might be an advantage in having a tie-in language between Mono and Java platforms that is so similar to C# and Java syntax (the language is designed for Java people to pick up easily), but with some claimed advancements. Gnome can still tap into the C# and Java programming pool, hardcore C/C++ guys may find it a decent compromise and swallow their pride long enough to play with a new toy without admitting that they're using C# or Java. And, should M$ try to "extend" the C# language that they cloned from Java to make it more difficult for Open Source implementers, they would already be using a more stable (referring to language, not performance) Open Source language to depend on.

= 9J =

Calm down, it's just a UI library/window manager

[iamacat]

Don't try to make it into the next language/operating system/computing platform. You talked to RMS and other Emacs people way too much. Why should people learn a new language just to write a new file picker to replace your unspeakable abdomination (that may be gone now - didn't follow the news from my OSX cave)?

Gnome should be written using generally available and well-known languages - like C++ and maybe Java if any of the free VMs are usable. If you want to replace C++, start a separate project and convince people to use it on its own merits. You might have to do lots more work than just writting code - publish textbooks, go to standards comeetes, run a website with developer forums - but Perl and Python also suggest that a small potato can succeed with the right stuff.

Then if your language project takes off on your own right, you might consider switching the core development of GNOME. But don't ask people to buy your car just because they want to listen to it's radio player.

Re:Laziness will always dominate software developm

[black mariah]

Then explain where he's wrong. Go on, try it.

Realistically, Java

[Animats]

OK, you're doing a desktop. Mostly GUI elements, no hard real time requirements, lots of pointers, many developers.

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.

Do the right thing please!

[Anonymous Coward]

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.

Re:Do the right thing please!

[Dr. Sp0ng]

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.

G# or Gava?

[Anonymous Coward]

personally I think "The [G/K/Q]ommunity" should find a way to Embrace, Extend, Extinguish both Java and C#...with their own standard.

In the interim preprocess both the highest level code (and/or bytecodes) into [G/K/Q]NU native format.

Run the resulting bytecodes on the "[G/K/Q]LR/[G/K/Q]LI".

Now is the time to out-FUD, out-EEE both Microsoft and Sun. IBM and Novell should step up to the plate and make it happen.

What we really saw last week was not Sun Micro joining MS, instead they are cowering in fear of IBM, and made a really shitty choice of running to satan for cover. This is going to cause the open side many, many problems down the road. But hey, as long as ballmer and mcnealy are golfing together, maybe RMS could be their caddy?

Eiffel Wrappger Generator

[WeiszNet]

One thing the article does not mention is that there is even an Eiffel Wrapper Generator. A tool which autmates much of the task when writing Eiffel bindings for C libraries.

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 (;

with regard to standards, you are incorrect

[brokeninside]

Eiffel has an independent standards body.

You may very well be correct about the rest of your criticisms.

You are missing the point

[sumengen]

> C# and Java are both widely used languages

My Answer: Why don't we have our FREE high level language/platform instead of depending C#/Java (meaning Sun/Microsoft)?

The problem is that both of these languages are non-free. It is apparent that a high level language with garbage collection and other fetures that increases efficiency is needed. Java is created by Sun and C# is created by Microsoft. I think both of them are nice, have lots of class libraries and capable of running your code as fast or faster than C/C++ (in my experience).

Now the best way would be to crete our FREE high level language (as Microoft created C# instead of using Java). We can have jc* high level language which is the best solution. Unfortunately there is not enough time, resources, etc. to decide on the language specs, implementation and testing.

If Eiffel is free (which it seems), and a nice language as C# or Java, and is available now! why not consider it. You can always embrace and extend it too.

Re:You are missing the point

[jarich]

No, you have missed the point.

Java doesn't cost you a dime. There are multiple implementations... one from Sun, another from IBM, Blackdown, HP, etc.

What you mean is that Java, unlike Linux distros, has a single maintainer and hasn't allowed the language to be fragmented.

Do you realize why most companies won't write apps for Linux? No profit. They have to port to Redhat, Debian, Suse... yes, the differences are minor to a guru, but each is different. Each has a different installation/upgrade mechanism, etc.

Windows is a solid, controlled platform. If Linux had a similar driver, it would wipe Windows off the planet... of course, it probably wouldn't have made it to where it is at... and it will probably ~still~ wipe Windows off the planet! :) It's just taking longer this way.

My point being, when you say Java is not "free", what you really means that you don't like Sun retaining control of the spec. It's not free enough to suit you (even though it costs no money, that's not "free"), so you say it's not free and compare it to MS's C#. Hogwash.

You already have a free, cross platform, enterprise capable language. It's called Java (and J2EE). Use it or continue to watch MS roll over the community.

Re:You are missing the point

[sumengen]

I am talking about Free as in freedom. I thought everybody on Slashdot understood this.

Diversity encourages innovation. It is a fantasy that if there is a driver linux wipes shomething out. Several incredible things arise from individuals working from their bedrooms. When you let one company control Java this is not possible. MS comes one day (7-8 years later than Sun) with C# and .Net surpasses both in terms of quality and soon mindshare.

> Use it or continue to watch
> MS roll over the community.

I use C# and I love it. I won't touch Java once again unless I have to.

Eiffel Wrappger Generator

[WeiszNet]

One thing the article does not mention is that there is even an Eiffel Wrapper Generator. A tool which autmates much of the task when writing Eiffel bindings for C libraries.

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 (;

Java or C#?

[NitsujTPU]

Shoot read the GNU/FSF pages. Software developed in a proprietary language is of less value to free software than software developed in a language grounded in real standards, the kind ANSI and ISO spec out.

Re:Java or C#?

[GnuVince]

Java is not standarized and C# has an open ECMA standard.

No, in fact people claiming a move are full of BS

[0x0d0a]

Are the people who control Gnome even considering moving it to a new language?

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 .NET, and that the people claiming it are full of it. Naturally, once a story gets rolling, people happily continue to propagate horseshit.

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 .NET as an implementation technology. The headline from the Register is misleading, for a number of reasons:

* 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 .NET interest:

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 .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.

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 .NET, it is very possible that people were asking `Miguel wants to depend on Passport' or something just as bad as that.

My only i

Re:Successor to C???

[perlchild]

The need for the new in this case is also probably linked to the facts that
1) Ximian/Novell wants to increase Mono's marketshare(a laudable goal), quite probably by increasing it's mindshare in the gnome community(still laudable) through being "the most compatible desktop environment to Microsoft's .NET" (not so laudable).
2) A new language might help allay some of the (hypothetical) problems(I don't develop for Gnome so I don't know what they would be) that a mix of language choice/design introduced earlier
3) A new language, with a seperate remote procedure call convention might drive them to change their corba-based current setup(Java's RMI and Mono's version of XMLRPC come to mind). This may or may not be related to hypothetical 2) Corba is generally considered useful, but heavy, but platform and language-agnostic. Moving to
a different language might change the equation in this case(not saying it's necessarily for the worse, but I'm trying to understand the logic behind this)

Re:Laziness will always dominate software developm

[thammoud]

>>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),

Hmmmm. A quick search on monster.com for Java yielded "Jobs 1 to 50 of more than 5000"

C++ Yielded "Jobs 1 to 50 of 4162"

So Java is not being used just in acadamia. Get you facts straight.

Ada?

[Anonymous Coward]

What about ADA?
Wasn't it developped with the express purpose of unifying development languages under one standard? I is widely deployed already, and has native support for all the higher-order functionnality needed from an application-level language

Why change?

[Uerige]

Why would they want to switch to another language, which some developers might not like at all, rewriting every core gnome app? Sounds like they're overdoing something (not sure what exactly). Why does it need to be one language for everything anyway? They could have applications written in nearly every language, because the bindings exist. Or limit it to some, like, C, C++, C#, java, python. Anyone care to explain?

It's about time.

[Kickasso]

It's about time OSS developers switch to an Object-Oriented language with a sound typesystem, a sensible implementation of multiple inheritance, a non-broken collections library, a reasonable threading model, and, last but not least, with multiple implementations of an open standard driven by an independent body.

In short, a language which is not Eiffel.

Re: your sig

[Ctrl-Z]

And this differs from any other Web site how?

How about ADA?

[burbilog]

Yes, it's difficult at first, but when you learn the ropes it's the best language around. I wrote some utilities in Ada for my company (nobody cared how these are written, it was purely my initiative) and know what I'm talking about.

Gtk bindings for Ada DO exist.

Pascal

[ffallen]

Ok. I know I'm going to get crap for this, however, Pascal is a good language that is easy to learn, readable, and efficient. Most people complain that its a "teaching language" and is not "industrial strength" however, tell that to the embedded programmers who still use it. Some Pascalisms, I agree are fairly annoying, but why not update the language instead of defining an entirely new one. There are at least two open source Pascal compilers (GNU and FreePascal) so why not make some efforts in bringing those two languages up to speed with some of the features that everyone is griping don't exist in this language or that language? Eiffel is arcane, but does have some useful features that others lack. However, I'd much rather have a language which is readable, efficient, well known, and available for many platforms. Lets work with what we have. Too many damn languages are being invented rather than concentrating on what we have and making it *right*.

Re:Speaking of language syntax

[Sir Joltalot]

Can we please debug our English at least as well as we do our source code?

I think you'd find if people debugged their English with the same quality they debug source code, it would be far, far worse :)

Give me a break.

[God! Awful 2]

C libraries that "allow the programmer to perceive the library as object-oriented" are great for people who like to reinvent the wheel.

C is perfectly capable of supporting garbage collection.

Sure, as a kludge! They *claim* that there is very little risk of memory leaks or accidental crashes due to this technique, but it doesn't exactly give me the warm fuzzies. Wait until hackers start exploiting this code to do resource exhaustion.

I.e. I hope that the NSA won't be recommending C garbage collection for use on nuclear missiles any time soon.

-a

Re:Give me a break.

[God! Awful 2]

In which language do you beleive Java's garbage collector is programmed ?

I'm not sure. Anyway, that's hardly relevant. Java uses reference counting and a deterministic algorithm to decide when an object is not needed. It is not based based on heuristics. Admittedly, the heuristics are pretty good, but it's still hard to trust an algorithm that "guesses" when an object is no longer needed.

-a

Re:Give me a break.

[AndyS]

Java (generally) uses mark and sweep Garbage Collection, and not reference counting. The only case when the C garbage collector will fail is when you actually try to HIDE a pointer - an example is if you XOR pointers to try and hide the real contents of them (either for efficiency, or to prevent people messing with your data structures)

Some Java implementations, such as GCJ (amongst others), use a conservative garbage collector for the stack, which can actually assume that memory is in use when it isn't, which is the much more likely failure mode of C garbage collection.

Re:Give me a break.

[God! Awful 2]

All it takes is for someone to do something slightly odd, such as subtracting two pointers and storing the difference. (I assume that this technique is smart enought to notice a pointer that points somewhere inside the allocated block.)

What seems dangerous to me is when a networked application has predictable memory addresses. An attacker creates connections using these memory addresses as session ids.

BTW, what happens if an object contains a pointer to itself?

-a

Re:Give me a break.

[God! Awful 2]

Okay, so what if there's a larger cycle (e.g. 2 objects contain pointers to each other).

-a

thanks for the link

[zogger]

thanks for the link to revolution. Been wanting to get my feet wet, never coded a lick beyond basic html, and that don't count. Everything else I have looked at made me go cross eyed.

Re:thanks for the link

[zogger]

well, thanks for that link too!

Ya, I was disappointed to to see it's a closed source propietary dealie, and not yet for linux anywway. I'll check back later with them and try it for the time period though. I liked the idea of you program in english. Juding by my dismal bash skills "english" will be hard enough.....

An overlooked alternative

[RussP]

I'll probably get ridiculed for this suggestion, but I think that Ada 95 would be an excellent choice. It has a reputation for rock solid code. Check out my Ada page. If you don't know much about Ada, you will be surprised.

I thought Eiffel was dead?

[rixstep]

I hoped so too.

Actually, there is little reason to listen to the confused rantings of the GNOMies anyway. Theirs may be a popular platform, but from the POV, it was long ago a lost cause.

Re:I thought Eiffel was dead?

[Cro Magnon]

Do you have confirmation from NetCraft?

Re:I thought Eiffel was dead?

[iggymanz]

dead? was it ever really alive?

Re:Laziness will always dominate software developm

[starm_]

C++ syntax is almost identical to Java syntax. At least when you don't use some of the more powerfull, weird stuff of C++. (You are not forced to use that stuff) The main difference is garbage collection.

"Java the language != Swing. Go back to school." Oh so if I only use the features that are easely done in C++ it's fast. Whats the point then?

Sorry don't believe you. Last year I used the IBM websphere IDE and just loading the damn thing without any project took 700 MB of ram. A C++ implementation would never have resulted in that much memory no matter how badly coded it was. (unless you were deliberately trying to take up memory of course). Hell I just verified the memory my Jedit was taking up right now: 40MB! Thats with only 12 relatively small text documents opened. Thats for a text editor! A text editor is the ideal example of an app that shouldn't take much resources.

When I have a lot of java applications running on my computer it becomes less responsive. I never have that problem with native code apps. When my system is low on ressources, the java apps are the first ones that stop working.

I have a 2.6GHz computer with a gig of ram and Java can easily take all of that up.
You sir are wearing blindfolds.

Agreed. Bottom line: Eiffel is dead in the market

[Ars-Fartsica]

Eiffel is so far down the list of languages set to become the "next" tool of choice that it is frankly laughable to suggest. You can count the number of experienced Eiffel programmers in the state of California on your fingers and toes. Come on guys, get real.

But Eiffel is not new...quite the contrary

[Ars-Fartsica]

Your argument may make sense for newish tools, but Eiffel has been floundering in the market for over a decade.

Re:Eiffel.... ick!

[austus]

Flamebait? Obviously the moderator hasn't noted the lack of semicolons and other cruft in the Python programming language. There are no semicolons, no brackets, no "begin"s, no "end"s. That's a serious improvement because all that cruft adds up. You simply can't appreciate it until you've programmed without all the cruft.

Re:and yet....

[AceMarkE]

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.

I'll freely admit I'm not an expert on the topic and don't know the exact details of the Java and .Net GCs, so any further comments would be appreciated.

Mark Erikson

Utterly Pointless

[davidle]

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.

Re:Utterly Pointless

[juhaz]

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.

It is quite clear that enforcing only one language is BS, whatever it is. People continue to write software in whatever language they want, I prefer Python. Some C++, some C, some Java, some C#, some even Perl (god forbid) good thing that GTK/Gnome apps can be written in all those. GTK and other Gnome core libraries are written in C, but nothing, NOTHING, requires anything else to be.

I laugh really, as the people who have whinged and whined have been proven to be, well; whingers and whiners.

You still need to wait for quite a some time before you get to laugh, because Gnome is not going to switch languages. See, this isn't about Gnome project doing anything, this is about a nobody called Thomas Delaet who had this bright idea that maybe this and that would be a nifty language, and somehow a troll or another got it posted it to Slashdot and made it look something that it isn't.

Re:Laziness will always dominate software developm

[chez69]

Oh please. I've used qutie a few development evironments that are memory hogs just as bad as websphere is ( I love websphere, by the way ) software bloat is not a java problem. you can easily make a bloated program in C++ or C.

by the way, when I load a empty project in websphere it takes around 100 meg.

Re:Laziness will always dominate software developm

[starm_]

ya I was using a beta, maybe that had something to do with it. But still...

Re:Laziness will always dominate software developm

[koali]

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.

Yeah, most definetely. I still program things in C when it makes absolutely no sense to (I don't program operating systems, device drivers, performance critical code, ...), but I'm pretty comfortable with it.

I'm also doing a lot of Java lately, because I've grown used to it at work, and it's even more comfortable (for a recursive argument, the C-like syntax makes for a natural progression :). I even use it for text-processing et al., even though there exist more appropiate alternatives.

Re:Laziness will always dominate software developm

[Baki]

Just to confirm this irony: I know as a matter of fact that all new internal software development in the major swiss banks uses java exclusively, except for some parts of mainframe software.

UBS is also moving towards java on the mainframe (using websphere) for a part of their mainframe development.

We are talking thousands of developers here in very large corporations. Surely these few corporations are not the only ones, many more must be betting entirely on Java for their enterprise software development.

Since many of the older projects used C or C++, the fact that java already catched up almost with C and C++ on sourceforge means that of the projects starting now, by far the largest part must be java projects.

Academic vs. Commercial Languages

[pxf]

Almost all commercially succesful langauges were invented outside academia and driven by real-world needs: C/C++ by AT&T, Java by Sun, C# & VB by Microsoft, Delphi by Borland (and it looks quite different from its Pascal predecessor), COBOL by a group of corportations (notably IBM, Honywell, and RCA) and the DOD, FORTRAN by IBM, JavaScript by Netscape, PERL by Larry Wall, Python by Guido van Rossum, and SmallTalk by Xerox PARC.

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.

Re:Speaking of language syntax

[The Monster]

We all make typos. . . . Who double checks posts on slashdot anyway?

What I quoted was not 'a post', but the Fine Article itself! Is it any wonder that the Elmer FUD contingent is able to get traction with PHBs, when we as a community can't be bothered do submit our articles to any kind of editorial review before we publish? If you can't tell the difference between 'lose' and 'loose', who would anyone pay attention to your ideas on languages.

Re:Laziness will always dominate software developm

[ultranova]

Hell I just verified the memory my Jedit was taking up right now: 40MB! Thats with only 12 relatively small text documents opened. Thats for a text editor! A text editor is the ideal example of an app that shouldn't take much resources.

A freshly started Gedit (written in C or C++, presumably) with no files open takes 11 megs of memory in my system.

It is an unfortunate fact that programs with graphical user interfaces take lots of memory as a rule.

When I have a lot of java applications running on my computer it becomes less responsive. I never have that problem with native code apps. When my system is low on ressources, the java apps are the first ones that stop working.

The JVM is a native application. Therefore, if Java applications are causing problems, it can be traced to either 1) Bad code in the Java application or 2) Bad code in the JVM. Neither of these tell anything about Java the language, just about the current implementation.

Which could be better - Sun's JVM 1.5 still crashes/behaves oddly with pthreads. Sigh...

One reason: Sun Java Desktop

[Anonymous Coward]

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.

Re:Laziness will always dominate software developm

[QuoteMstr]

Can you cite a source?

Gnome is dying.......

[ckeo]

long live KDE

Compiles to C != As fast as C

[marcovje]

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.

Re:Compiles to C != As fast as C

[gebner]

> Delphi: everybody knows it.

I don't know anybody who knows Delphi. I know Sh, Perl, Java, Python, Haskell, Ruby, O'Caml, C, C++, Io and a bit Lua, but I've never heard of Delphi.

perl6

[SanityInAnarchy]

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.

Do you know any other languages?

[Xtifr]

Do you know any other languages besides C/C++? I have over 15 years of C, and over 5 of C++, and I strongly disagree with you. They are not different languages. But then, I also have at least a passing acquaintance with Lisp/Scheme, Forth, Python, Tcl, Eiffel, Smalltalk, Haskell, Fortran, Pascal, Ada, PL/1, Prolog and SNOBOL. Compared to most of these, C and C++ (and Objective-C) are identical!

(Java and Perl, which I didn't list above, I would count as being in the same family as C/C++, although I suppose they are, technically, different languages.)

Yes, I've used boost and STL and such, and yes, it's a completely different style of programming from C. That still doesn't make it a new language. It's simply been enhanced to allow some new "paradigms". (And they're programming paradigms, not "C++ paradigms".) But I saw the same sorts of things happen back in the stone age, when macros were introduced to assembly language. Didn't mean I wasn't programming in assembler.

Re:Do you know any other languages?

[matusa]

ok, so apples and oranges vary more than types of apples. But a good chef will discriminate intelligently between granny smith and fuji apples, and that's what I was discussing, not the former.

Well said!

[hokanomono]

For me, an important reason to use C is GCC. (Also the good documentation of the glibc.) I don't want to spend to much of the development time debugging the compiler or interpreter. (But it's good to know that i could have the source.)

Re:and yet....

[voodoo1man]

You're wrong in your level of concern, though. The languages in question don't offer the foot-shooting capabilities of C/C++. You can't leak memory in a GC'ed language, so that removes that concern. Passing objects vs passing pointers isn't an issue in languages that only pass symbols which have references to the objects themselves. Etc, etc. Yes, there are other concerns in place to watch for bottlenecks and ways to improve speed, but these factors will not prevent the new programmers' code from running, just from running quickly, which can be solved in an iterative fashion.

Maybe we're reading the OP differently, but I think that is exactly his point. I don't think he was talking about new programmers as those that can't even get their code to compile, but to those that can't yet write very good code. Higher-level PLs may make it easier to get a running program, but they also make it ridiculously easy to write inefficiently stupid code (just because it seems to run doesn't mean it doesn't have major bugs!). In C, there's really only one "right" way to do things, and it tends to be fast enough for most compilers on most architectures. In contrast, C++ and other, higher-level languages often present several differing ways to do things with many trade-offs, some differing for implementations and machines. This is where a knowledge of the implementation is needed. Unfortunately, this does not work with a human-wave hieararchy of developers - you can't just assign one implementation guru to digest newbie's code, because more likely than not he will just rewrite most of it. Fortunately, many environments provide good profiling and advice tools, so the hot-spots of a system can be identified and improved without spending time on other stuff.

There's a lot of hand-pointing at C from some of the users of the high-level languages when they need efficiency: "Oh, we'll just rewrite the critical parts in C and be done with it." Unfortunately, to do that they need to know how to write efficient code for their C compiler and how to get an efficient interface between their language's runtime and the C code; they've just replaced one problem with two. Now they have to know about their C compiler and all the inner workings of their higher-level language implementation. If you have a half-decent native-code compiler for your language and are somewhat familiar with it, it is not all that hard to produce fast-enough (sometimes even faster :)) code with it than in C or C++. With some single-paradigm languages with no native-code compilers (Javascript, Pearl 5) you don't really have a choice, but I don't think you should be using a single-paradigm language anyway.

Security Manager

[rauhest]

While your point about using modern C++ constructs is correct, it should be noted that both Java and .NET have security manager that can give additional security and limit overall damage, even if developer writes insecure code.

Nope

[rauhest]

It doesn't support internationalisation.

Re:Speaking of language syntax

[optikSmoke]

... when we as a community can't be bothered do submit ...

Quoth the grammar nazi.

Forget Eiffel . . .

[npsimons]

. . . the future is brainfuck!

Um..

[shiftless]

Care to back up your statements? I happen to think the Eiffel great type system and its awesome implementation of multiple inheritance are strong selling points, not weaknesses.

Re:Speaking of language syntax

[JanneM]

The article is not posted on a news site, but on the writers own place. Furthermore, his name and the nature of the errors pretty strongly suggests that English is not his native language. I would suggest you untwist your linguistic panties a little and relax?

I like it

[shiftless]

I don't foresee GNOME switching over to Eiffel any time soon, but I would love to see someone write an Eiffel GNOME API.

I started messing around with Eiffel some time ago and I love it. I can't get enough of it. C++ is really a piss poor language in comparison. Now that I've gotten used to the cleanliness and simplicity of Eiffel, every time I see C++ source code I get a sick feeling in my stomach. Really, it's amazing to look back at this crap you had put up with for years and realize just how bad it is.

About the best analogy I can think of is this: It's like having a three-bay garage full of Snap-On tools, two and four post lifts, overhead motorized trolleys with electric winches, air conditioning, etc after you've spent years changing transmissions and doing major work outside on the ground with only the most rudimentary, cheap Chinese tools.

Now I know I'm gonna get flamed for these views, but I don't care. Out of all the people who disagree with me I'm sure only a few have actually taken time to learn and use Eiffel.

Yes, Eiffel lacks some features that it needs. One major example is dynamic library loading, which is totally non-existent in Eiffel at the moment. You can of course interface your Eiffel code to external C routines that load and use whatever C libraries you want, but you currently can't build and load Eiffel dynamic libraries. I am confident this need will be addressed in a forthcoming Eiffel standard.

Yes, Eiffel is a free and open standard. It is developed by the NICE group. One poster made the good point that the core libraries are different between the various implementations of Eiffel. This is true. However, the only Eiffel implementations really worth mentioning are a) SmartEiffel, the free GNU implementation, and b) ISE EiffelStudio, which is a really freakin awesome development environment, but is not free and costs mega $$$$.

As a language, Eiffel is clean, simple, and POWERFUL. The inheritance facility (both single and multiple) is top shelf stuff, far more clean and powerful than C++ or Java. Same goes for the type system, the syntax, etc.

Eiffel also supports and encourages a type of programming known as "design by contract"- basically, each class and feature (method) has a specifically stated contract it must fulfill. Suffice to say this method when properly used *will* result in a program that is not only far less buggy, but whose bugs are easier to catch and take care of.

IMO, one of the biggest problems with C++ programmers switching to Eiffel is that they instinctively write programs with C++ design and Eiffel syntax. When steel was invented, engineers didn't design steel replicas of wooden bridges, they came up with all new designs to take advantage of the better properties of steel. Same thing with Eiffel. It's easy to learn the syntax, but it takes a while to totally get used to Eiffel in a way that lets you take full advantage of its unique features to produce the best quality software possible. Trust me, when you get to this stage, you will not go back to C++.

I highly recommend the book "Object Oriented Software Construction 2nd Edition" by Bertrand Meyer. It is *the* definitive book on object-oriented programming. It extensively uses Eiffel as its notation, but the concepts introduced can be applied to C++ or Java or any other OO language to help create better software. Be warned, it's very verbose in a lot of areas, and some of the stuff is really dry and will put you to sleep. I recommend skipping past certain stuff like abstract data type theory, mathematical proofs of software correctness, and similarly intriguing subjects.

Monads: Don't Confuse Use and Understand

[Vagary]

Don't confuse using monads with understanding monads. Every imperative programmer is using monads (at least as much as they are "using" functions), because semantically every imperative program is monadic. Most Haskell tutorials teach Monadic I/O before they explain Monads, and I suspect that one could write many useful programs in Haskell without. The point of Monads is that they are an embedding of imperativeness in a purely functional language and therefore you have access to the imperative innards (to add things like exception handling).

Syntax and realpolitik

[Blackheart2]

I love O'CAML, but its syntax is too tricky for mainstream programmers

Really, the world is better off without the programs these people might write. A person who cannot grasp a context-free grammar is a person who cannot write a useful, working, non-trivial application.

Furthermore, the people who complain endlessly about syntax are in large part also the people who have not clue one about what really distinguishes one programming language from another, or, indeed, even what a programming language is. Hence all the ignorant remarks that language A is better than language B because it has a bigger library (a library is not part of a language), or because A is dynamically typed (static typing subsumes dynamic typing), or because A is interpreted or not (interpretation is a property of an implementation, not a specification).

Such people do not deserve a say in what syntax---much less language---they use, because they aren't informed enough to make a good choice.

Now, I am an informed programmer, and I do think I deserve a say. But I will tell you that, though I am not a big fan of OCaml's syntax, C-like syntax or LISP-like syntax, I will gladly use any of them if I need to, because I know that the importance of semantics dominates that of syntax, and because I know that learning a new syntax is the easiest part of learning a new language.

Arguing about syntax is like picking a political candidate because he looks attractive: irrelevant. Do you want an ignoramus like that to decide who governs you? Do they even deserve voting rights? There really is no point: you might just as well just thrown some random noise into the poll records, or automatically pick a candidate for these people based on whether they prefer Britney Spears over Avril Lavigne. Different method, same result.

Re:Syntax and realpolitik

[hak1du]

Really, the world is better off without the programs these people might write. A person who cannot grasp a context-free grammar is a person who cannot write a useful, working, non-trivial application.

Syntax matters. It may not matter in the way naive programmers think it matters, but it matters. Space probes have blown up because someone typed a period instead of a comma and the compiler couldn't catch it.

Arguing about syntax is like picking a political candidate because he looks attractive: irrelevant.

Assuming that the looks of a political candidate don't matter is as foolish as assuming that programming language syntax doesn't matter. Even if looks didn't tell you a lot aobut a candidate, they would simply matter because they matter to many voters.

Such people do not deserve a say in what syntax---much less language---they use, because they aren't informed enough to make a good choice. [...] Do you want an ignoramus like that to decide who governs you? Do they even deserve voting rights?

Welcome to the real world, where people with limited knowledge and information make important decisions, often irrational decisions. And to help improve such decisions and the effects they have, we have discussions, about syntax, semantics, and everything else. You are welcome to stick your head in the sand, I prefer to participate.

Re:Syntax and realpolitik

[Blackheart2]

Syntax matters. It may not matter in the way naive programmers think it matters, but it matters.

I did not say syntax does not matter; I said it does not matter as much as semantics. If program meanings were determined by a polynomial, syntax would be the lowest-order subterm, a constant factor, and one which is easy to modify simply by preprocessing compiler inputs or replacing the front-end.

In contrast semantics comprise all the higher-order subterms, and are tightly coupled. In general, one cannot change the semantics of a language and attempt to preserve the behavior of existing program by automatically translating to compensate.

Really, this should be obvious. By and large, programming language syntax is limited to context-free languages, or something slightly less restrictive. In contrast, a programming language by definition has a Turing-complete semantics, which corresponds as a parsing problem to type 0 languages. Type 0 does not reduce to CFL. So semantic issues subsume and dominate syntactic ones.

Even if looks didn't tell you a lot aobut a candidate, they would simply matter because they matter to many voters.

Your argument is obviously circular because you decided to define "matters" as "matters to voters". When I said that a candidate's looks don't matter, I was of course talking about their decision-making skills, policies, platform, etc. Now, why would you misread my argument in such a bizarre fashion?

Welcome to the real world, where people with limited knowledge and information make important decisions, often irrational decisions. And to help improve such decisions and the effects they have, we have discussions, about syntax, semantics, and everything else.

Unfortunately, your discussions hardly ever lead anywhere, not in small part, I think, because you are more concerned about parroting aphorisms and platitudes than applying rational methods to the problem, or building on established work.

You are welcome to stick your head in the sand, I prefer to participate.

You are not a participant; you are a spectator at a football game, yelling slogans because everyone else around you is yelling the same thing; someone who thinks that, because they go to all the games and know all the cheers, that they are on the team.

The people on the field are people like me, who read peer-reviewed literature, publish papers in scientific fora, prove results and, when they argue, can argue logically and support their points with relevant evidence based on the existing literature. You, on the other hand, seem to be unwilling even to respond to arguments in an intellectually honest manner.

Brooks said the same thing

[doug]

Check out Brooks's "The Mythical Man Month". I don't have it in front of me, but he mentions that the number of languages known (not just syntax) is a good indicator of ability. It is much better than years of experience.

- doug

Confused

[hummassa]

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
What? I am puzzled, and I will ask you (I don't think it's OT, too) to make today the day for enumerating its vices :-) It would be a nice counterpoint to its virtues. Thanks!

Re: Pointless - NO SECRET TO GOOD ENGINEERING

[mike.montagne]

"Success" of JAVA? From what I hear and see, there would be more JAVA engineers out of work for many years now than engineers of any other major development language, and, at some risk of unintentionally offending some, I'll submit what many of us said long ago, which imho has certainly proven true: the reasons were plain from the inception of JAVA, because JAVA's limitations and overhead were plain from its very inception. JAVA projects are notoriously more costly; notoriously more prone to flaws; and notoriously less efficient than alternative approaches. Talk to candid, truthful JAVA engineers, and you'll get the same story: Instead of realizing the promise of portability, they found they had to write down to the least common denominator -- the functionality of the least of involved systems. This itself "suggests" a very limited scope of functionality, achieved at great expense of learning those limitations "the hard way" -- and being "stuck" with them. Is JAVA as fast, cost effective, or reliable as the best development alternatives? Absolutely not. Nor can it ever be, because even before JAVA existed, development tools reached far beyond the potentials of JAVA. IF JAVA applications ever reached even the functionality threshold of conventional applications, it would be because local JAVA engines evolve to be as much as a second, redundant operating system. Is its concept even as clean and as clear as the best object oriented alternatives? No; and this answer particularly, if we are to respect the concept of building our wares out of the "right" building blocks, is a most important one, as it separates the right tools from the wrong ones. In engineering anything to be epitomized, nothing is done without a reason, and in fact, everything is done because ALL the questions were asked, and ALL the BEST answers WERE adhered to, without deviation. There is no "secret" to good engineering: it's a formula for closed doors to software failure (and thus insecurity); it's a formula for unlimited functionality; it's a formula for a balance of speed and resource conservation with no forfeiture whatsoever of reliability. In each of these areas, the very concept of JAVA suffers serious obstructions to excellence, to real portability, and thus to the cost and quality of end product. No time (or possibly place) for [more of] an article here, but you can count me among the many who think JAVA is a crazy way to do ANYTHING. Similarly, I believe there are subversive reasons behind the conception of DOT NUTS; I don't believe DOT NUTS either will serve its purported purposes -- and certainly no better than the best compiled executables of the present (except perhaps for areas of refinement of the object oriented architecture underneath it all -- which only suffers because the preceding architecture was in considerable areas, badly conceived). Interestingly however, the similarities between JAVA and DOT NUTS implementations are substantial. Even more interesting is the fact that our ahem, exalted, domineering, "fairly competing" company chose the architect of the best object oriented tools of this day -- and what many of us consider the first true object oriented development environment -- to try to engineer this concept into something maybe it cannot be. But they picked the best for a reason: the best was built on the right formula; and our giant monopoly really CANNOT "compete" unless such perfection is an integral foundation of their venture into a JAVA-like implementation, which strikes me most to serve the interest of involving particularly web development, with a system which at this very moment we can do entirely without, and best do without, if we are to maintain the standard of security carried by Linux. To make a long story short, I say executable web applications -- applications to which client-side executable objects are integral (versus data transmission supported by server-side functionality such as forms, web server applications, etc.) are INHERENTLY insecure, because merely opening the door to execution on the client

"Great" is subjective.

[Kickasso]

"Sound" is not. Eiffel's type system is unsound, and the implementation of MI is one of the reasons of its unsoundness. "Catcalls" are another reason.

I've spent entirely too much time on c.l.e and don't want to repeat all that argumentation again. Google has the archives, study them if you like.

Unicode support

[rikkus-x]

From the SmartEiffel documentation:

UNICODE_STRING
WARNING: THIS CLASS IS A WORK IN PROGRESS. SOME FEATURE ARE NOT YET IMPLEMENTED AND SOME FEATURE MAY APPEAR/DISAPPEAR.

Mature, fully-integrated Unicode support is in my top ten 'must have' features for a development system/language. I would think it should be in the Gnome project's, too.

Of course, C doesn't have built-in Unicode, but I'd guess that Gnome uses some library for it, as KDE uses Qt. In KDE, QString is used for 99.99% of strings and is a Unicode string. C-style strings (QCString) are only used for compatibility.

One of the things keeping me from doing more with Ruby is the fact that its String class doesn't do Unicode. I managed some hack, storing UTF-8 and converting with libiconv, but then I have to think about portability, etc. etc.

Re:Unicode support

[juhaz]

Mature, fully-integrated Unicode support is in my top ten 'must have' features for a development system/language. I would think it should be in the Gnome project's, too.

It is.

Gnome has been UTF-8 since Gnome2/GTK2.

Re:Laziness will always dominate software developm

[juhaz]

C++ syntax is almost identical to Java syntax. At least when you don't use some of the more powerfull, weird stuff of C++. (You are not forced to use that stuff) The main difference is garbage collection.

That "powerful, weird stuff" is what C++ is all about! If you don't use the features that are the main (and only) difference from C, why bother at all?

Hell I just verified the memory my Jedit was taking up right now: 40MB! Thats with only 12 relatively small text documents opened. Thats for a text editor! A text editor is the ideal example of an app that shouldn't take much resources.

A "text editor" with a featureset of jedit is by no means a small application that shouldn't take much resources.

jEdit != Notepad, as you well should know if you've actually used it as your primary editor.

Re:Laziness will always dominate software developm

[starm_]

I meant like templates and multiplie inheritance.

Re:Speaking of language syntax

[jabber01]

BRAVO!