One language or many

[Lynn H. Maxson]

Kyle Lahnakoski wrote: " It is
better to see the HLL as a set of domain specific 
languages." and "Furthermore I believe you are 
saying that a hardware specification language is a 
subset of HLL.".

We had best agree to disagree on this point.  I 
propose only a single specification language that 
covers the entire gamut or domain of software 
activities.  This misnomer between a specification 
language and a programming language is one we need 
to examine to make clear (or clearer) the 
distinction.  It began with Iversons APL (A 
Programming Language), intended as a specification 
language (written only, not executable) to replace 
flowcharting, and continued with Prolog to make a 
specification language "behave" as a programming 
language.

In my system all programming is done by the tool, 
the Developer's Assistant, based upon an input set 
of specifications.  That it works for a 
specification language I can refer to two computer 
architectures encoded in APL, the earlier Stretch 
7080 (in 1962) and the more remarkable S/360 (in 
1964).

Moreover if you refer to the Intel reference 
manuals on its processors, more recently the 
Pentium family of processors, you will find a 
HLL-encoded "specification" of every instruction.  
As you can see it is not new as it has a nearly 40 
year history.

At one time within Burroughs was a proposal to make 
APL the "standard specification" language for all 
software and hardware.  One language which covered 
the hardware and software domains from the lowest 
level (hardware encoded logic) to an unlimited 
number of higher levels.  Burroughs corporate 
management turned it down.

Since that time we have seen the rise of AI and 
logic programming, the most prominent remnant of 
which is Prolog.  As a reference I could suggest 
"Simply Logical: Intelligent Reasoning by Example" 
by Peter Flach. Though ostensibly a tutorial on 
Prolog, it nevertheless serves as one on logic 
programming as well.

If we back up a bit, broaden our vision somewhat, 
we will see that software development is a process.  
It takes as input user requirements, transforming 
(translating) them into specifications.  That's the 
first step within the process (as the requirements 
come from outside it).  Even the object-oriented 
advocates had to precede the programming (which 
occurs in the construction stage) with UML.

The point is that something occurs prior to 
programming and the use of a programming language.  
If you will accept the process of specfication, 
analysis, design, construction, and testing, then 
the question becomes what is it that you respecify 
in the later stages?  Why would you ever respecify 
anything except as part of the specification stage?

If you do not, if that is the only writing the user 
does (write specifications), then you turn the 
implications of that writing to the tool, the 
assistant, who performs the remaining stages 
automatically.  That includes automated analysis, 
design, construction, and testing all under control 
of the chosen set of specifications.

In short there is no (people) programming nor 
programming language.  The only language 
controlling each of the successive stages is the 
specification language.  The logic engine (or 
engines) within the tool provide the implications 
of the specifications.  They proceed asychronously, 
incrementally, and in parallel.  At any instance 
they reflect (present) the "state" of the system 
defined by the specifications.

The language is specified within itself 
(self-defining).  The tool is specified with the 
language.  Both the tool, the language, and the 
source for both constitute the product received by 
the user with absolutely no strings attached to its 
use.  None of the restrictions of "open source" as 
none are necessary to insure (protect) its 
"openness".

So there is only one language and one tool from 
which all the remaining "desirables" derive.