The status of C

[Malcolm]

The documentation specifies that the collecotr will work
assuming certain conditions, and if you do not respect them
your program may crash, or the block that the collector thinks
its free will be reused with unpredictable results.

The GC library is as any other library. There are zillion ways
to make it crash. The same as, say, a sockets library. You
can crash it in a zillion ways by feeding it wrong data,
using invalid pointers, destroying its internal data
structures whatever.

So what?

I would normally expect a function to crash if I feed it invalid parameters.
If it is possible to crash it by altering global varaibles it depends on, or
by calling functions in the wrong order (except to construct the parameters)
then I would say it is badly designed.
If it is possible to cause a function to crash by executing legal C in
another area of the program, then the library is not like any other library.
Effectively it is a change to the language.

That's not to say that it is necessarily a bad idea to make a few minor
changes, such as forbidding operation on pointer internal representations,
for the sake of allowing an automatic garbage collector to do its business.

 

[john_bode]

Hey guys

Since C is my language of choice for almost any kind of application, I'd
like to know what the status of C is around the world today.

And I am ofcourse not talking about C++ or C#. I think the lack of object
orientation and garbage collection causes better programming discipline
needed for harder projects anyway.

As evidenced by all the robust, secure, reliable, and maintainable code
out there right now?

"Better programming discipline" is built by following best practices,
not by restricting yourself to the most primitive tools available.

I suppose all home builders should throw away their table saws and
pnuematic hammers and laser levels and prefab trusses; using nothing
but a hand saw and claw hammer should enforce better building
discipline needed for bigger projects.

Sorry, it's just that my personal experience with the whole "let's do
it the hard way, because it'll make us better programmers" attitude has
resulted in redundant, buggy code and missed deadlines. There are
times C just isn't the right answer. Why write 50 lines of code when
you can accomplish the same thing in 10? Why roll your own library to
do something that's already supported at the language level in Java or
C#? Why not use tools that come with blade guards already attached?

Is C still the language of choice for serious programming?

Depends on what you mean by "serious". There are some domains where it
would not be my first choice. Anything that requires a heavy GUI front
end, for example, would be better served with a language that provides
high-level support for widgets and graphics (Java, or C# with the .Net
framework, etc.). String handling isn't exactly a happy proposition,
either. But there are times when code size or execution speed trump
everything else, and in those cases it's either C or assembler.

Which businesses favour C, e.g. game, driver, os, device or even web
developement?

Is C on the decline?

C was state of the art 30 years ago. The art has advanced somewhat
since then. I would expect to see C used for new development less and
less as time goes on. I expect the last holdouts to be in domains
where code must compile to as small a footprint as possible, yet still
remain portable; games, device drivers, OS kernels, etc.

 

[Jean-Claude Arbaut]

This thread is going to be a flame war ;-)

This IS a matter of feeling, taste, habit, etc... And of course
applications.
You won't use C for tasks usually done in awk or python, for example.
But programming discipline has nothing to do with the language. If you
really
like the hard way, write your GUI apps in assembly ! Some people do that,
I've seen some web sites... very impressive, indeed, but is it really a good
idea ?

As evidenced by all the robust, secure, reliable, and maintainable code
out there right now?

I thought OpenBSD was robust, secure and maintainable And it's not the
only one...

"Better programming discipline" is built by following best practices,
not by restricting yourself to the most primitive tools available.

But "restricting" to "primitive" tools is not forbidden ;-) And, who says
C is primitive ?

I suppose all home builders should throw away their table saws and
pnuematic hammers and laser levels and prefab trusses; using nothing
but a hand saw and claw hammer should enforce better building
discipline needed for bigger projects.

To complete the joke: Amish farms are said to be among the most productive.
But you still have the opportunity to buy seeds to Monsanto ;-)

Sorry, it's just that my personal experience with the whole "let's do
it the hard way, because it'll make us better programmers" attitude has
resulted in redundant, buggy code and missed deadlines.

