Linked by Thom Holwerda on Sat 26th Nov 2005 17:02 UTC, submitted by Megatux
Gnome "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."
Thread beginning with comment 65667
To read all comments associated with this story, please click here.
A couple of clarifications...
by on Mon 28th Nov 2005 05:28 UTC

Member since:

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?

Reply Score: 0

RE: A couple of clarifications...
by ma_d on Mon 28th Nov 2005 20:45 in reply to "A couple of clarifications..."
ma_d Member since:
2005-06-29

Could you post some evidence of this please. You've peaked my curiousity.

Reply Parent Score: 1