Little known computer languages

[Kris Stephens]

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