And is the attitude of a wannabe "real programmer" But it doesn't
necessarily mean that C is obsolete ! No need to become a C guru, you
can still write great programs with it.

You suggest that C is the "hard way". I'm sorry to inform you that
I program more easily in C than in any other language. I can compare with
BASIC, Pascal, Java, C++ and Fortran... I definitely prefer C. Some are
better for really simple tasks, but when I need full control over my
program, I use C, or sometimes assembly. Just try to check or change IEEE
flags
in Java... Hey, you can't !!!

There are times C just isn't the right answer.

I agree !

Why write 50 lines of code when
you can accomplish the same thing in 10?

Maybe it is faster, or more elegant, or more readable, etc...

Why roll your own library to
do something that's already supported at the language level in Java or
C#? Why not use tools that come with blade guards already attached?

Mmmm. Why reimplement in Java code already available for years in C.
This argument is pointless: you have only two "choices" (if you can choose
!)
when you decide to learn a new language: reuse existing code "as is" and
link,
or rewrite it. Both choices have drawbacks.

Depends on what you mean by "serious".

Would you suggest that C is not serious ? Just have a look at the
number of open source projects written in C... I wouldn't say they are
not serious.

There are some domains where it
would not be my first choice.

Here again, I agree

Anything that requires a heavy GUI front
end, for example, would be better served with a language that provides
high-level support for widgets and graphics (Java, or C# with the .Net
framework, etc.).

Well... Java is sometimes considered as a "toy" language, and it has many
many
drawbacks: subject to Sun will, have poor support for IEEE floating point,
is not as portable as claimed, etc. About portability: you first need a VM
on your OS. Try to run Java code on OpenBSD/macppc ! And it's not the most
uncommon. Even if you have a VM, there are differences, at least in
pathnames.
If you consider floating point, William Kahan has written a great paper on
this subject, I couldn't do better

If you need a GUI, you can still use C: X11 or Carbon are easily accessible
in C.
But a simpler way is using Python and/or TclTk for GUI, and C for all
computations.
Linking C in Python is very easy, and made even easier by SWIG.

Oh, and if you really like Object-Oriented programming, you can do that in C
as well.
It's not immediate, but not very hard either.

String handling isn't exactly a happy proposition, either.

In Java it's not perfect, but probably better. Nevertheless, string
handling is not a problem in C.

But there are times when code size or execution speed trump
everything else, and in those cases it's either C or assembler.

Oh, not necessarily either. Many scientific codes are written in Fortran,
and compiled functionnal languages can be very fast. Objective Caml is
said to be faster than C++.

C was state of the art 30 years ago. The art has advanced somewhat
since then. I would expect to see C used for new development less and
less as time goes on. I expect the last holdouts to be in domains
where code must compile to as small a footprint as possible, yet still
remain portable; games, device drivers, OS kernels, etc.

It's funny to note that almost all interpreters and compilers are
written in C. One remarkable exception is Octave, but it's also remarkably
slow ;-)
And BTW, many people criticize C++, for some good reasons. It's only an
hybrid
OO language, and Objective C may be considered much better. In fact, the
best OO language
may be the oldest, smalltalk. Perhaps too old for you But I don't think
old means
obsolete. UNIX is old, and MacOS X is built on a UNIX base... C is old, but
many
projects are still written in C. Why stop ? Only because someone has said
it's *too* old ?

Hey, a good task for Java is GUI, as you said before: MATLAB's GUI is
written in Java,
but you bet the computation core isn't !!! :-D

 

[jacob navia]

I would normally expect a function to crash if I feed it invalid parameters.
If it is possible to crash it by altering global varaibles it depends on, or
by calling functions in the wrong order (except to construct the parameters)
then I would say it is badly designed.
If it is possible to cause a function to crash by executing legal C in
another area of the program, then the library is not like any other library.
Effectively it is a change to the language.

