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]

Oh yeah? Well I hope you have a nice day! So there!

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

[Anonymous Coward]

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

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

[Anonymous Coward]

You're thinking of "Eiffel 65", which is a very old specification.

In fact, "Eiffel 2004" is very stable.

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

[Albanach]

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

Why not just change your sig to "Don't trust a word I say"?

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

[Anonymous Coward]

Absolutely agree. Who wants to develop for a platform if they have to learn a new language to do it?

Re:Pointless

[Anonymous Coward]

If all that was changed is the spelling of the latin word for peanut, then big deal. That isn't surprising at all. If it was the introduction of a lie in an important entry, then maybe this is something significant. We won't know until it is disclosed, and I hope it is. After all, if the grandparent poster isn't satisfied, a new change can be made somewhere else, and bragging about the new change can begin immediately.

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

[Anonymous Coward]

In summary, what matters is the support for continuous slagging.
Port everything to Eiffel, then put down some Skyy vodka and port it all to SkyOS, and then get wierd and port the whole mess to Perl.

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

[Anonymous Coward]

Which means nothing in the real world.

Turning completeness has nothing to do with the real-world functionality of the language. Fact is, there are a lot of things you can do in assembly that you can't do efficiently in C and a lot of things in C that you can't do efficiently in Eiffel. No human could write a significant GUI app in assembly, let alone machine code. And I doubt a group of 50 humans could in 50 years (if ever).

You could theoretically duplicate any C++ program in the machine language of a hand calculator. Good luck with that... ;)

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

[Anonymous Coward]

Efficiency is irrelevant. It's a fact that any program in a turing complete language can be transliterated into any other turning complete language.

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

[Anonymous Coward]

LMAO - "Efficiency is irrelevant". You obviously have no programming experience in the real world. And if your professors have taught you this, they are incompetent.

Re:Pointless

[Anonymous Coward]

Do you consider Harley-Davidson part of the "real world"?

Because that is what apps are developed in at HD. Java.

No C++, Visual Basic etc...

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

[Anonymous Coward]

Yeah, I think they run their networks on Novell too.

Re:Pointless

[Fermier de Pomme de]

If you find yourself using case statements in an OO language like Java you are probably missing the point.

If you are using an OO language, use it properly. If you want to program in C then do so.

Re:Pointless

[AKAImBatman]

Thank you for making my point for me, sir. Java is not elegent from a purly compsci perspective. However, it meets the real needs of the marketplace, which is a very different beast from the ivory towers of acedemia.

FWIW, I don't think you deserve the -1 Flamebait. You were simply stating your opinion. One which I predicted was coming about 3000 miles away. :-)

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]

No human could write a significant GUI app in assembly,

Rubbish. Of course they could. Amiga people used to do it all the time. Now, they had a sweet macro assembler, and, granted, m68k assembler makes x86 assembler look like brainf**k, but my point it that until relatively recently, many GUI apps _were_ written in asm.

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

[Anonymous Coward]

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

The crucial difference is that you got paid to do that. GNOME relies on people giving up their time freely, and I think that it's far more likely somebody will contribute to a project that uses a language they are already comfortable with than a project that uses a relatively obscure language like Eiffel.

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

[Anonymous Coward]

Technicaly, you're correct.

But I was thinking about a modern-day application. I'm sure you can make some apps on the Amiga that would have looked good a decade ago. But for something that would match today's software/UI requirements, that would not even come close.

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

[Anonymous Coward]

Uh. No. Amiga UIs were quite modern, I assure you. How a GUI looks is not determined by what language it is written in. The reason people don't write in assembly is portability, not UI requirements. C offers NOTHING over decent assembly except portability, unlike, say, Lisp or whatever.

FYI, here's some amiga assembly:
CALLGFX OpenWindow

Just because x86 asm traditionally sucks doesn't mean it has to.

Re:Pointless

[Anonymous Coward]

It's hard to disagree with anyone who calls me "Sir". I normally merely insist on Your Holiness. That said...

> Java is not elegent from a purly compsci perspective. However, it meets the real needs
> of the marketplace, which is a very different beast from the ivory towers of acedemia.

It bothers me that people feel they can dismiss anything and anyone from academia on the ivory tower basis. Now I freely admit that 90% of academics have yet to discover what their shoe laces are for, but that doesn't man the other 10% of us deserve to be tarred with the same brush. I spend more time than I should getting this point across when I talk to industry - thankfully I've got my act down pat now. I think I might have a future in second hand car sales ahead. Anyway, I digress.

