Programming Language Humor

There is many a programming language available on the market today but which is the best for you??? The following list should help you with your choice.

Selecting a Programming Language

bulletAssembler - A formula I race car. Very fast but difficult to drive and maintain.
bulletFORTRAN II - A Model T Ford. Once it was the king of the road.
bulletFORTRAN IV - A Model A Ford.
bulletFORTRAN 77 - a six-cylinder Ford Fairlane with standard transmission and no seat belts.
bulletCOBOL - A delivery van. It's bulky and ugly but it does the work.
bulletBASIC - A second-hand Rambler with a rebuilt engine and patched upholstery. Your dad bought it for you to learn to drive.  You'll ditch it as soon as you can afford a new one.
bulletPL/I - A Cadillac convertable with automatic transmission, a two-tone paint job, white-wall tires, chrome exhaust pipes, and fuzzy dice hanging in the windshield.
bulletC - A black Firebird, the all macho car. Comes with optional seatbelt (lint) and optional fuzz buster (escape to assembler).
bulletALGOL 60 - An Austin Mini. Boy that's a small car.
bulletPascal - A Volkswagon Beetle. It's small but sturdy. Was once popular with intellectual types.
bulletModula II - A Volkswagon Rabbit with a trailer hitch.
bulletALGOL 68 - An Aston Martin. An impressive car but not just anyone can drive it.
bulletLISP - An electric car. It's simple but slow. Seat belts are not available.
bulletPROLOG/LUCID - Prototype concept cars.
bulletMaple/MACSYMA - All-terrain vehicles.
bulletFORTH - A go-cart.
bulletLOGO - A kiddie's replica of a Rolls Royce. Comes with a real engine and a working horn.
bulletAPL - A double-decker bus. It takes rows and columns of passengers to the same place all at the same time but it drives only in reverse and is instrumented in Greek.
bulletAda - An army-green Mercedes-Benz staff car. Power steering, power brakes, and automatic transmission are standard.  No other colors or options are available. If it's good enough for generals, it's good enough for you.

Having Choosen you language Just how easy (or Not!!) is it to use??

For those of you who are still not satisfied try some of this.  These are Opcodes that can have a witty side. Some you have to think about though!!!

Computer OpCodes

T H E B E S T (IN MY HUMBLE OPINION)

MNEMONIC INSTRUCTION
APE Copy Previous Error
BAFL Branch And FLush
BLUSH Branch and .... Oops!
BOZO Branch On Zero Overflow
BPLPPL Branch PLease Pretty PLease
BTW Branch This Way (IBM-PC)
BTW By The Way (Unix)
BURP Botch Up (Recursively) Parity
CAIA Compare and Ignore Anyway
CROM Complement Read-Only Memory
DOD Divide On Divide
EIEIO Farm out operation [McDonald/IBM-PC]
ELF Enable Magic Process [Unix]
ELPR Enter Loop PRematurely
FOOT Bootstrap
GILA Get Imaginary Load Address
GIN Get Immediate Nibble [always ANDed with TONIC opcode]
GIRL Go Immediately to Register Load
IAPI Invalidate All Previous Instructions
ISORE Increment and Skip On REcursion
JA Jump Anyway
LPIO Light Pen Ink Overflow
LPRCHN Enable Magic Number [Irish PC]
PEPSI Pause Execution on Parity Set Immediate
RECUR Recurse to here
SALMN SpAwn new process
SEXIER Set EXtended IntERrupt
TONIC Turn ON Illogical Character [always ANDed with GIN opcode]
TPDA Triple Pack Decimal Adjust
TWEEP Terminate process With ExtrEme Prejudice
TWEP Terminate process With Extreme Prejudice
VACUUM Verify All blonde operators
WAFFLE Enable comms port

S E C O N D B E S T

