Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!amdahl!krs From: krs@amdahl.UUCP (Kris Stephens) Newsgroups: net.lang.lisp,net.lang.c,net.lang,net.jokes Subject: Re: Little known computer languages Message-ID: <1358@amdahl.UUCP> Date: Wed, 3-Apr-85 04:02:15 EST Article-I.D.: amdahl.1358 Posted: Wed Apr 3 04:02:15 1985 Date-Received: Thu, 4-Apr-85 08:06:02 EST References: <1663BZF@PSUVM> Organization: Amdahl Corporation, Sunnyvale CA Lines: 131 Xref: watmath net.lang.lisp:423 net.lang.c:4921 net.lang:1544 net.jokes:11653 > 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. ]