I have been writing code - sometimes commercially, often not - for many, many years. My opinion is one of a developer who just so happens also to be an academic. Yes, I design programming languages sometimes. No, I'm not silly enough to pretend they're Java replacements. Yes, I use mainstream programming languages a lot. No, I don't use Java anymore. Yes, I understand the theory. No, that doesn't mean that languages which ignore the theory are necessarily inferior.

(BTW, I appreciate your comments re: flamebait, which the original msg was not intended as).

Re:Pointless

[KingOfBLASH]

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

Re:Pointless

[Anonymous Coward]

As an Eiffel user I'd like to correct two incorrect points in recent posts.

> Eiffel is rarely (although not never) seen outside academia.

Fact: Eiffel is used much more in industry than academia. Its market has been large financial applications, defense, aerospace, health care. That you don't hear that much about it doesn't mean the applications aren't there. eiffel.com and other sites describe large projects at the Chicago Board of Trade, Axa Rosenberg etc.

> The language evolution depends on Meyer's whims

Fact: the language is currently being standardized through ECMA (TC39-TG4). Meyer was the creator but is no longer in control (although he is a member of the committee). The committee says it wants to finish the standard by the end of this year. ECMA has "fast track" status with ISO.

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?

[Anonymous Coward]

In my experience, C# alienates windows developers on windows, let alone linux! It's universally hated by existing windows developers I've talked to (admittedly, they were mostly VBers, but hey...)

Re:A new hot topic?

[Anonymous Coward]

I don't think syntax is an issue but I could be wrong. Tell you what... the next time the Eiffel community and I go out in my car to get pizza, I'll ask them if they think it is an issue.

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.

Re:A new hot topic?

[Anonymous Coward]

"Developpers"? Hehe. That's cool.

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

[alienw]

Neither C# nor Java are interpreted languages. In fact, they are light-years ahead of Python as far as speed goes.

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

[Anonymous Coward]

You're so funny you could make my dead dog laugh.

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

[Anonymous Coward]

Read replies above. Java bytecodes are compiled to native while execution. Thats why the virtual machine is name Hotspot. C# has a similar implementation.

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

[Anonymous Coward]

Large portage-ng discussions on the -dev and -core mailing lists. Moving away from python isn't for speed reasons, it's for flexibility and the ability to create a static portage with very few dependencies.

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

[Anonymous Coward]

Read replies above. Java bytecodes are compiled to native while execution.

They are? Man, I'd never have guessed that.

_EVERY LANGUAGE_ compiles to native in runtime if not before. They wouldn't work otherwise, the computer only runs native code, idiot.

Re:Python

[Anonymous Coward]

And compiling the bytecode to machine code at run-time is called ... DRUMROLL ... interpreting it.

All three still compile first to bytecode, then at runtime to machine code, obviously, if they didn't compile into machine code at runtime, they would not do anything.

Alternatives being, compiling to native code at the first compilation phase (like C), or compiling to native code straight from source without intermediate bytecode stage.

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

[Anonymous Coward]

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

Fuck that. I'm writing apps in Python today and making money.

Re:A requirement he missed

[p3d0]

Eiffel is very easy to learn. Try it.

Better learn C#, boys

[Anonymous Coward]

With Sun having thrown in the towel, Java is not long for this Earth.

Which is fine with me, C# is the superior technology anyway.

And I don't have any idea what this Eiffel crap is - sounds French. Perhaps we should rename it to "Freedom"?

Re:Better learn C#, boys

[Anonymous Coward]

Actually, Eiffel is a region in Germany :P

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.

Re:Better learn C#, boys

[Anonymous Coward]

With Sun having thrown in the towel, Java is not long for this Earth.

What have you been smoking, dopey? Sun didn't throw in towel WRT Java. Law suits weren't going to do much for Java one way or the other; and them getting settled does likewise. Sun as well as IBM are fully behind Java, and there are no signs for either having much second thoughts there.

Eiffel is overly verbose

[Anonymous Coward]

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

Re:Eiffel is overly verbose

[Anonymous Coward]

Just use Ocaml.

I'd prefer to use a wire brush mounted onto a power drill as a toothbrush first. OCaml is ugly.

Re:Eiffel is overly verbose

[Anonymous Coward]

The use Perl! No Python for you!

Re:Eiffel is overly verbose

[Anonymous Coward]

I'd prefer to use a wire brush mounted onto a power drill as a toothbrush first.

Please leave dentists out of the discussion.

Re:Eiffel is overly verbose

[Anonymous Coward]

It can easily be argued that Eiffel is no more verbose than it needs to be to properly convey what's going on in the program, and that languages with C-like syntax (or other, terse, punctuation-based syntaxes) are not verbose enough.

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

[Anonymous Coward]