MNEMONIC INSTRUCTION
ABAR Add Bits At Random
APCR Advance Program Counter Rudely
BCBF Branch on Chip box Full
BLED Blink LED
BOSC Branch on Second Coming
BPOFF Branch on Power Off
BRAS Branch and Suspend
BTDI Branch to Data Immediate
CURD Cook User's Raw Data
DEBAR Delete Extended Bits At Random
DOI Divide and Overflow [IBM PC]
DRB Drop Random Bits
DUMMY Suck operand
EABB Edit and Blank Buffer
EPSI Execute Program SIdeways
ETM Emulate Ternary Machine
GRAB Generate Random Access Bugs
KBB Kick Bit Bucket
LAWYER Load Accumulator With Yet another Error
MALP Multiply and Lose Precision
OSIN Overflow Stack INdefinite
PODD Print Only Double-Dutch
POT Cook in bit-bucket
RAMBO Read Ambiguous Memory BlOck
RDOB Read and Drop Odd number of Bits
ROSU Return On Shield Up
SUSS Subtract Until Senseless
SWAN SWAp Nibbles
WILL Write ILLegibly

M O S T A R E P R E T T Y G O O D

MNEMONIC INSTRUCTION
AMAM Add Mayo and Mustard
BFAB Belch Fire and Brimstone
BLT Bacon, Lettuce & Tomato
BOHO Branch on High Operator
BOND Binary Operator No Divide
BOOD Branch on Operator Desperate
BYAM Between You And Me
CPUMD CPU Melt Down
CREAM CREAte Memory
CRON Convert to Roman Numerals
EDAD Eat Disk and Die
EDRAD Emit Deadly Radiation
EFUD Emulate Frisbee Using Disk-pack
EMF EMulate 407
LAPD Laugh At Police Department
LAPM Laugh At Programmer
MBUGTD Mount Beatles on Tape Drive
MULR Multiply and Lose Record
OMTC Obscene Message to Console
PAROT PARity Overflow Transfer
PICH Print Illegible Characters
PSRIB Print and Shred Ribbon
RABT Rewind and Break Tape
RCLOB Run Clock Backwards
RDBL Replace Database with Blanks
REDI Rewind Disk Immediate
RLAC Relocate and Lose Core
RMF Ruin My files
ROMULUS Useless Roman Numeral
RPAB Reverse Parity and Branch
RPABL Read Print and Blush
SADD Seek and Destroy Data
SASC Show Appendix SCar
SAXS Show Appendix Scar
SESP Seek SPindle
SHC Shred Cards
SOOL Shit Out Of Luck
SORBET StOp and fizzle
STT Skip on Third Tuesday
SULP Solve UnsoLvable Problem
TOOO Toggle Operator On/Off
TTOL Time TO Logoff
UPM Understand Program[mer]
WINE Wait INdefinitely Extended
XXMP eXecute Miss Piggy

Now that you have chosen your language you need to know something about "REAL" Software engineers.

REAL SOFTWARE ENGINEERS DON'T READ DUMPS

bulletReal software engineers don't read dumps. They never generate them, and on the rare occasions that they come across them, they are vaguely amused.
bulletReal software engineers don't comment their code. The identifiers are so mnemonic they don't have to.
bulletReal software engineers don't write applications programs, they implement algorithms. If someone has an application that the algorithm might help with, that's nice. Don't ask them to write the user interface, though.
bulletReal software engineers don't eat quiche. If it doesn't have recursive function calls, Real software engineers don't program in it.
bulletReal software engineers don't program in assembler. They become queasy at the very thought.
bulletReal software engineers don't debug programs, they verify correctness.  This process doesn't necessarily involve executing anything on a computer, except perhaps a Correctness Verification Aid package.
bulletReal software engineers like C's structured constructs, but they are suspicious of it because they have heard that it lets you get "close to the machine."
bulletReal software engineers play tennis. In general, they don't like any sport that involves getting hot and sweaty and gross when out of range of a shower. (Thus mountain climbing is Right Out.) They will occasionally wear their tennis togs to work, but only on very sunny days.
bulletReal software engineers admire PASCAL for its discipline and Spartan purity, but they find it difficult to actually program in. They don't tell this to their friends, because they are afraid it means that they are somehow Unworthy.
bulletReal software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure.
bulletReal software engineers write in languages that have not actually been implemented for any machine, and for which only the formal spec (in BNF) is available. This keeps them from having to take any machine dependencies into account. Machine dependencies make real software engineers very uneasy.
bulletReal software engineers don't write in ADA, because the standards bodies have not quite decided on a formal spec yet.
bulletReal software engineers like writing their own compilers, preferably in PROLOG (they also like writing them in unimplemented languages, but it turns out to be difficult to actually RUN these).
bulletReal software engineers regret the existence of COBOL, FORTRAN and BASIC. PL/I is getting there, but it is not nearly disciplined enough; far too much built in function.
bulletReal software engineers aren't too happy about the existence of users, either. Users always seem to have the wrong idea about what the implementation and verification of algorithms is all about.
bulletReal software engineers don't like the idea of some inexplicable and greasy hardware several aisles away that may stop working at any moment. They have a great distrust of hardware people, and wish that systems could be virtual at ALL levels. They would like personal computers (you know no one's going to trip over something and kill your DFA in mid-transit), except that they need 8 megabytes to run their Correctness Verification Aid packages.
bulletReal software engineers think better while playing WIFF 'N' PROOF.

