More Languages Humour

Quick Reference

• Not the comp.lang.functional FAQ
• Revised Foot distinctions
• Tenne-C
• Old Cobol Programmers
• NULL Language
• Java Hints

Not the comp.lang.functional FAQ

What is the origin of Functional Languages (FLs)?

The basic idea of a FL is that instead of implementing the language, you implement the semantics of that language. This leads to a language with an exceptionally well defined semantics.

I am writing a simple editor in C/Pascal. Someone told me that FL programs are better, because you can prove the correctness of your program. Should I port my program to a FL?

Yes, that's a very good Idea. Proving the correctness of a FL program takes less time than running it, so don't let anyone convince you that proving program correctness is too complex.

Someone told me I can't do memory management in FL. Is that true?

Memory? Ever seen Bits 'n' Bytes in the Truly Beatiful Real World of Plato? If you want to work with memory, go back to earth and buy a C compiler. Don't bother us with such obscene questions.

But can I write an operating system in a FL?

Yes, you can. It's actually done twice. The fist one who did it is now locked up in a room with padded walls, the second one is still alive and kicking. Rumours has it that the latter built a C compiler in a FL and then recompiled UNIX sources. The compiler is still working on it, but hasn't given an error message yet, so there's still hope.

Why can't I have globals in an FL. I JUST NEED THEM!

You are in a very serious condition. Globals are the Root of All Evil, and it is obvious from your question that you are hooked to them. For addicts like you, monads were invented, enabling people to have globals without violating the Holy Principles of Functional Programming.

But if I use these monads, can't I simply use Pascal instead?

tsk, tsk, tsk!

What is "lazy" evaluation?

Lazy evaluation is one of the most expensive evaluation strategies information scientists have ever invented.

Why is it so expensive?

Because a lazy evaluator spends almost all its time trying to find things it doesn't have to do.

Then why is it called lazy?

