Pascal Schmidt wrote in a message to Roy J. Tellason:

 PS> Hi Roy! :-)

 RJT> That's a real good point.  I think a lot of
"programming" isn't so 
 RJT> much sitting down and writing code as much as defining both one's 
 RJT> understanding of the problem and the approach you plan to take to 
 RJT> deal with it.

 PS> Much agreed, but some amount of sitting down and coding is often
 PS> required to understand the problem and to find out what kind of
 PS> infrastructure a solution requires. Some design can be done before
 PS> starting to code (sometimes it's obvious how many different modules
 PS> are needed and what they should do), but things also tend to come
 PS> up while writing the code (like ending up writing a couple of
 PS> somewhat similar function and then putting them all in a module of
 PS> their own).

 RJT> I saw an awful lot of those machines,  mostly because of repairing 
 RJT> them,  which I did for a while.

 PS> Never had a problem with mine despite some abuse. ;) I wish I had
 PS> kept and not sold it.

 RJT> I thought back then that it would've been a whole heck of a lot more 
 RJT> usable a computer if someone had come up with a small card to plug 
 RJT> into the cartridge port and let you plug a 34-wire floppy cable on 
 RJT> the other side.  There even seem to be some lines there that were 
 RJT> meant for something of the sort.

 PS> Well, there were also regular floppy drives for the C64. I had one,
 PS> but they used one of the other ports of the machine. ;)

Yeah,  the 1541,  which gave new meaning to the word "slow"... :-)

 PS>> Then came university, which brought me to Linux and programming in 
 PS>> C and to some small extend also in C++.

 RJT> I've never really felt much attraction to c++ at all,  there's 
 RJT> enough with c to keep me busy for a really long time.  

 PS> C++ was required by some university courses, I don't use it when I
 PS> have a choice. I'm not a big fan of the object-oriented approach.
 PS> It has its uses for some things, none of which interest me (GUIs
 PS> and such).

I agree that it has its uses,  but it appears to be tending to be used
*way* too much,  for too many different things.  And there's a nontrivial
amount of additional overhead needed for it.

 RJT> Yeah,  most programs didn't bother with the BIOS because it was too 
 RJT> slow.  And since you wanted to write directly into video ram you had 
 RJT> to find out what hardware was running (mono or CGA,  EGA and VGA 
 RJT> came a bit later on :-) and where that ram was.  Programs were a lot 
 RJT> more complicated in this respect.

 PS> A somewhat similar problem exists today, at least when you're
 PS> writing portable stuff meant to run on different Unix flavors. It's
 PS> not so much about hardware, but about what system libraries are
 PS> available and what functions they provide.

I can see where that might happen,  but I haven't encountered that situation yet.

 PS>> Well, much of what is found in the Linux C library is derived from
 PS>> the POSIX standard(s).

 RJT> I don't even know what those _are_.  Except vaguely,  that is.

 PS> POSIX == Portable Operating System Interface for Unix

 PS> The standards define a lot of library function that have to be
 PS> there and also document system tools like sed or grep, along with a
 PS> set of parameters that those tools have to support to be able to
 PS> call themselves POSIX-compliant.

Ok.

 PS> [...]

 RJT> I remember back when I was in here years ago there were people 
 RJT> then who were using makefiles and such,  I never got into 
 RJT> anything that complicated at the time and now it seems like an 
 RJT> awful lot of stuff uses them.

 PS> It has lots of advantages for any project with more than, say, two
 PS> .c and .h files. For one, how to build the software is documented
 PS> by the makefile and there is no chance to forget any details.

That's the thing,  I look in those and try to understand what's going on
but I'm missing some bits yet.

 PS> For bigger projects, the fact that make only rebuilds what needs 
 PS> to be rebuilt is a big plus during development.

That was my original understanding of what they were good for.  I also
would think that this was more of an issue when machines were slower than
they are now.  I remember Bob saying something about having a whole 80M
drive to work with,  and wishing I had one at the time.  :-)

 RJT> At some point I'd like to get a better understanding of that 
 RJT> stuff too.  I see where O'Reilly has a book out on the subject, 
 RJT> maybe I'll see if I can find some online info on it if I can't 
 RJT> locate the book locally.

 PS> I've learned my make knowledge from "info make" ;), but O'Reilly
 PS> books are generally known to be of very good quality, too.

That's been my experience so far.

 RJT> Ok.  Where else would printf show up,  under bash?

 PS> printf is a command-line tool that is part of the sh-utils package
 PS> (or in newer distribtions the coreutils package), so it's
 PS> documented in section 1.

Ok.

 RJT> That's good to know.  There seem to be an awful lot of libraries out 
 RJT> there, and I have no clue as to what most of them are for,  or why 
 RJT> some applications seem to need so many of them.  Where is this 
 RJT> documentation normally found,  in the source packages?  I don't 
 RJT> recall running across much of it in the system here.

 PS> Much of it is manpages or html docs that are installed alongside
 PS> the devel packages. For example, on Red Hat, libpng documentation
 PS> is part of the libpng-devel package. They also come with the
 PS> sources, mostly, yes. Sometimes the documentation only lives on the
 PS> project's web pages, though. 

Well,  after way too long of depriving myself of such,  I've got web access
again (even though I've been unemployed since June) and am taking much
advantage of it these days.  I'm downloading some component data sheets as
I type this.  :-)

---