Lesser-Known Programming Languages

The Lesser-known Programming Languages #10: SIMPLE

SIMPLE is an acronym for Sheer Idiot's Monopurpose Programming Language Environment. This language, developed at the Hanover College for Technological Misfits, was designed to make it impossible to write code with errors in it. The statements are, therefore, confined to BEGIN, END and STOP. No matter how you arrange the statements, you can't make a syntax error. Programs written in SIMPLE do nothing useful. Thus they achieve the results of programs written in other languages without the tedious, frustrating process of testing and debugging.

The Lesser-known Programming Languages #12: LITHP

This otherwise unremarkable language is distinguished by the absence of an "S" in its character set; users must substitute "TH". LITHP is said to be useful in protheththing lithtth.

The Lesser-known Programming Languages #13: SLOBOL

SLOBOL is best known for the speed, or lack of it, of its compiler. Although many compilers allow you to take a coffee break while they compile, SLOBOL compilers allow you to travel to Bolivia to pick the coffee. Forty-three programmers are known to have died of boredom sitting at their terminals while waiting for a SLOBOL program to compile. Weary SLOBOL programmers often turn to a related (but infinitely faster) language, COCAINE.

The Lesser-known Programming Languages #17: SARTRE

Named after the late existential philosopher, SARTRE is an extremely unstructured language. Statements in SARTRE have no purpose; they just are. Thus SARTRE programs are left to define their own functions. SARTRE programmers tend to be boring and depressed, and are no fun at parties.

The Lesser-known Programming Languages #18: C-

This language was named for the grade received by its creator when he submitted it as a class project in a graduate programming class. C- is best described as a "low-level" programming language. In fact, the language generally requires more C- statements than machine-code statements to execute a given task. In this respect, it is very similar to COBOL.

The Lesser-known Programming Languages #18: FIFTH

FIFTH is a precision mathematical language in which the data types refer to quantity. The data types range from CC, OUNCE, SHOT, and JIGGER to FIFTH (hence the name of the language), LITER, MAGNUM and BLOTTO. Commands refer to ingredients such as CHABLIS, CHARDONNAY, CABERNET, GIN, VERMOUTH, VODKA, SCOTCH, and WHATEVERSAROUND. The many versions of the FIFTH language reflect the sophistication and financial status of its users. Commands in the ELITE dialect include VSOP and LAFITE, while commands in the GUTTER dialect include HOOTCH and RIPPLE. The latter is a favorite of frustrated FORTH programmers who end up using this language.

Submited By Stsai@huse.havard.edu

This one was passed on to me by a friend of mine. He doesn't remember where it came from.

Warning: This list may be offensive to ardent feminists.

PROGRAMMING LANGUAGES ARE LIKE WOMEN

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.

bulletAssembler - 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 a fierce and violent temper that make her the choice of last resort.
bulletFORTRAN - 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.
bulletCOBOL - 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.
bulletBASIC - 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.
bulletPL/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.
bulletC - 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.
bulletALGOL 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.
bulletPascal - 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).
bulletModula 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.
bulletALGOL 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.
bulletLISP - 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.
bulletAPL - 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.
bulletLOGO - 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.
bulletLUCID & 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.
bulletAda - 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.

Top 25 Explanations by Programmers

  1. Strange...
  2. I've never heard about that.
  3. It did work yesterday.
  4. Well, the program needs some fixing.
  5. How is this possible?
  6. The machine seems to be broken.
  7. Has the operating system been updated?
  8. The user has made an error again.
  9. There is something wrong in your test data.
  10. I have not touched that module!
  11. Yes yes, it will be ready in time.
  12. You must have the wrong executable.
  13. Oh, it's just a feature.
  14. I'm almost ready.
  15. Of course, I just have to do these small fixes.
  16. It will be done in no time at all.
  17. It's just some unlucky coincidence.
  18. I can't test everything!
  19. THIS can't do THAT.
  20. Didn't I fix it already?
  21. It's already there, but it has not been tested.
  22. It works, but it's not been tested.
  23. Somebody must have changed my code.
  24. There must be a virus in the application software.
  25. Even though it does not work, how does it feel?

