PROGRAMMING LAZINESS, IMPATIENCE, AND HUBRIS

According to Larry Wall( 1 ), the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.

Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.

Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

(1) Quoted from "Programming Perl", 2nd Edition, O'Reilly & Associates, 1996

In case you’ve ever wondered why ignorance rises to the executive level, here is a simple explanation that is also mathematical proof.

Knowledge is Power
Time is Money

and, as every engineer knows:

Power  = Work
--------
Time

If Knowledge = Power, and Time = Money, then:

Knowledge  = Work
--------
Money

Solving for Money, we get:

Money  = Work
--------
Knowledge

Thus as Money approaches infinity and
as Knowledge approaches zero, regardless of the Work done.

What this means is:

The Less you Know, the More you Make.


These acronyms are used by professionals
Please memorize and use when speaking to an IT professional.

ISDN — It Still Does Nothing
APPLE — Arrogance Produces Profit-Losing Entity
SCSI — System Can’t See It

DOS — Defective Operating System
BASIC — Bill’s Attempt to Seize Industry Control
IBM — I Blame Microsoft

DEC — Do Expect Cuts
CD-ROM — Consumer Device, Rendered Obsolete Monthly
OS/2 — Obsolete Soon, Too

WWW — World Wide Wait
MACINTOSH — Most Applications Crash; If Not, The Operating System Hang
PENTIUM — Produces Erroneous Numbers Through Incorrect Understanding of Math

COBOL — Completely Obsolete Business Oriented Language
AMIGA — A Merely Insignificant Game Addiction
LISP — Let’s Insert Some Parentheses

MIPS — Meaningless Indication of Processor Speed
WINDOWS — Will Install Needless Data On Whole System
MICROSOFT — Most Intelligent Customers Realize Our Software Only Fools Teenagers
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.  

ASSEMBLER — A formula I race car.  Very fast but difficult to drive and maintain.  

FORTRAN  II — A Model T Ford.  Once it was the 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 upholstery.  Your dad bought it for you to learn to drive.  You’ll ditch it 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 seatbelt (lint) and optional fuzz buster (escape to assembler).  

PASCAL — A Volkswagen Beetle.  It’s small but sturdy.  Was once popular with intellectual types.  

MODULA 2 — A Volkswagen Rabbit with a trailer hitch.  

ALGOL 60 — An Austin Mini.  Boy that’s a small car.  

ALGOL  68 — An Aston 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.  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.  

ADA — 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 Chosen you language Just how easy (or Not!!) is it to use??
TASK :- To Shoot Yourself In The Foot
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!!!

C — You shoot yourself in the foot.  

C++ — You accidentally 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 with the attempts to shoot yourself any ways because you have no exception-handling capability.  

PASCAL — The compiler won’t let you shoot yourself in the foot.  

ADA — After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot.  When you try, however, you discover you can’t because your foot is of the wrong type.  

COBOL — Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE.  THEN return HANDGUN to HOLSTER.  CHECK whether shoelace needs to be re-tied.  

LISP — You shoot yourself in the appendage which holds the gun with which
You shoot yourself in the appendage which holds the gun with which
You shoot yourself in the appendage which holds the gun with which
You shoot yourself in the appendage which holds the gun with which
You shoot yourself in the appendage which holds the gun with which
You shoot yourself in the appendage which holds.  .  .  

FORTH — Foot in yourself shoot.  

PROLOG — You tell your program that you want to be shot in the foot.  The program figures out how to do it, but the syntax doesn’t permit it to explain it to you.  

BASIC — Shoot yourself in the foot with a water pistol.  On large systems, continue until entire lower body is waterlogged.  

VISUAL BASIC — You’ll really only_appear_to have shot yourself in the foot, but you’ll have had so much fun doing it that you won’t care.  

HYPERTALK — Put the first bullet of gun into foot left of leg of you.  Answer the result.  

MOTIF — You spend days writing a UIL description of your foot, the bullet, its trajectory, and the intricate scroll work on the ivory handles of the gun.  When you finally get around to pulling the trigger, the gun jams.  

APL — You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.  

SNOBOL — If you succeed, shoot yourself in the left foot.  If you fail, shoot yourself in the right foot.  

UNIX % ls —
foot.c   foot.h  foot.o   toe.c   toe.o
%   rm   *.o
rm:  .o  no  such  file  or  directory
%  ls
%

CONCURRENT EUCLID — You shoot yourself in somebody else’s foot.  

370 JCL — You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot.  Three years later, your foot comes back deep-fried.  

