A revolutionary OS/Programming Idea

Lynn H. Maxson Lynn H. Maxson" <lmaxson@pacbell.net
Thu Oct 2 12:25:02 2003


Alaric B Snell wrote:
"I agree - my point was more that despite the efforts to use 
friendly sounding long names in COBOL and SQL rather than 
terse symbols, neither of them ended up being accessible to 
laymen in the long run, because software is complex for 
reasons other than the syntax of the language. ..."

Again you put COBOL and SQL in the same container.  Yet in 
your earlier response you mentioned the importance of 
knowing set theory, the very basis of relational databases and 
SQL.  In fact SQL is probably used by more non-programmers 
(those who do not realize that they are in fact programming) 
than programmers (those that realize they are in fact 
programming).  As one familiar with relational databases from 
their inception from Codd to the prototype System R to the 
production form of DB2 and the rest it was designed for ease 
of use by laymen.  COBOL was not.  In fact SQL is the most 
invoked 4GL in the world, even those most of its invokers do 
not make the connection between a query language and a 
programming language or a specification language.

I responded to the initial message from John Newman 
privately as probably I should have this one.  The "gods" of 
Tunes do not take kindly to trespassers, particularly those 
who have not taken time to learn the litany.

Even COBOL is accessible to the layman, the wannabee 
programmer.  I would probably submit that it is easier to 
"master" than C.  COBOL is largely a product of a committee 
of vendors wanting to preserve as much of their current 
programming language features in this newer programming 
language.  As a "business-oriented" language except for PL/I 
it has no match in its arena.  At the very least it supports 
variable precision, fixed decimal arithmetic natively, basically 
having no use for "float".<g>

"...Maybe, but it'd be a bit complex ;-) I'd rather study all the 
old and new languages (although there seems so little to 
learn from the new ones these days...) and try to make the 
*simplest possible* new one that combines the wisdom of all 
the ancients, removing features that can be done better with 
other features. ..."

In 1970 when Jean Sammet published her "History of 
Programming Languages" she referenced something like 750 
"old" programming languages.  I will not say that I have 
studied them all, but I did read the book from cover to cover.  
In truth I have studied and used quite a few.  None offer as 
broad a range of data element types as PL/I, even when 
taken altogether.  None offer as broad a range of operators 
as APL, again even when taken altogether.  APL and PL/I 
support aggregate (array and structure and every 
combination thereof) operands.  The only "native" data 
aggregate missing is the list aggregate, which we can take 
from LISP.

There's nothing complex to it: PL/I syntax, PL/I data types, 
APL operators, LISP list aggregate.  To allow for logic 
programming you need to add an assertion statement, 
hopefully based on predicate, not clausal, logic.  To allow for 
inclusion of rules relative to the use of the data you need 
only add a "range" attribute in the data declare.  This alone 
allows you to implement an OO methodology based on multiple 
inheritance without the need for either a class structure or 
library.

"...Also, I'm a fan of having a very simple language with a 
flexible enough syntax to make it easy to put things into the 
standard libraries, rather than in the language core itself."

We were probably pretty much in agreement up to this 
statement.  You use library in the plural, i.e. libraries, whereas 
I use it only in the singular, i.e. the specification pool (library).  
As the language itself is specified therein as well as the tools 
which process the language and every application written in 
it, it becomes impossible to have a "non-standard" library: no 
separation of source exists.

I will submit to you that "standard" libraries separated from 
the tools that process them are about the last thing you want.  
We have a history of their failures.  We don't have to look any 
further than C++ or JAVA.