A revolutionary OS/Programming Idea

[Alaric B Snell]

Lynn H. Maxson wrote:
> 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). 

You think so? The users of SQL I see these days are all programmers - be 
they writing code in their favourite language that generates SQL queries 
on the fly to send to the database in order to build a multi-tier 
system, or who are writing one-off queries to peer into the database to 
test their code or to produce a custom report; perhaps this is just an 
artefact of the industry sector I work in, but I don't see any laymen 
picking up SQL just so they can get at their business data, they always 
email people like me to do it :-)

 > 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. 

Hmmm, COBOL was designed to be comprehensible to business people...

"COBOL (Common Or Business Oriented Language) was designed at the end of 
the 1950s by Admiral Grace Hopper in response to a commission from the 
U.S. Admiralty. Like FORTRAN, it has proved extremely durable and most 
large-scale data processing systems today are still realised in COBOL. 
One of the design aims underlying COBOL is that programs written in it 
should be readable, even to non-computer professionals. So whereas 
FORTRAN, in describing program instructions, employs standard 
mathematical symbols and operators, in contrast, COBOL programs attempt 
to mimic natural language descriptions. In the earliest versions of the 
language no mathematical symbols were used and arithmetic operators were 
specified using the equivalent English word. This, amongst other 
features of the language, made COBOL programs appear to be extremely 
verbose^2.

2) There is an apocryphal story to the effect that COBOL was designed in 
this way so that directors and company chairmen could understand and 
modify the payroll programs run by their corporations and that English 
was necessary since such people would be incapable of understanding 
complex mathematical symbols such as +.

Thus the simple statement A = C + D in FORTRAN becomes ADD C TO D GIVING 
A in COBOL. The belief that by substituting English for mathematical 
symbols programs would become more understandable and thereby easier to 
write turned out, however, to be fallacious. The reason for this, which 
is obvious with hindsight but was not apparent at the time, is that what 
makes designing a computer program for a specific task difficult to do 
is the process of specifying, structuring, and ordering the activities 
to be carried out at a fine enough level of description, i.e. the 
difficulty in programming is constructing the appropriate algorithmic 
process. Once this has been done it is usually a relatively easy task to 
translate the algorithm steps into any programming formalism. Once this 
fact had been recognised, an important consequence was that more 
research effort was concentrated on methodologies for designing programs 
and algorithms rather than on superficial attempts to make such programs 
`readable' or `comprehensible'. The study of programming methodologies 
ultimately led to the theoretical disciplines of Programming Language 
Semantics, Formal Specification, and Formal Verification that were 
mentioned, briefly in the opening lecture. "

  - http://www.csc.liv.ac.uk/~ped/teachadmin/histsci/htmlform/lect6.html

> Even COBOL is accessible to the layman, the wannabee 
> programmer.  I would probably submit that it is easier to 
> "master" than C. 

That depends what you mean by master, I guess... I think I agree that 
it's easier to gain a sufficient understanding of all of COBOL's 
features than C's, for a layperson. But my main point is that just 
learning a language doesn't make you a programmer. You can start to 
produce basic scripts quite proficiently, but without mastering skills 
such as "abstraction" you won't be doing things like defining reusable 
functions and so on, and it'll be bad code to maintain, and you won't be 
able to write anything particularly complex without bugs springing up.

Oh, and without learning the tips and tricks of debugging, you'll spend 
forever trying to find trivial flaws... I've seen lots of newbie 
programmers trip up on this one and end up calling me in to show them 
what's wrong with their code!

 > 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>

SQL does that too ;-)

> "...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.

Ah, but is sheer *number* of features a good thing to aim for? My own 
programming language research aims for more of a FORTH-like ethic; I try 
to find the minimum set of language features from which all of the data 
element types and operators can be developed from - in libraries, rather 
than in the language core.

Mainly because I want a simple compiler, but also for reasons of 
openness; it's easier for others to write language extensions as 
libraries than into the compiler itself, and the libraries will be 
portable between compilers.

The important thing, of course, is to have a core language that lets you 
write these features in libraries without needing messy syntax. LISP and 
FORTH and Smalltalk are good examples of how to do that, IMHO.

> 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.

Well, by "standard", I meant "deemed likely to be available in every 
reasonable implementation of the language" - which does indeed probably 
mean them being designed by the same people as the language spec, if 
that's what you mean?

ABS