Why C?

[jacob navia]

Dear friends:

> 2. Most of today's senior programmers started out with C and feel
> more comfortable using something they know well.

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

By the way, I am 54, and I feel somehow concerned...



Am I too old to learn anything?

In any case I hope that Mr Tisdale will have to wait
a long time, do not feel like leaving right now.

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.

Surely not.

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.

Is that because of his object oriented mind set?

Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++. There was already objective C when he started,
that has survived well in the Mac and in the later
incantations of the Next step OS.

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

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.

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.

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.

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

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.

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.

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.

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

jacob

 

[Mike Wahler]

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

Neither "data-processing" nor "the real issues in data-processing"
are topical here. Nor are language comparisons, advocacy, etc.
The standard C language is the topic here.

-Mike

 

[Steve Graegert]

Dear friends:





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

 

[jacob navia]

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.



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

There are two interfaces to call your compile time functions.

1: You get called when the compiler informs you of a syntax
event, an event that you are interested in.

You express your interest for a specific event by using:

#pragma event(FunctionStart,MyFnCall,templates.dll)

When a function definition starts, the compiler loads
the MyFnCall function from the templates.dll shared library
and runs it. The function can produce text to, for
instance, record the fact that this particular function was called by
generating a string:
"fprintf(stdout,"entering function fn\n");"

The compiler compiles this string as it was written
in the program at that point.

Or the function will not produce anything but record in some
variables private to the dll the fact that this function is
called and look in the local variables of it if there is
any managed object that needs special initialization.

Or other stuff, whatever.

The interface between the compile time function and
the compiler are C strings.

The compiler run time provides you with functions and
methods to access the argument list, get the current function
name, and many other info that you may need. You get an
environment data block with most of the relevant info.

You call in the compiler by obtaining a function pointer table
from the compiler at load time. This will be done
automatically.

2:

You get called because you write a call to your compile
time function yourself in the source text:

#pragma compiletime(list,listgen, templates.dll)

Then you do:

list<int> *intList;
Then your list function generates code
"typedef struct tag_int_list {"
" struct tag_int_list*Next;"
" int data;"
"} INTLIST;"
" INTLIST *intList;"

And you can generate a series of library functions to handle
integer lists.

This is no longer generated automatically in a
preconceived way by the compiler but is programmed
by the user. The template expansion is done in
a function like this:

char *listgen(Type T)
{
char *typeName = GetTypeName(T);
static alreadycalled;

Output(NULL); // Initializes the buffer to empty.
if (GetLexicalLevel() == GLOBAL &&
alreadycalled == 0) {
Output("typedef struct tag_%s_list {",typeName);
Output("struct tag_%s_list *Next;",typeName(T));
if (Sizeof(T) <= sizeof(void *)) {
Output("%s data;",typeName);
}
else { // types bigger than ints are allocated.
Output("%s *data;",typeName);
}
alreadycalled = 1;
}
else if (GetLexicalLevel() >= LOCAL) {
// This template implementation decides that
// all types must be previously known by writing
// at the global level:
// list<int>, for instance. Other schemas
// are possible of course.
if (alreadycalled == 0) {
// No more incomprehensible template
// errors. Just normal messages.
CompilerError("template list<> called uninitialized");
return "";
}
// we are in a local variable declaration.
// Output just the name of the already defined
// type
Output("%sLIST");
}
else {
// We are not at the global level, and not in a
// local declaration. Probably parameter passing,
// or within another structure definition...
// Bad call, emit an error
CompilerError("Bad call to list<> template");
}
return Output("");
}

Note that this templates are programmed without any need
for the cumbersome "IF" template macros that are needed
when a compile expands the template.

The downside of this flexibility is (as always) that this
needs a bit of more effort.

I have a prototype of this up and running but it needs to be
fleshed out, the compile time procedures must be written,
the load/unload protocol must be refined, more events and
precise meanings must be defined, etc.

But the basic idea is this.

jacob

 

[Skybuck Flying]

Dear friends:





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.

By the way, I am 54, and I feel somehow concerned...



Am I too old to learn anything?

In any case I hope that Mr Tisdale will have to wait
a long time, do not feel like leaving right now.

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.

Surely not.

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.

IMHO C++ is precisly this... overly complex junk.

If you think C++ equals OO you haven't seen Delphi for example.

I love Delphi's OO

Programming without it would be unthinkable.

It's not a solution for everything... but it does help a gigantic lot

Then again... C is closer to ASM.

That means C might be more suited for LOW LEVEL STUFF and ENGINE stuff.

Though pascal/delphi can do many things that C can do as well too...

Skybuck.

 

[E. Robert Tisdale]

Yes, why not bring some new concepts into C.

That's what C++ does.

This idea is worth being discussed in more detail.

Probably not.
Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

Most C programmers (like Jacob Navia I suppose) are amateur programmers.
They have learned just enough C to write the programs
that they need to write to help them succeed
with their chosen professional careers whatever those careers may be.
They don't want to learn more complicated computer programming languages
and they don't want to learn about new and more subtle features of C.

