A revolutionary OS/Programming Idea

[Alaric B Snell]

John Newman wrote:
> I was trying to learn programming and got very
> frustrated.  I keep think, there's got to be an easier
> way to do this.

[snip]

Ok! You're either going to find this delightful or infuriating.

The fact is, this kind of thing *has* been tried before.

This is infuriating because you think "Damn! I was so pleased with that 
idea and now he's going to tell me why it didn't work!". It's delightful 
because you get to find out you're not mad and that somebody else 
thought the same as you etc.

SO what happened?

Well, your idea, IMHO, splits into two:

1) Programming is hard because of the syntax - if (foo) { wibble(); } 
etc. Make the syntax easier to and everyone can write code.

2) Rather than always treating source code as a string of characters, 
treat it as structured data and use a special program to edit it with a 
proper GUI

(1), sadly, was disproven. 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. In the 80s 
there was interest in so-called "4GL" systems that should allow one to 
use natural English and drag+drop to build user interfaces but they, 
too, failed.

The problem appears to be that the main difficulty in programming is the 
underlying model, not the language you use. If you are writing an 
application to deal with bulk data, an understanding of set theory is 
far more important than knowing how to use arrays or whatnot.

Successful programmers have spent years learning algorithms and data 
structures, and gaining experience of relevant file formats, APIs, 
network protocols, etc. that they work with from time to time. 
Successful programmers can learn a new language in a few days - because 
the language is just an interface.

There have been recent attempts to produce 'easy to use' languages; look 
at Cold Fusion, which is designed for non-technical people to write Web 
applications. They use a nice WYSIWYG HTML editor which also suports the 
special cold fusion 'tags' such as <CFIF>...</CFIF> and so on in a nice 
tree-based display.

HOWEVER, you don't want non-technical people making web sites, if you 
can avoid it. It's hard to explain HTTP session management and database 
structures to them. I've seen some very, very, broken Cold Fusion web 
sites, including an online web mail system where you put in your 
username and password on the login form, and the welcome page then links 
you through to "inbox.cfm?uid=5234". Sure enough, modifying that "uid=" 
to other numbers takes you to other people's in boxes.

That flaw was presumably there because the author didn't have enough 
experience with Web application security to be on guard for such 
slip-ups. I bet that they weren't stupid; if they had been shown the 
application without the prejudice of them having written it and asked 
them to try to find a way to get into other people's mailboxes, they 
might well have quickly spotted the flaw. But thinking like an attacker 
when writing security-related code is something you need to learn to do; 
the uneducated make a horrible hash of it.

In my own computing degree at Imperial College, London, most of the 
courses were about formal logic, mathematics, networking, CPU 
architecture, data structures, and so on. We only had a single course on 
'programming', right at the beginning.

(2) is not that bad an idea, although perhaps not quite as you have 
incarnated it. There is a concept in programming language theory called 
an Abstract Syntax Tree which you have hit right on the head. A bit of 
code is, at heart, a tree; the first stage of a compiler usually sucks 
in a string of source code and produces this tree as an actual data 
structure. In some systems (eg, LISP machines!) this stage is removed 
and the system does in fact store the AST on disk as 'the source'. This 
means:

   - The compiler is simpler and faster (parsing is slow and complex)
   - It's much easier to write programs that operate on programs - eg, 
things that examine your source code and produce nice diagrams of what 
modules call what, or extract comments from your definitions to produce 
technical documentation.
   - You can write all sorts of different editors:

     1) One that converts the AST you're editing into text using a 
normal written syntax, then invokes the user's favourite text editor, 
then when that saves the file, parses the result (popping up 
notification of any syntactic errors!) into an AST then saves that.

    2) One that offers a nice 'code browser' - you can point and click 
around class hierarchies, module hierarchies, etc. You can click on a 
function name to go to its definition. Etc. And when you click 'edit' on 
a function, it then converts that one function's AST into text and 
invokes the user's favourite editor for that one function, as above.

   3) Like the code browser, except that even function bodies are 
represented diagrammatically, with a GUI editor; however, this gets 
tricky. I can type "if (foo) {x++;}" faster than I can right click, 
select "IF", then go to the condition bit, right click, select "variable 
reference", type "foo" (or drag 'foo' from elsewhere onscreen), go to 
the other bit of the if, right click, select "INCREMENT", right click 
again, select "variable reference", and type or select 'x'. All the 
latter gives me is that it tells me that to make an IF I need a 
condition expression and a statement to make conditional, but for a 
sensible programming language (NOT C++! :-) there's not that many 
'constructs' to learn anyway and a smart editor will show me reminders 
of them as I start to type them, if I really want it to (perhaps only if 
I start typing it wrong :-).

But you're thinking along the right lines - lots of aspects of 
programming languages (like being written in text) are just there 
because of tradition; people have never seen any other way of doing it 
so they just copy it endlessly... So I reckon that if you learn more 
history and study some other programming languages (things like FORTH, 
for example,  have much less of a tree structure than most languages) 
then you'll be coming up with insights that haven't been done before!

Good luck!

ABS