Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels!xtbjh
From: xtbjh@levels.sait.edu.au (behoffski)
Newsgroups: comp.software-eng
Subject: Algebra .vs. Adjectives and Adverbs
Message-ID: <16268.28266541@levels.sait.edu.au>
Date: 6 May 91 22:58:48 GMT
Organization: University of South Australia
Lines: 79

[Apologies if this is a repost.  The local machine had a disk failure 
at the same time as I first tried to post this.  bjh]

I would like raise a topic for discussion based on an idea that I had 
quite some time ago.  The idea is very simple but allows some quite 
interesting improvements to language design and implementation.  

The idea is this: programming languages that were originally derived 
from algebra (Pascal, ADA, C, FORTRAN etc), suffer from algebra's bias 
towards nouns and verbs over adjectives and adverbs.  This deficiency 
is especially noticeable when trying to build interfaces between 
system components.  

For example, consider an interface to a software machine (or module, 
if you prefer) that implements binary trees.  The definition of the 
tree includes the "root" node and "leaf" nodes.  Now consider a 
request to find all the leaf nodes of the tree.  If you only have 
nouns and verbs, then the program will be something along the lines of:

        list.clear(list)
        tree.BeginEnumeration(this_tree, context)
        while tree.GetNextNode(context, this_node) do
                if tree.IsLeaf(this_node) then
                        list.add(list, this_node)
                end if
        end while

The simple adjective, leaf, has been turned into the verb IsLeaf.  
This has the unpleasant property of turning a single request, which 
is highly parallel, into a large number of sequential requests.  
The two biggest disadvantages of this result are:
        - in order to exploit parallel processing, a compiler must 
            reverse-engineer the original request, and
        - the interface for the machine "tree" must be highly 
            efficient since there will typically be many operations.

Adjectives allow construction of interfaces that scale neatly between very 
small machines and very large machines.  For example, assuming fairly 
well-balanced trees, the number of leaf nodes will be roughly half the 
nodes in the tree.  

It is interesting that adjectives and adverbs do appear in software 
mainly in two situations:
        - as command line switches, where non-positional switches 
            correspond to adverbs and positional switches correspond 
            to adjectives, and
        - in various contexts within graphical interfaces (e.g. clicking 
            a node in a tree selects all nodes beneath that node).  

Another advantage of adjectives and adverbs is that they allow an 
interface to be more natural and self-documenting.  The resulting code 
can look much like executable pseudocode.  The interface will usually 
be more general since each language component will need to be implemented 
independently of any other component.  

The reusability of machines defined with adjectives and adverbs is also 
sharply higher.  This is because modules remain separate, instead of being 
continually mingled in loops like the example above.  Another benefit is 
that edge cases, that often feature in off-by-one bugs, are greatly 
reduced since most are handled within adjectives or adverbs.  

One of the most promising areas opened up by this idea is allowing 
performance improvements in machine implementation without touching 
the original specification.  For example, if a particular combination 
of adjectives and/or nouns and/or adverbs and/or verbs was very common 
in a program (e.g. one-legged Australian programmers immediately shoot), 
then the machine implementation could add an optimised program for that 
special case.  This could be true even where the modifiers applied to 
a noun or verb originally came from different machines.  

I apologise for the lots of hazy edges in the discussion above.  Despite 
trying to define a language based on this idea for over a year, there are 
lots of grey areas in syntax and implemetation that I haven't been able 
to tie down without lots of compromises.  I have, of course, already 
decided on the name when it finally appears: Languish (puns intended).  

--
Brenton Hoff (behoffski)  | Senior Software Engineer | My opinions are mine
xtbjh@Levels.UniSA.edu.au | AWA Transponder          | (and they're weird).