Date: Tue, 6 Jun 1995 15:08:43 +1000 (EST) From: "Junaid A. Walker" Subject: Re: fork()/join() To: DJ Delorie Cc: terra AT diku DOT dk, djgpp AT sun DOT soe DOT clarkson DOT edu On Sat, 3 Jun 1995, DJ Delorie wrote: > > > > Wow. The first actual down-right rude reply I have ever seen on the > > >DJGPP mailing-list/newsgroup. Since when is ignorance and/or > > >incompetence met with this level of hostility? > > > > Hmm. I do that occasionally when somebody gets the idea that they > > are in a position to start demanding that things get done, and get > > done now. > > > > When it coincides with people whom I have never seen contribute I > > get mad. I assume that (e.g.) DJ also gets mad, but he's much > > more polite. Since he's low on sleep try pressing the issue. > > While I agree in principle, I find it much easier to just delete the > mail than to worry about it. I wrote djgpp for personal reasons, and > > "Calm down, it's only ones and zeros!" > > DJ > Goody, because you wont mind me commenting on the coding style of go32 and friends. Please dont take offence, just my humble opinions. 1) Serious lack of comments. This discourages people from working on the code. Most people do like to fix code in the extender etc, but (I) become dazzed by the code, with no comments to explain what's happening, especially around the extender, which because it has so much OS dependent code, is already hard to understand. Take a look at GDB, its well comented and identifiers are carefully chosen. I spent a day tracking down a serious bug in go32 support in gdb (already knowing what and why it was happenning). There was very little indication of what was going on in go32targ.c . Had to get out the magnifying glass and pour over the code, both in go32targ.c and gdb to figure out how and what was going on in go32targ.c .Then fall back on fsdb to see how things should be done. Lucky it was a trivial bug fix. 2) There really needs to be some doc describing the code changes with versions of go32 etc (changes.doc). This is usually informative to people making changes; they know what weaknesses exist in general, what has been done to try and fix things in the past, and which 'problem' files exist. 3) the tex info docs seem to getting along well, atleast you can plug and go, and edit them. This all sounds like a lot of work. But from past experience, documenting the code is trivial...and saves a lot of hack work later on when you are fuzzy on what things do (yes djgpp is getting that big). As a raw guess, one line of working bug free code takes 600% more time to get right than one line of comment. So comments that contribute to code legibility and reliability can really pay off when they reinforce what the coder intended (and we can check this off with what the code really does) I thinks its all about minimizing effort and maximizing results. From this point of view, djgpp has really go a raw deal, with only a handful of good apps using it, and more revisions than users. Regards, Junaid.