Of course you *can* make C++ secure and relatively memory leak free. But the point is that even with the STL, it's far more work to do it with C# or Java.

If you don't require the speed of C++ for most/all of the application, it's simply too slow and inefficient to develop in C++ nowadays. For critical routines (found by profiling, not guessing) it may make sense to put together a C++ (though preferably C) dll that speeds up critical areas.

The problem with C++ is that is tries to be both a low level language and a high level language simultaneously. When programming something like an OS, this may be a benefit. For just about anything else, it is a liability.

Re:STL

[Anonymous Coward]

"Of course you *can* make C++ secure and relatively memory leak free. But the point is that even with the STL, it's far more work to do it with C# or Java."

The reason I wouldn't recommend C# and Java is that there is no guaranteed way to write portable code that allows you to call functions from other languages. You have to deal with the runtime, so the only way to really do anything useful is through IPC. In C++ I can just list an extern function, and it works at link-time. So if I want to use Java or C#, I have to throw away a huge codebase or make a nasty kludge that uses IPC to communicate with my old code. And since C++ still plays nicely with other languages that don't use proprietary .NET or Java runtimes, I can simplify a complex datatype with lisp, use FORTRAN, and still have VB code making the interface. These are huge benefits and well worth it for being able to have a core group of competent C++ programmers who link together all the easier code written in easier languages or specialized languages by code monkeys.

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

[Anonymous Coward]

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

I understand your point, but I don't really see the bug as being that subtle. One of the core concepts of STL is that *it* handles all internal data. You have to use STL's operators to get to your data. As long as you follow this rule STL will be nice to you. Sure it makes coding a little more time consuming in some parts and in others it can make functions pretty long (as you call the different STL operators to get at your data), but it is safe. And while it may seem that using the reference would be a faster method of getting at your data, in many implementations it would be the same speed as getting your data from an array (or an array of pointers depending upon the data type), so you wouldn't see a huge speed drop.

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

[Anonymous Coward]

Thanks for proving my point. These competitions are for coding very small programs or even very small algorithms and are specifically testing the speed of those programs/algorithms, even when there is no real need for it. At any rate, ptimization of small sections of an application are exactly what C++ (or better C) is good for. Which was half of my point.

If you look at the applications listed for sale on the site - you'll see the only one listed is for Health Care Order Processing - which used Java.

The vast majority of code in professional applications (*especially* UI) does not need the sort of optimizations found in the algorithm competitions and the like. If you're using C++ for most of the application, you're just wasing your own time/money.

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

[Anonymous Coward]

Programmars make languages and languages have failings as much as anything else. Fact is, C++ is quite unorthogonal throws in everything but the kitchen sink and it's complexity/semantics also demonstrates rather poor design, IMO. The end result is that undocumented C++ code is often unreadable. A lot of other languages don't suffer from that sort of problem.

To look at it another way, you could make the same argument as above for any convoluted, if powerful, application. But no programmer who actually earns a living from programming would blame the user for not understanding the odd "features" of the application. At least not any who want to remain in business. ;)

Which is probably why C++ is losing mindspace to C# and Java. They are simply better designed and better tools for the great majority of jobs.

Re:STL

[Anonymous Coward]

I don't think you have any idea what topcoder is about. The only grading criterion is submission speed -- as in, how fast you go from reading a problem to clicking the 'submit' button for your code. As long as your code produces the correct output within eight seconds (easily possible as long as you aren't using an exponential algorithm), efficiency is irrelevant.

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

[Anonymous Coward]

Yeah, but in some languages, you have to be "talented" to make a program unreadable. ;)

In C++, it may not be the norm - but you don't have to be "talented" to make unreadable code. There are more "clever" C++ snippets floating around than you can shake a stick at.

I swear some people think there is a relationship between the size of a line of code and how fast it runs...

Re:STL

[Anonymous Coward]

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.

No, it's not. It's a full-fleged language, just like Smalltalk.

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

[Anonymous Coward]

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

But in any other language, it would have worked. The problem is that C++ (with STL or not) has one million ways to kill you, for no good reason. Why use it?

Re:STL

[Anonymous Coward]

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.

Wrong. In any other language (Java, Ocaml, Python, Ruby, Perl, Smalltalk, Ada, ...), it would have worked. Because what he did, was to take the reference of one object in a container. Why the hell, should that refence become magically invalid ??? Indeed, in any other language than C++, it doesn't.

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!")