PARADOX — Not only can you shoot yourself in the foot, your users can, too.  

MS-ACCESS — You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.  

REVELATION — You’re sure you’re going to be able to shoot yourself in the foot, just as soon as you figure out what all these nifty little bullet-thingies are for.  

ASSEMBLER — You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.  

MODULA2 — After realizing that you can’t actually accomplish anything in this language, you shoot yourself in the head.  

VMS: — $ MOUNT/DENSITY  =  .45/LABEL  =  BULLET/MESSAGE  =  "BYE" BULLET::BULLET$GUN SYS$BULLET
$ SET GUN/LOAD/SAFETY  =  OFF/SIGHT  =  NONE/HAND  =  LEFT/CHAMBER  =  1/ACTION  =  AUTOMATIC/LOG/ALL/FULL SYS$GUN_3$DUA3:[000000]GUN.GNU
$ SHOOT/LOG/AUTO SYS$GUN SYS$SYSTEM:[FOOT]FOOT.FOOT

%DCL-W-ACTIMAGE, error activating image GUN
-CLI-E-IMGNAME, image file $3$DUA240:[GUN]GUN.EXE;1
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha AXP image
oh well, almost. . .


FORTH — Foot in yourself shoot.  
self dup  >  foot shoot
T H E     B E S T
(IN MY HUMBLE OPINION)

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

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

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.  They never generate them, and on the rare occasions that they come across them, they are vaguely amused.  

REAL SOFTWARE ENGINEERS don’t comment their code.  The identifiers are so mnemonic they don’t have to.  

REAL 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.  

REAL SOFTWARE ENGINEERS don’t eat quiche.  If it doesn’t have recursive function calls, real software engineers don’t program in it.  

REAL SOFTWARE ENGINEERS don’t program in assembler.  They become queasy at the very thought.  

REAL 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.  

REAL 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.  "

REAL 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.  

REAL 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.  

REAL 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.  

REAL 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.  

REAL SOFTWARE ENGINEERS don’t write in ADA, because the standards bodies have not quite decided on a formal spec yet.  

REAL 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).  

REAL 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.  

REAL 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.  

REAL 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.  

REAL SOFTWARE ENGINEERS think better while playing WIFF ’N’ PROOF.  

REAL SOFTWARE ENGINEERS 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.  )

REAL SOFTWARE ENGINEERS don’t comment their code.  The identifiers are so long they can’t afford the disk space.  

REAL SOFTWARE ENGINEERS don’t write the user interfaces, they merely argue over what they should look like.  

REAL SOFTWARE ENGINEERS 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.  )

REAL SOFTWARE ENGINEERS don’t consider it a REAL environment if 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.  

REAL SOFTWARE ENGINEERS don’t program in assembler.  They don’t write in anything less portable than a number two pencil.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS 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.  )

REAL SOFTWARE ENGINEERS play go.  They have nothing against the concept of mountain climbing, but the actual climbing is an implementation detail best left to programmers.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS 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 SOFTWARE ENGINEERS find it hard to share 3081s when they are doing ’REAL’ work.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS regret the existence of PL/I, PASCAL and LISP.  ADA is getting there, but it is still allows people to make mistakes.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS 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.  

REAL SOFTWARE ENGINEERS 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 Lesser-known Programming Languages

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.  

LITHP &mdsah; 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.  

SLOBOL &mdsah;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.  

SARTRE &mdsah; 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.  

C- &mdsah; 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.  

FIFTH &mdsah; FIFTH is a precision mathematical language in which the data types refer to quantity.  The data types range from CC, OUNCE, SHOT, andJIGGER 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.  

Submitted By Stsai@huse.havard.edu
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.  

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 Software 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.  
by: Daniel J.  Salomon Department of Computer Science, University of Waterloo Waterloo, Ontario, Canada N2L 3G1

Warning:  This list may be offensive to ardent feminists or anyone who actually likes females.  

{  Ed: This is similar to another item Dan co-wrote, comparing programming languages to cars.  The one with the cars is superior.  It appears in Volume I of the TeleJokeBook series.  }

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 a fierce 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.  
Strange.

I’ve never heard about that.  

It did work yesterday.  

Well, the program needs some fixing.  

How is this possible?

The machine seems to be broken.  

Has the operating system been updated?

The user has made an error again.  

There is something wrong in your test data.  

I have not touched that module!

Yes, it will be ready in time.  

You must have the wrong executable.  

Oh, it’s just a feature.  

I’m almost ready.  