That's not to say that it is necessarily a bad idea to make a few minor
changes, such as forbidding operation on pointer internal representations,
for the sake of allowing an automatic garbage collector to do its business.

The GC doesn't crash. But if you hide a pointer from it, it
will assume that that block is free, and give it to you again
when you call GC_malloc. This may make your code to crash because
the code that accesses the old block, will assume pointers somewhere
for instance, and that will make the code crash since when the block
was rewritten those values disappeared and were replaced by another
ones, most probably wrong ones.

The same will happen if you free() a block and the go on using it.

 

[jacob navia]

Depends on what you mean by "serious". There are some domains where it
would not be my first choice. Anything that requires a heavy GUI front
end, for example, would be better served with a language that provides
high-level support for widgets and graphics (Java, or C# with the .Net
framework, etc.). String handling isn't exactly a happy proposition,
either. But there are times when code size or execution speed trump
everything else, and in those cases it's either C or assembler.

The IDE of lcc-win32 is a GUI program written in C. It is 750K, and
very fast. It uses all widgets available under the Win32 API and
demostrates that C can be used without any problems to write GUI code.

I looked at C#, for instance. The code is still more or less the same
as C, in a more "abstracted" view maybe, but you do exacly the same
as in C because you call exactly the same widget set provided by the
OS.

But there is another advantage that C continues to have.

I started writing the IDE more than 12 years ago, under windows 3.1.

Most of the interface code from that time still runs without any
problems. Tha appearence of the widgets has improved of course,
but I have been able to use those "new" widgets without adding any
line of code because the windows API has been very stable.

How many of the programs written in "the language of the day" way
back in 1993 (OWL for instance) are still running today?

The huge advantage of C is that your software will LAST. Software
written in C doesn't need to be rewritten each few years.

C was state of the art 30 years ago. The art has advanced somewhat
since then. I would expect to see C used for new development less and
less as time goes on. I expect the last holdouts to be in domains
where code must compile to as small a footprint as possible, yet still
remain portable; games, device drivers, OS kernels, etc.

Many people in comp.lang.c are C++ programmers (apparently) that see
C as a dead. Maybe this is why they oppose any improvement to C, to
force people migrate to C++. One of the most glaring examples is Mr
Tisdale, but as this thread demonstrates, there are many others.

The strength of C is its simplicity, and even if I have added extensions
to my compiler system (lcc-win32) I have kept the simplicity of the
basic design of C. This is what got lost in C++, and as simpler
languages like C# demonstrate, a simple language is much more easier
to debug and maintain.

May I remind you that basically machines haven't changed conceptually
since the sixties?

A CPU, some high speed RAM, some disk, some peripherals like the
keyboard, there, a computer.

The CPU has some high speed registers, slower main memory, and even
slower disk storage. This is since the sixties.

That is why the C programming model still holds perfectly today.
Yes, machines have more now, more memory, more disk, more speed.

But THAT IS ALL!

Conceptually, they are exactly the same as 40 years ago.

New concepts?

OO programming is derived from Simula, already present during the seventies.

Virtual Machines?

Remember USCD Pascal?

Java as an Universal Computer Language (UCOL)?

The UCOL project was started in the sixties. And it is still not
finished

BLOATED Software?

Just look at Algol. The C++ of the sixties.

jacob

 

[Keith Thompson]

Many people in comp.lang.c are C++ programmers (apparently) that see
C as a dead. Maybe this is why they oppose any improvement to C, to
force people migrate to C++. One of the most glaring examples is Mr
Tisdale, but as this thread demonstrates, there are many others.

You continue to misunderstand and/or misrepresent the reason many of
us object to discussions of non-standard extensions here.

I won't presume to speak for anyone other than myself, but I believe
the following reflects the opinion of most of the regulars. (I do not
include ERT in this; he is merely a troll.)

