A case against standards

[Lynn H. Maxson]

Ilmari and Armin,

"...On the ultimate language -topic, I'd rather have a visual 
language for programming visuals, an audible language for 
programming aurals and a textual language for programming 
text, than a single megalanguage that tries to do it all."

I can understand what you rather have.  Unfortunately we 
program only in part to talk to ourselves and others for whom 
visual, audible, and textual might seem reasonable options.  
We also have to talk to the computer albeit through software.  
At the basic or machine level we have only textual.  For the 
others, visual and audible, we find their beauty only skin 
deep.  Once below that level we have only text from there on 
down to the machine level.

I will not argue against someone's druthers for visual or 
audible.  Those, however, rely on textual underpinnings.  
Those visual or audible underpinnings ultimately on a set of 
data types, aggregates, and operators, all of which must map 
into a machine's instruction set.

Thus if three programming languages contain all the data 
types, aggregates, and operators found in all others combined, 
once you decide on a syntax no reason exists to have more 
than one programming/specification language.  You can use it 
to create any visual or audible user interface.

Why not one "megalanguage" with the simple syntax of PL/I: 
every program element is a statement and every statement 
ends in a semi-colon?  The alternative involves mastering 
multiple other, possibly incompatible programming languages, 
including symbolic assembly.  You could ask yourself which 
choice is more "mega".<g>

Again I would opt for the KISS principle.  For debugging, 
testing, and developing source code the most efficient (and 
effective) means lies in an interpreter.  Once you have 
completed all these in the most efficient manner the most 
efficient means of execution lies in a compiler.  As a compiler 
and interpreter differ only in the result of the proof theory, 
either interpretive or compiled code, it seems that having a 
choice in a particular instance can occur in one software tool.

I have a bias toward textual input but none with respect to 
presentation of output.  I see no reason when the 
completeness proof finishes with the now organized source 
that it cannot produce any form of visual, audible, or textual 
result according to the whims of the user.  After all we use a 
flowcharting programming to create a visual of source.  We 
have no reason to believe that we cannot do the same for 
UML, dataflows, structure charts, or directed graphs.  Again in 
accordance with the KISS principle it has the advantage of 
having only one source to maintain.