Huh? The bloat of templates and declarastista is real and is a major problem in C++ (declare, declare, declare, declare, declare until it make you vomit, declare iterator types, declare iterator functions, declare wrappers here, and again, and again, and AGAIN, I have C++ code which is 70% declarations, while my equivalent Python code is 90% code. Fuck C++). In communist Russia (or even, in Lisp, Ocaml, Smalltalk, Python, ...), you don't have to put templates everywhere, because you don't have to declare the type.

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

Ocaml is faster than C++.

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

[Anonymous Coward]

what he did, was to take the reference of one object in a container.

What he did, was to take the reference of one MEMORY LOCATION, which at the time pointed to object in a container.

Why the hell, should that refence become magically invalid ???

If it would be a reference to an object, it shouldn't, but it's not.

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

Mainstream language

[Anonymous Coward]

What ever language is chosen it should be a mainstream language, or the community will be having this discussion again in two years instead of ten. I could give all the reasons why, you could give all the reasons why not, but at the end of the day it's human nature that plays the biggest role... plain and simple.

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

[Anonymous Coward]

The features are emulated. For example, if I have a program that has array bounds checking and do

x = y[z];

Then the c code produced will be something like

if ((z < 0) || (z > array_size_get(y))
exception_throw(exception_out_of_bounds_new());
x = array_get(y);

get it?

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

[Anonymous Coward]

Yay! A hardware specific programming language that's just like Objective C but broken!

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

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.

Re:Interesting points, but...

[Anonymous Coward]

Ada? Small syntax set? I don't think you know the same Ada I do. Last I checked, Ada had the biggest syntax around. C++ may have caught up, though, but Ada95 may have leapfrogged it.

aQazaQa

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:Why the fuck

[Anonymous Coward]

[Why the fuck] Don't they just:
1) Code the core stuff in C.

They do.

2) Let people that like other languages code wrappers to a well designed API

They do.

3) Allow the people that code their user applications in whatever works best for them.

They do.

Don't buy every last piece of FUD you see floating on Slashdot.

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

[Anonymous Coward]

Wow, you sure have a hard-on for Ruby! Probably about the same as mine for Perl.

