A revolutionary OS/Programming Idea

[Alaric B Snell]

Lynn H. Maxson wrote:
> Alaric B. Snell writes:
> "... Very early on, languages were designed that had 'easy 
> syntax'. At the time there were no GUIs per se, so they 
> instead made it look like English, and you wrote it on special 
> paper that had the columns labelled to make it easier. It was 
> quick to learn.  It was called COBOL, Common Business 
> Oriented Language, and it was couched in terms that 
> managers and file clerks and so on would understand, so they 
> could write their own database applications. SQL, likewise, 
> was apparently designed as a simple 'non-technical' language 
> for business types to query databases. Yet both COBOL and 
> SQL, today, are things you hire an expensive person with a 
> degree to do. ..."
> 
> I admired the tone of this response up until I got into this part.   
> I have to protest mixing apples and oranges, COBOL and SQL.  
> If COBOL programmers seem expensive, it's a matter of 
> demand exceeding supply: sheer economics.  SQL is all over 
> the place as probably the most use database languge in the 
> world.

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.

> If you want simple syntax, you don't pick COBOL.  You pick 
> PL/I where "every" program element is a statement and 
> "every" statement ends in a semi-colon.   COBOL sytax, 
> leading to the frequent search for the "missing period", while 
> no means hard to learn does have some pitfalls.

I think COBOL wasn't meant to be simple in that sense, more that it was 
meant to make some sense when read by a layman - that observation from 
looking at it myself rather than having heard from the original 
designers... "ADD 2 TO SUBTOTAL GIVING TOTAL" rather than "total = 
subtotal + 2", and so on.

[merging PL/I, APL, LISP, etc]
> You end up with a single "universal" specification language, 
> self-defining and self-extensible.  That means no need for 
> any other language, including assembly language, which is 
> included as machine-dependent specifications for any given 
> platform.

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.

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.

ABS