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

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)

S E C O N D B E S T

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

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

REAL SOFTWARE ENGINEERS DON'T READ DUMPS

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.

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

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