I completely agree that mixing and matching languages is the best way to make a complex project have clean code. But I think that you missed my point, where if you put a newbie C++ coder down and have him do some work, he will probably be about a tenth as useful as a wisened C++ hacker. The only way for him to get good at C++ fast is to sit down with the 'old fart' and learn the intracies of C++ (which are unfortunately not very well documented since most computer programming writers aren't developers). This is the same for any language to a lesser extent.

This is a classic argument I've have with CS academia for years: that learning the concepts of CS will make you a better programmer than learning the hacks. I believe the hacks make a better programmer counterintuitively because they make you think more like a computer and less like a mathematician. When you think like the computer only then do you truly understand what is happening to your data. CS academia don't like to think that low-level (hence the minimization of assembly language programming, little education on how linkers work, little education on optimization techniquies, and in many cases no knowledge whatsoever on the digital electronics concepts that take place inside a microprocessor--don't believe me? As a CS graduate the differences between CMOS and TTL or what a control bus is). Sure their code looks nice and pretty, but once it crashes you know who the real programmers are when it comes time to debug the crash dump.

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

[topics]

Things like learning how to deal with pointers

A good programmer understands what he writes.

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

[perlchild]

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, and it's certainly raised equivalent uncertainty to sun's ownership of the java platform

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

[Anonymous Coward]

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.

No legal strings attached? Hah! Since when has the law been anything but a tool to Microsoft? It doesn't matter what standards bodies C# is endorsed by; Microsoft only needs to create the appearance of impropriety in the press to scare off corporate interests and bully hobbyists. Stick to C/C++ until something besides a corporate thug proposes a decent replacement.

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.

Re:Open your mind

[Anonymous Coward]

Your hired!

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?

[Anonymous Coward]

I love Objective-C. I really do. But it's a language of the past. I think that the first rule for jumping onto a new language choice for an entire framework should be: does the language support automatic garbage collection? For me this is the hallmark of a decent application-level, general-purpose language.

And no, retain/release is NOT automatic garbage collection.

Re:Objective-C?

[Anonymous Coward]

GCC's Objective-C compiler supports the boehm garbage collection system for quite a while.

Anyway, if you require a programming language to have GC (to be used in/with/by your framework), then you framework design is seriously flawed.

GC is nice. But it's for the lazy.
If you can't solve your problem without it, there's something wrong with your solution, not with the problem!

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?

Re:Objective-C?

[Anonymous Coward]

Boehm is a *conservative* collector. It can't distinguish between pointers and ints. It's also noncompacting and nonincremental. Wake me up when Objective-C (or C, or C++) becomes a language which is GC-safe.

Re:Objective-C?

[Anonymous Coward]

GC is nice. But it's for the lazy. If you can't solve your problem without it, there's something wrong with your solution, not with the problem!

This is idiotic. In real world, when the application gets complicated, 30% of the time may be spent just to manage memory. Tell that to your client:

• "30% of the price of your application is manual memory-management - this will cost you about $1,000,000"
• "Ah, so it can't be automated..."
• "Oh yes it can with GC! But GC are for the Lazy!"
• blank stare.

From what planet are you coming?

linux coders seek more obscurity, more news at 11

[Anonymous Coward]

nice job

You're right!

[Anonymous Coward]

Eiffel has way too many current users. It's not academic enough! Bing on Sather (first I'd heard of it) or some of those ML type of languages. Maybe somethig more functional? Miranda anyone? I think there are about two corporations and about fifty universities that use it. That'll scare away the developers if Eiffel won't.

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

[Anonymous Coward]

In my opinion, C# is, in every way, a better-designed language than Eiffel

Any open source developer that uses C# is just begging for trouble. 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, they only require Reasonable And Non-Discriminatory (RAND) licenses. In case you weren't paying attention when the W3C tried to use a RAND policy, it is completely incompatible with open source software.

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

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

[Anonymous Coward]

I can't answer to your other claims, but this one:

- failed to come even within an order of magnitude of equivalent C++ code in terms of performance

is not even close to true. Performance differences like that haven't existed in SmartEiffel/SmallEiffel for at least 5 years.

Here is one comparison of many languages (including C, C++, Java and Eiffel):

http://www.bitboost.com/people/intro-to-python-tcs /intro-to-python--2002-11--special-topic--runspeed --002.html

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.

Re:I don't think so

[Anonymous Coward]

The possibility of catcalls is the one and only botch in Eiffel. If a subclass doesn't fully implement the interface of a base class, it's not a subtype (it's not substitutable), so assignment and argument passing shouldn't treat it as conforming to the base type. Even C++ gets this right by offering private inheritance.

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

Re:Legislating nature

[Anonymous Coward]

Free Software does nothing to diminish number of programming jobs, it just moves the focus from initial development to maintenance and customization.

And unfortunately, us crazy hobbies need that magic substance called money too, so "monkey work" in the side is kind of needed, no?

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:Successor to C???

[Anonymous Coward]

Yeah... you don't actually know Java, do you?

Quick quiz: what's the maximum number of bytes before Hotspot won't inline a method? I thought so.

*REAL* programmers aren't so foolish as to lump Java/C# and Visual Basic in the same category ("Great languages for non programmers").

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.

I don't like C#

[The MESMERIC]

And I program in it.

Re:I don't like C#

[magadass]

Yeah its amazing how you dont like something when you suck at it.

I program in C#, came from VC++ WIN32, I like C# alot, its a great language and rapidly speeds up the productivity of a project!

Re:I don't like C#

[The MESMERIC]

How do you know I suck on it?
Unlike you I have a finished webapp in the same server ;)

Now suck this :)

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.

Re:Successor to C???

[steve_1x0]

You're right. I should have included LOGO and GW-BASIC as well.

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.

Re:Successor to C???

[Anonymous Coward]

"Let the script kiddies play with Java, Perl and the rest of that crap."

By this comment alone everyone knows that steve_1x0 is a moron and that his posts can be just as pure nonsense. If you need and more proof of his idiocy look at his comment history. Is there any way to mod his posts down permanently to "-9999 steve_1x0 is an idiot."

Eiffel.... ick!

[austus]

Eiffel has unforgivable Pascalisms and other nasty crap in its syntax. Fsk ":=". And fsk "END". And fsck all the rest of the silly shit I see in the syntax. Modern programming language designers need to take a good look at Python syntax before designing their machine code compilable languages.

Personally, I'd like a nice staticly typed Python-like language to fill that need.

Re:Eiffel.... ick!

[Anonymous Coward]

What's wrong with using ":=" as an assignment symbol? Even if you don't like the syntax, there is at least some logic behind its use. Why does it make sense to use the equality sign ( = ) to denote assignment (which we all understand to be different from equals) and then to use two equal signs to actually mean equals ( == )? How daft is that? After all, everyone understands the equal sign, why re-define its meaning?

Re:Eiffel.... ick!

[Anonymous Coward]

Begin and End are no different than { and }. And := no different than =, and = being equal to ==. Assuming you come from a C-like language background. But you're obviously out to just push one thing, and ignore anyone different.

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.

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.

Re:Laziness will always dominate software developm

[Anonymous Coward]

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