Let me paraphrase the original question,
"Why use C when C++ can do everything that C can do?"
All the "reasons" given for using C instead of C++
are actually "rationalizations" or "excuses".
None of them hold up under critical scrutiny.

Your assertion that
C was ideal for low level libraries for embedded device
begs the question.
If C was ideal for this purpose, then so was C++.
You offer no evidence to the contrary.


The notion that you can make complicated problems simpler
by using simpler programming languages is wishful thinking.
C++ is complicated because it needs to be complicated
to deal with complicated problems
that programmers need to solve today.
Smalltalk and Java are simpler because the language designers
chose to sacrifice performance and efficiency
to make programming easier and more reliable.
This was a good trade-off in most (> 90%) of all cases
but practically impossible to work around if, like me,
you really care about performance and efficiency.
Anyway, the current trend is for programming languages
to become more -- not less -- complicated.

The future belongs to professional programmers
who are willing to learn and use new language features
and new computer programming languages.
This means that amateur programmers are going to find
more and more programs that use language features
that they can't really read or understand.
Most of them are going to decide that
they can't be bothered to learn about them
and will elect to ignore them until the end of their careers.

Computer programming is *not* revolutionary.
It's evolutionary.

A scientific truth does not triumph
by convincing its opponents and making them see the light,
but rather because its opponents eventually die
and a new generation grows up that is familiar with it.
-- Max Planck

 

[Dik T. Winter]

Trolling again?

> Probably not.
> Most C programmers don't want to add new features to the language.
> Witness the resistance to the new C99 standard.

Right so. You should only add new features to a language when they do
not invalidate older programs.

> Most C programmers (like Jacob Navia I suppose) are amateur programmers.

Is Jacob? I think not...

> They don't want to learn more complicated computer programming languages
> and they don't want to learn about new and more subtle features of C.

Ever looked at Algol 68? A language that I have used quite extensive.

> Let me paraphrase the original question,
> "Why use C when C++ can do everything that C can do?"
> All the "reasons" given for using C instead of C++
> are actually "rationalizations" or "excuses".
> None of them hold up under critical scrutiny.

Actually my distrust of C++ comes from experience. Once upon a time I had
to install a program on both the Sun and SGI platforms. It was written
for the SGI, and compiled on that platform without glitch. It would
however not compile at the Sun, as the C++ implemented there was subtly
different from the C++ implemented on SGI. But both adhered to a then
current standard. I had to look very hard to see how to change the source
so that it would compile on the Sun, and I succeeded. After I made the
changes, the program did compile on the Sun, but no longer on the SGI.
It was impossible to get a program that would compile on both platforms.
I admit that this was in the early days of C++, and what was 'standard'
changed nearly dayly. But it gave me a general distrust of languages
that make incompatible changes, as was occuring with C++ at that time.

> The notion that you can make complicated problems simpler
> by using simpler programming languages is wishful thinking.
> C++ is complicated because it needs to be complicated
> to deal with complicated problems

Have you ever looked at Ada? Anyhow, solving complicated problems
does not necessarily mean you have to use complicated constructs.
Did you ever write a threads-library for C++? I did, for the SPARC.
And the ultimate result was a library completely written in C. The
task was complicated, but the tools needed were not.

Every problem has its own tools (and hence language) that fits best.

 

[Tim Rentsch]

Yes, why not bring some new concepts into C.

That's what C++ does.

This idea is worth being discussed in more detail.

Probably not.
Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

[52 lines of OT comments snipped]

Almost all of this was off topic. Please limit your comments to those
(agreement or disagreement notwithstanding) likely to be of interest
to the newsgroup's readers.

Also, just a little tip - most articles benefit if their fact/opinion
ratio is raised above 1%.

 

[sunil]

Dear all,
This is a great discussion. Both C and C++ are great languages for
Software Engineering. But I prefer to use C when dealing with low
level operations like microcontroller or kernel level or device driver
develeopments. I prefer to use C++ when I need generic programming
(templates) or dealing with computer science data structures (STL) or
several other application level developments.

Thanks to the developers of both C and C++.

Sunil

Dear friends:





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

 

[E. Robert Tisdale]

This is a great discussion.
Both C and C++ are great languages for Software Engineering.
But I prefer to use C when dealing with low level operations
like microcontroller or kernel level or device driver developments.

You can use C++ for this as well.
C doesn't have any features that C++ doesn't have.

I prefer to use C++ when I need generic programming (templates)
or dealing with computer science data structures (STL)
or several other application level developments.

Thanks to the developers of both C and C++.

They are the same people.
C++ is simply an extension of C.

See the
History of C++

http://www.hitmill.com/programming/cpp/cppHistory.asp

 

[jacob navia]

Delphi is a nice programming environment, no doubt about it.
C programming environments are starting to catch up now though.

 

[Flash Gordon]

Delphi is a nice programming environment, no doubt about it.
C programming environments are starting to catch up now though.

Starting to catch up?

Borland C++ builder has been available for a *long* time, and it
provides a very similar environment to Delphi being written by the
same people. There are others if you want that type of things and are
prepared to actually look for them. Admittedly very few will *only* do C
since most will do C++ as well and often a number of other languages.

 

