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.