Submitted by “I followed the debate about a successor for the C/C++ combination as the primary language for developing the GNOME core desktop platform very closely last month. There has been discussion about a number of options. What I would like to do on this page is give an overview how a probably less well-known language might be a viable compromise as a C/C++ successor. This language is called Eiffel and exists for over a decade. Eiffel takes the principle of Object-Oriented programming to its extremes and, as a consequence, is a very easy to learn language.”
I’ve always liked how powerful this language is for industrial tasks. Hoorah!
The whole of Gnome is written in C, not in C++ (or perhaps a *very* small amount of C++). Thus the discussion is not about a successor for C/C++, but for a successor of C alone.
You forgot one important criterion: The programming language you choose must have broad support among developers as otherwise you run out of volunteers doing the work quickly. GNOME already as a problem to find new developers when using a popular language like C. Using an exot like Eiffel would drain the source for fresh developers even more and therefore switching to Eiffel (or any other exotic language) would effectivly kill the GNOME project quickly.
If you need a proove, just look how much the Java vs. Mono vs. Python battle splits the community already.
Edited 2005-11-26 18:35
> Using an exot like Eiffel would drain the source for fresh developers even more and therefore switching to Eiffel (or any other exotic language) would effectivly kill the GNOME project quickly.
Eiffel is NOT a language for the language lawyers; it is designed to be very simple to learn, write and read. Its syntax is very straightforward.
Unfortunately, this is a not so known language, so using it in GNOME would be a very good thing to make it much more popular.
Syntax is largely immaterial. A little bit of a learning curve is no problem for something you’re going to be using to build very large programs. The question really is semantics. It seems to me that Eiffel hails from the same side of the language debate as Pascal, and honestly, in this day of highly dynamic languages like Ruby, Python, and even Objective-C becoming popular, do we really need to retread that old road?
> The question really is semantics. It seems to me that Eiffel hails from the same side of the language debate as Pascal, and honestly, in this day of highly dynamic languages like Ruby, Python, and even Objective-C becoming popular, do we really need to retread that old road?
Hum… I find it easier to understand the semantics of static languages compared to very dynamic or abstract languages.
And syntax and semantics ARE very related to each other.
related only by the hierarchal structure of language development.
Syntax can be right, but if the semantics are off, you have a logic error.
“The Dog ran for a touchdown at home plate”
syntactically, that sentence is correct., Semantically, it is gibberish.
That is how syntax is related to semantics…. IE, not very tightly.
Now what’s wrong with Pascal?
Object Pascal is C++ done right
It doesn’t really matter anymore what language to use. So Gnome should support all of them. Eiffel is a possibility, but it’s not exactly widely used, so moving from C to C++ in Gnome would be better.
Writing the major part of Gnome in C was a major mistake. C++, Java (compiled to native bytecode), Object Pascal are all better to do a task like Gnome.
it doesn’t really matter anymore what language to use.
That was precisely Microsoft’s point when they designed C# (“A language specification that compilers can follow if they want to generate classes and code that can interoperate with other programming languages (The Common Language Specification: CLS)” see: http://www.mono-project.com/Mono_Rationale)
De Icaza has written extensively about it, but nobody seemed to care, and FUD spreaders just said Mono was “like Java, Microsoft’s Java.”
And now, the community is further split because RedHat, due to their enterprise requirements and in order to compete with Novell, chose Java instead of supporting Mono. Great… As a side effect, shit spills over the other free UNIXes (the BSDs), because Java won’t work there.
Yeah. C culture is going to kill UNIX. Not Microsoft.
Eiffel makes a lot of sense. Think about it it. You can have Mono and Eiffel.The possibility is there by design:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn…
People have to understand 2 things in the free software community:
1) C is bad;
2) Java is bad (well, it’s proprietary – and it’s badly designed)
Well, C is good, Java is good, C++ is good.
Personally I’d recommend switching from C in Gnome to C++ as the language used for Gnome itself.
Other languages will be supported via bindings. Then users can develope in whatever language they want.
C# is pretty much overhyped in my mind, but it doesn’t change the fact it’s useful. But still.. C++ is my choice, though Object Pascal would be easier for more ordinary people to handle.
Java is good for smaller user applications, but I’d rather not use a DE written in Java
Eiffel is NOT a language for the language lawyers; it is designed to be very simple to learn, write and read. Its syntax is very straightforward.
But the documentation is absolutely HORRIBLE. No good free tutorials available online.
With enough exposure the community can build itself. Kinda like advertising. You already have a captive audience. Get a few key Gnome people to hype it up. Release a killer application written in Eiffel to draw a little more attention,to it. Then you have a small but decent group of curious and/or sold developers. From ther let it snowball.
Look at how one guy got sold on Haskell and suddenly you have the Pugs project.
C is amazing and gnome must stick to it. It ca also use ObjC or Embedded c++ (like Apple for kernels).
For scripting Python or TCL are good.
Following the debate until now, I think there are a number of requirements which need to be fullfilled when we choose a C/C++ successor:
Just write the bindings and use it if you wish, but stop talking about “we” when there will never be consensus on such an issue.
In the somewhat ideal world “we” would have a universal runtime so everybody could just use whatever or something like XPCOM (don’t know much about it), but there hasn’t been much talk about that in a while and since the Gnome 3.0 idea is going nowhere fast (Havoc Pennington made a post about 3.0 a while back), it’s pretty much futile to discuss huge architectural issues without also discussing a Gnome fork.
Edited 2005-11-26 18:41
I think the idea is for Gnome Foundation to support one other language for bindings…
The trouble with your average language binding is that they usually lose something from the original library. For example, I was playing with pygame a while back (a binding for python to SDL). It turns out it’s not really full bindings, it’s more like the minimal functionality you need to quickly throw together small, low complexity, 2d games. Which they are pretty honest about.
The second trouble is that they always release later than the actual library (that doesn’t have to happen if the same people who are working on the library are slapping someone and saying “hey, write a binding for what I just changed.”
And the biggest reason to pick one (although this isn’t a problem for eiffel, since it apparently compiles to c) is that languages like python and java both incur a runtime; and many users don’t have that kind of RAM just to run some tiny extra program. And developers know this; so they end up writing in c or whichever high level language is more popular on the platform (Python right now for Gnome).
That doesn’t mean bindings won’t happen for odd languages. But it does mean better documentation for people who develop in one of the supported languages. Some of Gnome’s documentation is terrible, but the GTK documentation, for example, is wonderful.
Yeah, bindings suck because they are always second class citizens, but Gnome is so stagnated in politics that nothing ever happens to address the obvious shortcomings in Gnome as a development platform that are recognized by Gnome developers.
The best intermediate term thing I could see happening is that all GUI functionality for Gnome is moved out of Gnome and into Gtk+ (which is supposed to happen), and then start working on some kind of component system like Kparts with Dbus on the backend.
Absolutely. I’m excited for Gtk 3 for just the reason you state; I want some of those extra library functionalities but I refuse to touch Gnome libraries.
I think you’re right though, Gnome is far too political right now. This is one thing I find attractive about KDE: While it’s oversized, bloated, and there’s a lot of programs in the distribution that aren’t good enough for that; the developers are psyched about writing code.
I’m fine with Gnome development being slow, but I’d like to see it be slow because it’s methodical.
Let’s be realistic here. One of the draws to open source programming is that it’s a fun way to learn new skills that you can bolster your resume with. Skills in C, C++, Java, and the .NET languages are in demand. Eiffel is not.
> One of the draws to open source programming is that it’s a fun way to learn new skills that you can bolster your resume with.
A resume is not a mere list of languages. Eiffel can be a great way to learn design by contract or even object-oriented design.
A resume is not a mere list of languages. Eiffel can be a great way to learn design by contract or even object-oriented design.
HR departments don’t give a damn about that though. All they know is that their job requires C++ skills (or whatever) and if you can say “hey, I made a big contribution to <some project> using C++” then that looks good. Saying “I learned design by contract using Eiffel” will be completely over their heads and you won’t even get past the initial screening.
First off, HR departments *definitely* don’t give a damn about GNOME, but I digress :-).
HR departments don’t drive IT requirements, so it’s really a moot point. If an IT project needs Eiffel, they better damn well let the HR department know that’s what they need, and give them a high level overview of what they’re looking for (at previous gigs I’ve done hiring for, we usually just give the HR folks a list of questions to ask with the associated answers we’re looking for).
What about bf then ? It’s definitely simpler than c/c++/java/anything out there, with it’s 8 commands… >:)
http://www.muppetlabs.com/~breadbox/bf/
I think the author was joking, right? Why not use an even lesser known language than Eiffel. As a joke I just thought of Forth. And then I thought about one of its derivatives: Display PostScript, which sounds like the right language to use with a Desktop Environment…
Seriously why reinvent the wheel, and why select a language that has fewer bindings than others? C suits me very well, as well as to all those who use any language of THEIR CHOICE to bind to the GNOME API.
Keep C.
Next!
Edited 2005-11-26 19:20
I agree with you. It sounds to me more like a joke than a serious “RFC”.
From the article:
This language is called Eiffel and exists for over a decade
Well, acording to the link to Wikipedia, it is two decades.
Eiffel takes the principle of Object-Oriented programming to its extremes and, as a consequence, is a very easy to learn language.
OOP != “easy to learn” IMHO
It seems that all requirements for the language of choice are fullfilled by C/C++ so, why change?
The thought has occurred to me. Maybe it’s a good limiting factor to only support C (especially if all language bindings dissappeared). Then you’d have to say “ok, is it worth it to write my own bindings for the stuff I need to do this in the language I want?”
What would happen? Fewer programs would be written, of course. But do we really want programs written by people who lack committment?
Just a thought. The reality of language bindings (which is a given with the sharing attitude in this community) sort of negates the idea as plausible. But I think the thought is important: We shouldn’t be picking a language for beginners and ease of developing small programs. We need a language that helps people who know what they’re doing.
Those articles that bytecoder posted by Paul Graham are very good. Everyone should read both
. Especially the arc one: http://www.paulgraham.com/noop.html .
And this section, of this: http://www.paulgraham.com/popular.html; wraps up why I don’t like Eiffel:
“It is a mistake to try to baby the user with long-winded expressions that are meant to resemble English. Cobol is notorious for this flaw. A hacker would consider being asked to write
add x to y giving z
instead of
z = x+y”
Compare to:
“from i := 0 until i >= 10 loop
my_array.put (0, i)
i := i + 1
end”
There is an exception to his rule though, SQL. Of course, SQL is intended for non-programmers as well.
It’s not really a big deal to type the extra stuff, it’s just annoying to read. Scanning through and seeing “loop” verse “end” is difficult: And if your editor can highlight it for you then why did you use so many characters for it anyway?
It also feels redundant to type what is obviously a foreach loop and still have to say “loop.” If it’s compiled, syntactic things like this are just obnoxious to the user; if it’s JIT that’s another story.
If it was just an “average” user writing the code (as is the case with SQL statements on a fairly regular basis) I would agree with you…we’re all (hopefully) highly trained professionals though, and the whole number of LOC debate is moot given the amount of help any decent IDE will give us at this point in writing code (and catching lots of stuff at compile time now). The example you gave is grossly exagerated as no developer on the planet would write that loop.
I have to be a smartass and say this about COBOL (as horrific of a language as it is): if “Cobol is notorious for this flaw” then why are there more lines of COBOL code in production than any other language combined? The obvious answer is that there weren’t that many options at the time of COBOL’s hayday, but it was also it’s verboseness that made it easy to program in (Visual Basic anyone?)…granted the quality of code might be low, but in general, languages suited to business (IT) use gain a bit from expressiveness as it usually fits the domain the language is being used in, which is why as great of a language as I think Eiffel is, it’s geared more towards business use; I can’t possibly see it being used for something as low level as GNOME.
The example eiffel was copied and pasted from their website…
There are more lines of COBOL because it was the only language for the job for an extremely long time. It was the language that the big guns ran. The only people who had those sort of machines were businesses, so managers were making the decisions.
And it continues to this day because no one wants to rewrite that old COBOL code. For a couple reasons:
1.) The company says no, cause that sounds expensive.
2.) They may not even be able to, it’d require someone who knows: COBOL, another language, and can design programs. Oh and the obvious: Works for the company.
So they add on, and add on. Eventually all this code will probably be replaced, but that’s gonna take a lot of time!
Why is so much code still out their in FORTRAN? The same reason, the original authors had no other language to use when they learned to use computers; and so later on they used fortran. Eventually they learned a new language, but they’re probably in a field where it doesn’t make sense to rewrite programs until you absolutely have to (ie, scientific, maybe even engineering).
The expressiveness of COBOL is what makes it hard to learn. I’ve been watching my roommate learn it. They don’t learn anything about programming with COBOL (as in, designing complex systems); they learn all the syntactical and functional niceties that let them modify streams. And they’re told that that stuff at the beginning is magic and they don’t need to understand it (which scares me).
LOC isn’t about writing code, as I said, it’s about reading it. English words are generally clutter and should only be used when necessary in control structures.
I really don’t see what’s so far fetched about that loop. Yes, no one would write _it_, but it’s representative of the sort of thing people do write.
LOC isn’t very important. It’s no reason to throw out a language, but it is annoying.
“And it continues to this day because no one wants to rewrite that old COBOL code. For a couple reasons:
1.) The company says no, cause that sounds expensive.
2.) They may not even be able to, it’d require someone who knows: COBOL, another language, and can design programs. Oh and the obvious: Works for the company. ”
Of course, “if it ain’t broke…”. As for two, there are quite a few COBOL programmers out their. Up in years, but still out their. Same with PL/1 and RPG.
You are a misinformed troll, just look at the following link. Anyone can make any language look bad if they want to.
http://en.wikipedia.org/wiki/Cobol#Defense
The same goes for people complaining about ALGOL and Fortran, even BASIC (if you can call recent BASIC dialects for BASIC at all).
Many non mainstream languages are meant to fulfill certain limited tasks or areas, and should be viewed in the light of these.
But apparently it’s so much more fun being religious about programming languages.
It’s easy.
Use C++ for Gnome itself, add bindings for other languages and hooray.. it works
Even thought C is a well known language right now, I think it could be a problem in the long run.
Today, most people who learn how to program, do so in some object oriented language and universities use languages like java or C# in their entry level programming courses. Most courses on software development and design focus on OO priciples.
This means that new developers may be less interested in Gnome and Gtk. Besides, GUI stuff is very well suited for OO development and people with current education will recognize this and get the feeling that Gnome and gtk is some kind of ghost from the past.
Even thought C is a well known language right now, I think it could be a problem in the long run.
Today, most people who learn how to program, do so in some object oriented language and universities use languages like java or C# in their entry level programming courses. Most courses on software development and design focus on OO priciples.
Whether or not that’s a good thing is debatable…
Besides, GUI stuff is very well suited for OO development and people with current education will recognize this and get the feeling that Gnome and gtk is some kind of ghost from the past.
That may be, if only because GUI programming is a rare case where screwing it up in OOP is virtually impossible to do.
-bytecoder
Gtk is highly OO. I suggest you look at it.
Those c machines don’t run c++ by magic. Some object things in c are *much* more confusing than say Java (nothing is more confusing than c++).
Only in the sense that “objects” (aka structures) are used to represent widgets. If you want to stretch it that far, you might as well call hello world in C object oriented, because you’re ‘sending’ the puts message to the string object.
-bytecoder
And that objects inherit functions from their parents. For example, if I have a GtkRadioButton I can call GtkButton and GtkWidget methods on it, because they’re both parents.
I’ve not tried getting too crazy with this, but it’s generally worked for me so far. I’m guessing it breaks down somewhere, and I’m sure the enforcement of the OO nature is by hand; but yes, you can write OO stuff in c. And Gtk is a very good example.
A hello world program in c would be simply sending a pointer to the first character of the string and the print function prints until it hits . It’s not showing any kind of inheritance, data hiding, or anything like that; so it’s not object oriented.
I don’t know what you’re talking about with this “string object” idea. It’s just a series of bytes on the program stack…
Object Orientation is a very abstract thing, and I’ve had it twisted against me many a time in arguments, which is why I prefer to define what I’m talking about beforehand. Object Oriented doesn’t imply another other than being “oriented” around “object”, neither of which is very descriptive. As far as I know, there is no definition of OO, and it’s doubtful there ever will be as there are so many different versions.
It’s not showing any kind of inheritance, data hiding, or anything like that; so it’s not object oriented.
None of those are intrinsic properties of OO.
I don’t know what you’re talking about with this “string object” idea. It’s just a series of bytes on the program stack…
So is any other type of data, which is where you miss the point. OO isn’t data, it’s how you look at it and treat it. Unfortunately, the general definition of “OO” tends toward strict and overcomplicated designs with lots of extra crud slopped on top of the code.
-bytecoder
“Object Orientation is a very abstract thing, and I’ve had it twisted against me many a time in arguments, which is why I prefer to define what I’m talking about beforehand. Object Oriented doesn’t imply another other than being “oriented” around “object”, neither of which is very descriptive. As far as I know, there is no definition of OO, and it’s doubtful there ever will be as there are so many different versions. ”
We’ve had this discussion before and I told you before that “Holub on Patterns” had a definition of what an “Object” was. Maybe it would be more proper to say that there’s a central quality of what OO is, and multiple misunderstandings of what OO is. OO seems to be right next to XML in the “misunderstanding” department.
“Unfortunately, the general definition of “OO” tends toward strict and overcomplicated designs with lots of extra crud slopped on top of the code. ”
Judging by a lot of code I’ve seen over the years. Apparently OO isn’t needed to get the above qualities.
Maybe we should start giving all programmers a copy of “The pragmatic programmer”?
We’ve had this discussion before and I told you before that “Holub on Patterns” had a definition of what an “Object” was. Maybe it would be more proper to say that there’s a central quality of what OO is, and multiple misunderstandings of what OO is. OO seems to be right next to XML in the “misunderstanding” department.
Exactly. There is no standard definition. What qualifies as OO is somewhat irrelevant to the conversation at hand, however.
-bytecoder
Well there’s not much point in calling it OO if everything is OO now is there?
From wikipedia:
“The idea behind object-oriented programming is that a computer program is composed of a collection of individual units, or objects, as opposed to a traditional view in which a program is a list of instructions to the computer.”
It’s still very vague, but I think there’s a clear line which would let any reasonable individual see that some things are OO, and some things are not OO.
Anyway, you’re running this off into a vague argument over nothing.
I have looked at it, and I agree with you, the ideas behind it are object oriented, but it is object oriented by ideom not by language. This gives people not realizing this, too many possibilities to screw it up.
Why not use a language that support these ideas, instead of having people do it manually. The fact that we can write structured programs in assembler doesn’t make assembler a good choise for everyday programming tasks, just like using C for object oriented stuff is generally a bad idea. For one thing, it increases the learning curve of the API.
I’m not saying that Eiffel would be a better choise than C, as there are probably to few people who know it.
C is preferable for bindability.
Very few people need to work on a library, as compared to how many will use it.
There are problems like people trying to look at parts of structs they shouldn’t (which in gtk is almost everything, but not quite, unfortunately) and they’ll have to read header files to find the contents as it’s not always documented. But hey, if you can’t follow directions you’ll use it wrong no matter what language it’s written in!
ma_d, you said: “Very few people need to work on a library, as compared to how many will use it.”
True, and that’s another area where Eiffel excels. Eiffel code adheres to the open-closed principle. Eiffel programmers do not believe that once you write a library, people are only willing to use it, not change it. There’s no such distinction between use and change except when it is forced upon one like C libraries do.
In Eiffel it’s easy to inherit parts of a library and extend it. And it won’t break any code because of Eiffel’s DbC support: the invariant of a class must be maintained, even if you extend that class and change some features. Allows for very safe reuse.
It looks terribly rigid and not very high level at all. It doesn’t look like it’d be too pleasant to program prodecurally in, either. I’m wondering why they don’t promote the development of a python-like compiled language (something that I happen to be working on, although I doubt many OO fanatics would like it).
-bytecoder
> It looks terribly rigid […]
Well, Eiffel is often referred to as a “bondage and discipline” language
IMHO, such rigid languages help a lot to write quality software (not that it is impossible to write great code using Perl or Python, of course).
..or C as well.
It is very high level, excellent libraries, purely object oriented, design-by-contract. Eiffel forces you to program in a disciplined manner and the code tends to be very clean.
Wonderful language pity that its creator (Meyer, ETH Zurich) doesn’t wish it to be free, gnuEiffel please pleaseplease!
http://smarteiffel.loria.fr/
”
(SmartEiffel was formerly named SmallEiffel.)
SmartEiffel The GNU Eiffel compiler is the fastest and the slimmest multi-platform Eiffel compiler on Earth! It is also completely FREE!
“
What the hell is wrong with c++ anyway? KDE uses c++ and they have as many developers as they need.
If you have properly designed libraries c++ is by far the bast language to use.
Well, for one thing, it’s fairly low-level, yet still manages to be complicated and bloated. It also lacks several very nice features, and isn’t terribly elegant, either.
-bytecoder
I generally agree with this except for your characterization of it as “low-level”.
Assembly is low-level and C is sort of low-level, C++ is a high level bloat monster.
Well, yes, I was using the term “low-level” to make a point. Technically speaking C is high-level, and I assume basically anything above assembly is also qualified as such. Unlike C++, C was actually fairly well designed, is simple, and was elegant at what it was meant to be.
-bytecoder
The problem with using C++ has always been inconsistent compiler approaches to mangling overloaded method names, meaning that you can only link libraries that have been produced by the same compiler. That I suppose is less of a problem in KDE because everybody will be using the same compiler, presumably it’s gcc. For the same reason it should be a non-issue in gnome too then.
D looks like a nice language, though I suspect its current implementation is not free enough.
D looks like a nice language, though I suspect its current implementation is not free enough.
I think the only way it would be considered “not free enough” is that most of the language considerations are done by one person. While he does take suggestions, in the end he has final say on what does or does not make it into the language.
Other than that, the “official” compiler has an open source front end and run-time library. It’s only the back end that is closed. There is also a front end for gcc for people who wish a completely free implementation.
http://home.earthlink.net/~dvdfrdmn/d/
Wouldn’t it be better for OO languages to compile to C++ making it easier for other OO languages to write bindings to those libraries instead of every language trying to wrap C again?
The battle should not be between languages but between frameworks. Instead of choosing one language they could decide on one managed language VM backend. Java and Python have compilers for both .net and java object code. This way people could use whatever language they want and take advantage of either Java’s or .net’s standard libraries. It would also avoid loading two large frameworks into memory at once.
First, Eiffel does *great* on benchmarks, very close to gcc.
Second, its Design By Contract is a great enhancement to squash bugs in their conception.
Third, there’s SmartEiffel, another *serious* technology devloped by French INRIA (“France’s MIT”).
Fourth, SmartEiffel is Free Software.
Fifth, it is fully object-oriented.
Now, *this* is the way to go. *Finally* people are begining to use their brains!
Sixth: it’s 20 years old and has not been able to become mainstream.
Eiffel is a dead language.
Fifth, it is fully object-oriented.
What do you mean by “object-oriented”? If you’re talking about the C++/Java style of OOP, then this is more of a restriction than anything else.
-bytecoder
What do you mean by “object-oriented”? If you’re talking about the C++/Java style of OOP, then this is more of a restriction than anything else.
-bytecoder
Well, THAT’s the thing: it’s truly object oriented without any ‘violations’, unlike the aforementioned.
First, when talking about Eiffel you normally talk about Eiffel Software’s version, not SmartEiffel. SmartEiffel is FOSS Eiffel Software Eiffel is not. Most lib bindings are for Eiffel Software Eiffel not for SmartEiffel and the bindings are usually old, bitroten and unmaintained. Neither SmartEiffel nor Eiffel Software Eiffel follow the so called standard (ECMA TC39-TG4) read the SmartEiffel wiki to get some ideas about the differences.
What dose this mean for you if you want to use Eiffel anyway? Well if you don’t care about making GNOME or GTK specific apps and free as in beer is good enough for you get the free version of Eiffel Software Eiffel (no commercial app development and so on). If you care about FOSS and you want to make GNOME and GTK specific apps stick to SmartEiffel and start working on eGTK.
Here’s a little definition of Eiffel for you.
Think about it before you go blurting out you lack of knowledge about Eiffel:
Think of Eiffel as a Java (OOP, Garbage collection, documentation) but *C* fast. Gcc fast.
Code in Eiffel is written with Design by Contract. This is a vaccine against bugs.
This is Eiffel. It’s been around for years.
And the only thing stopping it from being used are a couple of non-techical factors:
1) Disinformation
2) Prejudice
3) Lack of marketing (not Sun, not Microsoft, not IBM (read linux))
4) Because there were few Eiffel vendors, all quite content making good money to a selected clientelle. But there’s SmartEiffel now.
The problem with C/C++ ???!! What ??!! Don’t you know ??! Are you aware of the hundreds of exploits because of unsafety ???!!
Microsoft is moving away from C++ (in fact, Microsoft Research has hired some of the very best people from industry and academia. Already they have formal verification of device drivers). Will we not ? We want to be the community that gets listed on a daily basis on security lists because of buffer overflows ?!
My guess: the free software community will reject Eiffel on the basis of ignorance. Why ? Simply because not too many coders are willing to stop and actually /think/ about the piece of code they’re writing (the “release early, release often” Got root?
Eiffel grants you no excuse for not using a language with garbage collector. There’s no performance trade off. Even C++ freaks will eventually resort to garbage collector in a sufficiently large program.
See these two free books on techniques of programming:
http://www.eng.unt.edu/~ian/books/poa.html
http://www.cs.toronto.edu/~hehner/aPToP/
Think of Eiffel as a Java (OOP, Garbage collection, documentation) but *C* fast. Gcc fast.
Hehe. I’d bet you think java is a good language, too.
Code in Eiffel is written with Design by Contract. This is a vaccine against bugs.
Example?
And the only thing stopping it from being used are a couple of non-techical factors:
1) Disinformation
2) Prejudice
3) Lack of marketing (not Sun, not Microsoft, not IBM (read linux))
4) Because there were few Eiffel vendors, all quite content making good money to a selected clientelle. But there’s SmartEiffel now.
The problem with C/C++ ???!! What ??!! Don’t you know ??! Are you aware of the hundreds of exploits because of unsafety ???!!
Microsoft is moving away from C++ (in fact, Microsoft Research has hired some of the very best people from industry and academia. Already they have formal verification of device drivers). Will we not ? We want to be the community that gets listed on a daily basis on security lists because of buffer overflows ?!
My guess: the free software community will reject Eiffel on the basis of ignorance. Why ? Simply because not too many coders are willing to stop and actually /think/ about the piece of code they’re writing (the “release early, release often” Got root?
Eiffel grants you no excuse for not using a language with garbage collector. There’s no performance trade off. Even C++ freaks will eventually resort to garbage collector in a sufficiently large program.
For an informed view of language popularity, you should probably read this:
http://www.paulgraham.com/popular.html
This is also a decent read:
http://www.paulgraham.com/noop.html
I’d also like to point out that I am not a lisp fanatic. I don’t particularly like it at all, but some of the ideas and coding styles based around it are interesting nonetheless.
-bytecoder
I know Common Lisp and Scheme. For the life of me, I just can’t imagine GNOME coders getting their heads around macrology. Let alone the Common Lisp Object System, the most sophisticated object system there is. There’s not a free lisp universally available for all platforms, and that includes UNIX, that meets the requirement of decent compilation (there’s bytecoded Lisp, though – CLisp – but I think the garbage collector is borking on OpenBSD recently).
Eiffel is sufficiently close to the Algol-derived syntax most are accustomed to (C, C++, C#, Pascal, Delphi, Java, Python, etc). Not a problem. Unless you’re retarded.
Also, the object system does not present “problematic” concepts for mainstream developers.
Python and Ruby are little languages that demonstrate poor design. Look at Smalltalk, Lisp, etc and you’ll see. Plus, you don’t compile.
Eiffel has been around, it’s tested. Why didn’t it spread like fever? Well, first Microsoft wanted they’re Visual C++, then Sun their Java. That’s what sets the trend for the majority of programmers. C has been around for portability, efficiency and historical reasons.
Now Microsoft moves away from C++, MacOS uses ObjectC and we’re going to stick to C ?! Come on, how long will C hold ? Can you envisage a 20-year horizon of free software development *at large* without *at least* a garbage collector ?
Eiffel is currently under development. Sure, it lacks some documentation but it’s better now then it was then. People took up GNOME and Mono when there was poor documentation. Why can’t the same be done for SmartEiffel ?
It’s safe (garbage collected). Supports discipline (DBC) and methodology for large projects.
It compiles, and it compiles fast.
Java, for those who like Java, needs a VM that is proprietary. That excludes free UNIXes, for instance.
People ought to stop reinventing the wheel and just take what’s there. SmartEiffeil is also from the free software community, you know ?
And besides, C and C++ are a proven failure in terms of code safety. When people say “the problem is not the language” they just show they don’t understanding software engineering at large, they show they’ve *no* idea of the requirements of a large project.
All in all, I think Eiffel was an excellent proposal because it fits right in the current mainstream thinking (at least, that’s how I see it. OCaml and Clean, although both approach C performance, would not – they’re functional languages).
I know Common Lisp and Scheme. For the life of me, I just can’t imagine GNOME coders getting their heads around macrology.
I’ve researched the use of common lisp macros in lisp quite a bit, and the one conclusion I came up with was this: the use of macros to create domain-specific minilanguages looks strikingly similiar to data-driven programming, which is obvious if you realize that data is much higher level than any kind of code can ever be.
-bytecoder
“Think of Eiffel as a Java (OOP, Garbage collection, documentation) but *C* fast. Gcc fast. ”
You’d be surprised how fast Java is when comparing the same code against c, practically the same… IE, if you need to import in your java code, it’s wrong.
“Code in Eiffel is written with Design by Contract. This is a vaccine against bugs. ”
From my brief readings onf wikipedia. It looks to me like DBC is a runtime check that validates the IO of your function calls? I guarantee that’d cause slow downs…
“The problem with C/C++ ???!! What ??!! Don’t you know ??! Are you aware of the hundreds of exploits because of unsafety ???!!”
Bugs are the fault of developers, don’t blaim the language. C lacks a toolset to help you avoid them, but it’s still your fault for writing them. All that code is being run as *essentially* c code at some point anyway…
“Microsoft is moving away from C++”
That’s because c++ is probably the most obnoxious language in history. It’s not a superset of C, but when you’re staring at its compiler errors you’d swear it was. And, when you read other peoples code you end up finding the same stupid mistakes you were making in your c code (pointer issues). And adding in GC has been fairly problematic.
“My guess: the free software community will reject Eiffel on the basis of ignorance.”
Probably. It is entirely practical for the choosing of the language to be a democratic thing; and there’s just not many Eiffel developers. That may or may not be Eiffel’s fault, but there’s no reason to tell everyone to learn a new language.. This is probably one of the worst things going against Python; it’s so unpopular in Academia (amongst classes I’ve heard of) and professionals.. If you think about it, chunks of Gnome are already written in Python.. (Gnome panel applets). It may still be better to go with c# or Java, because so many professionals use it (which means many amateurs will be using it or are using it at work). I wouldn’t say that if the languages weren’t good enough; but I think they certainly are.
“Eiffel grants you no excuse for not using a language with garbage collector.”
So… Is someone advocating using c++ instead of c for gnome?
I see no reason to choose Eiffel over any of the more popular languages which have been developed. I’m actually getting a bit sick of learning new languages… I don’t have time to actually use them anymore!
“”Code in Eiffel is written with Design by Contract. This is a vaccine against bugs. ”
From my brief readings onf wikipedia. It looks to me like DBC is a runtime check that validates the IO of your function calls? I guarantee that’d cause slow downs…
Think of it more as built in unit testing, without the hassle of having to write seperate tests (it’s baked into the code itself, and _all_ code needs unit tests). I read the wiki as well…it’s pretty vague. Read this link for a much more thorough examination of DBC: http://archive.eiffel.com/doc/manuals/technology/contract/
At it’s root, DBC is more closely aligned to test driven development than anything else.
It looks like exception handling to me. It just formalizes the way you’d write out the code procedurally…
I suppose it’s nice to force programmers to do tests, but I don’t like being forced into things.
But if it does what it promises (and I’m not an Eiffel expert so who knows) by reducing the number of bugs, wouldn’t you *want* to do something like that? A few extra LOC for less bugs is well worth it IMO.
From the DBC wiki:
“The contract conditions should never be violated in program execution: thus, they can be either left in as debugging code, or removed from the code altogether for performance reasons.”
I wonder if the Eiffel compiler has a “release” mode configuration (either built in or configurable via switches) that strips out the DBC code after testing is complete…i.e. I would never ship production code with unit tests compiled in as well (for obvious perf reasons), though in a “debug” release the unit tests would be left in the code.
They look a lot like exceptions. That’s what I keep thinking. And exceptions look a lot like proper c functions which always return a state not a piece of data (although exceptions have an advantage, if function A doesn’t catch it, and function B which called A does you’re ok). I’m not gonna mention what that looks like in asm, I’m not that experienced with asm.
I wonder if the Eiffel compiler has a “release” mode configuration (either built in or configurable via switches) that strips out the DBC code after testing is complete…
Yes, that’s possible with a single click. I think it’s called “Freeze” in EiffelStudio. I don’t know if SmartEiffel supports it, though.
“I suppose it’s nice to force programmers to do tests, but I don’t like being forced into things.”
And that’s why programming is still behind. No one wants to be “forced” into doing what needs to be done, and at best have to learn the hard way, and at worst never do.
Programmers aren’t stupid. If you take away their personal methods you’ll take away their interest; and the quality of your end product.
When we are assimilated in the borg collective then we can all be perfectly efficient and work the same, collectively.
At best by doing things their way they learn a new way which is radically better.
Please, stay out of my career path, don’t be a programmer or a manager; we don’t like your type.
When programming work looks like data-entry work computer science in the workplace will be dead. And so will innovation in the software world.
When we are assimilated in the borg collective then we can all be perfectly efficient and work the same, collectively.
Judging by the amount of bad C/C++ code out there, I’d say that the borg collective is alive and well. My money’s on the fellas using languages that force them to plan for bugs that are avoiding things like rocket crashes.
But, if you want to write fast, sloppy code without planning too much or thinking too much about it, then by all means use C/C++ or your favorite…
NOTE: My problem with Eiffel is that the compiler writers seem to fork their code on occasion, making past code unuseable. I had a system that I was planning to expand, but SmartEiffel forked me; my code would no longer compile. Time to look around…
How is not wanting to get forced into a construct synonymous with wanting to write quick sloppy code.
There’s more than one way to write well finished code (I’m not gonna back that up, it’s pretty much a universal constant in life that there’s always more than one way to do things).
Frankly, what you just said was FUD: If we keep using languages which don’t force this or that we’ll have sloppy bad code forever. The quality of software in general has increased vastly over the last 10 years, and the 10 years before that, and the 10 years before that.
The sky is not falling folks. The worst thing that using a dated language is going to do is slow us down. Software isn’t going to suddenly become horridly broken.
It’s no excuse to stick with c forever. But I’m not about to jump into languages which say “thou shalt use OO, or I wilt error” or languages which say “if thou dost not give me io ranges I wilt cry and kill thine first born!”
It sounds like that is all optional in Eiffel, as it should be. It’s likely an effective tool, for some more than others. But if you force it, it’s just going to make for a bunch of angry programmers who hate their jobs because all they do is fill out function i/o range and exception reports (think TPS reports).
You’ll never finish a c project if you don’t think it through. And you won’t even get a c++ project to compile without thinking it through.
PS: Did they give you a tutorial on updating. This sort of thing seems to be fairly common in high level languages; and they’ll usually give you a list of deprecated junk… I’d imagine porting your code shouldn’t take too awful long. That’s the nature of languages that do more for you; they change more.
“But, if you want to write fast, sloppy code without planning too much or thinking too much about it, then by all means use C/C++ or your favorite… ”
Somehow I get the impression that the poster would have problems fitting into the XP methadology. Too “borg-like”. Oh well, as they say on Slashdot. ADAPT OR DIE!.
That article is from (at least) April 2004 and has been discussed on Slashdot ( http://developers.slashdot.org/article.pl?sid=04/04/11/1436234 ).
I had the joy to visit a lecture from the creator of Eiffel, Bertrand Meyer. It’s a great language, very well thought out and easy to learn. Never the less, it’s not a viable language for a project like Gnome, simply because 99.9% of all open source programmers don’t know it.
…how you code in general. I did a small Eiffel project a few years ago with some colleagues as a learning venture and was thoroughly impressed…if not just with the language as a whole, then the way it changed the way I code now.
Eiffel was doing TDD with their “design by contract” paradigm long before TDD was even a buzzword; granted Eiffel (the language) is built around this concept, but it’s easy to do in other languages as well. I highly recommend any developer do a weekend crash course on Eiffel concepts…it’ll change the way you think when programming in other languages.
It’s also available for the .Net framework: http://www.eiffel.com/products/envsn/ and FWIW it supports multiple inheritance (C#/VB do not, though the advantage is debatable…if you need to target .Net, and need multiple inheritance (and don’t want to use C++) Eiffel is worth having a look at).
Overall it’s a fantastic language.
It seems to me that any language used by Gnome would have to have a well-maintained and well-supported FOSS compiler before it could be considered practical. Eiffel is not part of the Gnu Compiler Collection, or any other well-supported and maintained FOSS compiler, and so it would not be practicle. As far as I can see, the practicle choices, other than C/C++, would be Java, Ada, and Objective C because these are all part of the Gnu Compiler Collection. With Mono, you might also include C#.
This article is 19 months old!!!!!!!! Yes nineteen months old! It dates from April 2004!
See http://thomas.delaet.org/writings.html
Now that is what I call news!
Thanks OSNews!!!!!!
What a great source of information you make!
At least this article is stirring up some controversy and hence page impression which will boost your adverting revenue. Your site lives on controversy anyway, especially on week ends.
Better late then never. Although I bet we argued about this 19 months ago, heh.
The D programming language http://www.digitalmars.com/d/index.html
fits the bill perfectly as a GNOME development language. Furthermore, it fits in well with existing C code, so well tested code doesn’t have to be rewritten.
-Walter Bright
The D programming language http://www.digitalmars.com/d/index.html
fits the bill perfectly as a GNOME development language. Furthermore, it fits in well with existing C code, so well tested code doesn’t have to be rewritten.
-Walter Bright
Now, Anonymous, that’s evil, using Walter Bright’s name for something like this…
Another Anonymous
C is simple, easy to learn, multi paradigm (you are free to use whatever you want), easy to bind, easy to port.
> C is simple, easy to learn, multi paradigm (you are free to use whatever you want), easy to bind, easy to port.
You must be new to software development with this kind of nonsense. Programming in C is like walking in a minefield.
Writing software in C is not a simple, but the original C compiler was probably easier to write because it left so many things out of the language.
Who needs strings? Just use an array and some lib – hello buffer overflows.
Boolean? Just define your own, which ever way, and so people did for 25 years until 1999 (and still do).
Constants? Just invent a pre-processor to patch up the lacks of the language. Have the pre-processor use a different language syntax, because consistency does not matter.
Add in non-typed checked macros and let the pre-processor execute like an over-simplistic search/replace manner. Easy to write the pre-processor but leave all the trouble to the application programmer. Macros are a great way to hide subtle errors in the source code.
Programs consisting of multiple source files? Who would ever need that? Lets have the modules interface with each other by making everything globally defined. Not a good idea? Oh, then use the static keyword to individually mark things private. Never mind that the static keyword is also used for a completely different purpose.
How does the C compiler handle multiple source files? Actually it does not, you need to use a make program with makefiles scripts written in another esoteric language.
Easy to port? Yeah, if all you do is a hello world program. For porting, the good thing about C is that it exist on so many different platforms. The bad thing is that it is not exactly the same that exists on the different platforms. So when porting between two different C compilers or two different CPUs you have to enforce all sorts of coding limitations yourself with no help from the compiler.
In short, C should never be the first choice when choosing an implementation language, rather it should be your last choice when no other option is possible.
#include <string>
#include <iostream>
using namespace std;
int main()
{
string x; x = “abcdefg”;
cout << x << “::” << x.size() << endl;
for (int c = 0; c < x.size() + 11; ++c)
cout << x[c];
cout << endl;
return 0;
}
[chris@rachelanne ~]$ ./test
abcdefg::7
abcdefgé
How about python? It actually checks. Java? Java checks as well.
“How does the C compiler handle multiple source files? Actually it does not, you need to use a make program with makefiles scripts written in another esoteric language.”
Oy. If you understood Make you’d understand what makes it wonderful; not difficult or esoteric. Anyway, this isn’t necessarily such a bad thing; it gives you a lot of low level control that you sometimes want.
“Constants?”
Exist in ANSI C. Or at least, gcc yells at me for them. They’re warning only, as they should be.
“Boolean?”
Integers are booleans anyway, what’s the difference? This isn’t a valid complaint. And yes, a quick macro will make boolean happen for you.
“Who needs strings? Just use an array and some lib – hello buffer overflows.”
Bounds checking will never solve bad programming. We’ve just found another way to sort of limit it.
“Macros are a great way to hide subtle errors in the source code.”
That’s why you aren’t supposed to write complex macros
.
I agree that C is not the language of choice for most things, especially building desktop software. But the reasons are things like: Lack of managed memory, while we are all smart enough to figure this stuff out, not having to saves you some time. Lack of helpful constructs, things like foreach loops, exceptions, etc.
The general fact that c is just lower level and more difficult to develop in. But if you throw it out as something to only use in a last ditch effort you’re really selling it short. It’s a great language to write your libraries in. It’s a great language to implement that complex function in and hook it into your higher level language. It’s a great language for that small standalone utility; there’s just no reason to invoke python or java to copy a file. It’s a great language to write large chunks of that game you wanted to write.
And here’s Makefile 101:
target: dependencies
commands to make the target
Does that make sense? It’s really not all that complex.
Here’s a DBC pre-processor for C written in Ruby: http://dbc.rubyforge.org/ (link from http://en.wikipedia.org/wiki/Design_by_contract). Anybody ever used this? Looks interesting…
Eiffel – Yecch … Has anyone seen “hello world” in Eiffel?
Here it is –
————————————————-
the HELLO_WORLD class (hello_world.c)
————————————————-
class HELLO_WORLD
creation make
feature make is
local io:BASIC IO
do!!io
io.put_string(“%N Hello World!!!!”)
end –make
end — class HELLO_WORLD
————————————————-
program to run HELLO_WORLD class (hello_prog.pdl)
————————————————-
program hello_prog
root HELLO_WORLD: “make”
cluster “./”
end
include “$EIFFEL_S/library/lib.pdl”
end — hello_prog
**********************************************
Mmmmm ….. not my cup of tea … 😉
If a somewhat “lesser-known” language were to be used, one possibility might be “D”. This is best known for the version from “Digital Mars”, but there’s also OpenD ( see OpenD.org). Think “cleaned-up C++” basically.
Pretty fast too – see the “language shootout” page at
http://shootout.alioth.debian.org
( Ok, there are always caveats with language-shootouts and benchmarks, but D is usually in the top 4 or 5 in the tests. )
Then there’s always Haskell. Activity in the Haskell area has really picked up in the last month or two. Several new Haskell compilers are being done. Everyone knows of GHC, but new ones include YHC, EHC and JHC.
YHC seems very promising. Still new, but it’s quite fast and produces very small binaries. YHC itself is small as well.
Just my 2c worth ….
It´s the power of Common Lisp with a more normal Syntax. It´s very dynamic (one criticism of C++ for GUIs).
Another language I would like is Ada.
egtk seems almonst dead, and is for gtk1.2!
but EWG (http://ewg.sourceforge.net/) looks interesting.
http://www.ruby-lang.org
It’s the best syntax I’ve ever seen!!
Boo, Boo, no realy try boo (i knew that name would come in handy some day)
http://boo.codehaus.org/
There is a window manager written in Eiffel. It is called Framer. The window manager is written to work with ROX Desktop.
Link:
http://laurent.moussault.9online.fr/framer/
I’ll add an IDE to that:
http://www.ruby-ide.com/ruby/ruby_ide_and_ruby_editor.php
Arachno IDE, writen in Eiffel with Fox gui bindings for ruby, python …
From April 11th
http://developers.slashdot.org/article.pl?sid=04/04/11/1436234&tid=…
Reminds me of the news a few years ago that a language called “D” was going to replace C. I think it still exists and has a community. Anyway, nothing will kill C overnight, it used for absolutely everything these days. Run-time languages aren’t a suitable replacement either.
The Computer Language Shootout Benchmarks:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&s…
D or Eiffel seems better that c++ and more clean languages
This is a better URL:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=gcc&l…
I thought the idea of software development was to create products that actually work with a minimum of errors. For that task, there is few languages a good as Eiffel. It removes the “programmer as god” mentality from software development and provides a structure that deters bugs. In fact, the only bug-free software I’ve ever heard of was developed in Eiffel. The entire syntax of the language can be learned in two weeks… I don’t know anyone who knows the entirety of the C++ syntax.
An argument has been made here that “rigid” development languages like Eiffel “shackle” the creative impulses of developers. That seems kind of dumb to me. It’s tough to be creative when you are constantly returning to fix broken code. It to Be, Inc. ten years to build the BeOS into a workable system working with C++ when they could have done that in a third of the time with Eiffel and have had a far more modular and stable system. I’d rather have a simple, rigid language that takes care of the crap that I don’t want to so I can focus on solving problems. I’m not trying to be an “artist” with a language, I just want to get stuff done.
That being said, if the open source community switched to Eiffel, it would practically eliminate most security vulnerabilites and bugs and have a tremendous advantage over closed-source projects, especially Microsoft. I recently read an article that talked about the new procedures Microsoft has implemented to improve its code quality and they sounded a lot like what is featured in Eiffel. Eiffel would be especially valuable in open source because QA would be built directly into the language, freely developers to explore new ground. Frankly, I don’t know why Eiffel hasn’t already been used for a major open source project. The language itself is simple, robust, and has an excellent reputation for producing fast, stable code. The only detractors I’ve ever encountered are “code artists” or people who haven’t actually used it. If the Open Source community wants to get serious about competing with companies like Microsoft, it’s going to have to stop following and start leading. That means finding any advantages it can to compete. It’d take a while for the community to get the ball rolling but, once everyone was up to speed, Eiffel would be a tremedous competitive advantage.
I expect the Open Source community to hang on to its sacred cows and ignore this advice because, as far as I’m concerned, it’s just the flip-side of Microsoft. If anyone in the community has any real sense, they’ll at least try Eiffel for a small project. They’re doing it for free anyway so what difference does it make? But I won’t hold my breath
The only way to produce bug free software is to write a formal (not necessarily by syntax, but by structure and provability) proof for your code.
This is not reasonable for very many people to do, and so very few people do this. Not because we’re not all smart enough, but because some of the proofs would take us a lifetime to write.
The general rule is that when someone claims they have a bug free program, and they don’t have a proof (and it’s not a joke), you avoid it because you know they’re either an egomaniac, deluded, or lying.
“I don’t know anyone who knows the entirety of the C++ syntax.”
There are a lot of languages which provide the features of c++ without the mess that c++ is. Eiffel is not the only one. It might be one of the oldest though.
“It to Be, Inc. ten years to build the BeOS into a workable system working with C++ when they could have done that in a third of the time with Eiffel and have had a far more modular and stable system.”
Do you know how I know that statements wrong? You claimed tripled efficiency simply by changing to a different language. C++ is only that detrimental if you don’t know how to use it, and I imagine the folks at Be knew it, or they’d not have chosen it.
“That being said, if the open source community switched to Eiffel, it would practically eliminate most security vulnerabilites and bugs and have a tremendous advantage over closed-source projects, especially Microsoft.”
No. No. Please stop saying this… If this were correct, then we’d know that all security bugs are caused by memory management issues and stupid function i/o issues. Then we could solve them all by making the heap non-executable and never putting data on the stack; woops you still have vulnerabilities.
You’re making far to outlandish claims about what Eiffel will do for a project. There’s just no quick fix to the problem: Programs are complex. That’s life, you try and make it better, but you know you aren’t going to find the fountain of youth…
And so, when someone says “tripled productivity” you immediately say “am I really wasting 2/3 of my day?” “Can I even type fast enough to triple my productivity?” “Would my sanity last 8 hours if I worked three times as fast?” “Are 2/3 of the problems I solve every day just flaws in the language I use?”
This is the reason why Open Source is doomed. The productivity claims have been proven but a naysayer who has never used Eiffel claims they are false. Nuff said.
“Productivity claims” aren’t what drive users to use a language; the language is what drives users to use it. If it’s not popular and it’s been around for a while, it’s very likely the people don’t like something about it. Besides, I don’t think it’s possible for “Open Source” to be doomed. It’s basically a never-ending hobby.
-bytecoder
Cite.
I wouldn’t like to read a thread such as this every day, but it was some time since I read the last…
First, some people think that somehow “open source developers” are any different from “commercial developers” or “egotistical companies”. I mean, each one of us has his own interests. The commercial developers sound eager to be able to develop applications using the open source developers tools, which need to improve. Is that right?
Second, I disagree with most of you when you think you need a system level language like Java, C++, Eifell (?), C#, to develop your programs. Because second on your list is powerful tools on top of your “preferred” languages which make it easier to read and write the generated code. I believe application developers need a higher abstraction which is compatible and consistent with other tools, so they can reuse code and knowledge more easily, without depending on tools support.
I believe the holy grail is an API for application development on top of the basic APIs. Both need to be accessible and easy to extend and modify, so you can better adapt them to your needs if by default they aren’t enough.
If my theory is correct, and I can make enough money for me, maybe in the future I will have the time to release my tools which support Linux and Windows, Web (CGI, Wiki, a Web Framework) and Desktop (Fox, wxWidgets, GTK+, several databases, and will support several report outputs (like HTML, PDF, TXT).
I believe in components above all! 🙂
First, some people think that somehow “open source developers” are any different from “commercial developers”
Yeah. They are. You wanna know how? If I hire you I say: this project uses LispWorks, or FranzLisp, or EiffelStudio, or Cincom Smalltalk. Or for that matter, Eclipse. Whatever.
But I get to order you to do it. I don’t get to listen to stupid arguments about C or C++, and you don’t get to write stupid bugs because you left a dangling pointer because you have a headache. You also don’t get to be artistic. Or only so far as an engineering discipline allows. And I couldn’t possibly care about your “woooh, Python/Ruby/C rocks” attitude.
You play by the rules, and the standards are set higher. You don’t like it, I hire another. I got a product to deliver, and I ain’t got a gargantual marketing machine or a monopoly behind me to push shit to people and they’ll keep buying next year. I got big clients for serious appications. I might be developing software for the aerospace, medical industry, or for banking institutions. Software you won’t read about on Slashdot or here.
You can hire open source developers and if you pay enough money you can be a monkey and they won’t care.
You know what? Do you know about the limits of Eiffel? Well, if you can write bug-free Eiffel code maybe you should declare that as a feature of your softwares, and if a customer finds bugs in your programs, allow them to get their money back.
Your attitude is to pretend that the differences of Eiffel will make if bullet proof or something. Silver bullets don’t exist. Hard work is the only way to advance in removing the montain, one chunk at a time.
You’re kind of talking about what I was thinking.
There is a need for separation, the FLOSS desktop needs a language/(or other development tool) that can do for the desktop what javascript once did for the web.
A tool that lets millions of clueless developers copy and paste code to get “cool” effekts and try out ideas. This is how you recruit and train the next generation. And this is where those odd projects that changes the world will start.
My first program was a short qbasic compilation that printed random noise on the screen, with the flashing text “Virus!” somewhere in the middle. How do you do the equivalent on a modern desktop system?
I am not feeling like sharing how I do it right now, because it’s a simple example, and many programming languages could do it in a simple way, but most wouldn’t be able to do it on Windows and on Linux and on the Web with the same code. Also, when it comes to database forms and stuff like that, that’s when you really need to support 90% of the developers.
But I am on the same page as you. For example, QT and GTK+ with the same program? All I need to do is to add the wrapper for QT. Maybe in the future I’ll add support for QT. And maybe one day someone could add support for Cocoa. 🙂
Components are king. You just need to know the interface. The rest should be hidden from you until you need it.
For example, QT and GTK+ with the same program?
Gambas v.2 (a Basic version for Unix) will do that. You’ll be able to use GTK+ or Qt GUI frontends at your choice.
Am I correct in interpreting that this is supposed to replace C use in the majority of Gnome?
I don’t think that’s a good idea, C and C++ still have a lot of support and most of the people contributing code to Gnome most likely know C. C is a very common language, it is powerful enough and fast enough for an entire window manager and many of the applications that sit on top. Replacing C doesn’t seem wise to me at all, especially since the language is still good and very well supported. C is very mature, and can be compiled for many platforms, as far as I know assembly is the only other programming language that can be compiled for more operating systems and architectures.
I think it would be a much better idea to have two officially supported languages for use with any desktop environment, one being either C or C++, and the other being somthing simple. Other programming languages can be used through contributed bindings.
Just my $0.02, no doubt not everyone will agree.
But has anyone had a look at Objective-C as a viable Object Orientated replacement for GNOME?
I mean, its alot more high profile, Apple has done a tone of work to get Objective C working well, its a well documented language, it has the nicities of C and C++ without all the ugliness and better still, its similar enough to both as to allow an easy transition from C to the new platform/language.
Personally, I’d love to see C# and .NET to take off, but there is still the uneasy feeling surrounding Microsoft and their unwillingness to say, “the WHOLE .NET Framework, including Indigo will be kosher and we won’t sue any third party implementations of it” and sign a legally binding declaration.
But like I said, Objective-C has potential to be a replacement for C++ and C; its sad, however, it won’t happen – because I could see GNOME’s future with Objective-C, coupled with a really good GTK drag and drop IDE – it would provide a great tool for companies to create products with minimum fuss and lower costs for the GNOME platform – any platform that has GNOME as a desktop.
see any gnome developers thinking aloud about this?
eiffel, yes, a great idea
lets replace c with a language that maybe 1% of existing gnome maintainers and coders have ever even looked at.
first of all, who is this wizard in the sky who is making this decision? gnome is a community, and in any community, he who shovels the hardest typically gets a bigger say. and all of those people are c coders. so you are telling me that overnight they will suddenly decide to adopt a new (dead) language? SURE
if you have a hard-on for eiffel, start a new project to compete with gnome. this is what you would be asking the gnome folks to do anyway, since you are asking them to banish c.
this entire thread is retarded.
I think C should stay, primarily as its already in use. Eiffel/Pyhton may be quicker/easier for new programmers but if you are competant with C is not so bad or slow. I think switching away from C could cause more problems than its worth.
<irony>eiffel, yes, a great idea
lets replace c with a language that maybe 1% of existing gnome maintainers and coders have ever even looked at.</irony>
This argument is flawed. It’s circular…they don’t know other languages, so we’ll stick to C, because they don’t know other languages, so we’ll stick to C…
In a 20-year horizon, where does that lead you ? To a continuous stream of security bugs.
Now, that, my friend, is a daily fact shoved in everybody’s face on a daily basis on security alert lists.
Personally, what I find amazing is how thick some people in the free software community are. They are much less prone to innovation and bold moves then some in the commercial arena. They stick to old ways.
It would be very funny to see free software hackers working with C in the next 10 years (except for kernel and certain system level developments, I don’t see why use this glorified assembler everywhere).
To all those proponents of Object-C – this is yet another example of something that was widely rejected on no rational basis and still not widely deployed on the free software community. Except, of course, that those fine people at Apple (and we all gotta recognize the great UNIX they’ve assembled – with some help from FreeBSD folks, of course) chose Object-C. Also, ObjC is unsafe as C.
The fact is, free software hackers are a bunch of old timers. They’re never bold, never really open to innovation. They just stick to their old ways. When they do try to innovate, they reinvent the wheel, badly (Python and Ruby). To be fair, I’m just talking about mainstreamers here. I’m definetely not talking about people who have a vision, like De Icaza. Or other fine group of innovative individuals, like the Perl6 crew and their use of Haskell.
But all this resistance against at least a garbage-collected language is really telling (oh, and when one is chose, often it is Java… Talk about bad design and moving away from free software ethics).
This argument is flawed. It’s circular…they don’t know other languages, so we’ll stick to C, because they don’t know other languages, so we’ll stick to C…
In a 20-year horizon, where does that lead you ? To a continuous stream of security bugs.
Now, that, my friend, is a daily fact shoved in everybody’s face on a daily basis on security alert lists.
Personally, what I find amazing is how thick some people in the free software community are. They are much less prone to innovation and bold moves then some in the commercial arena. They stick to old ways.
It would be very funny to see free software hackers working with C in the next 10 years (except for kernel and certain system level developments, I don’t see why use this glorified assembler everywhere).
To all those proponents of Object-C – this is yet another example of something that was widely rejected on no rational basis and still not widely deployed on the free software community. Except, of course, that those fine people at Apple (and we all gotta recognize the great UNIX they’ve assembled – with some help from FreeBSD folks, of course) chose Object-C. Also, ObjC is unsafe as C.
The fact is, free software hackers are a bunch of old timers. They’re never bold, never really open to innovation. They just stick to their old ways. When they do try to innovate, they reinvent the wheel, badly (Python and Ruby). To be fair, I’m just talking about mainstreamers here. I’m definetely not talking about people who have a vision, like De Icaza. Or other fine group of innovative individuals, like the Perl6 crew and their use of Haskell.
But all this resistance against at least a garbage-collected language is really telling (oh, and when one is chose, often it is Java… Talk about bad design and moving away from free software ethics).
People use what experienced programmers use. Experienced programmers (generally) only use good languages (C, lisp, python, etc.) or sometimes only good enough languages (C++, Java); the latter tends to be seen more so outside the UNIX world, which is a good thing.
Anyway, I see this discussion as becoming useless. I’m not going to bother checking, but I believe most of my posts have been rated down for the obvious reason (disagreeing with common opinion), which makes me believe my help towards improving common knowledge isn’t appreciated. Oh well, your loss.
-bytecoder
Oh but we like having you here bytecoder (seriously man, register!). You make good points.
This is a topic that I think people don’t actively think about until it’s presented to them; because most programmers care more about writing it rather than using their pet language.
It should be discussed. It really should. It helps in clearing up a lot of myths too.
If I’d known it was free I would’ve done it sooner
It’s just I get so annoyed when people rate down posts strictly because you don’t like it. People tend away from such discussions, although I find them quite fun.
-bytecoder (obviously
Edited 2005-11-27 23:36
Ok. One error at a time:
1.) It’s not that Unix/FOSS programmers are old timers who only use outdated stuff; it’s that you kids (which I use lightly as I’m 21) are just early adopters and you write more code than you maintain because your new fangled languages change every year
.
“They are much less prone to innovation and bold moves then some in the commercial arena.”
Some are, some aren’t. No one wants to write code and have to delete it cause the compilers dissappear or rewrite it cause they change dramatically. There is a lot of innovation in the FOSS world. It’s actually the best spot for it, because you don’t need as much capital to get a project that’s gonna fail going! And the best research is destined to fail, because we learn so much from failure (the question is how useful is the knowledge you gained from the failure and the successes).
“It would be very funny to see free software hackers working with C in the next 10 years”
Like they’re gonna rewrite stuff we don’t have too…
“Also, ObjC is unsafe as C.”
Managed code is not safe code. It’s just harder to completely bjork yourself with it; but given the extra cushion and comforts I’m sure we’ll get lazy enough to find a way.
“reinvent the wheel, badly (Python and Ruby)”
I can’t speak for Ruby, but Python is the only language I’ve used whose inheritance method makes logical sense… (because it’s so simplistic) I’m not sure what you have against Python.
“often it is Java”
Duh. Java is the current pet language of Computer Science (as a college department). Every freshman in CS today knows it, and so does every sophomore. It finally caught up to me (I was at the end of the C++ fad) in a later class (luckily I’d learned some on my own beforehand).
Java is an ok language. But yea, politically it makes little sense. And the hardcore freedom guys aren’t usually writing Java…
you kids just early adopters and you write more code than you maintain because your new fangled languages change every year
.
That is a really stupid, stupid comment. Common Lisp, Smalltalk and Eiffel all exist longer than you. Lisp is the second oldest language around still in use, only loosing to Fortran.
See, that’s one of the problems with the FLOSS communtiy. People think they can code, or think they understanding programming because they picked up an O’Reilly book on a scripting language.
I was born in 1984, not 1985, cute. It was a joke, hence the wink
. And, it’s “losing”, not “loosing”.
That’s extremely rude, given that you know absolutely nothing about me.
“this entire thread is retarded.”
Aside from the obvious (that Eiffel on GNOME probably isn’t the best idea), this has been one of the more informational threads I’ve read/participated in on OSNews in quite some time. People actually managed to stay somewhat civilized…wow, we *can* all get along.
And +1 to bytecoder needing to register.
//EDIT: Fixed typo.
Edited 2005-11-27 22:41
I vote for Objective-C
* It’s only a set of orthogonal extensions to C so all your C code it’s valid, you can use C libraries ‘out of the box’ (no need of extern “C” unlike C++)
* Less overhead due to object oriented features than C++
* It’s easier to learn than C++
* Well supported by open source dev. tools (at least by GCC 4.x, this is also true for C++, though)
Probably it has more advantages but I don’t remember them now.
Scriptol (http://www.scriptol.com) is designed to
manage Xml data and use XUL for graphical user
interface. And using XUL is just what Gnome or
any user interface should do.
And Scriptol also can use C library, no need to
rewrite them.
It may be learned also in some hours…
…for the disease. I mean I don’t think that a new language would alone solve Gnome’s problems. I also don’t think taking a debate longer than humanly reasonable over a new language would help Gnome either. And also, I don’t think Eiffel would be able to solve any of Gnome’s problems.
I don’t want to get into any professional or religious wars about c/c++/java/c#/py/ry/whatever else. I know a lot of them, I like a lot of them, I dislike some of them. Any of them could be use to build a DE like Gnome or anything better or worse than Gnome. I don’t think it’s the language choice that could/would make Gnome any better or worse. It’s the people, it’s the development method, it’s a usable (yes, in my dreams) api, fully implemented bindings to several other languages, it’s a usable integrated RAD environment (yes, i wish), better QA, and the ability of better attention to the other side – the latter meaning the KDE team has long long ago implemented some features that are so freaking good, it’s silly not to mimic them just because some freaking philosophical guidelines.
And please hunt those damn Gnome app memory issues down for once cause they can be a real pain in the ass (think evolution, then think a dozen other places). And this also doesn’t have anythng to do with the “officially” chosen Gnome dev. language.
If you really want to make developers happy, choose something like http://shakespearelang.sourceforge.net/
I personally wouldn’t want to contribute to a project with developers who write dozens of memleaking apps, lag behind with dozens of user/power user apps (doesn’t matter if it’s philosophically justified or not) and in the middle of development start arguing over the choice of a new development language. My 0.02.
I am a Linux newbie, but to me it sounds that we are mixing two topics.
Topic one: which language should be used for the ‘core’ Gnome where speed, memory footprint, low level programming capability,minimal dependencies,small/no runtime, neutral for language bindings is important(pango, gtk, SVG etc.).
Topic Two: Which language/platform should, for application development, be the officaly supported and recomended. Here I would guess is productivity,memory management, good windows binding and development tools are important factors…
I think the only way eiffel will be used for Gnome development is if someone writes an eiffel compiler for Mono. There is a .NET one but it is commercial.
Eiffel is very impressive, although the syntax is a little nutty. I like ruby’s syntax design better.
Choose a language that is not only technically (& legally) adequate but is growing in popularity among new FOSS developers and in the open source world in general. Growing popularity usually also means that the language is effective, powerful, intuitive, attractive, easy to learn, and will provide lots of new innovation, tools and toys also in the future. So – something like Python.
Many Ubuntu and GNOME people already seem to support and like Python a lot. Well, Python in itself, and as it now, does not suit all sorts of GNOME development. But what it certainly is, is that it’s ever more popular. On the other hand, Eiffel, as good as it might be in some strict technical sense, is not that popular, and there are no signs of that changing. Also, although C++ is stil very popular, developers seem to be moving away from it (and from C) gradually and looking for new, better alternatives.
http://www.digitalmars.com/d
* Language Bindings: We can’t expect that all third-pary applications are coded in the same language, so our solution needs to have the ability to expose it’s API’s to other languages.
D gives direct access to the C programming language, allowing you to create C, C++, and other language bindings.
* Incremental Transition: The language of the core Gnome components won’t be switched overnight. We need a steady transition path.
You can write C code in D if you want to, with a few tweaks.
* Open, community-driven language specification: It’s unacceptable that the language is controlled by a single company. The language specification needs to be open and the standardization process needs to be community-driven.
The D programming language is not controlled by a single company, and has a GCC frontend and a healthy community.
* Free compilers available: We can’t expect the different Unix-distributions to rely on proprietary compilers. There has to be a free compiler available for the language we choose.
Yes, D has free compilers available for linux, windows, mac, and wherever else gcc can go.
* Free Libraries available: Same arguments as above. The core libraries for our solution need to be free.
Yup, the libraries for D are free.
* Free from politics: Our ideal solution needs to be free from politics. We don’t want to loose one of the big supporters of the Gnome desktop platform.
D takes the stance of a religion-free language.
* Development Tools: It would be nice if there’s an IDE available for this language.
There are a few, but none are super polished. There is an eclipse plugin, a nice Windows only Elephant IDE. Give it some time, I’m sure one will be around.
* Easy of use: The reason why we’re questioning C/C++ is that a higer-level language would result in higher code efficiency. We expect garbage-collection, an easy to use syntax and reusability (less code to write).
D is very easy to use. Any C/C++ programmer should feel right at home.
* Efficiency: The language needs to be efficient. This is the reasen why so much software is still written in C/C++.
Yup, D is more efficient. The equivilent D code is much smaller than either C or C++ versions.
* Portability: The language needs to be portably to different platforms and operating systems.
The language is portable, just like C/C++ are portable. It includes version(Windows/linux/whatever) statements and has compilers available for different platforms.
D looks interesting actually. But how done is it? For example, under their arrays section they say this:
“Note: Array operations are not implemented.”
I actually don’t even like the idea of array operations, it makes something complex look trivial.
I like that they support the C ABI, and you can turn off the GC for individual objects.
According to wikipedia D is still beta though. So, I’m not saying never, but I prefer something that’s finished. Is the wikipedia article out of date?
I agree, D would probably be a better choise than Eiffel.
It is sufficiently similar to C/C++ to be very easy to learn for sombody with C/C++, Java or C# experience, but have many improvements.
Strange that it doen’t get mentioned more often when the frequently asked question of what language to replace C in Gnome/Gtk pops up. This is a language to like.
I’ve often thought that C++ would be fine, as long as you limited yourself to a small, simple subset of the language.
The whole giant edifice that is C++ is pretty gruesome if you allow folks to use every darn feature of the language, but if you made a strict Gnome-C++ policy doc: here’s the features we use, here’s the ones we don’t, here’s the patterns we prefer, here’s how we’ll manage memory, etc… If you really trimmed C++ down to the basics, my guess is that it’d probably work well.
How active is the D GCC front-end? Last time I looked there wasn’t much going on.
1) SmartEiffel is translated to ANSI standard C. It may then be compiled using any standards compliant C compiler, such as GCC. (ref: http://smarteiffel.loria.fr/ ). Alternatively, it may be compiled to Java bytecode.
2) The example of Eiffel hello world was terrible. Try this one instead:
class HELLO
creation make
feature
make is
local
do
std_output.put_string(“hello world”)
end
end
Like Java and Ada, there are more lines compared to, say, Python, but these are structural *features* designed to enable better development of large systems.
3) As a language polymath I appreciate the many qualities of Eiffel. I think it is an excellent, underused language. However, a large open source project such as Gnome would not be taking a very community-friendly approach by switching to a language that is little known as Eiffel. Making Eiffel a supported binding and then developing certain new subsystems in it would be a better tactic than wholesale conversion.
Finally, a few asides:
Design by contract principles may be applied to many other languages. The well known assert() macro is a weak analogy of pre/post condition testing.
Java is *much* slower than C and C++. The myth that the performance is nearly the same comes from the fact that the optimizer in the runtime is very good. If you take a section of code and loop through it 100,000 times, the performance *will* be as or nearly as good as C/C++. However, small loops and unrepeated code is often more than an order of magnitude slower than C/C++. Java programs feel sluggish largely because event driven code is a fine example of code that tends to not be executed 100,000 times at once, as are many other real world cases. Additionally, Java is far more memory wasteful than C/C++ which contributes directly to performance degradation of both Java applications and other programs on the system. So would you few folks propogating this Java performance=C++ performance myth drop it, please?
Could you post some evidence of this please. You’ve peaked my curiousity.
> Java is *much* slower than C and C++.
Hm…
Ok, here’s the scenario: you’ve got GCC (including GCJ) installed on your GNU/Linux box. You write two neat GUI (GTK+) programs; one in C (or C++) and the other in Java. (The Java one is using the JavaGnome binding to Gnome/GTK+.)
Since you’re using GCJ, you’re compiling your Java code down to machine code — just like with your C++ code. So, you end up with two binaries.
To run (for the first time), they both need to dynamically load their “standard libs” (in Java’s case, I think this is libjava.so or something). Perhaps the Java one takes a moment longer to load than the C/C++ one. Dunno. Maybe libjava soaks up more memory than libstdc++ — again, dunno.
At this point, both programs run pretty fast. Perhaps you’re able to detect that the C/C++ program is just a tad faster. Remember — they’re both machine code. They’ve both loaded their std libs into memory.
Now the question to ask is, since the end result of both programs is pretty much comparable, how do you decide whether to write your Gnome programs in Java or C/C++?
– which was quicker to write? (probably the Java one)
– which had fewer bugs? (probably the Java one)
– which is more likely to get other folks contributing to and improving it? (probably the Java one)
– which is more portable? (arguably, the Java one)
– which was easier to build? (I’m thinking of ant here)…
Now, looking at the big picture, how much does it really matter if the C (or C++) version runs marginally faster?
BTW, I’m not a particularly big fan of Java. If it were me, I’d probably just knock it out in even *less* time using Perl and the Perl-GTK+ binding.
But the point is, it’s tough writing apps using C or C++, and even tougher to get other people to do it in their spare time. There’s no “obviously better” solutions than using C or C++ for Gnome apps (and other infrastructure) — but there are *marginally* better ones, IMO.
1. 2 people know how to program in it.
2. A bus just ran over one of them.
And when did machine code become “c byte code”? AFAIK c compiles directly to machine code? Or at least it used to. I suppose I could be way behind the times here.
I wish the computer science departments at colleges would stop making up new ways of saying the same old things.
“Design Patterns”, “Agile Modeling”, “Extreme programming” blah blah blah… come on, these flippin’ concepts have been around since 1968 for Pete’s sake. Why do they have to be given a fancy name and have 4000 books written about them?
Sorry, I digress.
I need to do some research, I don’t even know WHY GNOME team is looking for a new development language…
Edited 2005-11-28 11:33
Because C is not needed for the things the Gnome project is facilitating (Gnome probably should stick to c for most things, but the people building on Gnome don’t need to, usually).
As much as I love c, it’s a pain in the butt to write big things in. It’s not that you can do it with half the effort in another language, it’s that the 10-20% of time you may save is the most obnoxious and demoralizing 10-20% of the time you spend debugging. Digging around for that error which crashes your program 3 minutes after it happens is not fun, even with amazing tools like valgrind you still have trouble finding it. And until you do, that amazing you code you wrote is worthless.
I really don’t see Eiffel as the best language choice. A lot of people have suggested D, but given that it compiles to native code and supports the C ABI there’s no point in supporting D (it’s already supported). Languages like C#, Java, or Python would gain by being the typical language used. Users don’t want to have the CLR running with Java and Python just to use their three favorite programs… And since all three of those have massive libraries of their own, …, well there goes another chunk of RAM (Eiffel may benefit here, I’m not sure).
If they simply say “use what you wish” people will use a hodge-podge of other languages and people will eventually have three VM/Interpretor’s running… Who knows, maybe even more.
I don’t see Eiffel as being either:
1.) The best high level language for Gnome.
2.) Gaining that much from official support.
Just don’t write buggy code.
JUST KIDDING!
Yeah, C can be a pain, as can any of the older languages. But I would have thought that by now the libraries would be so mature that it would be more like gluing together a few library calls and viola! You have a gnome program.
Mind you, I have never ever even LOOKED at this stuff fro a developer’s standpoint… I am too busy in my own little world of coding…
If your program were a text editor that couldn’t save or open files, sure….
Hello:
Bertrand Meyers’s Eiffel seems to me a very good candidate, easy, clean language, with “contract programming” (CP).
I also like a lot what I see in the D language, but D because of garbage collector (not deterministic) may not be a great system language… but ok with a GUI paradigm, like GNOME or KDE.
In my view the relative failure of Eiffel to be adopted is the lack of a good, open source GCC type (with ELF/DWARF debugging support) compiler: small Eiffel (now smart Eiffel) just did not convinced me.
I have little doubt that a “great Open Source Eiffel compiler” similar to GCC/G++ will lead to a good develloper envoronment, and Eiffel would take off.
The D language, is also a great candidate, and may very well succeed because there is a compiler, and a standard library (so important too!).
An why not C/C++?
C++ is just “bad language”, and even his author apologize for having “caved in to the C lobby”.
Neither Eiffel, nor D seems to have the problems of C++ and I would welcome both to write a great windowing environment that OO languages do so well.
C++ was only successful… by default: it was the only OO language with decent compiler, debuggers, libraries available.
I hope that ISE, that the inventor of Bertrand Mayer will lead the creation of an open source compiler, and he will find like Trolltech did, that it can be highly profitable.
Beside making money with compilers is not so easy!