[Dan Pop]

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.

Which doesn't make them right. C was not my first programming language.
By the time I learned C I was already familiar with Fortran, BASIC,
Pascal and several assembly languages (also several languages used by
programmable calculators). Yet, C was love at first sight: it allowed me
to express my intentions in a far more clear and concise way than anything
else I used before.

A couple of years later I tried C++. I didn't like it at all: many
features that looked useful at first sight proved to become maintenance
nightmares when used in non-trivial programs. The whole language was
marred with traps and pitfalls of the worst kind, that made trivial to
generate horribly difficult to find bugs. Furthermore, handling a
non-trivial program written by someone else proved to be next to
impossible if not downright impossible: practically no one writes the kind
of documentation a C++ program requires in order to be maintainable.
Some very sophisticated tools provide a certain help, but I don't feel
comfortable at all when I have to rely on anything more sophisticated
than grep, find and vi when dealing with someone else's code.

Since then I learned a few other languages, so it's not that my learning
capabilities were gone by the time I tried to learn C++. One could
argue that my mind is too weak to meet the requirements of *using* C++.

The life of the high level programmer, who merely uses class libraries
already developed by other people to solve his problems is much easier
than the life of the low level programmer who has to actually implement
and maintain all those class libraries.

I have seen C++ projects being abandoned when the developer moved to
another job. No one else could make any sense out of his code and his
comments. In one specific case, I was assigned the job of reimplementing
such a project in Perl, so that people coming after me could still have a
fighting chance of understanding and maintaining the code.

I'm not saying that one cannot write good C++ code, but I do say that it
takes more discipline and software engineering experience than the average
C++ programmer does possess. The big deal is not writing working C++
code but reading and maintaining someone else's C++ code.

As far as OOP in general is concerned, I've always felt that it never
delived what it promised. The concepts looked *much* better in theory
than in practice.

Dan

 

[Dan Pop]

Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

1. There is no resistance to the new C99 standard. Give me the
*conforming* implementations for everything I have to support and
I'll start using it.

2. There is a genuine lack of interest in C99, because the new features
it introduces are not the ones the C programming community at large
is really interested in. Give me typeof, statements and declarations
in expressions, pointer arithmetic on void pointers (sizeof(void) == 1)
and __builtin_types_compatible_p and you can take back all the new
features of C99, except inline functions and VLAs.

Dan

 

[Old Wolf]

IMHO C++ is precisly this... overly complex junk.
If you think C++ equals OO you haven't seen Delphi for example.
I love Delphi's OO
Programming without it would be unthinkable.

Surely you are trolling here? There is absolutely nothing that
you can do in Borland Delphi that you can't do in Borland
C++Builder (with the same level of complexity).

 

[Chris Hills]

They are the same people.

No we are not.

C++ is simply an extension of C.

It was when it started but no longer.

See the
History of C++
http://www.hitmill.com/programming/cpp/cppHistory.asp

Anyone can publish anything it does not make it true.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Michael Wojcik]

If you mean "great" in the sense of "bigger than it needs to be", I'll
agree.

C doesn't have any features that C++ doesn't have.

Trivially false. For example, C++ lacks C's feature of automatically
converting void* to and from any object pointer type.

They are the same people.

Trivially false. Dennis Ritchie is not Bjarne Stroustrop.

 

[jacob navia]

Dik T. Winter wrote: (citing Mr Tisdale)

Is Jacob? I think not...

I am an amateur of course. I like programming, building
systems, creating software. I mean I am not doing this
just because I need to earn money even if I earn my life
with it. I do it because I like it, like the amateur
programmers.

That's why I participate here, helping other amateurs
of this activity for instance, or engaging in momentous
threads about C, data-procesing, etc.

You can have the software I write for amateurs like
me if you download the C compiler system I work with.

http://www.cs.virginia.edu/~lcc-win32

It is a system designed for amateurs, people that
do not want to install a 2.4 GB system (latest MSVC)
or a complex language where the compiler is an
incomprehensible black box.

Just C. Fast, simple, small, the whole system is
4 MB, complete with IDE, compiler and all you need
to write systems in C.

My users are C amateurs like me, like many people
I know.

I remember the bulletin boards where the last words were
always:

Enjoy !

 

[E. Robert Tisdale]

Dik T. Winter wrote: (citing Mr Tisdale)

programmers.

Is Jacob? I think not...

I am an amateur of course.
I like programming, building systems, creating software.
I mean [that] I am not doing this just because
I need to earn money even if I earn my life with it.

Are you a hobbyist?

I do it because I like it, like the amateur programmers.

Professional programmers are hired and paid
to write code for other people to use.
Amateur programmers are hired and paid to do something else
and write programs for their own use to help them do there work.
There is nothing wrong with being an amateur.
They may be experts -- Olympic athletes are amateurs.
Amateur programmers tend to learn just one
computer programming language and try to use it for everything.
We expect professional programmers to become experts
in a variety of computer programming languages
and use whatever language is designated for a programming task.

 

[E. Robert Tisdale]

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.