I have no objection to the language extensions you've introduced in
lcc-win32. (It could be argued that they encourage the creation of
non-portable code, but I don't believe that's a strong argument.) I'm
not very familiar with lcc-win32 (I have little opportunity to use it
since I don't do much Windows programming), but from what little I've
seen it appears to be a good piece of work for the most part, and I
applaud you for making it available. It might even be a good idea to
incorporate some of your extensions into a future version of the C
standard; if so, your efforts will have provided the "existing
practice" that could make this practical.

*BUT*

That doesn't mean that discussions of your extensions, however useful
they might be, are topical here in comp.lang.c. The language compiled
by lcc-win32 (when invoked in a mode that enables the extensions) is
not C. It's obviously closely related to C, in much the same way that
C++ is, or that GNU C is.

Note that the same people who object to discussions of lcc-win32
extensions object equally strongly to discussions of C++ features that
do not exist in standard C. If we were trying to "force people
migrate to C++", this would be a very odd way to go about it.

This is not about objecting to what you've done with lcc-win32. This
is about objecting to your talking about it here, in a newsgroup
devoted to standard C.

And if you want to advocate the inclusion of lcc-win32 extensions in a
future standard, comp.std.c is the place to do it. But that's not
what you've done here. Rather than saying "C should support these
features", you've said "lcc-win32, a C compiler, supports these
features". We've already explained why the latter statement is
untrue.

To take a recent example, when someone asked about function
overloading in C, you responded by describing some non-C features in
lcc-win32. There was no reason to think that this would be useful to
the original poster (he didn't say he was using Windows), and it was
not an honest answer to the question. If you had said something like
this:

C does not support overloaded functions. If you're interested in
a C-like language that does support overloading, you might
consider C++ (discussed in comp.lang.c++) or the lcc-win32
compiler (discussed in comp.compilers.lcc).

I don't think anyone would have objected.

[...]

BLOATED Software?

Just look at Algol. The C++ of the sixties.

Are you thinking of Algol 68? Algol (the 1960 version) was a small
elegant language, an ancestor of both C and Pascal. The canonical
quotation on Algol 60 was C.A.R. Hoare's "Here is a language so far
ahead of its time, that it was not only an improvement on its
predecessors, but also on nearly all its successors." (comp.lang.misc
would be a good place to discuss this further.)

 

[Old Wolf]

Many people in comp.lang.c are C++ programmers (apparently)
that see C as a dead. Maybe this is why they oppose any
improvement to C.

[long refutation]

Dear Mr. Brick Wall,

I am getting a bit sore but I hope you do not mind
if we continue our regular meetings.

Signed,
Head.

 

[Mohd Hanafiah Abdullah]

Martin Johansen wrote on 09/06/05 :

This website might help:
http://www.tiobe.com/tpci.htm

Napi

 

[Dave Vandervies]

[Mind followups]

Of course, a lot of this is just for C programmers who are working with
a C++ compiler. A lot of C++ code is just C code, and C99 removed a lot
of the reasons to use C++ for non-OO work.

Namespaces
Templates
Automatic memory management
STL
....

Use the right tool for the job. OO is not the only reason C++ might be
the right tool for the job.


dave

 

[Dave Vandervies]

Hey guys

Since C is my language of choice for almost any kind of application, I'd
like to know what the status of C is around the world today.

And I am ofcourse not talking about C++ or C#. I think the lack of object
orientation and garbage collection causes better programming discipline
needed for harder projects anyway.

Working without these features might be a good way to _learn_ better
programming discipline, but good discipline combined with helpful features
is better than either one on its own.

Is C still the language of choice for serious programming?

Sometimes. Use the right tool for the job; sometimes C is the right
tool for the job, sometimes it isn't.
Keep in mind that technical advantages are never the only reason, and
often not the primary reason, why a particular tool is or isn't right
for a particular job. (But if they're ignored entirely that may be a
sign that something is wrong.)

Which businesses favour C, e.g. game, driver, os, device or even web
developement?

I write software for WeBuildRadar, and C is often the preferred language
for the parts of that software that I write (mostly data crunching of
various sorts).
The biggest reason for this is that additional features of "more advanced"
languages aren't necessary for the components of the system that I get
assigned to (mostly processing-intensive), and C is the language I'm most
familiar with and also the easiest to get other languages (often useful
in other parts of the system) to play nicely with. It's also nice to
have an easy "upgrade" path to C++ if additional C++ish features turn
out to be useful (it's not difficult to keep header files both C-clean
and C++-clean, and converting a well-written C module to correct C++
code ready for C++isms to be added can be done in an afternoon with time
to spare).
Another reason C is nice to work with for this type of application is its
"What you type is what you get" nature. This isn't always a Good Thing
(often you WANT the compiler to do things behind your back, because
you don't want to have to deal with them yourself), but in cases where
the type of things other languages do for you don't need to be done
anyways, not having to worry about things you don't want the language
doing without asking it to makes it easier (with enough experience)
to see bugs and inefficiencies when the first pass at the code doesn't
work correctly or quickly enough.

That having been said, I do end up switching to C++ (or starting with it)
often enough that being restricted to only C would make life difficult,
and I do have a few bits of C code that it would have been nice to have
converted to C++ BEFORE they started getting as messy and complicated
as they are now. So even though C is still useful, it's definitely not
the only language you need to know.

(And then there's the times when somebody else converts my code to C++
to make a change that would have been better done in C anyways... and
introduces a bug doing it... and then I have to find the bug without
any clues about whether it's a problem with the conversion or the new
code...)


So, short answer to your question: C is still useful (and widely used),
but not as universally as it was 20 years ago[1]; there are now more
general-purpose languages that are better for some things than C is,
and there are more special-purpose languages that are better than any
general-purpose language (including C) for the purpose they're built for.


dave

[1] It's worth noting that 20 years ago I was 5 years old and had never
seen a computer, so my knowledge of the state of the world then
is built solely on second- and third-hand knowledge, but I'd be
surprised if anybody who was around 20 years ago would disagree with
this assessment of the difference in the state of the world.

 

[Jean-Claude Arbaut]

Working without these features might be a good way to _learn_ better
programming discipline, but good discipline combined with helpful features
is better than either one on its own.

So the question is: Are C++ features helpful ? That depends

Is C still the language of choice for serious programming?

Sometimes. Use the right tool for the job; sometimes C is the right
tool for the job, sometimes it isn't.
Keep in mind that technical advantages are never the only reason, and
often not the primary reason, why a particular tool is or isn't right
for a particular job. (But if they're ignored entirely that may be a
sign that something is wrong.)


[...]

The biggest reason for this is that additional features of "more advanced"
languages aren't necessary for the components of the system that I get
assigned to (mostly processing-intensive), and C is the language I'm most
familiar with and also the easiest to get other languages (often useful
in other parts of the system) to play nicely with.

Now you see that depends ;-)

[1] It's worth noting that 20 years ago I was 5 years old and had never
seen a computer, so my knowledge of the state of the world then
is built solely on second- and third-hand knowledge, but I'd be
surprised if anybody who was around 20 years ago would disagree with
this assessment of the difference in the state of the world.

That must have depended on task: Fortran has always been the preferred
language in scientific computing.

1985... Turbo Pascal had just showed up I think.

But ya know... I wasn't very old either. Yep, that's right, 5

 

[john_bode]

The IDE of lcc-win32 is a GUI program written in C. It is 750K, and
very fast. It uses all widgets available under the Win32 API and
demostrates that C can be used without any problems to write GUI code.

Great. I do most of my work on Unix systems. lcc-win32 would be
useless to me.

Call me when your lcc app runs on *all* the popular desktops (Win32, OS
X, OpenLook, Gnome, KDE, etc.). My point was that since C doesn't
provide high-level (language) support for GUI features, you'd probably
be better off using a language that does provide that support in the
event you need to port or support multiple platforms concurrently. All
the world is *not* Windows running on x86.

I looked at C#, for instance. The code is still more or less the same
as C, in a more "abstracted" view maybe, but you do exacly the same
as in C because you call exactly the same widget set provided by the
OS.

Except that the widgets are provided by the .Net framework. As soon as
someone ports .Net to other platforms (such as the mono project on
Linux), then your code becomes *trivially* portable. GUI-intensive C
code is rarely trivially portable.

But there is another advantage that C continues to have.

I started writing the IDE more than 12 years ago, under windows 3.1.

Most of the interface code from that time still runs without any
problems. Tha appearence of the widgets has improved of course,
but I have been able to use those "new" widgets without adding any
line of code because the windows API has been very stable.

How many of the programs written in "the language of the day" way
back in 1993 (OWL for instance) are still running today?

I know the Navy is still using code written in Fortran IV dating back
to the early '70s.

The huge advantage of C is that your software will LAST. Software
written in C doesn't need to be rewritten each few years.

Properly engineered software rarely does, regardless of the
implementation language. There are plenty of Fortran and COBOL systems
still in daily use, because the requirements for those systems haven't
changed much since they were initially developed.

But tell me, how much *new* development is being done in COBOL? In
Fortran?

This is my point. The requirements for software are changing. C was
designed when most programs ran on time-shared minicomputers that
weren't widely networked and hardcopy terminals were the typical user
interface. The world has changed a *lot* since then. Apps have to be
network-aware, with all the security concerns that come with that.
They have to interact with a wide variety of input and output devices.
Compared to more recent languages like Python or Java, C's toolkit is
still pretty spare. Hell, just adding a standard library to deal with
basic networking would go a *long* way towards keeping the language
current.

Many people in comp.lang.c are C++ programmers (apparently) that see
C as a dead. Maybe this is why they oppose any improvement to C, to
force people migrate to C++. One of the most glaring examples is Mr
Tisdale, but as this thread demonstrates, there are many others.

Tisdale is a fscking troll; anything he says can be safely ignored.

I certainly don't advocate moving to C++; as OOLs go, it's a mess, and
for all the OO swoopiness it suffers from the same paucity of tools as
C for dealing with anything more advanced than a frickin byte stream
(and honestly, how OO is keeping the #include convention? I mean, come
*on*...).

The strength of C is its simplicity, and even if I have added extensions
to my compiler system (lcc-win32) I have kept the simplicity of the
basic design of C. This is what got lost in C++, and as simpler
languages like C# demonstrate, a simple language is much more easier
to debug and maintain.

A claw hammer is a lot simpler to use and maintain than a pneumatic
one. A pneumatic hammer is faster and gives more consistent results.
Which would you rather build a house with?

May I remind you that basically machines haven't changed conceptually
since the sixties?

In isolation, no. But the environment in which those machines operate
*has* changed significantly, as have the requirements that those
machines have to satisfy.

Machines are much more widely networked than they were 30 years ago,
and with that has come a host of security and reliability issues. C
provides no high-level support for network programming. C provides no
high-level support for protecting against malicious code; hell, it was
a fundamental weakness in the C library that allowed malicious code to
propogate in the first place.

I've been programming professionally for 15 years, the bulk of that in
C. And as I look at where software is going in the next few years, it
is becoming painfully obvious that C just isn't going to be the best
tool for an increasing number of domains. That doesn't mean I wish to
see the language *die*, it's just an acknowledgement that every
technology runs its course.

 

[Walter Roberson]

But tell me, how much *new* development is being done in COBOL? In
Fortran?

I asked a similar question a few months ago, and was answered that
COBOL and Fortran are still fairly active and are still undergoing
serious evolution.

http://groups-beta.google.com/group/comp.lang.c/msg/e1acf54c1bf8ca87

 

[Jean-Claude Arbaut]

Le 17/06/2005 21:54, dans [email protected], « Walter

I asked a similar question a few months ago, and was answered that
COBOL and Fortran are still fairly active and are still undergoing
serious evolution.

Fortran is still intensively used in scientific computing. It has
evolved to late to fight efficiently competing languages, but is still
in progress. 51 years later, it is still alive and healthy

 

[Jean-Claude Arbaut]

Le 17/06/2005 21:21, dans
(e-mail address removed),

I know the Navy is still using code written in Fortran IV dating back
to the early '70s.

Not surprising. NETLIB is full of old gems. Programs that were and are
still at the top. NSWC is another great (free) lib, from the Navy
I imagine.

 

[jacob navia]

Great. I do most of my work on Unix systems. lcc-win32 would be
useless to me.

Well you can fix that very easily if you buy the Unix version...

 

[Jean-Claude Arbaut]

Le 18/06/2005 01:47, dans [email protected], « jacob

Well you can fix that very easily if you buy the Unix version...

He He He I expected that. Self-advertinsing can't hurt...

 

[Keith Thompson]

Well you can fix that very easily if you buy the Unix version...

If you're referring to lcc,
<http://www.cs.princeton.edu/software/lcc/>, it appears to be free,
<http://www.cs.princeton.edu/software/lcc/pkg/CPYRIGHT>.

(Discussions about how the lcc license applies to selling copies of
lcc-win32 should probably take place in comp.compilers.lcc.)

 

[CBFalconer]

If you're referring to lcc,
<http://www.cs.princeton.edu/software/lcc/>, it appears to be free,
<http://www.cs.princeton.edu/software/lcc/pkg/CPYRIGHT>.

(Discussions about how the lcc license applies to selling copies of
lcc-win32 should probably take place in comp.compilers.lcc.)

To be fair, the owners can license it as they please. I believe M.
Navia bought rights, which is why his lcc-win32 is based on a
considerably earlier lcc. Other areas, such as the IDE, are
entirely his. I only put this here because I don't like leaving an
impression of software theft by M. Navia, which he has not done.

For John Bodes benefit, I believe the original portable LCC is
available, and does port to Unix. It will not have the extensions
etc. of lcc-win32.

Cross-posting to comp.compilers.lcc, so that my probable errors can
be corrected.

 

[john_bode]

So the question is: Are C++ features helpful ? That depends

For me, the STL is worth its weight. The string class makes text
processing a much happier proposition. For me personally, the overhead
hasn't outstripped the usefulness.

I find that I'm using templates a *lot*, not to say template syntax
isn't headache-inducing.

[1] It's worth noting that 20 years ago I was 5 years old and had never
seen a computer, so my knowledge of the state of the world then
is built solely on second- and third-hand knowledge, but I'd be
surprised if anybody who was around 20 years ago would disagree with
this assessment of the difference in the state of the world.

That must have depended on task: Fortran has always been the preferred
language in scientific computing.

1985... Turbo Pascal had just showed up I think.

But ya know... I wasn't very old either. Yep, that's right, 5

Well, in '85 I was starting my third year in college. We'd migrated
over from the old DEC 10s to a pair of spiffy and wicked fast VAX
8600s. Most of the terminals were VT220s, with a few old LetterWriter
hardcopy terminals for the nostalgic. C had just replaced Pascal as
the teaching language for the intro CS courses, which was causing no
end of grief for everyone involved. The professors and grad students
didn't have any experience with it, which combined with C's innate
weirdness caused a third of my class to *change majors*. Fortran was a
welcome breath of sanity after a semester of declarator hell.

In the PC domain, it was a wild and chaotic time. You had IBM PCs and
PC clones running CP/M or DOS, the original Mac had just been
introduced the year before, you had your Commodore 64s and VIC 20s and
TRS-80s and Timex Sinclairs and Coleco Adams and TI-99/4As, and you
programmed them all in either BASIC or Pascal or Logo. Everything you
did was either stored on 5-1/4" floppies or cassette tape (affordable
hard drives being a few years off yet). Your online options were BBSs
or Compuserve. Microsoft was just another struggling software
company.