To view parent comment, click here.
To read all comments associated with this story, please click here.
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.




Member since:
2005-07-06
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.