College, C, etc. (Was Re: Is there a language that Dijkstra liked?)

[Darren New <dnew@fv.com>]

Brian Mueller wrote:
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  Anyone
> wonder why the object ADA compiler and GUI program is written in C?
> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.

Uh, you can't teach great C.  C is a very simple language with lots of
potholes.  You can teach programming OK, but getting C right is simply a
matter of experience. You make the same mistake the third time, and you
say "Oh, right, I did that six months ago, it had the same wierd
behavior, maybe I did it again."  It's like driving. You can't teach
someone how to get out of a blow-out or where to drive during an
earthquake. The conditions where such could happen are just too
variable. A blowout on a back road is a lot different than on an
on-ramp, an off-ramp, on the freeway, etc.  C's much the same. The only
way to get good is to get a bunch of blowouts. It's like chess: you can
learn the moves in a day. To be good takes months of playing. To be
great takes years or decades.

It takes like 2 - 6 years of programming C on a regular basis to where
your programs will run without unfindable bugs after the first
successful compile. *And* I must say, C and assembler and FORTH are the
only languages (out of maybe 15 to 20 commercial languages I know) that
are like that. The rest, if they compile they're close enough to right
that you can find the bugs because it's obvious what's actually
happening. (Personally, I now avoid any languages that have popular
tools like Purify for patching your executable so you can find baroque
bugs.)

What's much more important than the language is to understand
programming, understand how to build a program that'll do what you want,
and all that other design/use case stuff.  It doesn't look useful now,
because you're only writing one-person one-month programs.  You can't
write a "great" program in homework by yourself. A "great" program is
one that takes curve-balls thrown at you by the continued existance of
the program without folding under the weight of a bad design. Sadly,
almost nobody rewrites a program when it comes time to do so, when the
maintenance costs of it exceed the cost of rewriting it. There's a
timeliness factor that prevents most companies from taking six months
off to rewrite a program to do the same thing as one they already have,
except done right. Hence, if you only give the customer what they ask
for, you're screwed three months later when they want to add something
that's just too hard to add, but easy for them to describe.

You need to understand correctness, robustness, how to interpret what
the customer's asking for and turn it into what the customer wants
(never the same), how to pick what language you'll use (I paid for my
Ph.D. by picking the right language :-), understand the limitations and
patterns and idioms you need to know in your chosen environment,
understand people using computers (i.e., user interface stuff, even when
you're not doing user interfaces yourself), and even various theoretical
maths are useful (proving things equivalent to the halting problem or
some NP-complete problem has prevented me from wasting weeks or months
at times).

> Now that you bring that up, I got into trouble for having too many
> comment blocks in my code, WFT is this?  I could have handed my
> project to anyone in that room and they would have been able to read
> it and understand what I was doing easily from my comments.  I've
> always been told, the more, the better.  

Not necessarily. A program that doesn't *need* comments is best. :-) 
Not that I agree with your professor, mind. But if you get to the point
where you can hand your *uncommented* code to someone else and they can
follow it, *then* you are a "GREAT" programmer. :-)  The benefit being
that you don't have to keep the comments up to date when you modify the
code. The danger being that the code isn't nearly as clear as *you*
think it is.

> I hate my C.S. class, can't
> wait until the spring when I get to take C (which I know a bit), and
> learn how to do it RIGHT.

Suggestion: The best way to do it "RIGHT" is to listen to your profs
with skepticism, and *learn* what works, rather than going into it with
the attitude that you already know what works and the prof must be
wrong. Because the frustration you're seeing right now is part of the
job you have to learn to work around. It's not restricted to one
programming language or one college class. And you'll go out there, and
your boss will say "Use Ada because I read it's good in a magazine."
Your choice will be to use and understand it, or shovel fries into
little bags. :-)

[Example: right now I'm doing java, because "Use Java instead of Eiffel,
because Eiffel is a botique language. We acknowledge it's far superior
to Java for what we want to do, but how do we know it'll be around in 5
years?"  Of course, Java wasn't around 5 years ago and Eiffel has been
around some 14 years with minimal changes, but mere logic and facts
couldn't sway Sun's hype-spinners .]

Did you ask the prof *why* he took off for error checking? Did you ask
him *why* comments are bad? I find that asking such questions (not
necessarily during class) generally clarifies such things. If I were to
play devil's advocate, I'd say you shouldn't have error checking because
you should do the right thing with any input, and you shouldn't have
comments because your code should be so clear it doesn't need comments,
but I suspect your prof is just being stupid.  But *you* will never
distinguish between a stupid prof and a prof who communicates poorly
unless you ask why.

> version, short description, that's it.  It's not all us, it's our
> teachers, who are just about 80 years old, and want us to follow
> exactly what they did.

Well, none of this was around 80 years ago. :-)

*-*-*

As an aside, here's some hints for GREAT C:

Don't cast things to incompatible types, even if it works and is much
easier. Don't do tricks, even if it works and is much easier. Don't
index off arrays on purpose (trust me, you'll do it accidentally often
enough).  Learn what "assert()" does and use it frequently.  Check
*every* array access and make sure it's in bounds; doing so visually is
enough in most cases, but *think* about it every time you write an array
index expression. The same with pointer indirections. Understand the
difference between globals and externs, between definitions and
declarations. Worry about efficiency last.  Allocate memory and
deallocate that memory in the same function, or in a pair of functions
that are always called from the same function. (Memory allocations and
running off the ends of arrays are probably the most common problems.
Fouling up declarations is probably second, but easier to figure out and
easier to learn a style that prevents it.) Finally, write programs. All
kinds of programs. File filters, GUIs, terminal emulators, servers,
clients, file floggers, number crunchers, etc.  By the time you're
really good at C, C will be like COBOL: Everyone will use it, nobody
will want to. :-) My $0.005.

-- 
Darren New / Senior Software Architect / First Virtual Holdings Inc
http://www.fv.com or info@fv.com -=|=- PGP Key: ftp://ftp.fv.com/pub/fv
Fingerprint: 61 7D AF 9E 00 CC C2 ED / D8 4C D7 AA E4 C2 A0 73