Get the idea? This is one of those amazing ongoing gags that have a life of their own; descriptions of elephant- hunting practices have been written for dozens and dozens of professions, mostly in the fields of science. Of course, they are usually most funny to those close-enough to the profession to really "get it".
Anyway, a couple months ago I volunteered to add the programming profession to the list, on a language-by- language basis. The write-up was a hit and has already been printed in a few user-group letters and magazines, but has been only sporadically available on CIS. Here, is the full text, for your enjoyment and corkboard or cubicle-wall posting. (User-groups: please reprint the entire issue, not an extract).
Clipper programmers don't actually hunt elephants, they just buy libraries of elephant parts and then spend years attempting to integrate them.
dBase programmers only hunt elephants at night when no one will notice that they are still using crossbows instead of rifles.
FoxPro programmers switch to a newer and better rifle every few days which causes them to spend more time learning new shooting techniques than actually hunting.
C programmers refuse to buy rifles off the shelf, and go to Africa with steel rods and a mobile machine shop, intending to build a perfect rifle for the job from scratch. They are then never heard from again.
Paradox programmers go to Africa with copies of Hollywood movie scripts about elephant hunting, the re-enactment of which they believe will help them to catch an elephant.
Access programmers zero right in on an elephant right away, even with no prior experience in elephant hunting, and then, dressed impeccably and fully looking the part, get the elephant in their beautifully-mounted scopes, and realize that other than missing a trigger, they are 99.9% "there".
Rbase programmers are even rarer than elephants. In fact, the elephants, if they ever do sight an Rbase programmer, consider it a "lucky day."
Visual Basic programmers point at their bullets, then point at their rifles, and then point at the elephant. This amuses the elephants, who run away. The VB programmers are unable to pursue them, because their jeeps are undrivable, having steering wheels, joy sticks, yokes, and rudders, due to their love of multiple "controls".
ADA, APL, Fortran programmers, the Tooth Fairy, and Santa Claus, are all fictional characters.
COBOL programmers have too much empathy to hunt another nearly-extinct species.
If you would like to submit new programmer/elephant hunting spec.'s, please do so! /Richard Grossman 75300,1556
Have you heard about the Microsoft Windows programmer who died? He found himself in front of a committee that decides whether you go to Heaven or Hell. The committee told the programmer he had some say in the matter and asked him if he wanted to see Heaven and Hell before stating his preference. "Sure," he said, so an angel took him to a place with a sunny beach, volleyball, and rock and roll, where everyone was having a great time. "Wow!" he exclaimed. "Heaven is great!" "Wrong," said the angel. "That was Hell. Want to see Heaven?" "Sure!" So the angel took him to another place. Here a bunch of people were sitting in a park playing bingo and feeding dead pigeons. "This is Heaven?" asked the Windows programmer. "Yup," said the angel. "Then I'll take Hell." Instantly he found himself plunged up to his neck in red-hot lava, with the hosts of the damned in torment around him. "Where's the beach? The music? The volleyball?" he screamed frantically to the angel. "That was the demo," she replied as she vanished.
1] Use lots of global variables.
2] Give them cryptic names such as: X27, a_gcl, or Horace.
3] Put everything in one large .h file.
4] Implement the entire project at once.
5] Use macros and #defines to emulate Pascal.
6] Assume the compiler takes care of all the little details you didn't quite understand.
"It's 5:50 a.m., Do you know where your stack pointer is?"
How to debug a "C" program.
1] If at all possible, don't, let someone else do it.
2] Change majors.
3] Insert/remove blank lines at random spots, re-compile, and excecute.
4] Throw holy water on the terminal.
5] Dial 911 and scream.
6] There is rumour that "printf" is usefull, but this is probably unfounded.
7] Port everything to CP/M.
8] If it still doesn't work, re-write it in assembler. This won't fix the bug, but it will make sure no one else finds it and makes you look bad.
Brian W. Kernighan & Dennis M. Ritchie
a.k.a. "The C Bible"
As revealed to the prophets Ian Chai and Glenn Chappell
Genesis
Chapter 0
0 In the Beginning Ritchie created the PDP-11 and the UNIX.
1 And the UNIX was without form and void; and darkness was upon the face of the system programmers.
2 And Ritchie said, "Let there be portability!" And nothing happened, so Ritchie realized that he had his work cut out for him.
25 And Ritchie said to Kernighan, "Let us make C in the image of B, after our own whims: and let it have dominion over the I and the O and all that runneth upon the UNIX," and it was almost, but not quite so . . . so he realized that he had his work cut out for him again.
Chapter 1
0 Thus the PDP-11 and the UNIX were finished, and all the programs in the
1 And on the seventh shift Ritchie ended his work which he had made; and he would have rested on the seventh shift from all the work which he had made, if it weren't for the system crash.
Chapter 2
0 Now the COBOL was more verbose than any language of the PDP-11, and he said unto the programmer, "Yea, hath the Manual said, 'Ye shalt not read of every device of the network?'"
1 And the programmer said unto the COBOL, "We may read of every device of the network:
2 But of the registers of the printer in the midst of the network, the Manual hath said, 'Ye shall not read of it, neither shall ye write to it without proper protocol, lest ye cause a system crash.'"
3 And the COBOL said unto the programmer, "Ye shalt not surely crash the system:
4 For Ritchie doth know that in the time slice ye read thereof, then your I/O shall be opened, and ye shalt be as system operators, accessing locked accounts with unlimited privileges."
5 And then when the programmer saw that the printer was good for interfacing, and that it was pleasant to the I (and to the O), . . .
6 And they realized they were unstructured, so they patched RATFOR subroutines . . .
The Gospel According to Chai
0 And the Messiah shalt come, born a mere B but to grow up into the Saviour C,
1 Wherein true structured programming may be achieved, yea, verily, yet while being able to do bit shifting.
2 For although the Law (Pascal) hath been given, the Law cannot
for (i=0; str1[i]!='\0'; i++)
str2[i] = (str1[i]> ='A' & & str1[i]> ='Z')? str1[i]+32 : str1[i];
but must
i := 0;
while (i < = length(str1)) do
begin
if str1[i] in ['A'..'Z'] then
str2[i] := chr( ord(str1[i]) + 32))
else
str1[i] := str2[i];
i := i + 1;
end;
The Revelation
0 Yea, in those last days, the Saviour shalt come again, but enhanced, in the rainment of C++
1 And then shalt the Beast, FORTRAN, and the AntiC, COBOL, be thrown into the trash HEAP where there is weeping and byting of pins.
2 And all the faithful programmers shalt be led into CRAY where billions of MIPS are at each one's fingertips.
DATAMATION_, July 1983, pp. 263-265 (Readers' Forum).
Back in the good old days -- the "Golden Era" of computers, it was easy to separate the men from the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature). During this period, the Real Men were the ones that understood computer programming, and the Quiche Eaters were the ones that didn't. A real computer programmer said things like "DO 10 I=1,10" and "ABEND" (they actually talked in capital letters, you understand), and the rest of the world said things like "computers are too complicated for me" and "I can't relate to computers -- they're so impersonal". (A previous work [1] points out that Real Men don't "relate" to anything, and aren't afraid of being impersonal.)
But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12-year-old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own Personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high-school students with TRASH-80's.
There is a clear need to point out the differences between the typical high-school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to -- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12-year-old Pac-Man players (at a considerable salary savings).
LANGUAGES
The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use FORTRAN. Quiche Eaters use PASCAL. Nicklaus Wirth, the designer of PASCAL, gave a talk once at which he was asked "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'." One can tell immediately from this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value- return, as implemented in the IBM\370 FORTRAN-G and H compilers. Real programmers don't need all these abstract concepts to get their jobs done -- they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a beer.
* Real Programmers do List Processing in FORTRAN.
* Real Programmers do String Manipulation in FORTRAN.
* Real Programmers do Accounting (if they do it at all) in FORTRAN.
* Real Programmers do Artificial Intelligence programs in FORTRAN.
If you can't do it in FORTRAN, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.
STRUCTURED PROGRAMMING
The academics in computer science have gotten into the "structured programming" rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the examples they use to show their particular point of view invariably fit on a single page of some obscure journal or another -- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000-line programs that WORKED. (Really!) Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000-line FORTRAN program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that -- it takes actual talent. Some quick observations on Real Programmers and Structured Programming:
* Real Programmers aren't afraid to use GOTO's.
* Real Programmers can write five-page-long DO loops without getting confused.
* Real Programmers like Arithmetic IF statements -- they make the code more interesting.
* Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop.
* Real Programmers don't need comments -- the code is obvious.
* Since FORTRAN doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTO's.
Data Structures have also gotten a lot of press lately. Abstract Data Types, Structures, Pointers, Lists, and Strings have become popular in certain circles. Wirth (the above-mentioned Quiche Eater) actually wrote an entire book [2] contending that you could write a program based on data structures, instead of the other way around. As all Real Programmers know, the only useful data structure is the Array. Strings, lists, structures, sets -- these are all special cases of arrays and can be treated that way just as easily without messing up your programing language with all sorts of complications. The worst thing about fancy data types is that you have to declare them, and Real Programming Languages, as we all know, have implicit typing based on the first letter of the (six character) variable name.
OPERATING SYSTEMS
What kind of operating system is used by a Real Programmer? CP/M? God forbid -- CP/M, after all, is basically a toy operating system. Even little old ladies and grade school students can understand and use CP/M.
Unix is a lot more complicated of course -- the typical Unix hacker never can remember what the PRINT command is called this week -- but when it gets right down to it, Unix is a glorified video game. People don't do Serious Work on Unix systems: they send jokes around the world on UUCP-net and write adventure games and research papers. No, your Real Programmer uses OS\370. A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all. A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)
OS is a truly remarkable operating system. It's possible to destroy days of work with a single misplaced space, so alertness in the programming staff is encouraged. The best way to approach the system is through a keypunch. Some people claim there is a Time Sharing system that runs on OS\370, but after careful study I have come to the conclusion that they were mistaken.
PROGRAMMING TOOLS
What kind of tools does a Real Programmer use? In theory, a Real Programmer could run his programs by keying them into the front panel of the computer. Back in the days when computers had front panels, this was actually done occasionally. Your typical Real Programmer knew the entire bootstrap loader by memory in hex, and toggled it in whenever it got destroyed by his program. (Back then, memory was memory -- it didn't go away when the power went off. Today, memory either forgets things when you don't want it to, or remembers things long after they're better forgotten.) Legend has it that Seymore Cray, inventor of the Cray I supercomputer and most of Control Data's computers, actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Seymore, needless to say, is a Real Programmer.
One of my favorite Real Programmers was a systems programmer for Texas Instruments. One day he got a long distance call from a user whose system had crashed in the middle of saving some important work. Jim was able to repair the damage over the phone, getting the user to toggle in disk I/O instructions at the front panel, repairing system tables in hex, reading register contents back over the phone. The moral of this story: while a Real Programmer usually includes a keypunch and lineprinter in his toolkit, he can get along with just a front panel and a telephone in emergencies.
In some companies, text editing no longer consists of ten engineers standing in line to use an 029 keypunch. In fact, the building I work in doesn't contain a single keypunch. The Real Programmer in this situation has to do his work with a "text editor" program. Most systems supply several text editors to select from, and the Real Programmer must be careful to pick one that reflects his personal style. Many people believe that the best text editors in the world were written at Xerox Palo Alto Research Center for use on their Alto and Dorado computers [3]. Unfortunately, no Real Programmer would ever use a computer whose operating system is called SmallTalk, and would certainly not talk to the computer with a mouse.
Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems -- EMACS and VI being two. The problem with these editors is that Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text [4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse -- introduce subtle and mysterious bugs in a once working subroutine.
For this reason, Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original FORTRAN code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job -- no Quiche Eating structured programmer would even know where to start. This is called "job security".
Some programming tools NOT used by Real Programmers:
* FORTRAN preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming -- great for making Quiche. See comments above on structured programming.
* Source language debuggers. Real Programmers can read core dumps.
* Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.
* Source code maintenance systems. A Real Programmer keeps his code locked up in a card file, because it implies that its owner cannot leave his important programs unguarded [5].
THE REAL PROGRAMMER AT WORK
Where does the typical Real Programmer work? What kind of programs are worthy of the efforts of so talented an individual? You can be sure that no Real Programmer would be caught dead writing accounts-receivable programs in COBOL, or sorting mailing lists for People magazine. A Real Programmer wants tasks of earth-shaking importance (literally!).
* Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers.
* Real Programmers work for the National Security Agency, decoding Russian transmissions.
* It was largely due to the efforts of thousands of Real Programmers working for NASA that our boys got to the moon and back before the Russkies.
* Real Programmers are at work for Boeing designing the operating systems for cruise missiles.
Some of the most awesome Real Programmers of all work at the Jet Propulsion Laboratory in California. Many of them know the entire operating system of the Pioneer and Voyager spacecraft by heart. With a combination of large ground-based FORTRAN programs and small spacecraft-based assembly language programs, they are able to do incredible feats of navigation and improvisation -- hitting ten-kilometer wide windows at Saturn after six years in space, repairing or bypassing damaged sensor platforms, radios, and batteries. Allegedly, one Real Programmer managed to tuck a pattern-matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter.
The current plan for the Galileo spacecraft is to use a gravity assist trajectory past Mars on the way to Jupiter. This trajectory passes within 80 +/-3 kilometers of the surface of Mars. Nobody is going to trust a PASCAL program (or a PASCAL programmer) for navigation to these tolerances.
As you can tell, many of the world's Real Programmers work for the U.S. Government -- mainly the Defense Department. This is as it should be. Recently, however, a black cloud has formed on the Real Programmer horizon. It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called "ADA" ((C), DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming -- a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD has enough interesting features to make it approachable -- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsgar Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the author of "GoTos Considered Harmful" -- a landmark work in programming methodology, applauded by PASCAL programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write FORTRAN programs in any language.
The Real Programmer might compromise his principles and work on something slightly more trivial than the destruction of life as we know it, providing there's enough money in it. There are several Real Programmers building video games at Atari, for example. (But not playing them -- a Real Programmer knows how to beat the machine every time: no challenge in that.) Everyone working at LucasFilm is a Real Programmer. (It would be crazy to turn down the money of fifty million Star Trek fans.) The proportion of Real Programmers in Computer Graphics is somewhat lower than the norm, mostly because nobody has found a use for computer graphics yet. On the other hand, all computer graphics is done in FORTRAN, so there are a fair number of people doing graphics in order to avoid having to write COBOL programs.
THE REAL PROGRAMMER AT PLAY
Generally, the Real Programmer plays the same way he works -- with computers. He is constantly amazed that his employer actually pays him to do what he would be doing for fun anyway (although he is careful not to express this opinion out loud). Occasionally, the Real Programmer does step out of the office for a breath of fresh air and a beer or two. Some tips on recognizing Real Programmers away from the computer room:
* At a party, the Real Programmers are the ones in the corner talking about operating system security and how to get around it.
* At a football game, the Real Programmer is the one comparing the plays against his simulations printed on 11 by 14 fanfold paper.
* At the beach, the Real Programmer is the one drawing flowcharts in the sand.
* At a funeral, the Real Programmer is the one saying "Poor George. And he almost had the sort routine working before the coronary."
* In a grocery store, the Real Programmer is the one who insists on running the cans past the laser checkout scanner himself, because he never could trust keypunch operators to get it right the first time.
THE REAL PROGRAMMER'S NATURAL HABITAT
What sort of environment does the Real Programmer function best in? This is an important question for the managers of Real Programmers. Considering the amount of money it costs to keep one on the staff, it's best to put him (or her) in an environment where he can get his work done.
The typical Real Programmer lives in front of a computer terminal. Surrounding this terminal are:
* Listings of all programs the Real Programmer has ever worked on, piled in roughly chronological order on every flat surface in the office.
* Some half-dozen or so partly filled cups of cold coffee. Occasionally, there will be cigarette butts floating in the coffee. In some cases, the cups will contain Orange Crush.
* Unless he is very good, there will be copies of the OS JCL manual and the Principles of Operation open to some particularly interesting pages.
* Taped to the wall is a line-printer Snoopy calendar for the year 1969.
* Strewn about the floor are several wrappers for peanut butter filled cheese bars -- the type that are made pre-stale at the bakery so they can't get any worse while waiting in the vending machine.
* Hiding in the top left-hand drawer of the desk is a stash of double-stuff Oreos for special occasions.
* Underneath the Oreos is a flowcharting template, left there by the previous occupant of the office. (Real Programmers write programs, not documentation. Leave that to the maintenance people.)
The Real Programmer is capable of working 30, 40, even 50 hours at a stretch, under intense pressure. In fact, he prefers it that way. Bad response time doesn't bother the Real Programmer -- it gives him a chance to catch a little sleep between compiles. If there is not enough schedule pressure on the Real Programmer, he tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week, in two or three 50-hour marathons. This not only impresses the hell out of his manager, who was despairing of ever getting the project done on time, but creates a convenient excuse for not doing the documentation. In general:
* No Real Programmer works 9 to 5 (unless it's the ones at night).
* Real Programmers don't wear neckties.
* Real Programmers don't wear high-heeled shoes.
* Real Programmers arrive at work in time for lunch [9].
* A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
* Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning. Real Programmers survive on Twinkies and coffee.
THE FUTURE
What of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft -- protected from the realities of programming by source level debuggers, text editors that count parentheses, and "user friendly" operating systems. Worst of all, some of these alleged "computer scientists" manage to get degrees without ever learning FORTRAN! Are we destined to become an industry of Unix hackers and PASCAL programmers?
From my experience, I can only report that the future is bright for Real Programmers everywhere. Neither OS\370 nor FORTRAN show any signs of dying out, despite all the efforts of PASCAL programmers the world over. Even more subtle tricks, like adding structured coding constructs to FORTRAN have failed. Oh sure, some computer vendors have come out with FORTRAN 77 compilers, but every one of them has a way of converting itself back into a FORTRAN 66 compiler at the drop of an option card -- to compile DO loops like God meant them to be.
Even Unix might not be as bad on Real Programmers as it once was. The latest release of Unix has the potential of an operating system worthy of any Real Programmer -- two different and subtly incompatible user interfaces, an arcane and complicated teletype driver, virtual memory. If you ignore the fact that it's "structured", even 'C' programming can be appreciated by the Real Programmer: after all, there's no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in -- like having the best parts of FORTRAN and assembly language in one place. (Not to mention some of the more creative uses for #define.)
No, the future isn't all that bad. Why, in the past few years, the popular press has even commented on the bright new crop of computer nerds and hackers ([7] and [8]) leaving places like Stanford and M.I.T. for the Real World. From all evidence, the spirit of Real Programming lives on in these young men and women. As long as there are ill- defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live FORTRAN!
REFERENCES
[1] Feirstein, B., "Real Men don't Eat Quiche", New
York, Pocket Books, 1982.
[2] Wirth, N., "Algorithms + Data Structures =
Programs", Prentice Hall, 1976.
[3] Ilson, R., "Recent Research in Text Processing",
IEEE Trans. Prof. Commun., Vol. PC-23, No. 4,
Dec. 4, 1980.
[4] Finseth, C., "Theory and Practice of Text Editors
-- or -- a Cookbook for an EMACS", B.S. Thesis,
MIT/LCS/TM-165, Massachusetts Institute of
Technology, May 1980.
[5] Weinberg, G., "The Psychology of Computer
Programming", New York, Van Nostrand Reinhold,
1971, p. 110.
[6] Dijkstra, E., "On the GREEN language submitted to
the DoD", Sigplan notices, Vol. 3 No. 10, Oct
1978.
[7] Rose, Frank, "Joy of Hacking", Science 82, Vol. 3
No. 9, Nov 82, pp. 58-66.
[8] "The Hacker Papers", Psychology Today, August 1980.
[9] sdcarl!lin, "Real Programmers", UUCP-net, Thu Oct
21 16:55:16 1982
DICTIONARY
ABEND: The IBM term for ABortive END. It's what you do to bring the system down when all else fails. Also, (jokingly) the command issued to the system to enable the third-shift operators to leave early (from the german Guten Abend, meaning good evening).
Real Men Don't Eat Quiche: It's a wonderful little booklet, describing, with a lot of humor, how a Modern Real Man can live in a world of quiche eaters.
Cuisinart: State-of-the-art, and rather expensive, brand of food processor.
Call-by-value-return: This is how FORTRAN compilers usually pass parameters to subroutines. It's not the same as call by reference (or by name), since you are not passing the addresses (references to) each individual parameter, but rather both the caller and the callee know where the parameter block is and deal with it appropriately.
Arithmetic-IF statements: Computed GOTO: Assigned GOTO: `Interesting' FORTRAN constructs: An arithmetic if is a statement like this: IF (expression) label1,label2,label3 If expression evaluates to negative, zero, or positive, the execution will continue at label1, label2 or label3, respectively. In REAL FORTRAN, of course, expression is just an integer variable! A computed GOTO is like the ON GOTO in BASIC (yuck!): GOTO (label1,label2,...,labeln),N when N is an index into the list of labels. If N< 0 or N> n the following statement is executed. An assigned GOTO is a bit different. You can assigne a label to an integer variable using the ASSIGN statement; you can say ASSIGN 10 TO IFOO, and then use IFOO as a label (e.g., GOTO IFOO). The GOTO IFOO (label1,label2,...,labeln) statement branches to that label matched by IFOO. If none is matched, execution continues. It's used when IFOO can have been set to a variety of labels, but you only want to branch is it has been set to some particular values. You can say it's a set membership operation! Now, how many CS seniors know that, I wonder!
CP/M: Control Program for Microcomputers. A very antiquated (ca 1978?) rudimentary operating system for 8080- based microcomuters. Would have been picked up by IBM instead of MSDOS, (then called QDOS) had the president of Digital Research not been out to lunch with instructions not to be interrupted!
IJK305I: IBM messages are usually three letters (indicating the module the error occured in), followed by a number, followed by a letter indicating the severity of the error. I is Information. IJK is a fictitious prefiex. The closest to that one is IKJ, which is the MVS (then OS) nucleus, if my memory serves me right. (I actually tried to look up this message when I was working for IBM!)
Orange Crush: Fluorescent-orange colored liquid, kind of like orange soda without the carbonation. Gross.
Peanut-butter-filled-cheese-bars: Vending-machine type of junk food. Also available at supermarket checkout counters. These are cheese-flavored (just flavored, no real cheese) crackers filled with rancid peanut butter or mock- cheese spread. Usually three one-square-inch sandwiches to a package.
Double-stuffed Oreos: A brand of cookies made by Nabisco. They are `sandwich' cookies, two ~2 inch, very dark, supposedly chocolate-flavor cookies, with a vanilla-flavored stuffing. They are very common in the US.
Twinkies: YA example of junk food. These are small cakes filled with some sort of custard. They are not too bad (taste-wise).
Taken from Gary Derzen (FIDO)
C: You shoot yourself in the foot.
C++: You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
FORTRAN: You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception-handling ability.
Modula-2: After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.
COBOL: USEing a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANGUN to HOLSTER. CHECK whether shoelace needs to be retied.
BASIC: Shoot yourself in foot with water pistol. On big systems, continue until entire lower body is waterlogged.
FORTH: Foot in yourself shoot.
APL: You shoot yourself in the foot, then spend all day figuring out how to do it fewer characters.
Pascal: The compiler won't let you shoot yourself in the foot.
Concurrent Euclid: You shoot yourself in somebody else's foot.
Motif: You spend days writing a UIL description of your foot, the trajectory, the bullet, and the intricate scrollwork on the ivory handle of the gun. When you finally get around to pulling the trigger, the gun jams.
Unix: % ls foot.c foot.h foot.o toe.c toe.o % rm *.o rm: .o: No such file or directory % ls %
XBase: Shooting yourself is no problem. If you want to shoot yourself in the foot, you'll have to use Clipper.
Paradox: Not only can you shoot yourself in the foot, your users can too.
Reveration: You'll be able to shoot yourself in the foot just as soon as you figure out what all these bullets are for.
Visual Basic: You'll shoot yourself in the foot, but you'll have so much fun doing it that you won't care.
Prolog: You tell your program you want to be shot in the foot. The program figures out how to do it, but the syntax doesn't allow it to explain.
370 JCL: You send your foot down to MIS with a 4000-page document explaining how you want it to be shot. Three years later, your foot comes back deep-fried.
----------------------------------
I didn't like the cobol one ( A little in accurate?) so I redid it and added several more. -Daniel Lo
Cobol: After writting an UNGODLY data division and a short - WORDY procedure division, and other stuff you realize that you can't run the program nor pull the trigger becuase you have Carple Tunnel Syndrome.
Assembler: After writting a thousand thousand little it'y BIT'y instructions, telling how to make the gun from the ground up and writting formuals discribing how to pull the trigger and shoot the Talon Clawed bullet, as you fire the gun. It explodes in your face doing serious damage to your system, because you screwed up on some little it'y BIT'y instruction. In no way hurting your foot of course.
T-Pascal: After making a object classes to describe the bullet, gun, hand, and foot. You pull the trigger only to find out that your foot was wraped in pascal's bullet proof armor which had a type-casting error about letting the bullet in.
C (New standards?): You see a type-casting warning about the bullet and the foot, but that doesn't really do anything, so you shoot yourself in the foot after a moment's pause to read the warning message.
Batch file (Autoexec.bat, Config.sys, ect..) prior to dos 6.0: After writting one or two wrong statements in the batch file the system locks up whenever you boot up, then rebooting to start the circle again. Then you realize it would have been a great idea to ban Fully Automatic Weapons when CP\M was around.
Windows programming (rumors): You realize that you're getting old and this is one of the new fancy guns with lazer sighting and distance messurements and a digital read-out display. You can't even comprehend the number or type
- Real programmers don't write specs. Users should consider themselves lucky to get any programs at all and take what they get.
- Real programmers don't comment their code. If it was hard to write, it should be hard to read.
- Real programmers don't write application programs, they pro- gram right down on the bare metal. Application programming is for feebs who can't do systems programming.
- Real programmers don't eat quiche. Real programmers don't even know how to spell quiche. They eat Twinkies, Coke and palate-scorching Szechwan food.
- Real programmers don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much it did for them.
- Real programmers don't read manuals. Reliance on a reference is a hallmark of the novice and the coward.
- Real programmers programs never work right the first time. But if you throw them on the machine they can be patched into working in only a few 30-hours debugging sessions.
- Real programmers don't use Fortran. Fortran is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulation.
- Real programmers don't use COBOL. COBOL is for wimpy application programmers.
- Real programmers never work 9 to 5. If any real programmers are around at 9 am, it's because they were up all night.
- Real programmers don't write in BASIC. Actually, no program- mers write in BASIC, after the age of 12.
- Real programmers don't document. Documentation is for simps who can't read the listings or the object deck.
- Real programmers don't write in Pascal, or Bliss, or Ada, or any of those pinko computer science languages. Strong typing is for people with weak memories.
- Real programmers know better than the users what they need.
- Real programmers think structured programming is a communist plot.
- Real programmers don't use schedules. Schedules are for man- ager's toadies. Real programmers like to keep their manager in suspense.
- Real programmers think better when playing adventure.
- Real programmers don't use PL/I. PL/I is for insecure momma's boys who can't choose between COBOL and Fortran.
- Real programmers don't use APL, unless the whole program can be written on one line.
- Real programmers don't use LISP. Only effeminate programmers use more parentheses than actual code.
- Real programmers disdain structured programming. Structured programming is for compulsive, prematurely toilet- trained neurotics who wear neckties and carefully line up sharpened pencils on an otherwise uncluttered desk.
- Real programmers don't like the team programming concept. Unless, of course, they are the Chief Programmer.
- Real programmers have no use for managers. Managers are a necessary evil. Managers are for dealing with personnel bozos, bean counters, senior planners and other mental defectives.
- Real programmers scorn floating point arithmetic. The decimal point was invented for pansy bedwetters who are unable to "think big."
- Real programmers don't drive clapped-out Mavericks. They prefer BMWs, Lincolns or pick-up trucks with floor shifts. Fast motorcycles are highly regarded.
- Real programmers don't believe in schedules. Planners make up schedules. Managers "firm up" schedules. Frightened coders strive to meet schedules. Real programmers ignore schedules.
- Real programmers like vending machine popcorn. Coders pop it in the microwave oven. Real programmers use the heat given off by the cpu. They can tell what job is running just by listening to the rate of popping.
- Real programmers know every nuance of every instruction and use them all in every real program. Puppy architects won't allow execute instructions to address another execute as the target instruction. Real programmers despise such petty restrictions.
- Real programmers don't bring brown bag lunches to work. If the vending machine sells it, they eat it. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
Acknowledgements to Bruce Tonkin, T.N.T. Software Inc., 34069 Hainesville Road, Round Lake, IL, 60073 (312)- 223-8595, for his article in Dec '87 COMPUTERPEOPLE Monthly, from which this is copied. This file may be freely distributed, but not for profit, etc. Be sure to take a look at MY WORD! and BBC, IBM-Basica compiler.
Advanced: (adj.) doesn't work yet, but it's pretty close. See: bug, glitch.
Analyst: (n.) one who writes programs and doesn't trust them. A cynic.
Assembler: (n.) a minor program of interest only to obsessed programmers.
BASIC: (n.) a computer one-word oxymoron.
BBS: (n.) a system for connecting computers and exchanging gossip, facts, and uniformed speculation under false names.
Benchmark: (n.) a test written ostensibly to compare hardware or software, but actually used by manufacturers to misinterpret or quote out of context in advertisements.
Binary: (n.) a two-valued logic especially susceptible to glitches and bugs. It originated as a way of counting on the thumbs, since programming managers usually find fingers far too confusing. See: Hexadecimal, Octal.
Bug: (n.) any program feature not yet described to the marketing department.
Bus: (n.) a connector you plug money into, something like a slot machine.
Byte: (n.) eight bits, or one dollar (in 1950 terms). Presently worth about two-tenths of a cent and falling fast.
C: (n.) the language following A and B. The world still awaits D and E. By Z, it may be acceptable for general use.
Chip: (n.) a stylized picture of a logic diagram on refined and alloyed sand. See: glitch, bug.
COBOL: (n.) an old computer language, designed to be read and not run. Unfortunately, it is often run anyway.
Code: (n.) a means of concealing bugs favored by programmers. (v.) the process of concealing bugs by programming.
Cookie: (n.) any recondite message displayed by a time-shared system. The message is not often seen, because it only appears when the system is operating properly. Common cookies include the timeless "Murphy was an optimist" and "When in danger or in doubt, run in circles, scream and shout."
Copy Protection: (n.) a means of circumventing various rights granted by the Constitution so as to artificially inflate profits.
CPU: (n.) acronym for Central Purging Unit. A device which discards or distorts data sent to it, sometimes returning more data and sometimes merely overheating.
Crash: (v.) to terminate a program in the usual fashion, i.e. by locking up the computer of setting a fire at the printer. (n.) the process of such termination.
Data: (n.) raw information, esp. that supplied to the central purging unit for transformation and disposal.
Data Base Manager: (n.) any fast filing system which gives misleading answers. Also see: menu, bug.
Diagnostic: (n.) a test foolishly but often believed to determine the reason for a particular failure. Competent professionals prefer the I Ching or phrenology.
Digital: (adj.) of or pertaining to the fingers, esp. to counting on them. See: Binary, Hexadecimal, Octal.
Documentation: (n.) a novel sold with software, designed to entertain the operator during episodes of bugs or glitches.
DOS: (n.) Acronym. a program which outpes questions given answers, putting users in jeopardy.
Emulate: (v.) to simulate hardware glitches with software bugs. Emulator: (n.) a program which emulates. See: Virtual.
Engineer: (v.) to build somethign with bugs (software) or glitches (hardware). (n.) One who engineers.
Format: (v.) to erase irrevocably and unintentionally. (n.) The process of such erasure.
Forth: (n.) a stack-oriented programming language written right to left and read from bottom to top. It runs efficently on no common computers and is written effectively by no common programmers.
FORTRAN: (n.) an ancient programming language which changed IF's to GOTO's by using a strange three-valued logic on binary computers.
Glitch: (n.) an undocumented design feature, esp. of hardware.
GOTO: (n.) an efficient and general way of controlling a program, much despised by academics and others whose brains have been ruined by overexposure to Pascal. See: Pascal.
Hard Disk: (n.) a rapidly spinning platter divided into sectors. See: Sector, Glitch, Bug.
Hardware: (n.) anything prone to physical failure.
Head: (n.) the part of a disk drive which detects sectors and decides which of the two possible values to return: 'lose a turn' or 'bankrupt.'
Hexadecimal: (adj.) of or refering to base-16 numbers - binary numbers grouped four digits at a time so as to quadruple the opportunity for glitches and bugs. Originated as a means of counting on the fingers of one hand, using the thumb for the 'carry.' Purists who don't like to use the thumb at all prefer 'octal.' See: Octal, Binary.
Icon: (n.) a complex, blurry, and easily-misinterpreted pictorial representation of a single unambigious word. Preferred by illiterates and semi-literates for these reasons, and by others because it slows most computers down so even a cretin with an IQ of 53 may justly feel superior.
Increment: (v.) to increase by one, except when segments are used; then, the increase may be by sixteen unless word mode addressing is used in which case the increase is by one or two, depending on the processor and whether the address is on an even boundary or such increase causes an overflow exception processor fault, which may either cause the program to crash or decrease by a large number instead of increase, depending the register used and the operation being attempted.
Iterate: (v.) to repeat an action for a potentially and often actually infinite number of times.
Joystick: (n.) a device essential for performing business tasks and training exercises esp. favored by pilots, tank commanders, riverboat gamblers, and medieval warlords.
K: (n., adj.) a binary thousand, which isn't a decimal thousand or even really a binary thousand (which is eight), but is the binary number closest to a decimal thousand. This has proven so completely confusing that is has become a standard.
Kernal: (n.) a misspelling of 'kernel' used by beginning (funtionally illiterate) programmers, especially thos with some knowledge of C.
Kernel: (n.) the core of a program, i.e. the source of all errors. Thus the common misspelling, 'kernal.'
Keyboard: (n.) a device used by programmers to write software for a mouse or joystick and by operators for playing games such as 'word processing.'
Kludge: (v., adj., or n.) to fix a program in the usual way.
Leading Edge: (n., adj.) anything which uses advanced technology. See: Advanced.
License: (n.) a covenant which tells the buyer that nothing has been purchased and that no refund, support, advice, or instruction may be anticipated and that no resale is permitted. A modern way of saying "Thanks for all your money and goodbye," far less crude than "Stick 'em up" but even more effective since the purchaser will often borrow the funds requested.
Logic: (n.) a system of determining truth or falsity, implication or exclusion, by means of a sort of binary Oneiromancy.
Loop: (n., v.) 1. aseries of instructions to be iterated. 2. the process of iterating them. Most loops ar unintentional and can be quite droll.
Macro: (n.) a series of keystrokes used to simulate a missing but essential command.
Megabyte: (n.) more than you can comprehend and less than you'll need. See: UNIX.
Megaherz: (n.) a way of measuring how well your computer matches the frequency of your local television channels. Most computers perform exceptionally well on this test, especially the higher-quality foreign-made ones.
Menu: (n.) any list of choices, each of which is either unsatisfactory or in some fashion contradictory.
Micro-: (prefix) anything both very small and very expensive.
Mode: (n.) a way of forcing glitch or bug.
Modem: (n., v.) a device used to connect computers (see: BBS) or the process of transmitting data between or among computers, esp. for those unable or unwilling to speak.
Monitor: (n.) a sort of television with exceptionally poor picture quality and limited to a single very local station.
Motherboard: (n.) the hardware version of the software 'kernel.'
Mouse: (n.) an input device used by management to force computer users to keep at least a part of their desks clean.
Nano-: (prefix) a thousandth of a thousandth, but not a binary thousandth in either case. Decimal is used for all very small measurements since no further confusion is necessary.
Octal: (n.) a base-8 counting system designed so that one hand may count upon the fingers of the other. Thumbs are not used, and the index finger is reserved for the 'carry.'
Offset: (n.) a method which permits access to any memory location in thousands of ways, each of which appears different but is not. Used with segments. See: Segment.
Operator: (n.) 1. One who has no experience with computers. 2. Any beginner, esp. one part of whose salary is paid in soft drinks and processed salted food treated with dangerous and illegal drugs or preservatives. Differs from a programmer in that a programmer will often take the dangerous and illegal drugs or preservatatives directly.
Pascal: (n.) a classroom project which was released before it could be graded - probably a good idea, considering. One wishes the University had had a better system of academic controls.
Patch: (v.) to fix a program by changing bytes according to the rules of logic. (n.) Any repair of this form.
Pirate: (v., n.) to steal software, or one who is such a thief. True pirates see nothing wrong with thievery, having successfully forgotten or repressed all moral values.
Pop: (v.) to remove from an area of memory naively thought to be the stack in a futile attempt to keep a program running.
Portable: (adj.) that which can be physically moved more than a hundred yards by an unaided olympic athlete without permanent damage to that individual more than 50% of the time.
Printer: (n.) a small box attached to a computer and used to start fires in cold weather.
Procedure: (n.) a method of performing a program sub-task in an inefficient way by extensively using the stack instead of a GOTO. See: Pascal and C.
Processor: (n.) a device for converting sense to nonsense at the speed of electricity, or (rarely) the reverse.
Program: (n.) that which manipulates symbols rapidly with unforseen results. Also: a bug's way of perpetuating bugs.
Programmer: (n.) 1. one who writes programs and trusts them. An optimist. 2. Any employee who needs neither food nor sleep but exixts on large quantities of caffeine, nicotine, sucrose, and machine-vended preservatives thinly disguised as foodstuffs.
Programming Language: (n.) a shorthand way of describing a series of bugs to a computer or a programmer.
Prompt: (n.) a computer request for a random operator error. Also a game where the computer plays the part of Vanna White and the operator, a contestant. There are no prizes for winning.
Push: (v.) to put into an area of memory believed to be the stack for the ostensible purpose of later retrieval. Tonkin's rule: In any program there are always more 'pushes' than 'pops.' See: Recursion.
Quantum leap: (adj.) literally, to move by the smallest amount theoretically possible. In advertising, to move by the largest leap imaginable (in the mind of the advertiser). There is no contradiction.
Recursion: (n.) a programming method which tests the limits of available memory in an iterative way by using the stack. When the program fails, all memory has been used. Memorize this definition, then see: Recursion.
Register: (n.) a part of the central purging unit used to distort or destroy incoming data by arbitrary rules. See: Increment.
Relational: (adj.) purchased from, or sold to, blood kin. See: True relational.
Sector: (n.) a disk arc on which is inscribed 'lose a turn' or 'bankrupt.' See: Hard disk, Head, Glitch.
Segment: (n.) a way of restricting or complicating access to memory in an attempt to break a programmer's will to live. Outlawed by both the A.S.P.C.A and the U.N. but still practiced in some backward areas of the world. See: Offset.
Software: (n.) anything other than hardware. That which hardware manufacturers can blame can blame for physical failures.
Sort: (v.) to order a list of data in such a way as to destroy all relationships between the items. (n.) The process which accomplishes this, esp. if it takes a very long time.
Source Code: (n.) a record of a programmer's thought for a period of time. A stream-of-consciousness novel or short story.
Spreadsheet: (n.) a way of forcing repeatable answers from insufficient data for superficial purposes. Also, a game played during office hours by bored or restless yuppies.
Stack: (n.) any area of memory which grows and eventually destroys both code and data. (v.) To place in such an area.
Standard: (n., adj.) a design target which manufacturers may embellish, improve upon, or ignore as they wish, so long as it can be used profitably in their advertising.
Transportable: (adj.) said of software - that which can be put on a new machine in less time than it took to write in the first place. Said of hardware - that which can theoretically be moved more than ten feet in one minute by some combination of machinery or explosives. The meanings are equivalent.
Truly relational: (adj.) relational, but where the paternity is indubitable.
TSR: (n.) acronym for Terminate and Stay Resident. A way of turning a useless computer with plenty of memory into a computer with no memory at all.
Turbo-: (prefix) computer software which uses air under pressure (supplied by a special fan) to achieve high performance.
User-friendly: (adj.) trivialized, slow, incapable, and boring. See: Icon, Mouse.
UNIX: (n., v.) a DOS which needs more memory than you have and run more slowly than you can bear. To UNIX: to grossly enlarge and slow down out of all proportion, esp. by using C.
User: (n.) one who knows from experience that programs cannot be trusted. A realist.
Vendor: (n.) a manufacturer's lackey.
Virtual: (adj.) emulated. See: Emulate.
Warranty: (n.) a list of vendor's promises with carefully-worded exceptions which cancel each of the promises in turn. See: License.
Windowing: (n., adj.) a way of making a large and easily-read display into many small, cluttered, and confusing ones.
Word Processor: (n.) A program which makes a $5,000 computer into a $250 typewriter. A computer game for beginning operators.
WORM: (n.) acronym for Write Once, Read Mangled. Used to describe a normally-functioning computer disk of the very latest design.
XYZZY: (n.) a common user prompt.
Yarrow: (n.) kind of stalks wuse by computer diagnosticians when performing the ritual of the I Ching. See: Diagnostics.
Zaxxon: (n.) a sophisticated simulation and design program used by the brightest programmers to test the consistency of internal logic and memory. Management prefers to use games such as 'spreadsheet' for the same purpose.
The computer engineer said, "I think I can fix it."
The systems analyst said, "No, I think we should take it into town and have a specialist look at it."
The programmer said, "OK, but first I think we should get back in and see if it does it again."
1. Any given program, when running, is obsolete.
2. Any given program costs more and takes longer each time it is run.
3. If a program is useful, it will have to be changed.
4. If a program is useless, it will have to be documented.
5. Any given program will expand to fill all the available memory.
6. The value of a program is inversely proportional to the weight of its output.
7. Program complexity grows until it exceeds the capability of the programmer who must maintain it.
Pierce's Law
In any computer system, the machine will always misinterpret, misconstrue, misprint, or not evaluate any math or subroutines or fail to print any output on at least the first run through.
Corollary to Pierce's Law
When a compiler accepts a program without error on the first run, the program will not yield the desired output.
Addition to Murphy's Laws
In nature, nothing is ever right. Therefore, if everything is going right ... something is wrong.
Brook's Law
If at first you don't succeed, transform your data set!
Grosch's Law
Computing power increases as the square of the cost.
Golub's Laws of Computerdom
1. Fuzzy project objectives are used to avoid embarrassment of estimating the corresponding costs.
2. A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
3. The effort required to correct course increases geometrically with time.
4. Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.
Osborn's Law
Variables won't; constants aren't.
Gilb's Laws of Unreliability
1. Computers are unreliable, but humans are even more unreliable.
2. Any system that depends upon human reliability is unreliable.
3. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
4. Investment in reliability will increase until it exceeds the probable cost of errors, or until someone insists on getting some useful work done.
Lubarsky's Law of Cybernetic Entomology
There's always one more bug.
Troutman's Postulate
1. Profanity is the one language understood by all programmers.
2. Not until a program has been in production for six months will the most harmful error be discovered.
3. Job control cards that positively cannot be arranged in improper order will be.
4. Interchangeable tapes won't.
5. If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it.
6. If a test installation functions perfectly, all subsequent systems will malfunction.
Weinberg's Second Law
If builders built buildings the way programmers write programs, then the first woodpecker that came along would have destroyed civilization.
Gumperson's Law
The probability of anything happening is inversely proportional to its desirability.
Gummidge's Law
The amount of expertise varies inversely with the number of statements understood by the general public.
Zymurgy's First Law of Evolving System Dynamics
Once you open a can of worms, the only way to recan them is to use a larger can (Old worms never die, they just worm their way into larger cans).
Harvard's Law, as Applied to Computers
Under the most rigorously controlled conditions of pressure, temperature, volume, humidity and other variables, the computer will do as it damn well pleases.
Sattinger's Law
It works better if you plug it in.
Jenkinson's Law
It won't work.
Horner's Five Thumb Postulate
Experience varies directly with equipment ruined.
Cheop's Law
Nothing ever gets build on schedule or within budget.
Rulz Accuracy
When working toward the solution of a problem, it always helps if you know the answer.
Zymurg's Seventh Exception to Murphy's Law
When it rains, it pours.
Pudder's Laws
1. Anything that begins well ends badly
2. Anything that begins badly ends worse.
Westheimer's Rule
To estimate the time it takes to do a task: estimate the time you think it should take, multiply by two and change the unit of measure to the next highest unit. Thus, we allocate two days for a one hour task.
Stockmayer's Theorem
If it looks easy, it's tough. If it looks tough, it's damn near impossible.
Atwoods Corollary
No books are lost by lending except those you particularly wanted to keep.
Johhnson's Third Law
If you miss one issue of any magazine, it will be the issue that contains the article, story or installment you were most anxious to read.
Corollary to Johnson's Third Law
All of your friends either missed it, lost it or threw it out.
Harper's Magazine Law
You never find the article until you replace it.
Brooke's Law
Adding manpower to a late software project makes it later.
Finagle's Fourth Law
Once a job is fouled up, anything done to improve it will only make it worse.
Featherkile's Rule
Whatever you did, that's what you planned.
Flap's Law
Any inanimate object, regardless of its position, configuration or purpose, may be expected to perform at any time in a totally un- expected manner for reasons that are either entirely obscure or else completely mysterious.
I. Introduction: What IS a REAL programmer?
How to spot a REAL programmer:
1. REAL Programmers never leave their computer to prepare food (i.e.: will toast bread in floppy drive, frys eggs on hard disk)
2. REAL Programmers don't eat quiche.
3. REAL Programmers don't hack software; they rewrite their own version.
4. REAL Programmers always have the latest version of a programming language, no matter what the price.
5. REAL Programmers can measure thier debugging speed in FFUPMs (Fixed-Foul -Ups-Per-Minute).
6. REAL Programmers are (don't correct me if I'm wrong) always single (Chicks don't dig "hackers")
7. REAL Programmers NEVER, EVER write in Basic. They do not aknowledge the existance of Basic.
8. Bill Gates is NOT a REAL Programmer. He leaves his desk for food, and he eats quiche.
9. REAL Programmers don't even know how to spell quiche.
10. REAL Programmers don't need to buy the language, just the compilers.
11. REAL Programmers know every nook and cranny of every procedure in the launguage they're using, and will use every variety of every command in thier code.
12. REAL Programmers laugh in the face of Carpel Tunnel Syndrome.
2. Laws about hunting REAL Programmers:
1. It is unlawful to be dusguised as a CEO, Contractor, Distressed person looking through a DOS manual (Only if hunting operating system programmers, such as Bill Gates), or Vending Machine for the purpouse of hunting REAL Programmers.
2. It is legal to be disguised as a Computer/Software salesperson for the purpouse of hunting REAL Programmers.
3. It is unlawful to hunt for REAL Programmers within 150 yards of:
Vending Machines
Egghead Software (300 yards)
All other software stores (175 yards)
Qwickie-Marts
Fast-Food Restaraunts
Shopping plazas that contain software stores (175 yards)
3. What kind of REAL Programmer should I hunt?
If you're hunting for fun, all kinds.
If you're hunting for food...
DO NOT EAT REAL PROGRAMMERS WITH ANY ONE OR MORE OF THESE CHARACTERISTICS:
1. Pocket Protector (indigestible)
2. Has been programming in weenie scientific languages such as ASM
3. Carries business cards from all his clients
4. Has been eating quiche
5. Wears overalls (HillBilly REAL Programmers are often poisonous)
6. Has bloodshot eyes (Too much CRT)
4. A hunting we-a-go!
If you follow these rules, you'll be able to have a safe and enjoyable REAL Programmer hunting trip.
Happy hunting!
The Tao Of Programming
-------------------------------------------
Translated By
Geoffrey James
- 1 -
---------------------------------
Table of Contents
---------------------------------
Book 1 -- The Silent Void
Book 2 -- The Ancient Masters
Book 3 -- Design
Book 4 -- Coding
Book 5 -- Maintenance
Book 6 -- Management
Book 7 -- Corporate Wisdom
Book 8 -- Hardware and Software
Book 9 -- Epilogue
- 2 -
The Silent Void
Book One
-----------------------------------------------------------------
Thus spake the master programmer: "When you have learned to snatch the error code from the trap frame, it will be time for you to leave."
-----------------------------------------------------------------
1.1
Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming.
If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is great, then the application is great. The user is pleased and their is harmony in the world.
The Tao of Programming flows far away and returns on the wind of morning.
1.2
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now their are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
1.3
In the beginning was the Tao. The Tao gave birth to Space and Time. Therefore Space and Time are Yin and Yang of programming.
Programmers that do not comprehend the Tao are always running out of time and space for there programs. Programmers that comprehend the Tao always have enough time and space to accomplish their goals.
How could it be otherwise?
1.4
The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at is.
If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear. Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs.
The Ancient Masters
Book Two
-----------------------------------------------------------------
Thus Spake the Master Programmer: "After three days without programming, life becomes meaningless."
-----------------------------------------------------------------
2.1
The programmers of old were mysterious and profound. We cannot fathom their thoughts, so all we do is describe their appearance.
Aware, like a fox crossing the water. Alert, like a general on the battlefield. Kind, like a hostess greeting her guests. Simple, like uncarved blocks of wood. Opaque , like black pools in darkened caves.
Who can tell the secrets of their hearts and minds? The answer exists only in Tao.
2.2
Grand Master Turing once dreamed that he was a machine. When he awoke he exclaimed:
"I don't know whether I am Turing dreaming that I am a machine, or a machine dreaming that I am Turing!."
2.3
A programmer from a very large computer company went to a software conference and then returned to report to his manager, saying: "What sort of programmers work for other companies? They behaved badly and were unconcerned with appearances. There hair was long and unkept and their clothes were wrinkled and old. They crashed out hospitality suite and they made rude noises during my presentation."
The manager said: "I should have never sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conventions?
They are alive within the Tao."
2.4
A novice asked the Master: "Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmer in the world. Why is this?"
The Master replies: "That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao."
Design
Book Three
-----------------------------------------------------------------
Thus spake the Master Programmer:
"When the program is being tested, it is too late to make design changes."
-----------------------------------------------------------------
3.1
There once was a man who went to a computer trade show. Each day as he entered, the man told the guard at the door:
"I am a great thief, renowned for my feats of shoplifting. Be forewarned, for this trade show shall not escape unplundered."
This speech disturbed the guard greatly, because there were millions of dollars of computer equipment inside, so he watched the man carefully. But the man merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes, but nothing was to be found.
On the next day of the trade show, the man returned and chided the guard saying: "I escaped with a vast booty yesterday, but today will be even better." So the guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his curiosity no longer. "Sir Thief," he said, "I am so perplexed, I cannot live in peace. Please enlighten me. What is it that you are stealing?"
The man smiled. "I am stealing ideas," he said.
3.2
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying "What is appropriate for the master is not appropriate for the novice. You must understand Tao before transcending structure."
3.3
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
3.4
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: "How long will it take to design this system if assign five programmers to it?"
"It will take one year," said the master promptly.
"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"
The master programmer frowned. "In that case, it will take two years."
"And what if I assign a hundred programmers to it?"
The master programmer shrugged. "Then the design will never be completed," he said.
Coding
Book Four
-----------------------------------------------------------------
Thus spake the master programmer:
"A well-written program is its own heaven; a poorly-written program is its own hell."
-----------------------------------------------------------------
4.1
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the 'Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.
4.2
A novice asked the master: "I have a program that sometime runs and sometimes aborts. I have followed the rules of programming, yet I am totally baffled. What is the reason for this?"
The master replied: "You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is prefect.
The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment."
"But how will I know when I have received enlightenment?" asked the novice.
"Your program will then run correctly," replied the master.
4.3
A master was explaining the nature of Tao of to one of his novices, "The Tao is embodied in all software -- regardless of how insignificant," said the master.
"Is the Tao in a hand-held calculator?" asked the novice. "It is," came the reply.
"Is the Tao in a video game?" continued the novice.
"It is even in a video game," said the master.
"And is the Tao in the DOS for a personal computer?"
The master coughed and shifted his position slightly. "The lesson is over for today," he said.
4.4
Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without an error message, and the program ran like a gentle wind.
"Excellent!" the Prince exclaimed, "Your technique is faultless!"
"Technique?" said the programmer turning from his terminal, "What I follow is Tao -- beyond all techniques! When I first began to program I would see before me the whole problem in one mass. After three years I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off."
Prince Wang said, "Would that all of my programmers were as wise!"
Maintenance
Book Five
-----------------------------------------------------------------
Thus spake the master programmer:
"Though a program be but three lines long, someday it will have to be maintained."
-----------------------------------------------------------------
5.1
A well-used door needs no oil on its hinges. A swift-flowing stream does not grow stagnant. Neither sound nor thoughts can travel through a vacuum. Software rots if not used.
These are great mysteries.
5.2
A manager asked a programmer how long it would take him to finish the program on which he was working. "I will be finished tomorrow," the programmer promptly replied.
"I think you are being unrealistic," said the manager, "Truthfully, how long will it take?"
The programmer thought for a moment. "I have some features thatI wish to add. This will take at least two weeks," he finally said.
"Even that is too much to expect," insisted the manager, "I will be satisfied if you simply tell me when the program is complete."
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement lunch, he discovered the programmer asleep at his terminal. He had been programming all night.
5.3
A novice programmer was once assigned to code simple financial package.
The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
When the master asked about this, the novice became indignant. "Don't be so impatient," he said, " I'll put in the financial stuff eventually."
5.4
Does a good farmer neglect a crop he has planted? Does a good teacher overlook even the most humble student? Does a good father allow a single child to starve? Does a good programmer refuse to maintain his code?
Management
Book Six
-----------------------------------------------------------------
Thus spake the master programmer:
"Let the programmer be many and the managers few -- then all will be productive."
-----------------------------------------------------------------
6.1
When managers hold endless meetings, the programmers write games. When accountants talk of quarterly profits, the development budget is about to be cut. When senior scientists talk blue sky, the clouds are about to roll in.
Truly, this is not the Tao of Programming.
When managers make commitments, game programs are ignored. When accountants make long-range plans, harmony and order are about to be restored. When senior scientists address the problems at hand, the problems will soon be solved.
Truly, this is the Tao of Programming.
6.2
Why are programmers non-productive? Because their time is wasted in meetings.
Why are programmers rebellious? Because the management interferes to much.
Why are the programmers resigning one by one? Because they are burnt out.
Having worked for poor management, they no longer value their jobs.
6.3
A manager was about to be fired, but a programmer who worked for him invented a new program that became popular and sold well. As a result, the manager retained his job.
The manager tries to give the programmer a bonus, but the programmer refused it, saying, "I wrote the program becauseI thought it was an interesting concept, and thus I expect no reward."
The manager upon hearing this remarked, "This programmer, though he holds a position of small esteem, understands well the proper duty of an employee. Lets promote him to the exalted position of management consultant!"
But when told this, the programmer once more refused, saying, "I exist so that I can program. If I were promoted, I would do nothing but waste everyone's time. Can I go now? I have a program that I'm working on."
6.4
A manager went to his programmers and told them: "As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon." At this, all of them became angry and several resigned on the spot."
So the manager said: "All right, in that case you may set your own working hours, as long as you finish your projects on schedule."
The programmers, now satisfied, began to come in at noon and work to the wee hours of the morning.
Corporate Wisdom
Book Seven
-----------------------------------------------------------------
Thus spake the master programmer:
"You can demonstrate a program for a corporate executive, but you can't make him computer literate."
-----------------------------------------------------------------
7.1
A novice asked the master: "In the east there is a great tree- structure that men call 'Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying 'Go, Hence!' or 'Go, Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity exist?"
The master replies: "You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?"
7.2
In the east there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its mark upon the beach. Then the bird mounts on the wind and, with the blue sky at its back, returns home.
The novice programmer stares in wonder at the bird, for he understands it not. The average programmer dreads the coming of the bird, for he fears its message. The master programmer continues to work at his terminal, for he does not know that the bird has come and gone.
7.3
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.
"This is an integrated, distributed, general-purpose workstation," began the magician, "ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state of the art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing."
The master raised his eyebrows slightly. "It is indeed amazing," he said.
"Corporate Headquarters has commanded," continued the magician, "that everyone use this workstation as a platform for new programs. Do you agree to this?"
"Certainly," replied the master, " I will have it transported to the data center immediately!" And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, "I cannot find the listing for my new program. Do you know where it might be?"
"Yes," replied the master, "the listings are stacked on the platform in the data center."
7.4
The master programmer moves form program to program without fear. No change in management can harm him. He will not be fired, even if the project is canceled. Why is this? He is filled with Tao.
Hardware and Software
Book Eight
-----------------------------------------------------------------
Thus spake the master programmer:
"Without the wind, the grass does not move. Without software, hardware is useless."
-----------------------------------------------------------------
8.1
A novice asked the master: "I perceive that one computer company is much larger than all others. It towers above its competition like a giant among dwarfs. Any one of its divisions could comprise an entire business. Why is this so?"
The master replied, "Why do you ask such foolish questions? That company is large because it is large. If it only made hardware, nobody would buy it. If it only made software, nobody would use it. If it only maintained systems, people would treat it like a servant. But because it combines all of these things, people think it one of the gods! By not seeking to strive, it conquers without effort."
8.2
A master programmer passed a novice programmer one day. The master noted the novice's preoccupation with a hand-held computer game. "Excuse me", he said, "may I examine it?"
The novice bolted to attention and handed the device to the master. I see that the device claims to have three levels of play: Easy, Medium and Hard", said the master. "Yet every such device has another level of play, where the device seeks not to conquer the human, nor to be conquered by the human."
"Pray, great master", implored the novice, "how does one find this mysterious settings?"
The master dropped the device to the ground and crushed it under foot. And suddenly the novice was enlightened.
8.3
There was once a programmer who worked upon microprocessors. "Look at how well off I am here," he said to a mainframe programmer who came to visit, "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?"
The mainframe programmer then began to describe his system to his friend, saying "The mainframe sits like an ancient sage meditating in the midst of the data center. Its disk drives lie end-to-end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs,each unique, move through the system like a swift-flowing river. That is why I am happy where I am."
The microcomputer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
8.4
Hardware met Software on the road to Changtse. Software said: "You are Yin and I am Yang. If we travel together we will become famous and earn vast sums of money." And so the set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rage and hobbled along propped on a thorny stick. Firmware said to them: "The Tao lies beyond Yin and Yang. It is silent and still as a pool of water. It does not seek fame, therefore nobody knows its presence. It does not seek fortune, for it is complete within itself. It exists beyond space and time."
Software and Hardware , ashamed, returned to their homes.
Epilogue
Book Nine
-----------------------------------------------------------------
Thus spake the Master Programmer:
"Time for you to leave."
-----------------------------------------------------------------
In the Beginning the Project Manager created the Programming Staff. The Programming Staff was without form and Structure. And the Project Manager said, "Let there be Organization;" and there was Organization. And the Project Manager saw that Organization was good; and the Project Manager separated the workers from the supervisors, and he called the supervisors "Management", and he called the workers "Exempt".
And the Project Manager said, "Let there be a mission in the midst of the Organization, and let it separate the workers, one from another." And the Project Manager created the mission and he called it "The System." And the Project Manager separated those who were to benefit from the System from those who were to build it. And he called the former "User," and he called the latter "Programmers."
And the Project Manager said, "Let all the Programmers in the Organization be gathered together into one place, and let a Chief Programmer be brought up to lead them." And it was so. And the Project Manager saw that it would work.
The Project Manager said unto the Chief Programmer,"Create for me a schedule so that I may look upon the schedule and know the Due Date." And the Chief Programmer went among his staff and consulted with them. And the staff was divided into two parts, one part was called "Analysts,"and the other part was called "Application Programmers." And the Analysts went back to their desks and estimated, as was their custom. And it came to pass that each Analyst brought his estimate to the Chief Programmer whereupon he collected them, summarized them, and drew a Pert Chart.
And the Chief Programmer went unto the Project Manager and presented to him the estimate saying, "It shall take ten months." And the Project Manager was not pleased and said,"I have brought you up from the depths of the staff; and you have not grasped the "Big Picture." And the Project Manager hired consultants, and authorized overtime, and he said to the Chief Programmer, "Behold and see all that I have done!The Due Date will be in five months." The Chief Programmer was much impressed and went from before the Project Manager and proceeded to implement the System.
And the Chief Programmer sent his Analysts to the users and said, "Let Specifications be written." And there were meetings, and lunches, and telephone calls. And the Specifications were written. And there was a Payday and the Happy Hour, one month.
And the Chief Programmer examined the Specifications and saw that they were too ambitious. And he separated the mandatory features from the optional features. And he called the mandatory features "Requirements," and he called the optional features "Deferred," and the Users called him names. And the Chief Programmer gave the Specifications to the Analysts and said, "Let the Requirements be Analyzed and let the Files be Designed." And it was so. And the Chief Programmer said, "Let the Software Houses put forth their salesmen, and let us have a Data Management System." And it was so. The software houses brought forth all manner of Salesmen who presented their packages, and claimed wondrous things for them, each according to his own file structure. And it came to pass that a Data Management System was selected; and the Chief Programmer saw that it was good.
And the Chief Programmer said, "Let there be Progress Reports, so we can monitor and control;" and there were Progress Reports. And the Chief Programmer looked upon the Progress Reports and saw that the Due Date was not to be met. And the Chief Programmer arose, pressed his suit, shaved his beard, and went unto the Project Manager and groveled. And the Chief Programmer pointed his finger, and caused blame to issue forth upon all manner of creatures who sold Hardware and Software. And the Chief Programmer asked for an Extension.
And the Project Manager was exceedingly angry, and cast doubts upon the Chief Programmers ancestry; and uttered a multitude of threats. But it came to pass that an extension was granted; and the Chief Programmer took the extension back to the programming teams, and there was much rejoicing.And the programming of the modules was completed. And there was a Payday and the Happy Hour a fifth month.
And the Chief Programmer said, "Let the modules be integrated one with another, so that System Testing may begin." And it was so.
Great difficulties were experienced, and many hours of overtime were used, and many cups of coffee were consumed.And it came to pass that System Testing was completed. And there was a Payday and the Happy Hour, a sixth month.
Then the Chief Programmer did go to the Project Manager and said unto him, "Behold, I bring you good tidings of a great joy which will come to all the Users; for on this day the System is completed." And suddenly there was with them a multitude of Users praising the Chief Programmer and saying,"Glory be to The System in the highest, but can you make this one small change?
by Greg Borek
If automobiles were manufactured the same way programs are...
Team Leader (TL): OK, what have we got?
Programmer (P): Well, we drove the new release out of the factory and it didn't catch fire, ...well, within the first 3 miles anyway. I think we may be onto a winner here.
TL: Excellent! Does the car perform the way the customer wants?
P: Sort of. The customer asked for a car that can cruise at highway speeds, and our new release can attain speeds of nearly 75 mph, ...um, under certain conditions.
TL: What conditions do you mean, besides obvious ones like going down a steep hill?
P: As long as there is not too much fuel in the tank and no one is actually in the car at the time, we can attain some really good speeds. Passengers particularly tend to degrade the performance.
TL: Not allowing passengers in a car may inconvenience the user. How much is the performance degraded by a passenger?
P: One passenger chopped the speed down to 8 mph. I'm sure the customer can adapt his highway driving to accommodate this slight restriction. I'm absolutely sure he won't mind when he gets a load of all of the fancy features included in this new release.
TL: You did remember to adequately document these alleged features in the owner's manual, I hope? It was sort of embarrassing the number of support calls we got about people not knowing they had to start the car by putting the key in the trunk lock.
P: All of the features are very clearly and simply explained. That guy we hired that used to write tax booklets for the IRS can sure churn out manuals. Especially the twelve chapters devoted to the air conditioner. We felt that it was necessary to go into some detail about the air conditioner.
TL: Why so many chapters about the air conditioner?
P: The user wanted a really powerful air conditioner, and, well, the boys down in the design department got a little carried away. The car doesn't so much have an air conditioner as a refrigeration unit.
TL: Doesn't that degrade the engine performance?
P: We were worried about that too until one of the brainboxes came up with the idea of "overlaying" the engine. For the mere cost of half of the passenger compartment we swap the pieces of the engine between the engine and passenger compartments. Only the pieces of the engine that are currently in use are under the hood. We really feel this was the most clever way to provide all of the required features while reducing the overall size of the vehicle.
TL: Even so the thing is a bit large. I seem to remember the target size of the vehicle being about that of a 2 seater, wasn't it? To the casual observer, our vehicle looks kind of like an Essex-class aircraft carrier.
P: I know, and down in the design department we are kind of embarrassed. We really wanted to make sure we included all of the neat features we had been working on.
TL: Did the user ask for all of these features?
P: Well, not all of them, but they are all really neat... and he probably will once he sees what we've included. I mean, the rocket launchers alone may prove invaluable during his commute to work.
TL: That's true, but what about the gas milage?
P: We came close to what the user asked for, provided he's not too finicky and does not know basic math. If you look off the stern you can see the tractor semi-trailer tanker truck that must be connected to the car at all times. We are going to recommend prepositioning the tanker trucks at every exit on the interstate.
TL: You know, all in all we made it a pretty lousy sports car. At least we can take solace in the fact we met the government standards for a sports car. Good job.
Greg Borek is a C programmer with a "Highway Helper" (OK, "Beltway Bandit" - but don't tell his boss we told you) in Falls Church, VA. He has previously been mistaken for a vampire. Netmail to: Greg Borek at 1:261/1129. Internet: greg.borek@f1129.n261.z1.fidonet.org
DeadStones: The number of megabytes of storage on your server's disk that you never get to use. This measure addresses the vast wasteland of disk space devoted to your operating system, device drivers, swap files and, of course, your fat-and-getting-fatter applications.
FloppyMarks: How many disks you must shove into a machine to install your software. One of the highest FloppyMarks ratings on record came from an early release of The Santa Cruz Operation's Open Desktop. The more than 50 disks included with the package almost single-handedly created the disease now widely known as "floppy elbow".
StretchMarks: How far you can stretch your server's components before they max out. A powerful CPU, for example, might have a high StretchMark rating, while a solitary hard disk would score low on the scale. The server's overall StretchMark would, of course, acheive the lowest rating of all its components.
MillStones: The number of disks a RAID subsystem can devote soley to redundant storage. The lower the MillStone score the better. A RAID 5 sybsystem might notch a 0.25 MillStone while a pair of mirrored disks would rate a 1. Most disk arrays can't yet break the 1 MillStone barrier, but we could yet see multiple disks voting on every read operation to jack their MillStone rating to 2 or even higher.
IdleMark: Speaking of waste, here's a measure of how much CPU power your server devotes to simply standing still. As operating systems like OS/2 and Windows NT hit the desktop, more and more processing power goes to all the stuff you never see: interprocess communication, memory management, scheduling and so on. Chip vendors don't have any hope of winning the IdleMark race against software suppliers.
DeadMarks (see DeadStones): The number of megabytes of RAM your server operating system needs to boot and just sit there, doing nothing. Windows NT may be the first server operating sytem to turn in a DeadMark of 10 Mbytes.
I had a 9:00 meeting with my sales rep. I needed to buy an entire new series 70, the works. He said it'd take about an hour. Three hours later, we'd barely got the datacomm hardware down on paper, so he invited me downstairs for lunch. This was my first experience in an IBM cafeteria. Above the service counter was a menu which began...
MMU's (Main Menu Units)
00010A Burger. Includes sesame-seed bun.
Must order condiments 00110A separately
001 Deletes seeds.
002 Expands burger to two patties.
00020A Double cheeseburger, pre-configured. Includes cheese, bun
and condiments.
001 Add-on bacon.
002 Delete second patty.
003 Replaces second patty with extra cheese.
00021A Burger Upgrade to Double Cheeseburger
001 From Single Burger.
002 From Double Burger.
003 Return credit for bun.
00220A Burger Bundle. Includes 00010A, 00210A and 00310A
001 Substitute root beer 00311A for cola 00310A.
My eyes glazed over. I asked for a burger and a root beer. The waitress looked at me like I was an alien.
"How would you like to order that, sir ?"
"Quickly, if possible. Can't I just order a sandwich and a drink ?"
"No sir. All our service is menu driven. Now what would you like ?"
I scanned the menu. "How big is the 00010 burger ?"
"The patty is rated at eight bites."
"Well, how about the rest of it ?"
"I don't have the specs on that, sir, but I think it's a bit more."
"Eight bites is too small. Give me the Double Burger Upgrade."
My sales rep interrupted. "No, you want the Single Burger option 002 'expands burger to two patties'. The double burger upgrade would give you two burgers.
"But you could get return credit on the extra bun," the waitress chimed in, trying to be helpful, "although it isn't documented."
I looked around to see if anybody was staring at me. There was a couple in line behind us. I recognized one of them, a guy who nearly mowed me down in the parking lot with his cherry-red '62 Vette. He was talking to some woman who was waving her arms around and looking very excited.
"What if... we marketed the bacon cheeseburger with the vegetable option and without the burger and cheese ? It'd be a BLT!"
The woman charged off in the direction of the telephone, running steeplechases over tables and chairs. My waitress tried to get my attention again. "Have you decided, sir ?"
"Yeah, give me the double burger- excuse me, I mean the 00020A with the option 001. I want everything on it." She put me down for the Condiment Expansion Kit, which included mayonnaise, mustard and pickles with a option to substitute relish.
"Ketchup." I hated to ask. "I want ketchup on that, too." "Thats not a condiment, sir, it's a Tomato Product."
My sales rep butted in again.
"Thats not a supported configuration."
"Why not ?" I kept my voice steady.
"Too juicy. The bun can't handle it."
"Look. Forget the ketchup, just put some lettuce and tomatoes on
it."
The waitress backed away from the counter. "I'm sorry, sir, but that's not supported either, the bun can take it but the burger won't fit in the box. The sales rep defended himself. "Just not at first release." "It is being beta-tested, sir."
I checked the overhead screen.
Fries, number 000210A, option 110, French
followed by option 120, English.
"What the hell are English Fries ?" I turned to the sales rep.
"Chips they call them. We sell a lot of them."
I gave up. "OK, OK just give me a plain vanilla Burger Bundle."
This confused the waitress profoundly.
"Sir, Vanilla as an option is configured only for series 00450 Milk Shakes." My sales rep chuckles.
"No ma'am, he just wants a standard 00220A off the shelf. I wondered how long it had been on the shelf. I didn't ask.
"Very good, sir." The waitress breathed a sigh of relief.
"Your meal is now on order. Now how would you like it supported ?"
"Support ?" She directed me to the green shaded area at the bottom of the menu, and I began a litany with my Sales Rep that I'll never forget.
"Implementation assistance ?"
"You get a waiter."
"Implementation analysis ?"
You tell him how hungry you are and he tells you what to eat."
"Response Center Support ?"
"He brings it to your table."
"Extended materials ?"
"You get refills."
I stuffed some money at the waitress and told her to take it. She gave me my check on three sheets of green-bar paper. I studied it on my way to the table, and decided it'd pass as an emergency napkin.
Table? My Sales Rep had been bright enough to order us a table. He hadn't been bright enough to check on a delivery date. The table waiter slouching in his corner surveyed the crowded room, looked at me and said "Two weeks. But I can get you a stand alone chair by the window right away."
I handed him the tray. A woman rushed up to me with two small cups of chile and sauerkraut for the hot dog somebody else had ordered. The room began to grow dim, my eyesight faded...
I woke up clutching the water-glass at my bedside table. It was five AM, four hours till my meeting with IBM I had had a vision, I did what it told me to do. I dialed my office, and I called in sick.
Micro was a real time operator and dedicated multi-user. His broad-band protocol made it easy for him to interface with numerous input/output devices, even if it meant time sharing. One evening he arrived home just as the sun was crashing, and parked his Motorola 68000 in the main drive (he had missed the S100 bus that morning), when he noticed an elegant piece of liveware admiring the daisy wheels in his garden. He thought to himself, "She looks user- friendly, I'll see if she'd like an update tonight." Mini was her name, and she was delightfully engineered with eyes like COBOL and a prime mainframe architecture that set Micro's peripherals networking all over the place. He browsed over to her casually, admiring the power of her twin, 32-bit floating point processors, and enquired "How are you Honeywell?". "Yes, I am well", she responded, batting her optical fibers engagingly and smoothing her console over her curvi-linear functions. Micro settled for a straight line approximation. "I'm stand-alone tonight", he said. "How about computing a vector to my bas address, I'll output a byte to eat, and maybe we could offset latter on"? Mini ran a priority process for 2.6 milli-seconds, the transmitted "8K, I've been dumped myself recently, and a new page is just what I need to refresh my disks. I'll park my machine cycle in your background and meet you inside". She walked off, leaving Micro admiring her solenoids and thinking, "WOW, what a global variable, I wonder if she'll like my firmware?"
They sat down at the process table to a tub of form feed and fiche and chips and a bucket of baud. Mini was in conversational mode an expanded on ambiguous arguments while Micro gave occasional acknowledgements although, in reality he was analyzing the shortest and least critical path to her entry point. He finally settled on the old "Would you like to see my bench-mark routine?", but Mini was again one step ahead. Suddenly she was up and stripping off her parity bits to reveal the full functionality of her operating system software. "Lets' get BASIC, you RAM", she said. Micro was loaded by this stage, but his hardware pulling module had a processor of it's own and was in danger of overflowing it's output buffer, a hang-up that Micro had consulted his analyst about. "Core", was all he could say. Micro soon recovered, however, when she went down on the DEC and opened her device files to reveal her data set ready. He accessed his fully packed root device and was just about to start pushing into her CPU stack when she attempted an escape sequence. "No, no!", she piped. "You're not shielded!" "Reset, baby", he replied. "I've been debugged". "But I haven't got my current loop enabled, and I can't support child processes", she protested. "Don't run away", he said, "I'll generate an interrupt". "No that's too error prone, and I can't abort because of my design philosophy". Micro was locked in by this stage though, and could not be turned off. But she soon stopped his thrashing by introducing a voltage spike into his main supply, whereupon he fell over with a head crash and went to sleep. "Computers!", she thought as she compiled herself, "All they ever think of is Hex!"
1) Computers are unreliable, but humans are even more unreliable.
Corollary
At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
2) Any system which depends on human reliability is unreliable.
3) The only difference between the fool and the criminal who attacks a system is that the fool attacks unpredictably and on a broader front.
4) A system tends to grow in terms of complexity rather than of simplification, until the resulting unreliability becomes intolerable.
5) Self-checking systems tend to have a complexity in proportion to the inherent unreliability of the system in which they are used.
6) The error-detection and correction capabilities of any system will serve as the key to understanding the type of errors which they cannot handle.
7) Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
8) All real programs contain errors until proved otherwise -- which is impossible.
9) Investment in reliability will increase until it exceeds the probable cost of errors, or somebody insists on getting some useful work done.
Golub's Laws of Computerdom
1) Fuzzy project objectives are used to avoid the embarrassment of estimating the corresponding costs.
2) A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
3) The effort requires to correct course increases geometrically with time.
4) Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.
Peck's Programming Postulates (Philosophic Engineering applied to programming)
1) In any program, any error which can creep in will eventually do so.
2) Not until the program has been in production for at least six months will the most harmful error be discovered.
3) Any constants, limits, or timing formulas that appear in the computer manufacturer's literature should be treated as variables.
4) The most vital parameter in any subroutine stands the greatest chance of being left out of the calling sequence.
5) If only one compiler can be secured for a piece of hardware, the compilation times will be exorbitant.
6) If a test installation functions perfectly, all subsequent systems will malfunction.
7) Job control cards that positively cannot be arranged in improper order, will be.
8) Interchangeable tapes won't.
9) If more than one person has programmed a malfunctioning routine, no one is at fault.
10) If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it.
11) Duplicated object decks which test in identical fashion will not give identical results at remote sites.
12) Manufacturer's hardware and software support ceases with payment for the computer.
Troutman's Laws of Computer Programming (and see Peck's Programming Postulates)
1) Any running program is obsolete.
2) Any planned program costs more and takes longer.
3) Any useful program will have to be changed.
4) Any useless program will have to be documented.
5) The size of a program expands to fill all available memory.
6) The value of a program is inversely proportional to the weight of its output.
7) The complexity of a program grows until it exceeds the capability of its maintainers.
8) Any system that relies on computer reliability is unreliable.
9) Any system that relies on human reliability is unreliable.
10) Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English.
11) Profanity is the one language all programmers know best.
Dijkstra's Prescription for Programming Inertia
If you don't know what your program is supposed to do, you'd better not start writing it.
Gray's Law of Programming
n+1 trivial tasks are expected to be accomplished in the same time as n trivial tasks.
Logg's Rebuttal to Gray's Law of Programming
n+1 trivial tasks take twice as long as n trivial tasks.
Halpern's Observation
That tendency to err that programmers have been noticed to share with other human beings has often been treated as if it were an awkwardness attendant upon programming's adolescence, which like acne would disappear with the craft's coming of age. It has proved otherwise.
Hoare's Law of Large Programs
Inside every large program is a small program struggling to get out.
Weinberg's Law
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
Corollary
An expert is a person who avoids the small errors while sweeping on to the grand fallacy.
- or -
Defining Computer Terms from a "Marketing" point of view
ALL NEW -- The Software is not compatible with previous versions.
ADVANCED DESIGN -- Upper Management doesn't understand it.
BREAKTHROUGH -- It nearly booted on the first try.
NEW -- It comes in different colors from the previous version.
DESIGN SIMPLICITY -- It was developed on a shoe-string budget.
EXCLUSIVE -- We're the only ones who have the documentation.
FIELD TESTED -- Manufacturing doesn't have a test system.
FOOLPROOF OPERATION -- All parameters are hard coded.
FUTURISTIC -- It only runs on the next-generation supercomputer.
HIGH ACCURACY -- All the directories compare.
IT'S HERE AT LAST -- We've released a 26-week project in 48 weeks.
MAINTENANCE FREE -- It's impossible to fix.
MEETS QUALITY STANDARDS -- It compiles without errors.
PERFORMANCE PROVEN -- It works through the beta test.
REVOLUTIONARY -- The disk drives go round and round.
SATISFACTION GUARANTEED -- We'll send you another copy if it fails.
STOCK ITEM -- We shipped it once before, and we can do it again, probably.
UNMATCHED -- It's almost as good as the competition.
UNPRECEDENTED PERFORMANCE -- Nothing ever ran this slow before.
YEARS OF DEVELOPMENT -- We finally got one to work.
DOS: Everybody pushes it till it glides, jumps on, and lets it coast till it skids... then jumps off, pushes, jumps back on, etc.
DOS w/QEMM: same as DOS but with more leg room to push.
MAC: all the stewards, stewardesses, captains, baggage handlers, etc., look the same, act the same, and talk the same. Every time you ask questions about details you are told you don't need to know, don't want to know, and everything will be done for you without knowing, so just shut up.
OS/2: to get on board you have to have your ticket stamped 10 different times by standing in 10 different lines; then you have to fill out a form that states how you want your seating arrangement to be--whether it should have the look and feel of an ocean liner, a passenger train, or a bus. If you are successful in getting on board and getting off the ground you have a wonderful, enjoyable trip... except for times when the rudder and flaps freeze stuck, in which case you have time to say your prayers and get your personal things in order before you crash.
Windows: nice colorful airport terminal, friendly stewards/stewardesses, easy access to a plane, uneventful takeoff.... then BOOM! you blow up without any warning whatsoever.
NT: everyone sits on the runway and forms the outline of a plane, then they just sit there and go "PHHLLZZZSST" like they're flying.
Unix: everyone brings one piece of the plane with them when they come to the airport. Then they go out on the runway and piece it together, all the time arguing about what kind of plane they are building.
Few people realize that in addition to writing plays, William Shakespeare was an accomplished programmer and Borland beta-tester. His PC was configured "with all appliances and means to boot" [Henry IV 2, III.1.29], and he also used a Macintosh, as evidenced by the remark, "What light through yonder window breaks?" [Romeo and Juliet II.2.1] -- uttered before he found the brightness control.
Structured programming was not Shakespeare's forte. Troilus and Cressida, written in Fortran for a Japanese auto firm, contains the regrettable line, "Go to, go to!" [II.2.53] as well as fifteen other go to's, two go from's and the invitable comment, "And whither go they?" [I.2.2]. A similar comment, "Stand not upon the order of your going/ But go at once" [Macbeth III.4.29] clearly refers to a multilevel exit from deeply nested procedures.
Shakespeare liked user-defined data types because, as he put it, "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy" [Hamlet I.5.166]. Elsewhere he asks, "Shall I compare thee to a summer's day?" [Sonnets 18.1] -- an obvious type mismatch, which is why he "did never sonnet for her sake compile" [Love's Labour's Lost IV.3.134].
As an early colleague of Philippe Kahn, Shakespeare cautioned him that "Les langues des hommes sont pleines de tromperies" [Henry V, V.2.118], and advised him to bring out a fast, low-cost Pascal compiler, for "I am as poor as Job, my lord, but not so patient" [Henry IV 2, I.2.145]. Many Borland products are based on Shakespeare's suggestions, including SideKick ("A calendar! a calendar!" [Midsummer Night's Dream III.1.55]) and Turbo Prolog (with "much virtue in 'if'," As You Like It V.4.108).
Shakespeare disparaged BASIC on the ground that its designers "have been at a great feast of languages, and stolen the scraps" [Love's Labour's Lost V.1.39], though exactly which SHARE or SIGPLAN banquet he had in mind is not clear. He later wrote a book on Ada, _Much Ado About Nothing_, and a list of bugs in PC-DOS 3.2, the _Comedy of Errors_. In the latter he tells a programmer, "We may pity, though not pardon thee" [I.1.97]. Elsewhere he describes how DOS crashes with a stack overflow: "He dies, and makes no sign" [Henry VI 2, III.3.29] and gives his advice to a colleague to whom this happened: "Boot, boot, Master Shallow" [ibid., V.3.141].
The Pizza Metric
How: Count the number of pizza boxes in the lab. What: Measures the amount of schedule under-estimation. If people are spending enough after-hours time working on the project that they need to have meals delivered to the office, then there has obviously been a mis-estimation somewhere.
The Aspirin Metric
How: Maintain a centrally-located aspirin bottle for use by the team. At the beginning and end of each month, count the number of aspirin remaining in the aspirin bottle. What: Measures stress suffered by the team during the project. This most likely indicates poor project design in the early phases, which causes over-expenditure of effort later on. In the early phases, high aspirin-usage probably indicates that the product's goals or other parameters were poorly defined.
The Beer Metric
How: Invite the team to a beer bash each Friday. Record the total bar bill. What: Closely related to the Aspirin Metric, the Beer Metric measures the frustration level of the team. Among other things, this may indicate that the technical challenge is more difficult than anticipated.
The Creeping Feature Metric
How: Count the number of features added to the project after the design has been signed off, but that were not requested by any requirements definition. What: This measures schedule slack. If the team has time to add features that are not necessary, then there was too much time allocated to a schedule task.
The "Duck!" Metric
How: This one is tricky, but a likely metric would be to count the number of engineers that leave the room when a marketing person enters. This is only valid after a requirements document has been finalized. What: Measures the completeness of the initial requirements. If too many requirements changes are made after the product has been designed, then the engineering team will be wary
The Status Report Metric
How: Count the total number of words dedicated to the project in each engineer's status report. What: This is a simple way to estimate the smoothness with which the project is running. If things are going well, an item will likely read, "I talked to Fred; the widgets are on schedule." If things are not going as well, it will say, "I finally got in touch with Fred after talking to his phone mail for nine days straight. It appears that the widgets will be delayed due to snow in the Ozarks, which will cause the whoozits schedule to be put on hold until widgets arrive. If the whoozits schedule slips by three weeks, then the entire project is in danger of missing the July deadline."
Black Box The tester has no clue as to what's going on inside. Often used by large corporations for software verification. More often NOT used by large corporations for software verification.
White Box The tester knows the internals, but doesn't manipulate them directly. This is handy because the tester can avoid messy problems or functions that are likely to cause trouble. This is also know as "doing a demo"
Open Box The tester directly manipulates the internals. This is handy because it allows the tester to test particular bits of code when other, important bits aren't even written yet. This is also knows as "rigging a demo"
Toy Box The tester plays with the product. Often in ways in which the product was never intended to be used. The people at Underwriters Laboratories are experts at this. So is your three year old nephew. This kind of testing leads to lengthly disclaimers and warranties.
Jack-in-the-Box The tester cranks on the product until something surprising happens. If nothing surprising happens, it gets marketed. If something surprising happens, it gets marketed as "new" and "improved" and the version number goes up by 0.0.1
Shoe Box The tester places the product in a dark closet or cupboard and forgets about it. Eventually, someone discovers that micro organisms have performed some astoundingly intense testing of their own. This provides the key "cleaning instructions" section of the manual. (If the product is software, this testing consists of putting the code under source management control, the software equivalent of a dark closet. The only difference is the no one will ever see it again.)
Gray Box Marketing paints the product to gain a larger market share/ improve its ergonomics. This is especially interesting with magnetic media. This is also known as "platinum box" testing.
Cardboard Box A rather trivial test of the packaging materials. You can tell if this step was neglected when your floppy disk arrives in a 3' shipping carton, packed in styrofoam peanuts.
Strong Box Tests the physical integrity of the product. Often for military contracts, though HP does it just for the heck of it. 3 1/2 floppies were Strong Box tested, 5 1/4 floppies weren't. This test is near-impossible to perform with software, nevertheless, it is required for government contracts.
Bacchus invented FORTRAN. /* I knew FORTRAN was old, and that it may have been designed under the influence of alcohol, but... */
There are three kinds of program statements: sequence, repetition, and seduction.
There are two types of graphics: vector and rascal. /* Otay... */
Programming languages have specifictions. /* Obviously this student has dealt with a few standards. */
Macs are compatible with each other. /* Imagine the alternative: "What's your Mac's serial number? We'll go back to the ware-house and get your software." */
Doctors use computers to create a three demential picture of a person's brain. /* Is this classic, or what? */
One kind of a hostile computer program is a Trojan.
C is a logical programming language. /* < rim shot> */
Heuristics (from the French heure, "hour") limit the amount of time spent executing something. [When using heuristics] it shouldn't take longer than an hour to do something. /* An absolutely terrific "false cognate". */
Having the computer automatically fill in images for animation is called "spleening". /* Derivation: most likely "splines" + "tweening". */
One method of computer security is a phone line. /* She qualified it later by adding, "You have to know the number." */
Video games are examples of fault-tolerant systems.
On one test, I gave the students some abbreviations and asked them to tell mewhat they stood for. You won't believe the creativity of a student in a testsituation. For example, one of the abbreviations was "fax", which *really*stands for "facsimile". However, various Comp 4'ers said it stood for: Fiber-optic Aided Xeroxing, Frequency Automatic X-rays, /* and my favorite... */ Fast A** Xeroxing
Bove's Theorem: The remaining work to finish in order to reach your goal increases as the deadline approaches.
Cann's Axiom: When all else fails, read the instructions.
Deadline-Dan's Demo Demonstration: The higher the "higher-ups" are who have come to see your demo, the lower your chances of are of giving a successful one.
Deadline-Dan's Demon: Every task takes twice as long as you think it will. If you double the time you think it will take, it will actually take 4 times as long.
Demian's Observation: There is always one item on the screen menu that is mislabeled and should read "ABANDON HOPE ALL YE WHO ENTER HERE."
Dr. Caligari's Come-Back: A bad sector disk error occurs only after you've done several hours of work without performing a backup.
Estridge's Law: No matter how large and standardized the marketplace is, IBM can redefine it
Finagle's Rules: 1) To study an application best, understand it thoroughly before you start. 2) Always keep a record of data. It indicates you've been working. 3) Always draw your curves, then plot the data. 4) In case of doubt, make it sound convincing. 5) Program results should always be reproducible. They should all fail in the same way. 6) Do not believe in miracles. Rely on them.
Franklin's Rule: Blessed is the user who expects nothing, for he/she will not be disappointed.
Gilb's Laws of Unreliability: 1) At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. 2) Any system which depends on human reliability is unreliable. 3) Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited. 4) Investment in reliability will increase until it exceeds the probable cost of errors, or until someone insists on getting some useful work done.
Gummidge's Law: The amount of expertise varies in inverse proportion to the number of statements understood by the general public.
Harp's Corollary to Estridge's Law: Your "IBM-PC compatible" computer grows more incompatible with every passing momement.
Heller's Law: The first myth of management is that it exists.
The Last One's Law of Program Generators: A program generator creates programs that are more "buggy" than the program generator.
Meskimmen's Law:.More.. There's never time to do it right, but always time to do it over.
Nixon's Law: The man who can smile when things go wrong has thought of someone he can blame it on.
Nolan's Placebo: An ounce of image is worth a pound of performance.
Peer's Law: The solution to a problem changes the problem.
Robert E. Lee's Truce: Judgment comes from experience; experience comes from poor judgment.
SNAFU Equations: 1) Given any problem containing N equations, there will be N + 1 unknowns. 2) Any object or bit of information most needed will be least available. 3) Any device requiring service or adjustment will be least accessible. 4) Interchangeable devices won't. 5) In any human endeavor, once you have exhausted all possibilities and fail, there will be one solution, simple and obvious, highly visible to everyone else. 6) Badness comes in waves.
Thoreau's Theories of Adaptation: 1) After months of training and you finally understand all of a program's commands, a revised version of the program arrives with an all-new command structure. 2) After designing a useful routine that gets around a familiar "bug" in the system, the system is revised, the "bug" is taken away, and you're left with a useless routine. 3) Efforts in improving a program's "user friendliness" invariably lead to work in improving a user's "computer literacy." 4) That's not a "bug", that's a feature!
Wood's Axiom: As soon as a still-to-be-finished computer task becomes a life-or-death situation, the power fails.
Zymurgy's First Law of Evolving System Dynamics: Once you open up a can of worms, the only way to recan them is to use a larger can.
From: elf@ee. ryerson. ca (luis fernandes)
1. You can always tell a good idea by the enemies it makes. - programmer's axiom
2. Everything always takes twice as long and costs four times as much asyou planned. - programmer's axiom
3. It's never the technical stuff that gets you in trouble. It's thepersonalities and the politics. - programmer's sayings
4. Those who can't do, teach. - article of faith among studentsAnd vice-versa. - programmer's addendum to students' article of faith
5. Living with a programmer is easy. All you need is the patience of asaint. - programmer's wives' saying
6. Applications programming is a race between software engineers, whostrive to produce idiot-proof programs, and the Universe whichstrives to produce bigger idiots. - software engineers' sayingSo far, the Universe is winning. - applications programmers' saying
7. The three most dangerous things in the world are a programmer with asoldering iron, a hardware type with a program patch and a user withan idea. - computer saying
8. You can't do just one thing. - Campbell's Law of everything
9. Friends come an go, but enemies accumulate. - Murphy's Law #1024and sometimes the the real trick is telling the difference. - Murphy's Law #1024a
10. Whenever you use a jump, be sure of your destination address. - programmer's saying
11. Always secure your files. You never know who's lurking about. - programmer's saying
12. Never argue with a redhaired witch. It wastes your breath and only delays the inevitable. - the collected sayings of Wiz Zumwalt
13. If you eat a live toad first thing in the morning, nothing worse will happen all day long. - California saying To you or the toad. - Niven's restatement of California saying--well, most of the time, anyway. . . - programmer's caveat to Niven's restatement of California saying
14. You never find out the whole story until after you've signed thecontract. - programmer's saying
15. A jump gone awry is one of the hardest bugs to locate. - programmer's saying
16. You can't unscramble an egg. - old sayingYou can if you're powerful enough. - the collected sayings of Wiz Zumwalt
17. Magic is real, unless declared integer. - the collected sayings of Wiz Zumwalt
18. Any sufficiently advanced technology is indistinguishable from magic. - Clarke's law Any sufficiently advanced magic is indistinguishable from technology. - Murphy's reformulation of Clarke's law Any sufficiently advanced magic is indistinguishable from a rigged demostration. - programmer's restatement of Murphy's reformulation of Clarke's law
19. Putting twice as many programmers on a project that is late will makeit twice as late. - Brooks' law of programming projects
20. Never give a sucker an even break. - W. C. Fields Especially not if he's a big mean sucker. - the collected sayings of Wiz Zumwalt
21. Sleep? Isn't that a completely inadequate substitute for caffine?- programmer's saying
22. Good client relations are the key to a successful project. - consultants' saying
23. At some time in the project you're going to have to break downand finally define the problem. - programmer's saying
24. Customer support is an art, not a science. - marketing saying So are most other forms of torture. - programmers' response
25. Programming is like pinball. The reward for doing it is the opportunity of doing it again. - programmers' saying
Daniel Solomon & David Rosenblueth
Department of Computer Science, University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
With such a large selection of programming languages it can bedifficult to choose one for a particular project. Reading the manuals toevaluate the languages is a time consuming process. On the other hand,most people already have a fairly good idea of how various automobilescompare. So in order to assist those trying to choose a language, wehave prepared a chart that matches programming languages with comparableautomobiles.
Assembler - A Formula I race car. Very fast, but difficult to drive and expensive to maintain.
FORTRAN II - A Model T Ford. Once it was king of the road.
FORTRAN IV - A Model A Ford.
FORTRAN 77 - A six-cylinder Ford Fairlane with standard transmission and no seat belts.
COBOL - A delivery van. It's bulky and ugly, but it does the work.
BASIC - A second-hand Rambler with a rebuilt engine and patched upholstry. Your dad bought it for you to learn to drive. You'll ditch the car as soon as you can afford a new one.
PL/I - A Cadillac convertible with automatic transmission, a two- tone paint job, white-wall tires, chrome exhaust pipes, and fuzzy dice hanging in the windshield.
C - A black Firebird, the all-macho car. Comes with optional seat belts (lint) and optional fuzz buster (escape to assembler).
ALGOL 60 - An Austin Mini. Boy, that's a small car.Pascal - A Volkswagon Beetle. It's small but sturdy. Was once popular with intellectuals.Modula II - A Volkswagon Rabbit with a trailer hitch.
ALGOL 68 - An Astin Martin. An impressive car, but not just anyone can drive it.
LISP - An electric car. It's simple but slow. Seat belts are not available.
PROLOG/LUCID - Prototype concept-cars.
Maple/MACSYMA - All-terrain vehicles.
FORTH - A go-cart.
LOGO - A kiddie's replica of a Rolls Royce. Comes with a real engine and a working horn.
APL - A double-decker bus. Its takes rows and columns of passengers to the same place all at the same time. But, it drives only in reverse gear, and is instrumented in Greek.
Ada - An army-green Mercedes-Benz staff car. Power steering, power brakes and automatic transmission are all standard. No other colors or options are available. If it's good enough for the generals, it's good enough for you. Manufacturing delays due to difficulties reading the design specification are starting to clear up.
by: Daniel J. Salomon
Department of Computer Science, University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
There are so many programming languages available that it can be very difficult to get to know them all well enough to pick the right one for you. On the other hand most men know what kind of woman appeals to them. So here is a handy guide for many of the popular programming languages that describes what kind of women they would be if programming languages were women.
Assembler - A female track star who holds all the world speed records. She is hard and bumpy, and so is not that pleasant to embrace. She can cook up any meal, but needs a complete and detailed recipe. She is not beautiful or educated, and speaks in monosyllables like "MOV, JUMP, INC". She has afierce and violent temper that make her the choice of last resort.
FORTRAN - Your grey-haired grandmother. People make fun of her just because she is old, but if you take the time to listen, you can learn from her experiences and her mistakes. During her lifetime she has acquired many useful skills in sewing and cooking (subroutine libraries) That no younger women can match, so be thankful she is still around. She has a notoriously bad temper and when angered will start yelling and throwing dishes. It was mostly her bad temper that made grandad search for another wife.
COBOL - A plump secretary. She talks far too much, and most of what she says can be ignored. She works hard and long hours, but can't handle really complicated jobs. She has a short and unpredictable temper, so no one really likes working with her. She can cook meals for a huge family, but only knows bland recipes.
BASIC - The horny divorcee that lives next door. Her specialty is seducing young boys and it seems she is always readily available for them. She teaches them many amazing things, or at least they seem amazing because it is their first experience. She is not that young herself, but because she was their first lover the boys always remember her fondly. Her cooking and sewing skills are mediocre, but largely irrelevant, it's the frolicking that the boys like. The opinion that adults have of Mrs. BASIC is varied. Shockingly, some fathers actually introduce their own sons to this immoral woman! But generally the more righteous adults try to correct the badly influenced young men by introducing them to well behaved women like Miss Pascal.
PL/I - A bordello madam. She wears silk dresses, diamonds, furs and red high heels. At one time she seemed very attractive, but now she just seems overweight and tacky. Tastes change.
C - A lady executive. An avid jogger, very healthy, and not too talkative. Is an good cook if you like spicy food. Unless you double check everything you say (through LINT) you can unleash her fierce temper. Her daughter C++ is still quite young and prone to tantrums, but it seems that she will grow up into a fine young woman of milder temper and more sophisticated character.
ALGOL 60 - Your father's wartime sweetheart, petite, well proportioned, and sweet tempered. She disappeared mysteriously during the war, but your dad still talks about her shapely form and their steamy romance. He never actually tasted much of her cooking.
Pascal - A grammar school teacher, and Algol 60's younger sister. Like her sister she is petite and attractive, but very bossy. She is a good cook but only if the recipe requires no more than one pot (module).
Modula II - A high-school teacher and Pascal's daughter. Very much like her mother, but she has learned to cook with more than one pot.
ALGOL 68 - Algol 60's niece. A high-society woman, well educated and terse. Few men can fully understand her when she talks, and her former lovers still discuss her mysterious personality. She is very choosy about her romances and won't take just any man as her lover. She hasn't been seen lately, and rumor has it that she died in a fall from an ivory tower.
LISP - She is an aging beatnik, who lives in a rural commune with her hippie cousins SMALLTALK and FORTH. Many men (mostly college students) who have visited the farmhouse enthusiastically praise the natural food and perpetual love-ins that take place there. Others criticize the long cooking times, and the abnormal sexual postures (prefix and postfix). Although these women seldom have full-time jobs, when they do work, their employers praise them for their imagination, but usually not for their efficiency.
APL - A fancy caterer specializing in Greek food. She can cook delicious meals for rows and rows of tables with dozens of people at each table. She doesn't talk much, as that would just slow her work down. Few people can understand her recipes, since they are in a foreign language, and are all recorded in mirror writing.
LOGO - A grade-school art teacher. She is just the kind of teacher that you wish you had when you were young. She is shapely and patient, but not an interesting conversationalist. She can cook up delicious kiddie snacks, but not full-course meals.
LUCID & PROLOG - These clever teenagers show a new kind of cooking skill. They can cook-up fine meals without the use of recipes, working solely from a description of the desired meal (declarative cooking). Many men are fascinated by this and have already proposed marriage. Others complain that the girls work very slowly, and that often the description of the meal must be just as long as a recipe would be. It is hard to predict what these girls will be like when they are fully mature.
Ada - A WAC colonel built like an amazon. She is always setting strict rules, but if you follow them, she keeps her temper. She is quite talkative, always spouting army regulations, and using obscure military talk. You gotta love her though, because the army says so.
* * *
In the beginning, all was void, with the spirit of God brooding
over the dark vapors.
* * *
Then God said: LET THERE BE BYTE, and there was byte. God saw the
byte, and was pleased with it, and divided the byte in bits. He
created a multitude of similar bytes, all identical in their ethereal
perfection, and all containing zeros, for zeros were all there were.
* * *
On the second day God toyed with the bytes, and organized them
into groups to which he said: YOU SHALL BE CALLED WORDS, FOR FROM BYTES
YOU CAME AND OF BYTES YOU ARE COMPOSED. And God saw the words, that
they were good and was pleased.
* * *
The third day God said (to whom God was talking has never has
never been ascertained or even questioned): I HAVE WORDS, MADE UP OF
BYTES, MADE UP OF BITS, BUT SOMETHING'S MISSING.
* * *
So God scraped up a lump of clay, squeezed it tightly in his
mighty hands, and flung it against the sky, where it solidified into a
smoky mass. God saw the steaming heap, that it was good and said to
it: YOU SHALL BE CALLED HARDWARE, A HOME FOR MY BYTES AND BITS, AND AS
YOU ARE THE VERY FIRST OF YOUR KIND I SHALL CALL YOU CPU. And God
turned, and with a flick of his wrist spew forth tape drives (FOR YOU
SHALL BE TEMPORARILY A HOME FOR MY WORDS...), stations, whole
teleprocessing installations.
* * *
And God saw all this sparkling in the heavens, that it was good
and he was pleased. Having done all this, God rested.
* * *
On the fourth day, God reviewed all that he had done. He saw his
bits and his bytes statistically on an infinite variety of media. But
he was not satisfied. SOMETHING'S MISSING, said he, I NEED TO ANIMATE
MY TREASURED BYTES TO GIVE THEM LIFE. So God leaned back, touched a
soiled hand to his mighty brow, and with one single, all-powerful
thought set his hardware in motion. YOU said he to the intangible
breath now coursing through his hardware, I SHALL CALL SOFTWARE, FOR
...(so on, and so forth.)
* * *
And he continued: YOU ARE THE FIRST, THE BEST, THE MOST PERFECT
AND OMNIPOTENT SOFTWARE. And God divided the software in many parts,
into utilities, compilers, system libraries and his favorite, most
privileged and beloved operating system. God was pleased, so he
rested.
* * *
On the fifth day, God again surveyed all that he had done, and was
filled with joy. He found that with his creation he could determine the
value of pi to ten thousand digits. He found that he could produce
flow charts of his beloved operating system, and these he posted by his
throne. He discovered that he could run off Snoopy calendars, pictures
of Mona Lisa, and witty little computer accounts of the creation. And
with a terminal at his throne, he didn't have to travel halfway to
hell to access his system.
* * *
He called his creation IMPERATUM BYTAM MAGNAMUS (or IBM for
short).
* * *
But all was not well. God's beloved system was so large, so
complex, that even the mighty God - maker of heavens and earth (but
that's another story), the builder of cpu and virtual memory, the
author of fortran - even that God was hard- pressed to keep up on how
everything worked.
* * *
So God said I'LL MAKE ME A MAN. And he did, and to the man he said
YOU SHALL BE CALLED (logically enough) "MAN" AND TO YOU SHALL FALL THE
RESPONSIBILITY OF MAINTAINING ALL THAT I HAVE DONE. And to keep Man
happy after-hours, God gave him Woman, saying to Man FOR I KNOW THAT
EVEN BYTES GET HUNGRY FOR A LITTLE BIT. And God rested, chuckling at
his own play on words.
* * *
On the sixth day, God mounted his throne, logged onto his
terminal, and engaged in a full day of uninterrupted one second
turnaround. He saw all that he had done, that it was good. He was
pleased that from his first byte he had created such a wonderful and
extensive toy. He created file after file, he performed advanced and
impressive on-line database updates, he wrote a faster and more
extensive fortran compiler, and in general rejoiced in the perfection
of his IBM.
* * *
After a hard day's work on a hot terminal - during which Man was
quietly familiarizing himself with the system documentation - God
called it a day (YOU I SHALL CALL DAY... and so forth and so on.)
* * *
On the seventh day - so tired was he from the week's labors -
God slept all day. What transpired on that crucial seventh day is
recounted in THE FALL OF MAN...
INS TECHNOLOGY WATCH: [Mike Taylor, INS Correspondent]
Nattick, MA, USA]
COMPUTERWORLD 1 May
CREATORS ADMIT UNIX, C HOAX
In an announcement that has stunned the computer industry, Ken
Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix
operating system and C programming language created by them is an
elaborate April Fools prank kept alive for over 20 years. Speaking at
the recent UnixWorld Software Development Forum, Thompson revealed the
following:
"In 1969, AT& T had just terminated their work with the
GE/Honeywell/AT& T Multics project. Brian and I had just started working
with an early release of Pascal from Professor Nichlaus Wirth's ETH
labs in Switzerland and we were impressed with its elegant simplicity
and power. Dennis had just finished reading 'Bored of the Rings', a
hilarious National Lampoon parody of the great Tolkien 'Lord of the
Rings' trilogy. As a lark, we decided to do parodies of the Multics
environment and Pascal. Dennis and I were responsible for the operating
environment. We looked at Multics and designed the new system to be as
complex and cryptic as possible to maximize casual users' frustration
levels, calling it Unix as a parody of Multics, as well as other more
risque allusions. Then Dennis and Brian worked on a truly warped
version of Pascal, called 'A'. When we found others were actually
trying to create real programs with A, we quickly added additional
cryptic features and evolved into B, BCPL and finally C. We stopped
when we got a clean compile on the following syntax:
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("|"+(*u/4) %2);
To think that modern programmers would try to use a language that
allowed such a statement was beyond our comprehension! We actually
thought of selling this to the Soviets to set their computer science
progress back 20 or more years. Imagine our surprise when AT& T and
other US corporations actually began trying to use Unix and C! It has
taken them 20 years to develop enough expertise to generate even
marginally useful applications using this 1960's technological parody,
but we are impressed with the tenacity (if not common sense) of the
general Unix and C programmer. In any event, Brian, Dennis and I have
been working exclusively in Pascal on the Apple Macintosh for the past
few years and feel really guilty about the chaos, confusion and truly
bad programming that have resulted from our silly prank so long ago."
Major Unix and C vendors and customers, including AT& T, Microsoft,
Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time.
Borland International, a leading vendor of Pascal and C tools,
including the popular Turbo Pascal, Turbo C and Turbo C++, stated they
had suspected this for a number of years and would continue to enhance
their Pascal products and halt further efforts to develop C. An IBM
spokesman broke into uncontrolled laughter and had to postpone a
hastily convened news conference concerning the fate of the RS-6000,
merely stating 'VM will be available Real Soon Now'. In a cryptic
statement, Professor Wirth of the ETH institute and father of the
Pascal, Modula 2 and Oberon structured languages, merely stated that P.
T. Barnum was correct.
In a related late-breaking story, usually reliable sources are
stating that a similar confession may be forthcoming from William Gates
concerning the MS-DOS and Windows operating environments. And IBM
spokesmen have begun denying that the Virtual Machine (VM) product is
an internal prank gone awry.
/*
The problem I find when I'm looking at lines
Of programs all written in C
Is that the syntax and grammar resemble the stammer
Of a dyslexic demoralized bee.
I'll bet any man here (I'll wager a beer)
Can't guess how to copy a string.
The mess is dramatic, all [ ('[' = 'Open Square Bracket')
. & _ and ! ('.' = 'Dot' ; & = 'Ampersand')
('_' = 'underscore')
('!' = 'pling')
Pointers collected, and thrice indirected,
Collated in structs and compiled,
When traced by debugger can make coders shudder,
And conditionals drive a man wild.
I don't wish to seem bitchy, but if only old Ritchie
Had been strangled a birth by a Nurse;
And the fate that I've planned for all Kernighan's clan
Is unprintably several times worse.
I find that the pain begins with the main(),
The only way out is to hack it.
The one bit of syntax that keeps my mind intact
Is the very last } ('}' = 'curly brace')
I hope that this ode is clearer that code
I write in that monstrosity.
You might think that Pascal's a bit of a rascal,
But the ultimate b*d is C. ('*' = 'a star')
My program is calling (in structure appalling),
I must finish my poetic plea.
But, let's all face it, use Forth, LISP or BASIC,
Whatever you do, don't use C.
*/
(Translator's guide to pronunciation:
[ = open square bracket
. = dot
& = ampersand
_ = underscore
! = pling
} = close curly bracket
* = a star)
-- Rupert Goodwins
META Consulting Group Technical Note #2
by Martin E. Tabnik
last revision: 9 June 1993
Possibly no message since IBM's "Correct Error and Rerun Job" has been the subject of so much sarcastic comment and so many snide taglines as MicroSoft's "Press Any Key". There have been many stories of users frantically calling technical support staff demanding the location of the "ANY" key.
Experienced programmers find this message self-explanatory and obvious. However, the power and sophistication of MS-DOS compatible PCs is increasing almost as fast as their prices are decreasing. The result is that the PC is replacing the typewriter as the "second" office machine. (The telephone, of course, is the first.) Meanwhile, the average user's level of computer knowledge continues to drop as small business owners and their clerks replace programmers as the "typical" persons at the keyboard.
Finally, the price for a "complete office package" of a 486 with 4 megs of RAM memory, a 170 meg hard drive, software, a VGA monitor, a 101 key keyboard, a modem+FAX+Voice_mail board, and a floppy disk drive has broken through the $2000 barrier.
Today's $2000 computer system (often classified as "office equipment" by workers in large corporations in an attempt to avoid the embrace of the MIS Department) has more power than one that would have cost $2,000,000 only 25 years ago. So, is it surprising that potential clients are less willing to spend $50 and up for an hour of consulting time?
It is time for PC software industry to pull up its socks and make an effort to confound Bullwinkle cartoons' villain Boris Badenov
Fools proof, yes!
Idiots proof, no!
by making messages and documentation as failure-proof as possible.
As a first step, we should replace
Press Any Key
with
Press A key
Even if the user interprets the indefinite article as an adjective and presses the "A" key, he or she will still achieve the desired result.
Acknowledgement: META Consulting Group appreciates the assistance of
Ms. Ava Weintraub of The Write Stuff Catalog, 1-800-989-8833.
MS-DOS:
You would get in the car and try to remember where you put your keys.
Windows:
You get in the car and drive to the store very slowly, because attached to the back of your car is a freight train.
Macintosh System 7:
You get in the car to go to the store and the car drives you to church
UNIX:
You get in the car and type GREP STORE. After reaching speeds of 200 miles per hour en route, you arrive at the barber shop.
Windows NT:
You get in the car and write a letter that says, "go to store". Then you get out of the car and mail the letter to your dashboard.
OS/2:
After fueling up with 6000 gallons of gas, you get in the car and drive to the store with a motercycle escort and a marching band in procession. Halfway there, the car blows up, killing everbody in town.
S/36 SSP [mainframe, obv]: You get in the car and drive to the store. Halfway there you run out of gas. While walking the rest of the way, you are run over by kids on mopeds.