Because under optimal conditions (e.g. an opposition between the planets Venus and Mercury, provided it's full moon) it has been reported that a lazy evaluator actually found a subexpression that did not need to be evaluated.

How do you call a FL that's not Lazy?

Dirty.

Is LISP a FL?

There are reliable sources reporting that useful programs have been written in LISP. The answer therefore is: NO, LISP IS NOT AN FL.

Scheme then?

Scheme has globals. The Fundamental Rule of Language Evaluation is: "If a language has an impure feature, the language itself is impure." So the fact that you can do FL-like programming in Scheme is totally irrelevant.

How many production applications have already been written in FLs?

2

All those FL's are very similar. Is that a coincidence?

No, it's not. They are basically dialects of the same language. The point at which they differ is how they avoid the obscene code you end up with when trying to program directly in the Lambda Calculus.

Then why are FL programmers having language-wars from time to time?

For the same reason Protestants have more trouble with Catholics than with Muslims.

Can't FLs run faster when executed in parallel?

Yes, but they can't run as fast as a non-FLs excecuted in parallel. Sorry.

Can I become a FL programmer myself?

Yes, by meditating your ass off and showing respect for your masters, you might reach this superior state, er.. denote this superior function within only one lifetime.

How can I prove I'm worthy of being a FL programmer?

By writing a hard-disk controller in Haskell. (don't worry, it doesn't have to work for real; as long as you can prove it might work)

Shooting Oneself in the Foot (Reprised)

I run across these lists everywhere. Unfortunately, they all seem to have been done by some brain-damaged soul who thinks C is a "normal" language. So I have made an attempt to come up with a new list that is a little more accurate, at least where I sit.

Ada

You aim at your foot and pull the trigger, but the safety stops the gun from firing. The safety won't budge until you tag your foot with a sign reading "Bullet Hole in this foot", and call the paramedics. You do so, then shoot yourself in the foot.

C

The gun comes in 38 pieces, with a set of assembly instructions. After painstakingly assembling the pieces, you pull the trigger and the gun promptly backfires and blows your head off.

Assembly

The same as C, except you have to hand-machine all the pieces as well. When you pull the trigger, your whole house explodes.

Java

You break into someone else's home and steal their water pistol. You then make a child gun that uses .38 rounds instead of water. When you pull the trigger on the child gun, nothing happens to you, but everyone who visits your house gets shot in the foot.

Basic

You aim the gun at a straight horizontal and pull the trigger, which causes a stream of water to be squirted straight down onto your foot.

Perl

You aim the gun at your foot and pull the trigger. There is no explosion, but gravity causes the bullet to slide out of the barrel and bounce off your foot.

Lisp

You do a small part of the remaining work involved in shooting yourself in the foot. You then call yourself, and tell yourself to shoot yourself in the foot.

Pascal

The same as Ada, except when you pull the trigger a little sign pops out reading "BANG!".

C++

The same as Java, except you try to build the parent water pistol using the gun tools from the C gun. When you pull the trigger on the child gun, the parent C gun explodes, spraying water everywhere, including the chamber of the child gun. This causes the child gun to backfire, blowing your head off.

Visual C++

The same as C++, except that the bullets, the gun parts, the tools you use to put it together, the hospital you get taken to afterwards, and the ambulance that takes you there are all owned by the same company.

APL

Whenever you pull the trigger, no matter where you aim the gun, the bullet ricochets off of 13 objects and lodges in your foot. The gun has been examined by ballistics experts, mechanical engineers, and even the person who made it, and none of them can figure out how it works.

FORTRAN

When you aim the gun at your foot and pull the trigger, a table indexing error causes the gun to shoot its firing pin into your foot instead of the bullet.

T.E.D.
http://www.iag.net/~dennison/

Tenne-C

Tenne-C programming language
from Good Ol' Boy Systems

For all those unfamiliar with Tenne-C, the comment delimiter is WHISPER. The computer stores all WHISPERed comments in memory, but the instruction execution unit can never quite decode them, so they are ignored. Some beta site users have reported an occasional problem with IBM clone machines. These machines may get slightly confused or mildly paranoid due to the whispered remarks in the background, but the effects are usually limited to an occasional mutterance printed on the display. Note that the optional extended obcenity instruction set should not be installed in clone machines. Should such a machine crash, you could be arrested for making an obscene clone fall.

General Idiosyncrasies of Tenne-C

Single arguments are not passed to functions individually; rather, multiple passes are made simultaneously to all functions. Thus, in Tenne-C, we speak of feuds rather than arguments. This is an extremely powerful, albeit somewhat destructive feature of Tenne-C.

Relational operators work similarly to those in other languages, but in Tenne-C these are called kinfolk operators. It will be noted that some of these interrelate better than others. Kinfolk operators include:

        Bettern                 (mines) bettern (yourn)
        Boutlack                (mines) boutlack (yourn)
        Nearlyboutlack          (mines) nearlyboutlack (yourn)
        Worsern                 (yourns) worsern (mine)
        Nearlyboutsgoods        (yourns) nearlyboutsgoods (mine)
        Lack                    (mines) lack (yourn)
        Sortalack               (mines) sortalack (yourn)
        Differrtn               (yourns) differrtn (mine)

        taint
        istoo
        tis
        aintdunnit
        nary
        nope

ahdodeclare:  a's     nearlybout      3
              b's     zacktly         4
              c's     bout            2
              d's     morerless       TWEV
              e's     2, an imeanit   WHISPER a constant

Arrays must be declared with the AHDODECLARE statement, and are referred to as messa, as in:

        Ahdodeclare(dinner)     messa(fish)     TWEV

The program section is referred to as CHORES and is labeled as such. Several loop and conditional constructs are available. These include the following:

        Hauloff and do
        Fer, til loop
        Whol, longasyerattit
        Iffen, theyen
        Yehbut, nowait

Block Structure

If a KIBBITZ ERROR is encountered at compile time, that is a single kib [ with a pair of bits (). The ommision of a single ] can also result in a NO BULL! error. Very serious compiler errors will be preceeded by the SELF message. That's right, brace yourself. We're talking about such errors as SOURCE FILE TURNED TO TRASH, SOURCE FILE CONVERTED TO RUN FILE, HEX PUT ON SOURCE FILE, that sort of thing. Errors of this type will be followed by the message "START ALL OVER FROM SCRATCH," and the offending source file will, of course, be deleted.

Errors

Error messages can be quite strong indeed. We have one of the most arrogant compilers in the business, a source of great pride for us. Typical error messages include:

        WELL, IF THAT AIN'T ABOUT THE DUMBEST DANG THANG
	  I EVER SEEN!
        WHADJA DO THAT FER?
        ERROR TWENNY SEM, DUMB AICE!
        DAMMIT, BOY, HOW MANY TIMES I GOT TO TELL YOU?!

Support Tools

Good Ol' Boy Systems still clings tenaciously to the notion that single-sided diskettes are better than double-sided diskettes. We maintain that a single-sided diskette is in opposition to the laws of physics as we know them today. However, we further maintain that, at some time in the future, Good Ol' Boy Systems will be the first to discover the unlimited storage of the heretofore undiscovered "nether side" of single-sided diskettes. Now THAT, folks, is virtual disk space.

A software linker is not yet available. Until the virtual disk space is truly solved, we strongly recommend double sided disk drives. You can then purchase our hardware linker, which allows you to superglue two single-sided diskettes together.

We're working on other things, too. For instance, there's our new operating system, MS-HOSS, with the 'Mater Vine file structure. And for 'Mater Vine support, there's 'Mater Stakes. And if you thought SideKick was good, wait til you see our new ButtKick utility. Expected to be widely available by the end of next month, regardless of what month this be, it is being developed using our powerful new Four Barrel Tenne-C. While we aren't yet ready to develop a Turbo Tenne-C, we feel that the high data compression ratio of Four Barrel Tenne-C will suffice.

Here is a sample of our work. This is part of our new floating point package, written in LOWLIFE, our low-level programming language.

     UNSTACKUMDOTNUMBER   WHISPER rip number off the stack
     JIP DOTREMOVER       WHISPER jump if punctuated
     DONTDONOTHING        WHISPER no op
     JUMPEM2DGITBACK      WHISPER return
     GUMDROPS4EARPLUGS    WHISPER sweet things in my ear

DOTREMOVER:
     RDLDOTNUMBER         WHISPER Rikki, don't lose that
                                  number
     ASRDOTNUMBER         WHISPER shift the number right
     JISPDOTREMOVER       WHISPER jump if still punctuated
     ABSOLUTELYNOT        WHISPER negate and take ABS
     BZZBZZBZZ            WHISPER WHISPER WHISPER EM2DGITBACK:
     RTS                  WHISPER return to stack
     RETURNS              WHISPER return estimated truncated
                          WHISPER unary radix numerix stuff

Old COBOL Programmers Never Die...

After a couple of years, he was burnt out. He got to the stage where he'd see lines of COBOL float past whenever he shut his eyes, and he had regular nightmares about the year 2000. One day, he saw an advert for a cryogenics company. He contacted them, and they assured him they could put him in cryogenic suspension until after the year 2000. The process was very expensive, but he reasoned he could afford it, so he agreed to it. He really looked forward to waking up in the year 2001 so that he could put the year 2000 behind him and get on with the rest of his life.

He was anaesthetized, and the next thing he knew, he was waking up in the cryogenic chamber. The room seemed much more high-tech than he remembered, and it was full of very excited looking people saying things like "he's still alive", "we've done it" and "it's a miracle". One of the technicians explained that the cryogenic equipment hadn't been Y2K compliant, and they'd only just been able to override the equipment to wake him up. In fact, he'd been asleep for several thousand years. The technician said there was someone very important who wished to speak to him.

A large screen that filled most of one wall lit up, and a man appeared on the screen. He explained he was the President of the Earth. He said that the world was at peace, that famine and disease were a thing of the past, mankind had colonized the planets and that it was a great time to be alive. He said they were very excited that they'd been able to revive him.

The programmer said he could understand their excitement, seeing as he'd been asleep for so long. The president said, "Oh no, it's not that at all. It's going to be the year 10,000 in a couple of years time, and you're the last COBOL programmer left alive".

NULL - The Ultimate Computer Language

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 GOTOs 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:

• Highly structured constructs.
• Advanced data hiding techniques.
• A NULL compiler can be written first in NULL without ever needing to be written in a lower-level language
• Since there are no statements to compile, in fact, no compiler need ever be written in the first place, saving time and money.
• Since there will be no compilers, no new releases will ever be issued hence maintenance is reduced.
• NULL programs are highly portable and totally machine independent.
• 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.
• Since there will never be new releases of NULL, all programs are upwardly and downwardly compatible.
• NULL can be parsed top-down, bottom-up, left-right, right-left, inside-out, and over-easy.
• NULL programs are both self-documenting for clarity and self-concealing for security.
• NULL programmers are easy to find and once found can be fired since they are not needed.
• 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.

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

Java Programming Tips

1. Lie in the comments. You don't have to actively lie, just fail to keep comments as up to date with the code.
2. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.
3. Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.
4. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
5. In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.
6. If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.
7. In the name of efficiency, use cut/paste/clone. This works much faster than using many small reusable modules.
8. Never never put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable, not even a temporary!
9. Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.
10. Cd wrttn wtht vwls s mch trsr. When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz.
11. Never use an automated source code tidier to keep your code aligned. Lobby to have them banned them from your company on the grounds they create false deltas in PVCS (version control tracking). You are now free to accidentally misalign the code to give the optical illusion that bodies of loops and ifs are longer or shorter than they really are.
12. Rigidly follow the guidelines about no goto, no early returns, and no labelled breaks especially when you can increase the if/else nesting depth by at least 5 levels.
13. Use very long variable names that differ from each other by only one character, or only in upper/lower case. Wherever scope rules permit, reuse existing unrelated variable names. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc.
14. Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables.
15. Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global.
16. Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired.
17. To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean write to a file, and to a print on a laser, and to display on the screen). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be unprofessional breach of the the structured design principle of information hiding.
18. In naming functions, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.
19. Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work. As a corollary, never document the units of measure of any conversion constants, or how the values were derived. It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments.
20. In engineering work there are two ways to code. One is to convert all inputs to S.I. (metric) units of measure, then do your calculations then convert back to various civil units of measure for output. The other is to maintain the various mixed measure systems throughout. Always choose the second. It's the American way!
21. I am going to let you in on a little-known coding secret. Exceptions are a pain in the behind. Properly-written code never fails, so exceptions are actually unnecessary. Don't waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit(). Just stick a perfectly standard set of throws on every method header whether they could throw any exceptions or not.
22. C compilers transform myArray[i] into *(myArray + i), which is equivalent to *(i + myArray) which is equivalent to i[myArray]. Experts know to put this to good use. Unfortunately, this technique can only be used in native classes.
23. If you have an array with 100 elements in it, hard code the literal 100 in as many places in the program as possible. Never use a static final named constant for the 100, or refer to it as myArray.length. To make changing this constant even more difficult, use the literal 50 instead of 100/2. These time-honoured techniques are especially effective in a program with two unrelated arrays that just accidentally happen to both have 100 elements.
24. Eschew any form of table-driven logic. It starts out innocently enough, but soon leads to end users proofreading and then shudder, even modifying the tables for themselves.
25. Nest as deeply as you can. Good coders can get up to 10 levels of ( ) on a single line and 20 { } in a single method. C++ coders have the additional powerful option of preprocessor nesting totally independent of the nest structure of the underlying code. You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. Wherever possible, convert nested ifs into nested [? :] ternaries.
26. Join a computer book of the month club. Select authors who appear to be too busy writing books to have had any time to actually write any code themselves. Browse the local bookstore for titles with lots of cloud diagrams in them and no coding examples. Skim these books to learn obscure pedantic words you can use to intimidate the whippersnappers that come after you. Your code should impress. If people can't understand your vocabulary, they must assume that you are very intelligent and that your algorithms are very deep. Avoid any sort of homely analogies in your algorithm explanations.
27. Make "improvements" to your code often, and force users to upgrade often - after all, no one wants to be running an outdated version. Just because they think they're happy with the program as it is, just think how much happier they will be after you've "fixed" it! Don't tell anyone what the differences between versions are unless you are forced to - after all, why tell someone about bugs in the old version they might never have noticed otherwise?
28. The About Box should contain only the name of the program, the names of the coders and a copyright notice written in legalese. Ideally it should link to several megs of code that produce an entertaining animated display. However, it should never contain a description of what the program is for, its minor version number, or the date of the most recent code revision. This way all the users will soon all be running on different versions, and will attempt to install version N+2 before installing version N+1.
29. The more changes you can make between versions the better, you don't want users to become bored with the same old API or user interface year after year. Finally, if you can make this change without the users noticing, this is better still - it will keep them on their toes, and keep them from becoming complacent.
30. If you have to write classes for some other programmer to use, put environment-checking code (getenv() in C++ / System.getProperty() in Java) in your classes' nameless static initializers, and pass all your arguments to the classes this way, rather than in the constructor methods. The advantage is that the initializer methods get called as soon as the class program binaries get loaded, even before any of the classes get instantiated, so they will usually get executed before the program main(). In other words, there will be no way for the rest of the program to modify these parameters before they get read into your classes - the users better have set up all their environment variables just the way you had them!
31. In Java, disdain the interface. If your supervisors complain, tell them that Java interfaces force you to "cut-and-paste" code between different classes that implement the same interface the same way, and they know how hard that would be to maintain. Instead, do as the Java AWT designers did - put lots of functionality in your classes that can only be used by classes that inherit from them, and use lots of "instanceof" checks in your methods. This way, if someone wants to reuse your code, they have to extend your classes. If they want to reuse your code from two different classes - tough luck, they can't extend both of them at once!
32. Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes. And it might even be a security flaw - after all, isn't java.lang.String final for just this reason? If other coders in your project complain, tell them about the execution speed improvement you're getting.
33. Make as many of your class variables as possible static. If you don't need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you're getting.
34. Keep all of your unused and outdated methods and variables around in your code. After all - if you needed to use it once in 1976, who knows if you will want to use it again sometime? Sure the program's changed since then, but it might just as easily change back, you "don't want to have to reinvent the wheel" (supervisors love talk like that). If you have left the comments on those methods and variables untouched, and sufficiently cryptic, anyone maintaining the code will be too scared to touch them.
35. On a method called makeSnafucated insert only the comment /* make snafucated */. Never define what snafucated means anywhere. Only a fool does not already know, with complete certainty, what snafucated means.
36. Reverse the parameters on a method called drawRectangle(height, width) to drawRectangle(width, height) without making any change whatsoever to the name of the method. Then a few releases later, reverse it back again. Generalisations are left as an exercise for the reader.

Return to Languages index