You probably think this is an April Fools posting, but in fact
c.l.c gets suggestions like this on a regular basis.
I can believe it. People do get caught up in stuff and often this amounts
to selecting form over function. (I especially love the one about the
Jaguar owner who ends up buying a used Toyota to get around in while the
Jag's in the shop.)
OOP is not better than functional or procedural approaches, it's slower and
much more complicated. But it is more popular because one can drop classes
in like building blocks (like you can't do that with a good library of
subroutines?).
RAD is the cause of most of the bloat out there but programmers on deadlines
like the way it impresses the boss.
These aren't improvements... they're form over function marketing tactics.
C may be an old language, and it probably should be updated to include a
true string type, but it is still one of the most powerful and machine
compatible languages out there. Modern computers may be faster and smarter,
but they still work essentially the same way as computers did when C was
created. C is still around because the same basic computer architecture is
still around. CPUs don't understand Objects and Classes... they understand
sequential execution, subroutines and interrupts... i.e. they understand C.
That's the key to C's longevity, C programming structure has a 1 to 1
correlation with the way CPUs work. (The only way to get closer is ASM and
I wouldn't wish a big assembler project on my worst enemy. [grin])
Delphi provides a perfect example of why C remains a viable language...
I started out programming in Pascal way back in the late 70s. Moved to
turbo pascal when PCs came out and then, after an interregnum where I played
at being a hardware geek, I purchased Delphi which was touted as the newest
and best programming language on the planet. (Yes, I know Delphi is
actually an application written in Object Pascal.)
After producing a number of small utilities (learning curve stuff) that
turned out to be huge --really freaking huge-- I began to question the
language. Eventually I dug the object pascal underpinnings out of Delphi
and began working in that, producing smaller and far more efficient
programs...
Until, that is, I discovered this...
Program ohno;
{$apptype console}
// uses sysutils;
var a,b,c : integer;
begin
a = 1;
b = 0;
Try
c = a / b;
Except
writeln('I snagged an exception');
end.
Every Delphi programmer should test this simple program. Note that the
division by 0 exception is NOT caught unless you un-comment the "uses
sysutils" line. And when you do un-comment that line your program grows by
nearly 30k (the entire object and class mechanisms have to be fully
initialized to handle the exception).
When writing programs in Delphi entire *keywords* of the language shut down
if you don't include certain units ("sysutils", in the example above).
Ever wondered why the Delphi IDE auto-includes so many units when you start
a new project? This is why. Core language functionality implemented upon
classes and objects in user loaded libraries. And don't even get me started
on their memory manager...
And were's the warning about this? Does it produce a syntax error? Is there
a compiler warning? Nope. The caution exists only as a softly worded note
in the back pages of a help file... AND Borland has said this is "acceptable
behaviour".
Lets face it... Any language that relies upon user loaded libraries for it's
core functionality is *deeply* flawed. One has to wonder how many Delphi
programs are out there with this nasty little bugg(er) alive and kicking.
I'm working in C now...
Found an implementation I really like...
I think I'll stick with it for a decade or three.
~~~