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

[steve <steve@seasoned-software.com>]

[-- Attachment #1: Type: text/plain, Size: 5624 bytes --]



James Giles wrote:

> 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 DOUBT this was because C taught them bad habits.

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

ACTUALLY, Linux itself, and many programs, are SYSTEMS code!  Some
features can't or shouldn't be used, and it is ALWAYS more prone to
errors.  It surprises me how well Linux generally runs, and rarely
crashes!

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

You don't do things like this until absolutely necessary.  I think there
is only ONE program I have done this with, and that is because it had to
interface with ANOTHER one that did the same(a run time interface).  NO,
it WASN'T LINUX!

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

This is because of the ones you talk to.  Maybe they all went to the
same class! 8-)

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

To tell you the truth, I only use pointers:

When the amount of data can vary, and is large(if it is only a few dozen
items(maybe a few hundred), I use an array).
When the structure is unknown.
To pass info to/from a function.
When it will make things faster, and I need the speed.

I have converted some programs to DBL(a fortran like language), COBOL,
and C,. and all three look similar.  The C version isn't overrun with
pointers.  Then again, C was like the 9th language I learned.  Sadly, I
have forgotten most of the others. 8-(

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

I haven't seen that!  HECK, some WRITE new languages.

I have seen the situation you describe more with COBOL than anything
else!

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

How many C programmers learned ONLY C?  I doubt that it is very many.

>  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)?

Probably NOT, but there IS a nice debate on C v. COBOL in the cobol
group! 8-(

>
>
> --
> J. Giles
> Ricercar Software



[-- Attachment #2: Card for steve --]
[-- Type: text/x-vcard, Size: 265 bytes --]

begin:          vcard
fn:             steve
n:              ;steve
org:            SEASONED SOFTWARE
email;internet: steve@seasoned-software.com
note:           notes would be here!
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard