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 65105
To read all comments associated with this story, please click here.
stick to C
by on Sat 26th Nov 2005 21:31 UTC

Member since:

C is simple, easy to learn, multi paradigm (you are free to use whatever you want), easy to bind, easy to port.

Reply Score: 1

RE: stick to C
by rif42 on Sun 27th Nov 2005 02:34 in reply to "stick to C"
rif42 Member since:
2005-11-20

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

Reply Parent Score: 5

RE[2]: stick to C
by ma_d on Sun 27th Nov 2005 03:49 in reply to "RE: stick to C"
ma_d Member since:
2005-06-29

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

Reply Parent Score: 1