Nonsense. Bad code can be written in any language. Well-written Java code is fast stuff. The two primary speed problems in Java are: (1) multi-dimensional array lookup and (2) the need for casting from Object arrays. Outside of that, my experience is that Java code is quite fast.

And C++ is much harder than Java. Its syntax is gigantic and tacked-on,

... and only mean to be run by me for a school projects.

Ahhhhh.... suddently everything becomes clear.

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?

Don't you realize this is a vanishingly tiny percentage of total runtime?

For people who say Java is fast, do you think Jedit would run on 386?

Java the language != Swing. Go back to school.

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.

Re:Realistically, Java

[Anonymous Coward]

I used Java for a GUI project for 2 years, and although the language and tools have some very cool features, the performance, memory consumption, and terrible garbage collection have now turned me away from Java.

I profiled the hell out of the code. I found places where my code caused some of the problems. So I added flyweights, object pools, and made other memory- and performance-enhancing modifications to the design. At the end of the day, however, the raw drawing performance of Java (particularly on text) was about 10 times slower than that of some C/C++ rendering code I was comparing it with.

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?

and yet....

[Anonymous Coward]

You're right, you need to know how your compiler interacts with the machine. 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.

Re:and yet....

[Anonymous Coward]

Just a pointer: GC has been available in propietary and non-proprietary libraries for C++ for over a decade. Programmers are always free to use it, though some prefer to register objects in debug code so as to be able to check on destructions and still squeeze out the most performance. And then there are some who are evil enough that they do neither.

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

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.

Re:and yet....

[Anonymous Coward]

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.

To clarify, the "usual form of leaking" occurs when some dynamically allocated memory is "lost" by the application. It has no pointers to the memory, and therefore cannot deallocate it. GC'ed languages "leak" when they accidentally maintain a reference to memory they don't need any more (usually in some data structure that persists during execution). They both will free the memory "in the end" (meaning program termination), so the resulting effect is generally the same.

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

your sig

[Anonymous Coward]