Q: How many Windows programmers does it take to change a light bulb?

A: 472. One to write WinGetLightBulbHandle,  one to write WinQueryStatusLightBulb,   one to write WinGetLightSwitchHandle,  etc.

Q: How many C++ programmers does it take to change a light bulb?

A: You're still thinking procedurally. A properly designed light  bulb object will inherit a change method from a generic light  bulb class, so all you'd have to do is send a light bulb change

The Twelve Bugs of Christmas

when the first bug appeared, my manager said to me:

  1. see if it happens again.

when the second bug appeared, my manager said to me

  1. ask them how they did it,
  2. see if it happens again.

when the third bug appeared, my manager said to me

  1. try to reproduce it,
  2. ask them how they did it,
  3. see if it happens again.

when the fourth bug appeared, my manager said to me

  1. use a debugger,
  2. try to reproduce it,
  3. ask them how they did it,
  4. see if it happens again.

when the fifth bug appeared, my manager said to me

  1. ask for a dump,
  2. use a debugger,
  3. try to reproduce it,
  4. ask them how they did it,
  5. see if it happens again.

when the sixth bug appeared, my manager said to me

  1. reinstall the software,
  2. ask for a dump,
  3. use a debugger,
  4. try to reproduce it,
  5. ask them how they did it,
  6. see if it happens again.

when the seventh bug appeared, my manager said to me

  1. say they need an upgrade,
  2. reinstall the software,
  3. ask for a dump,
  4. use a debugger,
  5. try to reproduce it,
  6. ask them how they did it,
  7. see if it happens again.

when the eighth bug appeared, my manager said to me

  1. find a way around it,
  2. say they need an upgrade,
  3. reinstall the software,
  4. ask for a dump,
  5. use a debugger,
  6. try to reproduce it,
  7. ask them how they did it,
  8. see if it happens again.

when the ninth bug appeared, my manager said to me

  1. blame it on the hardware,
  2. find a way around it,
  3. say they need an upgrade,
  4. reinstall the software,
  5. ask for a dump,
  6. use a debugger,
  7. try to reproduce it,
  8. ask them how they did it,
  9. see if it happens again.

when the tenth bug appeared, my manager said to me

  1. change the documentation,
  2. blame it on the hardware,
  3. find a way around it,
  4. say they need an upgrade,
  5. reinstall the software,
  6. ask for a dump,
  7. use a debugger,
  8. try to reproduce it,
  9. ask them how they did it,
  10. see if it happens again.

when the eleventh bug appeared, my manager said to me

  1. say it's not supported,
  2. change the documentation,
  3. blame it on the hardware,
  4. find a way around it,
  5. say they need an upgrade,
  6. reinstall the software,
  7. ask for a dump,
  8. use a debugger,
  9. try to reproduce it,
  10. ask them how they did it,
  11. see if it happens again.

when the twelfth bug appeared, my manager said to me

  1. tell them its a feature,
  2. say it's not supported,
  3. change the documentation,
  4. blame it on the hardware,
  5. find a way around it,
  6. say they need an upgrade,
  7. reinstall the software,
  8. ask for a dump,
  9. use a debugger,
  10. try to reproduce it,
  11. ask them how they did it,
  12. see if it happens again.

ZEN AND THE ART OF SOFTWARE DOCUMENTATION

(Translated from the P'-u-t'ung hua dialect by W.C.Carlson)

Editor's Note: The following are excerpts from the only known treatise on Zen Software Documentation. Called "H'ring-chu-tsu", which literally translates to "Ink of Several Insignificant Matters", this treatise was written in 12th Century Japan by the scholarly monk E'm-ie-T'. That it discusses Software documentation -- predating the advent of software by 850 years -- is but another of the mysteries of those who walk the true path.)

This article should be read twice.

On Preparing to Write of Software

