A case against standards
Lynn H. Maxson
Lynn H. Maxson" <firstname.lastname@example.org
Mon Nov 3 16:24:02 2003
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.