(At the time of writing, m00nun1ts signature was:

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

Yeah, and I pissed in your fucking OJ this morning. Not literally, but all societies are based on trust and cooperation. Go and fix it again, you vandal.

Wikipedia will always have some amount of entropy. That's hardly news.

Re: your sig

[Ctrl-Z]

And this differs from any other Web site how?

Re: your sig

[Anonymous Coward]

It doesn't need to be trusted, and lacking trust does not make it a toy(I assume you mean this in a pejorative sense). The same could be said of print books, journalism, and even peer-reviewed scientific research. All of these sources contain factually incorrect information from time to time. None of them can be trusted, but they are all still useful.

Re: your sig

[Anonymous Coward]

(I did some nasty comment about orange juice that I can't remember. Sorry for that.)

The point is well intentioned people can put in factually incorrect information and it may not be corrected.

It can be corrected and I hope you've done so, now.

I don't trust any information source, we just have to make do with what we've got.

You put in something that was factually incorrect. So can the editors of the New York Times.

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:Laziness will always dominate software developm

[Anonymous Coward]

Here's what I believe is the biggest reason they don't: they're lazy.

People aren't always lazy. To create rich, responsive, fast native desktop applications, C and C++ are better choices than Java or Python. That is why a great deal of development continues in these languages. Note that I didn't say they were better languages ("better" is always a subjective viewpoint anyway), merely that they can create faster, more responsive programs on less-powerful hardware.

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)

Speaking of language syntax

[The Monster]

Learning the syntax of a new language should not be a significant challenge

How about learning English? I can't take an 'article' seriously if it has errors like:

the ability to expose it's API's

We don't want to loose one of the big supporters . . .

The language needs to be portably to different platforms and operating systems

(If you have to ask what the errors are, please don't write 'articles'.) Can we please debug our English at least as well as we do our source code?

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

Re:Speaking of language syntax

[Anonymous Coward]

We all make typos. If you don't want to argue against someone's point, be honest with yourself. The grammar problems you pointed out weren't that bad. Maybe if you showed him those 3 fragments and he couldn't find the problems it would be bad. Who double checks posts on slashdot anyway? There's no point to it. We got what he was trying to say. If you didn't, I guess you can just ignore it then.

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:Speaking of language syntax

[optikSmoke]

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

Quoth the grammar nazi.

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?

Re:Speaking of language syntax

[jabber01]

BRAVO!

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.

Please stay with C/C++

[Anonymous Coward]

But if You absolutely have to stray from the good ol' trusted model take a loot at other options like O'Caml: http://www.ocaml.org/

Cheers

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?

Re:Why change?

[Anonymous Coward]

Well, they wouldn't.

And they aren't.

GNOME project is not switching languages, this is just typical /. nonsense.

Glib

[Anonymous Coward]

For all the people who say that C should be used because it is well known by everybody so there is a low point of entry -- have you seen GLib??? It's another language!

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.

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:Pascal

[Anonymous Coward]

If people were to seriously consider pascal they would be better off going to Ada. Ada has many similarities with Pascal, but has many significant improvements. Pascal suffers from fact that almost every vendors has developed its own set of non-standard non-portable extensions that are needed to make it suitable for low level programming and other common tasks. Ada, on the other hand, was developed with the full range of programming tasks in mind, including low level bit banging like C. Ada was also designed to support large programming projects rather than teaching. Ada is standardized, portable, modern, object oriented, strongly typed, efficient, and widely available. Oddly enough it is more popular in Europe than the US.

Ada is often maligned over a number of canards. It is often claimed to be a big language, but it is smaller than C++. It is claimed that it was designed by committee when in fact what is now Ada was the winner of a contest between three languages, each of which had a primary designer, submitted in a contest. It is claimed that all of the compilers suck which was pretty much true, in 1983, but hasn't been true in a long time. Some people claim that since it is a "military language" that it isn't suitable for general purpose programming, but that is nonsense. Ada is a general purpose language and isn't limited to "military applications" any more than COBOL was.

I think that one of the big reasons that software is so bad, has so many bugs, and costs so much to maintain is that the primary development paradign is "throw something together in C." A better design process and Ada would help reduce problems in the software industry.

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.

[Anonymous Coward]

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

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.

[Anonymous Coward]

Any program that loses the last pointer into an object and then expects to create another is fundamentally broken (though it may appear to work on many systems). Pointer arithmetic is only allowed within an object, and there is no non-pointer type defined to be large enough to hold a pointer.

Re:Give me a break.

[Anonymous Coward]

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

This is only a problem for reference counting (it's the smallest possible cycle). With a real garbage collector, if an object is unreachable, any references it contains are ignored and cannot make any object (including itself) reachable.

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

[The MESMERIC]

Look for this article on Learning to program with Javascript -.
I haven't read the article, but since HTML -> leads to Javascript .. it might be an interesting step.
Or good luck with Revolution - I was thinking of inspecting it more - shame it's proprietary with 30 days trial.

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.

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.

Jeebus

[Anonymous Coward]

When you build something and hits a problem, there are 2 ways of dealing with it.

1. Going back to step 0 and redo from there.
2. Make things work and move on.

GNOME's progress is SLOOOOW because its leaders are trying to redo the same thing over and over and over and over and over, like choosing another language would magically solve all of their problems.

While another desktop, which I'll not name, chooses 1 language, sticks with it, and then concentrates on the applications themselves.

I'm sure this will not be the last time GNOME reconsider its programming language choice. Gimme a break - you cannot anticipate future problems so it is impossible to choose a perfect language.

I really hope this is the last time "programming language" is the main focus of future GNOME directions. Really. They are all Turing complete, thus equivalent. Just choose one and STICK WITH IT.

If, 3 years from now, we come back to the same question, then it's the time GNOME dies.

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.

The D Programming Language

[Anonymous Coward]

fits the requirements just file. TDPL. There's even a gnu implementation of it now.

Re:No, in fact people claiming a move are full of

[Anonymous Coward]

Well not quite. No one is saying anything about rewriting GNOME in some other language. The issue is whether or not they add a new language to the list of languages that official Gnome applications and libraries can be written in. If they chose c#, it would mean that you could go write an application in c# and still have it be considered an actual part of gnome and not just a GNOME compatible application.

In the end it doesnt really mean much for the average user or developer. Someone who wanted to write something using C# and GTK# would do it whether it was officially recognized or not.

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

OAMSD

[Anonymous Coward]

Once Again, More Slashdot Drivel!!!!!!!

Why is this moron modded up? What this moron is saying the more languages you pick up, the more skillful you are; on contrary, if you learn one language and can do it better than everyone else, you're some whore that is replaceable. Then the moron goes on to say all you need is two weeks to learn from a book to get the job done well.

Does something sound familiar? MCSE anyone?

If you can't communicate well with your out-sourced office using only your native language, you're "a one trick pony" - a pony who can save the company money for a short term. Even if you take 2 weeks to read a book learning the out-sourced's native language, you're still "a one trick pony" who think you can learn something indepth from a book in two weeks.

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

Go ahead and do it!

[Brandybuck]

Go ahead and do it! As a KDE fan, I think this would be the greatest thing Gnome could do. Switch to Eiffel, round up all of the five Gnome developers who know Eiffel, abandon the others, and rewrite the desktop from scratch in the new language. No way in the world would KDE be able to compete with that!

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.

Re:Compiles to C != As fast as C

[Anonymous Coward]

Specially for the zealots:

Delphi is the payware version of Free Pascal

www.freepascal.org

Now you probably recognize it :-)

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.

Re:perl6

[Anonymous Coward]

A 20% improvement can be realized by simple tweaking the official perl5 interpreter's code. Since Ponie would never be 100% perl5 compatible it would have to be at least twice as fast as the official Perl5 interpreter for anyone to want to make the effort to port their perl code to it.

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?

[Anonymous Coward]

Thanks for the hair-splitting, you qualification-spewing asshole. Next time post something useful.

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.

Re:Do you know any other languages?

[Anonymous Coward]

I'll grant you Java, but ... PERL? Perl belongs to C-family?

You MUST be kidding.

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

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.

Re:Security Manager

[Anonymous Coward]

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

At what cost? Since they are running virtual machines they can control their input and output fairly well. But at the same time you can't link your old functions from outside your virtual machine. The only way to communicate is through IPC which would a complicated solution. The only other way is to throw out your old code and start anew with C# or Java.

Nope

[rauhest]

It doesn't support internationalisation.

Who cares

[Anonymous Coward]

Who cares anyway. The current direction of Gnome is nothing more than trying to be like Windows. So we have Gnome that looks nice but is doomed due the people like Havoc and other "usability" morons.
I mean... remove the tab completion just to simulate Windows' "tab is used to move to the next UI element"? Get real. What's next? Remove the tab completion in Gnome-terminal?

We have KDE, which still has the depth of options and freedom that *nix is all about, but lacks all the nice looks of Gnome. The themes are bad, the icons are really bad, the panel is a pain and the icons on the toolbar are too close to each other.

And we have a lot of old window managers that look like they came from Eastern Europe anno 1980.

The Gnome people should focus on making browsers support videos flawlessly, support Flash flawlessly (my browser hangs like never before whenever I'm trying to open either a video or an Flash thingie), they should focus on making administraion of fonts easy, they should focus on making a functional clipboard for all applications. They should see the big picture, not trying to remove each and every choice the user can make.

The KDE people should work a bit on their usability, but my guess is they're scared after seeing what happened when the selfproclaimed GUI experts took on Gnome.

Personally I'm tempted to go back to using Windows. If Gnome is never going to be anything but an attempt to copy Windows, I might as well use the original. And I'll keep praying that some day a brave hacker will fork the entire Gnome desktop and start embracing the nice features that make *nix unique - like tab completion.

Havoc, you ought to be ashamed of yourself. It's not nice to alienate all the good, old Gnome users.

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.

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

Eiffel experience...

[Anonymous Coward]

I have used Eiffel for over 10 years, and keep using it because it is far superior to Java or C# - it properly supports OO semantics, and is the only language with contracts support. Java was a 10-year old language design when it came out, and in my view, it's really quiet hopeless now semantically speaking. It may be ok for programming, but not for building reliable, fast, model-based components. C# is only slightly better; and worse, programming in either of these makes it harder to integrate with tools built in the other language.

My motivations to use Eiffel are due to the hard requirements of reliability and maintainability, originally in control systems, more recently in health. (And I programmed in C and C++ for years before Eiffel).

Eiffel is easy to learn, has nice tools and libraries, and can be integrated with C# and Java, as well as other languages. And there is a nearly 1:1 relationship from the model to the code. Java seems to me to be a single-language lock-in; C# seems to be a single platform lock-in (but may change). Maybe a few of the commentators here might have a look at Eiffel before commenting?

- thomas beale

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

[Anonymous Coward]

Really, the world is better off without the programs these people might write.

The world with 2 computers and all-powerful programmers writing software in punch cards, perhaps.

The real world, however, is not. Welcome to it.

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: Pointless - NO SECRET TO GOOD ENGINEERING

[Anonymous Coward]

Just a hint: you may find yourself with bigger audience if you learn to outline your text.

That's completely, totally, unreadable. I didn't think anyone could mangle English to almost resemble perl...

Ocaml

[Anonymous Coward]

Ocaml Ocaml Ocaml, did I say Ocaml? Why specify types when you just don't care, let the Ocaml compiler figure it out and smack you if you made a type error.

button#on_click
(fun () -> text_area#add "button clicked.\n")

Higher order are just great for connecting up all those disparite gui elements.

Throw away all those old crusty languages like Eiffel, Java, C#, and C++. They just don't cut it. And while you're at it throw away all those old void pointer languages like Smalltalk, Python, Ruby. I mean who wants to find out about a type error at run time, really.