Little known computer languages
Kris Stephens
krs at amdahl.UUCP
Wed Apr 3 19:02:15 AEST 1985
> A friend of mine at Carnegie-Mellon sent me the following list of "lesser
> known" computer languages:
...
>
> I would be interested in hearing from anyone who can report on any other
> little known languages in use out there.
>
> ============================================================================
> Dave Bealer BZF @ PSUVM (Bitnet)
Okay, Dave...
Maybe It's Time for 'MAYBEBOL'
ENTROPY: The amount by which a system differs from its ideal state.
The Second Law of Thermodynamics can be interpreted as saying "Entropy
always increases with time". This means that as soon as a perfect system is
achieved, it starts to deteriorate. This may be understandable in
mechanical systems where moving parts are subject to wear and tear. But
what is not so evident is that the concept of entropy applies to logical,
or software, systems also.
It is no secret that 60% to 80% of every programming dollar is spent on
combatting entropy -- that is, maintaining existing systems. If you are
involved with any commercial systems, think of how often programmers have
to code changes upon changes to that "ideal" system. Why is this always
the case? Is there any way to get around this problem?
Let's examine the situation. Many times the people requesting a new
computer system (the users) cannot define their needs precisely. Often,
they are not sure what they want or how to deal with certain situations.
Many ambiguous features are left in systems with the idea, "We'll deal with
that problem when we get to it."
Programs and programming languages require exact and unambiguous
definitions to function effectively; solving an unknown or ambiguous
problem is next to impossible with today's programming languages.
As I see it, there are two possible solutions to this problem.
Solution #1: Carefully and objectively resolve the system design to
achieve an exact problem definition. Response: Who are you kidding? Face
it, people have been trying to do this since day one and no one has
succeeded yet. Every time they get close, entropy sets in.
This leaves us with the second solution:
Solution#2: Change the programming language.
Why not? We're trying to use rigidly defined programming languages
structured along exact lines to provide predictable and consistent
results. This obviously does not reflect real-life applications at all. To
handle modern complex situations, a more flexible language is needed -- a
language to procrastinate and deliver the silicon equivalent of a shrug.
After much research, deep thought and trial and error, I have come up
with the outline of an innovative programming language which I call the
Multiply Analytic Yet Basically Evasive Bull-Oriented Language, or
MAYBEBOL. The following are some of MAYBEBOL's more attractive features.
IF ... THEN ... MAYBE. An eloquent concrete admission of indecision, this
statement is the heart and soul of MAYBEBOL.
DO SOMETHING. When those unforeseen situations occur, the user is on
sabbatical in Africa and the project is due tomorrow, the DO SOMETHING
statement just might help you hit that deadline. Example: IF ADD-CHG-DEL-
CODE = PIZZA DO SOMETHING.
Ideally, no one should have any idea just what might be done. (Some
more adventurous souls may wish to set up a pool and bet on the outcome.)
GO SOMEWHERE. Where? I don't know, do you?
ON ERROR conditions. The ON ERROR statement would have two possible
formats:
1) ON ERROR GENERATE EXCUSE. Everyone knows excuses are more important
than results.
2) ON ERROR FORGET ABOUT IT. Self-explanatory.
In each of the ON ERROR conditions, control will be returned to the main
program by means of the GO SOMEWHERE statement.
GENERATE x REPORTS. X is an integer from 1 to 32.
Users always demand reports. They take these reports and place them
carefully in multicolored binders. These binders are then stacked on the
shelf, giving the users a place to store their dust collections. Since
no one ever looks at these reports, a great deal of time and effort can
be saved by generating them randomly.
COIN. A built-in subroutine, COIN will return a character value or
"HEADS" or "TAILS." This can be very useful when making decisions.
GUESS. The programmer doesn't know what to do, the user doesn't know what
to do, nobody knows what to do, so why not?
PRETEND. As in "IF BAD-DATA THEN PRETEND."
SEARCH table-name. The SEARCH statement will consecutively search a table
in memory. Note that it is illegal to supply what to search for. If
somehow a match is found, set the ERROR condition (see ON ERROR).
LOOP FOREVER. A great time saver for the programmer. Instead of having to
subconsciously invent subtle and hardto-find infinite loops, he may now
declare them explictly.
DIVIDE x BY ZERO. Same concept as LOOP FOREVER.
The above statement and philosophy will be the basis for MAYBEBOL. As
time permits, I will attempt to complete the language design. This task
should be much easier to accomplish than it may appear. You see, just the
bare-bones version of MAYBEBOL provides an excellent medium for the
computer-aided design of the rest of the language. Just think of all the
delightful treasures of illogic waiting to be discovered!
Now, if I can just get this machine out of this LOOP FOREVER
statement...
By Joey Robichaux.
Robichaux is a computer analyst for Louisiana State University in Baton
Rouge.
Copied without permission from COMPUTERWORLD February 2, 1981.
--
Kris Stephens (408-746-6047) {whatever}!amdahl!krs
[The opinions expressed above are mine, solely, and do not ]
[necessarily reflect the opinions or policies of Amdahl Corp. ]
More information about the Comp.lang.c
mailing list