Re: Which language pays most 17457 -- C++ vs. Java?

["James Giles" <jamesgiles@worldnet.att.net>]

It's not a requirement, but C as a first language often teaches
quite bad habits and ideas.  I mention three examples below,
but these are the tip of the Iceburg.  These are merely things
that I've recently (within the past few weeks) had to explain
to someone because s/he was not getting the results or
the speed s/he expected.  Over the years I've noticed that
the quality of programs (and the quantity and quality of
errors made) are all worse if the programmer's first language
was C.  This applies to nearly all aspects of programming,
from simple character manipulation to sophisticated data
structures and from easy algorithms to large-scale programs.

I was horrified to learn just recently that many textbooks (and
courses) for beginning C programmers still teach the use of
gets().  This is a function that, if you mention it to beginners
at all, you tell them *not* to use it under any circumstances.
Use fgets() instead, so that you can tell the I/O library how
large your buffer is and it can prevent it from being overrun.
(Better yet, use fread() instead and scan for the record mark
yourself, since fgets() doesn't inform you if you've only
read a partial record.)  Just in case you think this is only
a naive beginner's problem, there was a LINUX security
problem because of exacly this sort of error (an overrun of
a buffer - though I don't think it was gets() that was used).
Bad habits and misconceptions resurface even in the code
of 'gurus' who have presumably learned better -  but lapse
sometimes.

Many C programmers think that a (float ***) is the same
thing as a multidimensional array - it isn't.  In most
environments the resulting pointer-to-pointer-to---to float
is much less efficient than an array and can lead to serious
and difficult to find errors if you actually manipulate the
pointers themselves a lot.  I just corresponded with
someone who was complaining that Fortran couldn't
remap arrays with pointer-to-pointer... mechanisms
like C does.  I pointed out that Fortran has more
efficient ways to reshape arrays (as does C) and that
he shouldn't be using pointers so much anyway.

Indeed, C users tend to vastly overuse pointers in a lot of
contexts.  If I mention to a group of programmers that I'm
going to implement a given data set as a list, only the C
programmers in the group tend to uniformly assume I'm
going to use a linked list and pointers.  This is in spite of
the fact that linked lists are almost always the *least*
efficient way of implementing a list - and are more error
prone as well.

There are actually an enormous number of things of this kind.
I'm of the opinion that programming with good style can be
taught regardless of the language used.  But it seems to me
that C makes this more difficult and the issues involved aren't
well addressed by the way C usually gets taught.  The above
misconceptions are something that the C programmer will
have to unlearn sometime in his(her) career.  This is true
of a number of other C-isms that are quite common.  It'd
be better for new programmers not to learn these false
ideas in the first place.  Languages which tend not to induce
bad habits (and were designed with teaching in mind) like
Turing and Pascal would be better first languages (you
can get bad habits from those as well - but fewer and easier
to remedy).

This brings to mind another C-ism (or, it seems to be a C
programmer's position more than anyone else's): they tend
not to learn any other languages (except C++ and other C
derived languages).  Indeed, they often come up with the
most bizarre rationalizations for not bothering to learn other
languages.  I think that C is so hard to learn to use *well*
that most C programmers assume that the same is true for
all other programming languages.  They, quite naturally,
hesitate to embark on that path.  Instead they learn all
the convenient (and usually false) criticisms of the other
languages.

Is any of this really relevant to comp.lang.(fortran, cobol,
smalltalk, or ada)?

--
J. Giles
Ricercar Software