laura@hoptoad.uucp (Laura Creighton) (03/01/86)
In article <653@moscom.UUCP> jens@moscom.UUCP (Jens Fiederer) writes: > >Dear Laura: > >I think accusing people whose C code does not pass lint, assumes ints are >n bytes long, who don't check return codes from function codes, etc. of >being unprofessional is going a bit far. Yes, their code is not portable. >If their intention was to write portable code, your accusation hits home. >Otherwise they might be entirely unconcerned. It is this ``entirely unconcerned'' attitude that bothers me. That is what is unprofessional. To be a professional is to do the best possible job even under adverse circumstances. It is possible to learn how to write protable code, and possible to discipline yourself so that you do not write unportable code. I know lots of people who do this routinely. I know lots of people who would like to do this but do not know how. This is why I am writing a book. And I know lots of people who really don't care. And these people I call unprofessional. [long list of reasons why people are in a rush and don't care...] These are excuses. But good architects don't build building which fall down when it rains and good civil engineers don't build bridges that buckle after 10 years of use and good mechanical engineers don't design valve systems that won't last through the winter and good doctors and nurses keep giving out their vey best despite lack of sleep and tremendous pressure... but good programmers can say, ah, managment was hassling me and there was a deadline? Come on. There was a time when it was (supposed to be -- I wasn't alive then) possible to tell the difference between the professionals and the ``blue collar workers'' because the professionals had a personal stake in their work and the blue collar workers (with notable exceptions) put in their time without having a personal stake. Now I know lots of programmers who have no personal stake in their work and view programming as an ``assembly line job''. And I know blue collar workers who care a lot more about their work. Remember how this discussion started? (Though I have cross-posted to net.cse, this one began in net.singles.) People wanted to know what title they should give. Somebody, I forget who, complained that he didn't want to be confused with a person who had taken the 8 week -- be a programmer from ``Miracle Data''-- course. And I flamed him real good since I knew lots of professional programmers who didn't have a degree and lots of non-professionals who didn't? I have been doing a lot of thinking over the last few weeks and have written several flames which I have not sent to net.cse. (As a point of reference -- if you ever need to get vitriolic and nasty, consider breaking your tailbone and doing without sleep for 2 days. I did this last week, and was able to generate infinite amounts of vitriol for all things which bothered me.) I am sorry that I toasted that person a month ago. I would send him an apology except that this news expired. Assuming that he is a professional, or wants to be the same, then he has a real problem in that he doesn't want to be identified with the non-professionals. I think that he is wrong in thinking that it is a degree that has made him a professional, though. I am tracking three sorts of people in university today. Type A -- likes thinking about things more than building them, doesn't care much about professionalsism, except as applied to ideas, and is really turned on about the interesting things in csc theory. Type B -- likes building things more than thinking about them, is obsessed with professionalism, and is really turned on about creating wonderful (programs/machines). Type C -- likes the idea of being a programmer more than programming itself. It is an ``good career''... (Actually, I am very usure what motivates these people. It isn't the intellectual stimulation, though.) Type A I used to call the ``mathematician'' sort of csc major. But in the last month I have decided that this may describe most of the people who should be getting a csc degree at all. Type B I used to call the ``engineer'' sort of csc major. But, again in the last month, I have decided that they are probably what engineering students in computer science should be. Type C I found all over the place and thought should be crated into tiny boxes and send a long time ago in a galaxy very far away. No doubt there are lawyers and doctors who think that they could provide members of their professions who should join them... Actually, I am very puzzled by them. I have a good many Jewish friends who went to university to get a CSC degree over the protests of their parents who, to the bitter end, were still `noodging' them to be a doctor. The Type Cs seem to be their analogues. I cannot help but think that in this world there is *some* career that would interest the Type Cs as much as csc and engineering interests the Type As and Bs. And I think that they would be much better off if they found out what that was and did it rather than majoring in csc. But I doubt that my opinions are going to stop them. As far as I have observed, unfortunately, the Type C's outnumber the As and Bs combined. Peter Ladkin is at Stanford, so perhaps things are different there. He has a real problem in that he knows there are beautiful and wonderful things in csc and wants people to know them .... and I think that he is also right on the money. (This is going to be a big week for apologies...) I think that there are a great many wonderful and beautiful thoughts happening in Computer Science today, and, to the extent that you are interested in them a CSC degree is a wonderful thing to have. The thing that saddens me is that too the extent that you tailor your csc program to handle the Type Cs, you will weaken your program so that you only get to do ``real stuff'' in grad school. -- Laura Creighton ihnp4!hoptoad!laura utzoo!hoptoad!laura sun!hoptoad!laura toad@lll-crg.arpa
g-rh@cca.UUCP (Richard Harter) (03/02/86)
Laura, what you say makes a great deal of sense, but I think you are making a fundamental mistake. The universities have always, from the founding of the first universities in the middle ages onward, served a dual function. One function is to serve a temple of wisdom -- a place where learning for the sake of learning is encouraged and supported. The other function is to prepare the young for their place in society. Let me expand on the latter thought for a bit. Working societies above the tribal level all have a major social division that corresponds to the difference between enlisted men and officers in the military. A young person either starts out in the social pyramid at the bottom or somewhere halfway up. Those who start halfway up are given special training. In our society this is conventionally done in the universities. Most people who go to college do so in preparation for becoming members of the officer class of society. That is the principal function of the universities, from the viewpoint of society as a whole, and the reason that they are supported. The love of learning is a secondary function of the university system -- necessary and valuable, but not primary. In some parts of the system it is primary; on the whole it is secondary. These are general principles; they apply to CSE as well. You seem to feel that people ought not to take up CS because it is a good paying field. You are shoveling sand against the tide. All you can really ask is that those people who are taking CS (medicine, whatever) be trained properly in the career that they have chosen. I don't care why my doctor originally chose medicine -- I care very much whether she is is a good doctor or not. Similarly, I don't care why the CS major majored in CS. When this person comes to me saying, "I have trained as a valuable employee, hire me for big bucks", I really only have one concern -- Is this person a valuable employee who is worth big bucks? Maybe this all sounds cynical, but it is not. You may love opera, and consider opera the finest thing in the world. Some do. But one ought to know that you can only have opera in a world that can afford opera, and that somewhere somebody is growing potatoes, and someone is cutting wood, and that all these people are doing all the things that are needed so that people have enough to eat and drink, clothes to wear, and warm places to sleep. Richard Harter, SMDS Inc.
gds@mit-eddie.UUCP (Greg Skinner) (03/02/86)
I am not going to include any of Larua's text, because I think she
made some very good points. There is really no excset for not doing
the best job you can. I think the following is an explanation of why
"the best job possible" is not always done in the software industry.
Laura states that good civil engineers build bridges that last > 10
years, good architects build houses that don't fall, etc. There is a
major difference between those professions and the software industry.
Those professions have been around for centuries! The techniques
involved in building robust structures are well understood, and have
been for many years. The software industry is just a baby compared to
those professions. Techniques for building robust systems are not
fully understood yet by researchers, let alone implementors. In
general, the software industry has not matured yet to the point where
those techniques of robustness are an integral part of the industry.
It is still largely in an experimental stage, where most of the
concern is "can we do it?" and "after we've proved we can, let's do it
right" rather than "by golly, we're going to do it, and do it right
the first time".
If the software industry survives, and software becomes an integral
part of everyone's lives, I believe that certain standards of
robustness (of which portable code is just one) will be required. It
will be necessary, because society will not tolerate software which
does not work as well as doing it by hand. The market will demand
this robustness. It is good that people like Laura are out there
raising our consciousness now, so the next generation of software
produced will be generally more robust.
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, gatech, ihnp4}!mit-eddie!gds
gds@eddie.mit.edubzs@bu-cs.UUCP (Barry Shein) (03/03/86)
Professionalism etc. It all reminds me of my high school advanced algebra course. Generally while we sat frantically taking an exam the teacher would break off into this bellowing, rhetorical monologue, one of them went like this: I'M an engineer I built a bridge... it was 10 feet too short... CAN I GET PARTIAL CREDIT!?!? Needless to say we weren't quite sure whether to laugh or to cry. -Barry Shein, Boston University
jjboritz@watnot.UUCP (Jim Boritz) (03/03/86)
I feel that you partly hit the problem right on the nose. Most CS majors fall into your type C. I agree with this totaly. However it is not their fault (totally) that they do not (cannot) write good code. A great deal has to do with the cirriculum. Students can only be motivated to do things when there are marks associated with them. This is especially true of your type C student. Taking this and then running with it. Very few CS courses provide marks for things like style. Sure you will lose marks if your programs are not clear, but not for bad sytle. This has to do with how hard it is for the TA to read your code, not how concerned anyone is about your clarity. I have had some experience marking papers, and what I have seen is that very few people are willing to do more than is required. Much of this is due to the time pressure associated with doing an assignment somone that has three other assignments to do is not going to worry about more than the minimum required. The only ones that will do more are those that live in front of a terminal. (Hacks). But hacks only write code for themselves and other hacks. This means that it does alot but is close to impossible to use. Put this all together and you get a bunch of people graduating that have never had to write good code. I will probably be one of them. Jim Boritz
jin@hropus.UUCP (Jear Bear) (03/04/86)
And then there are type Ds: Frustrated Cinical Psychologists who write real-time code to run on machines two orders of magnitude too slow for the requirements. (In case you couldn't tell I'm one of them.) No, not everyone *can* (occupational deficiency, not personal) write portable C code, in fact I still code assembler. I'll leave the war stories for later. -- Jerry Natowitz ihnp4!houxm!hropus!jin The Master Baker
chk@purdue.UUCP (Chuck Koelbel) (03/04/86)
In article <569@hoptoad.uucp>, laura@hoptoad.uucp (Laura Creighton) writes: > In article <653@moscom.UUCP> jens@moscom.UUCP (Jens Fiederer) writes: > > > >Dear Laura: > > > >I think accusing people whose C code does not pass lint, assumes ints are > >n bytes long, who don't check return codes from function codes, etc. of > >being unprofessional is going a bit far. Yes, their code is not portable. > >If their intention was to write portable code, your accusation hits home. > >Otherwise they might be entirely unconcerned. > > It is this ``entirely unconcerned'' attitude that bothers me. That is what > is unprofessional. To be a professional is to do the best possible job > even under adverse circumstances. It is possible to learn how to write > protable code, and possible to discipline yourself so that you do not > write unportable code. I know lots of people who do this routinely. > I know lots of people who would like to do this but do not know how. This > is why I am writing a book. And I know lots of people who really don't > care. And these people I call unprofessional. [101 lines deleted] Is this really the type of material that needs to be cross-posted to net.singles? Could you please only post this discussion to net.cse? Thanks.
rcj@burl.UUCP (Curtis Jackson) (03/05/86)
In article <11569@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes: >Very few CS courses provide marks for things like style. Sure you will >lose marks if your programs are not clear, but not for bad sytle. I had a prof who had two guidelines, both of which I thought were very sound: a) Assembler programs *had* to have at least one line/phrase of comment per line of code. The comment had better not say, "Load r2 with r1" or you were history -- they had to be functional. b) Other programs were graded with one rule-of-thumb: if he had to ask you how a piece of code worked or why it was there, your answer had better convince him that you did something so revolutionary or so brilliantly devious in that portion of the code that he just couldn't fathom the very *idea*. This did not happen often. The above not only taught people how to comment meaningfully, it also prevented them from putting things in their code that were incredibly ugly, non-functional, or downright wrong -- "I don't know what the following 2 lines of code do, but the program won't work without them." -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
garys@bunker.UUCP (Gary M. Samuelson) (03/05/86)
In article <1087@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: >In article <11569@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes: >>Very few CS courses provide marks for things like style. Sure you will >>lose marks if your programs are not clear, but not for bad sytle. > >I had a prof who had two guidelines, both of which I thought were very >sound: > >a) Assembler programs *had* to have at least one line/phrase of comment >per line of code. The comment had better not say, "Load r2 with r1" >or you were history -- they had to be functional. But requiring one comment per line at times implies such non-informative comments. For example, with a Z80 it takes three instructions to determine if a pointer is null (LD A,H; OR L; JP Z,label;) -- should each of these instructions have a separate comment? I think not. >b) Other programs were graded with one rule-of-thumb: if he had to ask > you how a piece of code worked or why it was there, your answer had > better convince him that you did something so revolutionary or so > brilliantly devious in that portion of the code that he just couldn't > fathom the very *idea*. This did not happen often. This is a very good rule, and should apply to assembler as well as any other language. When writing code, one should note that it will be read more times than written; therefore ease of reading should be more important than ease of writing. (Pet peeve: Many people seem to think that assembly language is inherently unreadable -- this is nonsense. Good code can be written in assembly, and bad code can be written in C.) >The above not only taught people how to comment meaningfully, it also >prevented them from putting things in their code that were incredibly >ugly, non-functional, or downright wrong -- "I don't know what the following >2 lines of code do, but the program won't work without them." I cringe when I see comments like that, too; but in the case where someone has inherited someone else's trashy code, putting a warning like that in is better than nothing. Eventually, it should be replaced when (if) someone figures out why the code is there. Gary Samuelson
jjboritz@watnot.UUCP (Jim Boritz) (03/06/86)
In article <1087@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: >>Very few CS courses provide marks for things like style. Sure you will >>lose marks if your programs are not clear, but not for bad sytle. > >I had a prof who had two guidelines, both of which I thought were very >sound: > >a) Assembler programs *had* to have at least one line/phrase of comment >per line of code. The comment had better not say, "Load r2 with r1" >or you were history -- they had to be functional. I have seen alot of assembly language programs some were comment extremely well and others extremely bad. Most of the bad ones were the ones which had a comment on every line. A great many of the well commented programs had enough comments to make code segments easy to understand, but they were far from the comment per line guideline which you mentioned. >b) Other programs were graded with one rule-of-thumb: if he had to ask > you how a piece of code worked or why it was there, your answer had > better convince him that you did something so revolutionary or so > brilliantly devious in that portion of the code that he just couldn't > fathom the very *idea*. This did not happen often. One professor does not a department make, nor does one computer science course make a good computer scientist. For every good Prof out there, there is also a bad prof. > >The above not only taught people how to comment meaningfully, it also >prevented them from putting things in their code that were incredibly >ugly, non-functional, or downright wrong -- "I don't know what the following >2 lines of code do, but the program won't work without them." I was a tutor for an assembly language course a few months ago. When a student does not know that part of their code is wrong, what is to prevent them from putting this wrong piece of code in their programs. >-- > >The MAD Programmer -- 919-228-3313 (Cornet 291) >alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj > ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj Asides from all this marks cannot be assigned simply upon the appearance of a program. For one thing marks must be assigned consistently. In order to assign marks consistently the marking process must become somewhat mechanized. This leaves you with a big problem when someone writes a bunch of crap for a program and then asks you to try to find the problem when it doesn't work. After pouring over this persons spaghetti for twenty minutes trying to wrap your mind around logic which has been reversed three times, all you find is a missing semi-colon. At the end of it all you are still forced to give marks out for the parts that worked. Jim Boritz
g-rh@cca.UUCP (Richard Harter) (03/07/86)
In article <> jjboritz@watnot.UUCP (Jim Boritz) writes: > >I have seen alot of assembly language programs some were comment extremely >well and others extremely bad. Most of the bad ones were the ones which >had a comment on every line. >A great many of the well commented programs had enough comments to make >code segments easy to understand, but they were far from the comment per >line guideline which you mentioned. > Just a, ah, comment. I tend towards the one comment per line school myself, both for assembler, and for HOLs that will support it. (Coupled, of course, with descriptive prologs for program sections -- my programs run about 70% comment material by character count.) My observation is that the comments on individual lines have their greatest value in explicating what you are doing while you are writing the code. I also find that the thing that it is really important to comment are the declarations. Repeat -- this is really important. The reason that it is really important is that it forces you to have a well defined meaning associated with each variable. In my experience (and I have a lot of it) conceptually ill defined variables is the second most common source of logic errors in programming (inability to think is first. No smiley, unfortunately.) Richard Harter, SMDS Inc.
colonel@ellie.UUCP (Col. G. L. Sicherman) (03/07/86)
["You saved my life, Captain Buffalo! Have a CIGAR!"] In article <1149@mit-eddie.UUCP>, gds@mit-eddie.UUCP (Greg Skinner) writes: > I am not going to include any of Laura's text, because I think she > made some very good points. ... > Laura states that good civil engineers build bridges that last > 10 > years, good architects build houses that don't fall, etc. There is a > major difference between those professions and the software industry. > Those professions have been around for centuries! The techniques > involved in building robust structures are well understood, ... There's a deeper reason. Bridges and houses are _permanent_ structures; they're built to last. Most programs are are more or less ad-hoc. The problems they're designed to solve go away, or change, and the programs have to be scrapped or rewritten. It's part of the cultural transition from HARD-ware to SOFT-ware: with electronic communication, we don't need permanent structures--anywhere! -- Col. G. L. Sicherman UU: ...{rocksvax|decvax}!sunybcs!colonel CS: colonel@buffalo-cs BI: csdsicher@sunyabva
colonel@ellie.UUCP (Col. G. L. Sicherman) (03/07/86)
["YOU are number 6."] In article <230@bu-cs.UUCP>, bzs@bu-cs.UUCP (Barry Shein) writes: > > It all reminds me of my high school advanced algebra course. Generally > while we sat frantically taking an exam the teacher would break off > into this bellowing, rhetorical monologue, one of them went like this: ... More evidence that high schools are asylums for the terminally dogmatic! Q: Is there Life after Death? A: Yes, in the dictionary. --American Pie -- Col. G. L. Sicherman UU: ...{rocksvax|decvax}!sunybcs!colonel CS: colonel@buffalo-cs BI: csdsicher@sunyabva
hollombe@ttidcc.UUCP (The Polymath) (03/10/86)
In article <11577@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes: > ... marks cannot be assigned simply upon the appearance >of a program. For one thing marks must be assigned consistently. In >order to assign marks consistently the marking process must become somewhat >mechanized. This leaves you with a big problem when someone writes a >bunch of crap for a program and then asks you to try to find the problem when >it doesn't work. After pouring over this persons spaghetti for twenty minutes >trying to wrap your mind around logic which has been reversed three times, >all you find is a missing semi-colon. > >At the end of it all you are still forced to give marks out for the parts >that worked. So you give 40% because it works (i.e.: you didn't have time to find the hidden bugs), and take 60% off because it's not maintainable. We just fired a programmer who's about to get his CS degree, with a straight A average yet. He had a head full of calculus and graph theory and parse algorithms, but couldn't program for sour apples. Example: He was assigned to write a Pascal routine that would clear a VT100 screen and draw a numbered grid in the upper right corner. Simple enough. When he was finished, his code went on for 2 1/2 pages of hard coded escape sequences. I politely suggested that he write a move cursor routine, just in case we had to switch terminals. He grudgingly agreed and the resulting code covered another page and a half. All this took about 2 days. At that point, I decided to write the routines myself, just to see if all that fuss was necessary. The move cursor routine took six lines, three of which were error handling he hadn't bothered with (two of the remaining three were Pascal overhead). The draw grid routine took another half dozen lines -- one for loop. Combined, they took well under an hour to design and code. Lest you think I'm picking on an unusual incident, we'd been putting up with atrocities like this from him for over two years. (My boss doesn't like to fire people and kept hoping we could train him). My background? A Master's in Clinical Psychology. The horrifying aspect of this is the programmer in question actually believes he's a good programmer. Why? Because he get's A's in his CS courses because his programs work (i.e: they generate the required output from the given input). I submit that the people giving him those A's are doing him and the DP community a grave disservice. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ The Polymath (aka: Jerry Hollombe) Citicorp(+)TTI 3100 Ocean Park Blvd. Geniuses are people so lazy they Santa Monica, CA 90405 do everything right the first time. (213) 450-9111, ext. 2483 {philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe
seifert@hammer.UUCP (Snoopy) (03/13/86)
In article <1097@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: > >(Pet peeve: Many people seem to think that assembly language is >inherently unreadable -- this is nonsense. Good code can be >written in assembly, and bad code can be written in C.) ... >I cringe when I see comments like that, too; but in the case where >someone has inherited someone else's trashy code, putting a warning >like that in is better than nothing. Eventually, it should be replaced >when (if) someone figures out why the code is there. I've seen some pretty horrible "spagetti code" written in C. Function calls can be as bad as gotos. How can the schools teach students about the real world? Easy, just give them a real world assignment: Give them a piece of poorly written, uncommented, code and have them debug it. Snoopy tektronix!tekecs!doghouse.TEK!snoopy
gabor@qantel.UUCP (Gabor Fencsik@ex2642) (03/19/86)
> > Laura states that good civil engineers build bridges that last > 10 > > years, good architects build houses that don't fall, etc. There is a > > major difference between those professions and the software industry. > > Those professions have been around for centuries! The techniques > > involved in building robust structures are well understood, ... > > There's a deeper reason. Bridges and houses are _permanent_ structures; > they're built to last. Most programs are are more or less ad-hoc. The > problems they're designed to solve go away, or change, and the programs > have to be scrapped or rewritten. It's part of the cultural transition > from HARD-ware to SOFT-ware: with electronic communication, we don't > need permanent structures--anywhere! [Colonel Sicherman] Yeah, I can see it now -- we won't need bridges and tunnels and such. We are not going anywhere ... just sitting like mushrooms, virtual users staring at our virtual terminals attached to the great virtual network ... Sounds like the Global Potemkin Village to me. ----- Gabor Fencsik {ihnp4,dual,lll-crg,hplabs}!qantel!gabor
mat@mtx5a.UUCP (m.terribile) (03/20/86)
> >I have seen alot of assembly language programs some were comment extremely > >well and others extremely bad. Most of the bad ones were the ones which > >had a comment on every line. > >A great many of the well commented programs had enough comments to make > >code segments easy to understand, but they were far from the comment per > >line guideline which you mentioned. The problem with the comment-per-line is that it focuses you on the HOW and takes you away from the WHAT and the WHY. There are plenty of good ways to cumunicate the HOW. One can use abstract types, or the concepts thereof. One can use data representations tuned to the problem at hand, so that one page of code reduces to a line or two. And finally, one can write code with a sense of purpose. Just as prose can wander, or be coherent, code can be focused or diffuse. Code that is focused does all of one task before moving on to another. Code that is diffuse can't quite decide what subtask has to be completed first, so it does a snippet of this and a skoshe of that. Diffuse code will repeat a clumsy addressing operation several times in the course of a few lines. Coherent code will use compund-assignment operations, or compute the addresses once and store them in pointers whose simple, topical names tell WHAT, hint at WHY, and clarify HOW. Every comment advertises doubt: the code may not read clearly enough. Every comment admits to failure. Don't get me wrong ... I use plenty of comments. In my current assignment, I've been accused of writing tomes. Yet even those tomes are inadaquate. To address one important datum in the current system, starting from the basic data: which X in what unit of Y, takes about 65 characters of code, including two subscripting operations, five structure/union selections, and several explicit additions. And because some data are stored in parallel tables (because of valid powerfail protection requirements) this operation may have to be repeated! How in hell can you remember WHAT you're doing and WHY when you have to work that hard to describe the minutiae of HOW? > I also find that the thing that it is really important to comment are > the declarations. Repeat -- this is really important. The reason that > it is really important is that it forces you to have a well defined > meaning associated with each variable. In my experience (and I have > a lot of it) conceptually ill defined variables is the second most > common source of logic errors in programming (inability to think is > first. No smiley, unfortunately.) True. We have one situation where a datum has a type field, and a value of zero in that type field means that the datum is empty. The only problem is that in every blocked group of these things, several data at fixed locations have fixed types -- and the type fields for these are zero, just as if they were unassigned. Instead of being able to just look at the datum to decide what to do with it, instead of being able to address it once and pass a pointer to it to all things called below, we must pass the specific index of the datum in the block. We must also keep the block index around ... Instead of being able to test or switch or index a function or attribute table with the function code, we must also check the relative position of the datum to the beginning of the block. Literally hundreds of tests, maybe thousands, need to be done on the type field in different parts of this system. Every one of them must be between three and six times as complex as it ought to be with extra data to be hauled around and lost or mishandled, and every test on how to handle that troublesome datum must be built from a set of non-parallel cases. One must be able to see this stuff BEFORE it happens. The people responsible for this humpty dumpty mess were patting themselves on the back for having put a complex problem to bed when I came on the project. NO amount of schooling will teach you what working with 20,000 lines of well-designed code for six months will teach you. And not one of these people had seen more than two hundred lines of well-designed code in any six-month period. ``Any fool can criticize, condemn, or complain, and most fools will do just that.'' -Dale Carnagie ``Almost, at times, the fool'' T.S.Eliot, in The Love Song of J. Alfred Prufrock -- from Mole End Mark Terribile (scrape .. dig ) mtx5b!mat (Please mail to mtx5b!mat, NOT mtx5a! mat, or to mtx5a!mtx5b!mat) ,.. .,, ,,, ..,***_*.