BL> K&R is like all books: it puts things badly and leaves bits out, but
BL> it is especially difficult when coupled to C, where it is virtually
BL> impossible to try a few things to see what they mean. I have four
BL> books, and I swap back and forth, hoping that one or the other will
BL> put it in a way that I can make sense of. Oddly, the best one is the
BL> Borland Turbo C short turorial in the User's Manual. It concentrates
BL> on the things most likely to go wrong. K&R writes it as if nothing is
BL> ever going to go wrong with this best of all languages.

True, but essentially you arent doing what those books are aimed at, a
gradual progression thru learning the language. You are attempting the
other route, find something useful to do, want to be able to just quickly
look up the detail on a particular operation. Say you want to open and
read in the PKT, you really want a decent book which you can look up file
ops and get to the page which covers that virtually straight away, and
just have it presented succinctly. They dont attempt that. And its
actually compounded by the problem you talk about later where the
fundamental problem is that C is too low a level language for you. So you
have a problem that what looks like a very simple question, like 'how the
fuck do I get all all available *.PKTs which fit a mask and just suck out
the data as I want it from them. C just doesnt have that level of elegant
IO standard, so the book cant just show you the open command which does
that opening of them all with one statement, and then show you how to say
detect that you are moving from one PKT to the next.

C isnt even really a very suitable language for your task at all.
What you really need is a decent database type language where you
just specify the FORMAT of the PKTs and QWKs and just tell it to
open all the PKTs, have a very simple loop which just reads the
next message from the total collection of PKTs, do a bit of field
manipulation between the PKT format of the message and the QWK
format of the message, and write the QWK form of that message.

C really aint a suitable language, so you have to spend lots of
time farting around with IO, lots to learn on how to do it, and
the book just cant really treat that special case of the PKTs
and just show you how to do that work you need to do on the PKTs.

DB> As I said though, if you really want to *learn* C, then start
DB> at the beginning and work your way through - even if only to
DB> read the exercises and get a feel for "what goes where" in the
DB> book, so that when you encounter a problem at least you'll
DB> have a vague idea where in the book to start hunting 'round..

BL> I don't learn linearly, as I said, but I can look up an index.
BL> It seems our attitudes are different. I don't want to *learn* C,
BL> I want to *use* C.

Yes, and with a low level language like C, thats damned
hard for a book. Its not even that easy with a 4GL.

BL> I am trying to decide which language(s) I need.

There never is just one, depends on what you want to do.

BL> This is my second visit to C.  It was obvious
BL> that C is not the language to learn programming,

Thats not really true. It is indeed well suited as a language to learn
relatively LOW level programming, Its main problem is that it doesnt
protect the user enough from his stupiditys. OTOH the problem with the
other approach, teaching in a language which does, is that FAR too many
never actually make the step away from the teaching language like Pascal.
Frank is a good example of that. And it cripples your capability if you dont.

BL> and after my season with VB, learning tricks, I have come back
BL> to C to compare the two languages and find their limitations.

Corse many of the 'tricks' shouldnt be necessary. All the crap about
buffering shouldnt be necessary, the programmer should be able to
specify what he wants to do, and the SYSTEM should look after all
that crap without him even considering it. And thats what a 4GL does.
Atleast in theory.

Same for any essentially database style application. You are also
endlessly farting around writing code to check field values when
all you should have to do is to specify with a simple specification
whats an acceptible set of values for a particular field, and let
the system do that crap for you too, with you specifying what you
want done with the exceptions which arent legal. Like what you want
done with a dud message date.

BL> To me, the language is a bloody nuisance; the interest (and
BL> the money) is in doing something new in the software itself.
BL> The language gets in the way of me creating, and limits me.

Yep, its much too low a level language for that work you are doing.

BL> In spite of what everyone says, C suffers a great limitation
BL> with strings and buffers. Clumsy is the word that spring to mind.

Yes, but you havent noticed that it goes FAR further than that.
ALL the IO should be done by the system for that PKT->QWK app,
you should be able to just specify the format detail, and that
by data entry too, not farting around writing code. Ditto for
the field validation rules etc too, tho you do need a little
bit of roughly language syntax stuff at times there.

BL> VB does it transparently, in C I have to do it myself.

Well, VB does a lot more transparently, sure. But you shouldnt
have to fart around with buffers etc. And you ought to be able
to get the same final speed result too. And currently you cant.

BL> Something that was easy in VB turns out to be a shambles in C,

Yes, but you can get the reverse too. You dont notice those
when converting a VB to a C, but you would going the other way.

BL> and it is not always the approach itself. A simple
BL> array of names in VB is a pointer-monster in C.

Yeah, C has some very real problems with lots of stuff like that.
Corse part of your problem with just jumping in a praying is that
you have likely just used the very low level stuff in even C too.
Probably not using proper structures etc which can help heaps.

BL> VB is clumsy in other ways, and generally slower.

Yeah, but then you have to also question just how vital
this mindless obscessive timing anal stuff really is too.

BL> The other problem with C is the English part of the language.
BL> C encourages one to write in shorthand (I'm doing it myself
BL> already), and this makes it impossible to read,

Thats crap Bob. Thats actually one of Cs real strengths, allowing
a very very succinct expression of what you want to do, which, when
you really are fluent with C is as obvious as A=B. Corse C also
allows ou to write the most impenetrably cryptic 'clever' shit too.

Just like english, you have to make a distinction between a very
elegant and clean result and a piece of shit. Thats not the fault
of the language, its the fault of those who use it to write shit.

BL> especially if I come back in a week and try towork out why I did something.

Thats either of two things. It can be just shit code, far too cryptic,
and even if you were fully fluent in C would still be too cryptic. Or its
just because you arent yet fluent enough for it to be as obvious as A=B is.

BL> I have found that pointers also make it impossible
BL> to work out WTF is happening most of the time.

Nope, only for those who arent fluent in them. They are just

(Continued to next message)

--- PQWK202