To prepare for the writing of Software, the writer must first become one with it, sometimes two. Software is untasteable, opalescent, transparent; the user sees not the software, so the writer must see through it. Spend long, quiet mornings in meditation. Do not sharpen the mind, but rather blunt it by doing Zen crosswords.

(Ed. note: Zen crosswords are done by consulting only the "Down" clues; and always in the mind, never on paper.)

The mind should be rooted but flexible, as a long stemmed flower faces the Sun yet bends with the Wind. Think not of compound adjectives because they tend to wire the mind in two directions. Rather, consider the snowflake, which radiates in beauty in any and all directions.

Partake of strong drink.

Do not study the Software; let it study you. Allow the Software admission to your mind, but keep in the cheap seats. Let it flow around you at its own pace. Do not disturb or dismay it, but keep it from your private parts because it tends to coalesce there.

When the Software is with you, you will know it. It will lead your mind where it should be, and prepare you for the narcolepsy that is cert ain to follow. You will know when the Software is with you, and so will others. You will smile with an inner smile. Typewriters will frighten you. You will fall down a lot.

The first exercise in writing Software documentation is the Haiku.

Haiku are 17 syllable poem forms in which many ideas of a single concept are reduced -- nay, distilled -- into a short, impressionistic poem.

For example, the Haiku for preparing to write of Software goes:

Emptiness on paper;
Fleeting thought.
Red Sox play at Fenway's
Green Park.

By concentrating on the Softwares form and function in a concise, subliminal, truly meaningless Haiku verse, you have transcended the Software, and you can then write the true manual.

The following Haiku is from a Zen manual on Data Transmission:

How swiftly whirls the disk;
Data leaps to the floating head
And is known.

And this is on Hardware Maintenance:

The smell of hot P.C. card,
Blank screen, no bell,
New parts will be needed.

And another Haiku, this one on Debugging:

All the lights are frozen;
The cursor blinks blandly.
Soon, I shall see the dump.

Let the Haiku thoughts free your mind from your fingers. Your fingers will write what must be written. Soon you will be in Doc. Prep.

On the Review Cycle

This is the murkiest path. Storms gather and disperse around you many directions, none of which are in English. The path becomes unclear as many an idea compete for attention. Some of them are fatal.

But the writer of Zen Software documentation fears not the turbulence of review cycles. Let it storm around you and be dry, warm, and safe in the knowledge that you have written the pure manual.

Anyway, you know the printer. You shall in the end have it your way.

Computer Language Breakthrough

By John R. Andrews, University of Illinois at Chicago.

Bell Laboratories has formally announced what it believes is the ultimate computer science language. Described by Iusi Nogoto, the foremost Japanese fourth generation language expert, as "the only truly elegant computer language ever devised." NULL, as it is known, was developed by the same department that originally invented the wrong number, the busy signal, and the phrase, "The number you have reached is not in service." NULL is the culmination of five years of work by a team of language designers and computer science mathematicians. The final breakthrough occurred when operating system expert

Hugh Nicks suggested that if removing GO TO"s was good then why not scrap IF statements as well, since they usually required typing too many characters anyway. This brilliant concept was extended through a series of complex mathematical theorems that form the basis of the NULL language. Put in layman"s terms by Sally Kahn-Vallee, electrical engineer and PROM reader, "Like we first we tossed out the bath water, then the baby, and like finally the whole tub." The elegance and conciseness of NULL can thus be proven to be a direct consequence of the fact that the language as defined contains no statements at all. While at first glance this may seem a drawback, in fact, it is a major improvement over any other language. A few of the numerous reasons are:

  1. Highly structured constructs.
  2. Advanced data hiding techniques.
  3. A NULL compiler can be written first in NULL with out ever needing to be written in a lower level language.
  4. Since there are no statements to compile, in fact, no compiler need ever be written in the first place, saving time and money.
  5. Since there will be no compilers, no new releases will ever be issued hence maintenance is reduced.
  6. NULL programs are highly portable and totally machine independent.
  7. NULL programs compile and execute rapidly. An important point to note is that with the addition of a small amount of language dependent code, e.g. PROC/END etc., all NULL programs can be compiled by any other language compiler.
  8. Since there will never be new releases of NULL, all programs are upwardly and downwardly compatible.
  9. NULL can be parsed top-down, bottom-up, left-right, right-left, inside-out, and over-easy.
  10. NULL programs are both self-documenting for clarity and self-concealing for security.
  11. NULL programmers are easy to find and once found can be fired since they are not needed.
  12. If desired, specialized NULL hardware could be designed implementing the code in firmware. Of course, such hardware may require years of development.