Of course, I just have to do these small fixes.  

It will be done in no time at all.  

It’s just some unlucky coincidence.  

I can’t test everything!

THIS can’t do THAT.  

Didn’t I fix it already?

It’s already there, but it has not been tested.  

It works, but it’s not been tested.  

Somebody must have changed my code.  

There must be a virus in the application software.  

Even though it does not work, how does it feel?
Bell Laboratories has formally announced what it believes is the ultimate computer science language.  Described by Lusi 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 TOs 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 seriesof 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 without 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 Noraand Andy Gates was to take an existing available chip and remove allthe instructions except NOP.  While this should work in theory,they acknowledgedthat it is probably not the most efficient implementation.  
These are just a few of the manyways 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."
Q: How many Windows programmers does it take to change a light bulb?
A: One to write WinGetLightBulbHandle,
One to write WinQueryStatusLightBulb,
One to write WinGetLightSwitchHandle,
One to 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 Ten Commandments For C Programmers
  1. when the first bug appeared, my manager said to me
    see if it happens again.  
  2. when the second bug appeared, my manager said to me
    ask them how they did it,
    see if it happens again.  
  3. when the third bug appeared, my manager said to me
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  4. when the fourth bug appeared, my manager said to me
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  5. when the fifth bug appeared, my manager said to me
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  6. when the sixth bug appeared, my manager said to me
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  7. when the seventh bug appeared, my manager said to me
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  8. when the eighth bug appeared, my manager said to me
    find a way around it,
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  9. when the ninth bug appeared, my manager said to me
    blame it on the hardware,
    find a way around it,
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  10. when the tenth bug appeared, my manager said to me
    change the documentation,
    blame it on the hardware,
    find a way around it,
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  11. when the eleventh bug appeared, my manager said to me
    say its not supported,
    change the documentation,
    blame it on the hardware,
    find a way around it,
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  12. when the twelfth bug appeared, my manager said to me
    tell them it’s a feature,
    say its not supported,
    change the documentation,
    blame it on the hardware,
    find a way around it,
    say they need an upgrade,
    reinstall the software,
    ask for a dump,
    use a debugger,
    try to reproduce it,
    ask them how they did it,
    see if it happens again.  
  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.
  1. Anything not specifically permitted is prohibited.
  2. Anything not specifically prohibited is mandatory.
  3. Anything described as optional is either prohibited or mandatory, depending on the context in which it is used.
  4. Variables are more or less constant.
  5. Constants are subject to variation, more or less.
  6. Coincidence between the manual’s description of a command’s operation and the system’s response is just that, coincidence.
  7. The description of any UNIX command includes the "except when..." clause, except when the command is optionally mandatory or conditionally permissible.
  8. In some cases UNIX is redundant.
  9. If everything seems to be going well, you* have obviously overlooked something.
    * Don’t take the "you" in this expression personally. It refers to some hapless programmer, not an intelligent and informed person like yourself.
  10. Early on you learn to cope.
©  SEKHAR CHINTALAPATI
Office /  Home:
236 Flour Daniel Building 807 College Avenue, Apt #24
Mechanical Engineering Department Clemson, SC 29631
Clemson University, Clemson Tel: (864)653-4785
South Carolina, 29634-0921 E-mail: schinta@eng.clemson.edu
Tel: (864)656-0482

This is the Canonical List Of Programming Language Humor.  It has been compiled with the assistance of a lot of people but a special thanks goes to Prof P.  Piacenza ( chpp@unitrix.utr.ac.za ) who contributed a great deal of jokes etc to this list.  

Any submissions should be sent to :- N.Thomson@bcs.org.uk where they will be added to the list and the submitter will get a personal copy of the list.  Any requests for copies of this list sent to the above addressee will be cheerfully ignored.  If you are reading this then you have a copy in front of you.  If your joke is more suited to any of the other lists then it will be placed there.  

This file can be FTPed from FTP.CCO.CALTECH.EDU in the directory /pub/humor/canonical.list - login as anonymous and enter E-Mail address as password.  

Ok enough of the boring stuff - enjoy.  .  .  .  .  .  .  .  .  .  .  .  .  

Disclaimer

David M Friscia does not warrants the accuracy, reliability or timeliness of any information and shall not be liable for any losses caused by such reliance on the accuracy, reliability, or timeliness of such information. Portions of such information may be incorrect or not current. Any person or entity who relies on any information obtained from the System does so at his or her own risk.

Questions or comments, email mailto dave@dmfriscia.info