[Courses] [C Programming] Anyone still here?

[Malcolm-Rannirl]

On Monday 27 May 2002 10:57 pm, Julie wrote:

> > My guess was a little different: I think at least one of my instructors
> > simply wasn't up on the latest language, and didn't want to be forced to
> > admit his competence was in Urdu, basically.
> >         And this was back when people actually spoke it.

> It has NOTHING to do with languages, tho.  That's what people
> just don't get.  

Nothing to do with specific languages, but it does (to a degree) depend on 
the class of language. Some general approaches work for all languages, others 
do not. 

There is a very different way of thinking (at least among the people I've 
talked to) between procedural (C, perl, etc), functional (lisp, haskell, etc) 
and object-oriented (smalltalk, subset of C++, etc) languages. People who 
have only every written or learned prodedural languages seem to approach 
things quite differently than those with experience with others. (I haven't 
met anyone who's only ever learned functional or OO, so have no comparison 
there).

This is where the "theory" part becomes essential (IMO). I've seen far too 
much "C that looks like C++ and claims to be OO" over the years. (I've seen a 
fair amount of the reverse too, well written OO C. Background clearly shows 
in the design).

> For example, I've spent a month or so rattling an idea around
> in the back of my mind.  It's just kinda bounce around with a
> lot of other things.  Two weeks ago that idea finally made it to
> the top of the heap and I began writing a design.  

Unless it's a complex problem (or contains a fair amount of math), I tend to 
find that I design in my head. I don't document what every function does 
before I write it (writing pseudo-code that differs little from actual code 
generally seems pointless to me). I do have a good handle on the abstract 
structure and work out details I know are going to be issues in advance 
though.

Of course if working with more than just me, this does not work so well, as 
my coworkers are not mindreaders (probably a good thing all things 
considered). In which case I do document.

To use a current example, I spent a week or so gathering information and 
thinking, before spending a couple of hours writing code. Other than a couple 
of typos and a miscommunication about the system it was interfacing to, the 
code worked. Of course explaining to your boss what you were doing for that 
week of thinking can be interesting. Especially when the resulting code is 
twenty lines long. (Most bosses don't seem to like the "It took you a week to 
write 20 lines?!" "It took a week -because- it's only twenty lines" argument).


> with "the design".  When I become "Goddess of All Programmers
> In My Realm" I will inflict design-before-code on all of my
> loyal subjects.  

There are times when "design by prototype" works well though. 

> It's always been the watchword.  I've been programming for 23 years
> and there has never been a time in my life when people really
> believed code should just be thrown away.  

Oh, I'd love to throw a whole bunch of code I'm currently working with away.

There are times when I do write things intended to be thrown away. The "plan 
to throw one away" approach to really understanding the problem often does 
apply in real-world situations. Unfortunately managers rarely see it that way.


-- 
"Just fear me, love me, do as I say, and I will be your slave."
- Jareth 

<<------------------------------------------------------------------>>
<<  This email is monitored by the US government under the auspice  >>
<< of the USA act. For private communication, ask me for my PGP key >>
<< ----- PGP: envelopes for email - www.pgp.com www.gnupg.org ----- >>