One suggestion from Bell"s VLSI experts Nora and Andy Gates was to take an existing available chip and remove all the instructions except NOP. While this should work in theory, they acknowledged that it is probably not the most efficient implementation.

These are just a few of the many ways NULL is superior to all current computer languages. You can, no doubt, think of more. For further reading consult any of the numerous books and articles by Donald Knuth, David Parnas, and of course, the basis of all modern computer language theory, "The Emperor"s New Clothes."

Real Computer Scientists Don't Write Code

By David Houk

bulletReal computer scientists don't write code. They occasionally tinker with 'programming systems', but those are so high level that they hardly count (and rarely count accurately; precision is for applications.)
bulletReal computer scientists don't comment their code. The identifiers are so long they can't afford the disk space.
bulletReal computer scientists don't write the user interfaces, they merely argue over what they should look like.
bulletReal computer scientists don't eat quiche. They shun Schezuan food since the hackers discovered it. Many Real computer scientists consider eating an implementation detail. (Others break down and eat with the hackers, but only if they can have ice cream for desert.)
bulletIf it doesn't have a programming environment complete with interactive debugger, structure editor and extensive cross module type checking, Real computer scientists won't be seen tinkering with it. They may have to use it to balance their checkbooks, as their own systems can't.
bulletReal computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
bulletReal computer scientists don't debug programs, they dynamically modify them. This is safer, since no one has invented a way to do anything dynamic to FORTRAN, COBOL or BASIC.
bulletReal computer scientists like C's structured constructs, but they are suspicious of it because its compiled. (Only Batch freaks and efficiency weirdos bother with compilers, they're soooo un-dynamic.)
bulletReal computer scientists play go. They have nothing against the concept of mountain climbing, but the actual climbing is an implementation detail best left to programmers.
bulletReal computer scientists admire ADA for its overwhelming aesthetic value, but they find it difficult to actually program in, as it is much too large to implement. Most Computer scientists don't notice this because they are still arguing over what else to add to ADA.
bulletReal computer scientists work from 5 pm to 9 am because that's the only time they can get the 8 megabytes of main memory they need to edit specs. (Real work starts around 2 am when enough MIPS are free for their dynamic systems.) Real computer scientists find it hard to share 3081s when they are doing 'REAL' work.
bulletReal computer scientists only write specs for languages that might run on future hardware. Nobody trusts them to write specs for anything homo sapiens will ever be able to fit on a single planet.
bulletReal computer scientists like planning their own environments to use bit mapped graphics. Bit mapped graphics is great because no one can afford it, so their systems can be experimental.
bulletReal computer scientists regret the existence of PL/I, PASCAL and LISP. ADA is getting there, but it is still allows people to make mistakes.
bulletReal computer scientists love the concept of users. Users are always real impressed by the stuff computer scientists are talking about; it sure sounds better than the stuff they are being forced to use now.
bulletReal computer scientists despise the idea of actual hardware. Hardware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O.
bulletReal computer scientists love conventions. No one is expected to lug a 3081 attached to a bit map screen to a convention, so no one will ever know how slow their systems run.

THE TEN COMMANDMENTS FOR C PROGRAMMERS

By Henry Spencer

  1. Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine.
  2. Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
  3. Thou shalt cast all function arguments to the expected type if they are not of that type already, even when thou art convinced that this is unnecessary, lest they take cruel vengeance upon thee when thou least expect it.
  4. If thy header files fail to declare the return types of thy library functions, thou shalt declare them thyself with the most meticulous care, lest grievous harm befall thy program.
  5. Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
  6. If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance.
  7. Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive.
  8. Thou shalt make thy program's purpose and structure clear to thy fellow man by using the One True Brace Style, even if thou likest it not, for thy creativity is better used in solving problems than in creating beautiful new impediments to understanding.
  9. Thy external identifiers shall be unique in the first six characters, though this harsh discipline be irksome and the years of its necessity stretch before thee seemingly without end, lest thou tear thy hair out and go mad on that fateful day when thou desirest to make thy program run on an old system.
  10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short.

1997-2000 as named above. Last update: Saturday, November 02, 2002