Re: Why C?

From: Steve Graegert (str0ng_at_caths.co.uk)
Date: 11/01/04 

Date: Mon, 01 Nov 2004 23:41:43 +0100

jacob navia wrote:

> Dear friends:
>
> In another thread, John Bode wrote:
> > 2. Most of today's senior programmers started out with C and feel
> > more comfortable using something they know well.
>
> And in that same thread, Robert Tisdale wrote:
>
> > The only reason that C still exists is that
> > there are a large number of C programmers
> > that still aren't comfortable with C++.
> > There is no reason now to expect them to ever learn C++.
> > We are just waiting for them to retire or die.
>
> Mr Tisdale has often been called a troll here.
> I never understood why until I read that sentence.
> But he is saying the same thing that Mr Bode.
> In another language, yes, but the same thing.

I merely believe they were actually talking about themselves.

> By the way, I am 54, and I feel somehow concerned...
>
> :-)
>
> Am I too old to learn anything?

You're never to old to learn something. Especially not as a programmer
who always needs to learn more as new technologies emerge.

[snip]

> The crux of the matter is that I never swallowed the
> object oriented hype. I think that "object oriented"
> programming is OK in a number of applications that
> are well described by hierarchical models, but not
> for *all* applications.

I totally agree to that. I've developed, or at least been involved in a
lot of projects, where C++ was the language of choice, especially when
in comes to reusability, in terms of components, GUI development and
interoperability (in terms of networking across platforms). Sure all
these are some kind of built-in features of C (and a lot of other
languages) to some degree, but for those who have seen both worlds, C++
is superior on these issues.

On the other hand, when we were devloping low level libraries for
embedded devices, other constraints where in place and C was ideal for
these tasks. We didn't even think about using C++.

[snip]

> I saw Bjarne start with the idea of a better C and
> get stuck in an ocean of complexity, that swallowed
> him and his intrepid collaborators alive.

Complexity is not always a bad thing. You can do a lot of things in a
lot of different ways, but everybody is free to use as much of the
complexity as needed to accomplish his or her task. Use what you need
and leave the rest alone.

[snip]

> Maybe, maybe not. There are many other simpler
> languages (all object oriented) that have started
> after C++.

Exactly, and it is a good thing. It's the evolution of languages and
technologies.

> The creation/destruction of objects was one of
> the innovations of C++. Yes, but:

This is only the tip of the ice berg. There are lots of other
improvments that made C++ a valuable tool. For example, we highly
profited from the template mechanism in our projects, just to mention
one of the improvements.

> Automatic creation and destruction of objects can be
> obtained with a good GC. And I mean objects not in the
> C++ sense but in the C sense, i.e. a contiguous amount of
> memory cells, that have related information structured
> in a programmer defined way.

Why should an application programmer worry about the undelying memory
management when there is a language feature that does it for him/her.

> The problem of making an incomprehensible compiler, that
> generates code with algorithms completely impossible to
> follow by hand (i.e. by mind) is that nobody knows
> any more exactly how the software works.

I don't think a good programmeer needs to know how the compiler works to
be able to write good software. It's helpful, of course, but not a
requirement, unless you are doing systems programming at a lower level.

> Complexity leads to britle software, that is patched
> without any understanding because to patch it you
> have to understand all the class hierarchy in it.

This is partially true, also for C programs. To patch a C program you
should have a knowledge on how the program works. The same is true for a
C++ program that simply has it's logic structured hierarchically.
Analyzing a C program you have not written yourself can be as annoying
as analyzing a C++ program with all the hierarchy it embodies.

> C software is transparent compared with C++. This
> inherent simplicity is the great strength and the
> great weakness of C.

True. Read statements above.

> Because I am not a "C wave the flag" person either.
> Data processing is much more complicated than that.
>
> The positive side of C++ is the STL.

Absolutely, and I'm glad there is one.

> The STL can be done in a simpler way in C. Templates
> are just macros. The only thing to do is to make a macro
> facility that can be programmed, in C.

It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That's why some C functions
are implemented as macros while other simply can't, just because of that.

> I am thinking about an open compiler interface, where you
> write your macros not in "template C++" but in C.
>
> The compiler would load a DLL/shared object and execute the
> program in there, that will produce (eventually) text to be
> inserted at the current position. You write C at compile time
> parametizing it in C.
>
> A recursive language.

Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.

> I "didn't make it" to C++ for many reasons, reasons that I
> consider valid. It is a pity there is so little disucssion
> here about the real issues in data-processing and we stay
> at the superficial level of "I like it" or "I do not like it".

You mentioned a lot of good points, although I do not agree to all of
them. Just as you said, I hope the discussion is being held at a high
level exchanging good ideas on why to C or not to C.

Thanks

Steve

Relevant Pages

  • Re: The War On HLA
    ... If you're assuming that macros' only purpose is for "in-line" functions, ... languages demonstrate the ability of using macros to extend the language. ... I would ask why you're using Delphi in the first place. ... programming language (i.e., you can assign them to variables, ...
    (alt.lang.asm)
  • Re: macro for shorter array syntax
    ... How is OCaml on adding readmacros, which Lisp can do easily. ... I would not ask that of a parsed language. ... We're confident that using macros is useful to us, ... debate has legitimate points on both sides. ...
    (comp.lang.lisp)
  • Re: LSE64 in standard Forth
    ... The cost of an additional add verses the cost of: ... language and the benefits and pitfalls of that language. ... LSE64 forces a lot more naming of things than Standard Forth, a thing I consider positive, but some in the group have criticized. ... The problem I have with macros is one well known in the C community: while a macro names a concept, it does not automatically provide a clean interface. ...
    (comp.lang.forth)
  • Re: Hey, what is all this off topic posting?
    ... >>> that's all you're using macros for, I can see why you don't much like ASM. ... > PL/I language constructs though. ... >> write the macros using some arcane assembler to do that on a new ...
    (sci.electronics.design)
  • Re: Python syntax in Lisp and Scheme
    ... >>expressive power because you believe it will be misused. ... people programming languages, both on the job and as a University ... that, Macros are just one. ... number of lines of code per year regardless of the language they write ...
    (comp.lang.python)