A revolutionary OS/Programming Idea

[Lynn H. Maxson]

John Newman wrote:
"...Seems to be sound advice--will do.  But with a quick
google, I found that there are object oriented
versions of declarative and logic languages.  So, I
don't see why my idea wouldn't work with them as well
(perhaps work better--without all the unnecessary
syntax). ..."

There's object-oriented and then there's object-oriented.  
Fortunately for programming we've never had any other kind.  
Unfortunately for programming on the basis of some research 
work at PARC we have a significant population dedicated to a 
restricted form in which they are slowly (and then not so) 
drowning themselves.

We have only data (objects) and operations (instructions).  So 
far we haven't developed machine architectures based on 
anything else.  So no matter how high an abstract level you 
create and how many lower levels you must transcend you 
end up with a set of machine instructions.  You write 
instructions.  You don't draw them.

You may draw at some abstract level, say your visual 
programming level, but someone or something at the next 
level has to translate them into some written form.  If you can 
only draw and not write or restricted in what and where you 
can write, then you are at the mercy of someone or 
something.  That in itself violates the principle of open source.

If you want a visual programming language of some standing, I 
would probably suggest AS Visualizer 
(http://www.astrac.com/).  You can also contact the Visual 
Prolog people (http://www.visual-prolog.com/) for a free, 
functional Prolog development environment.

The reality of programming lies in its 100% basis in formal logic 
of its languages and the machines on which they execute.  
Programming like algebra, geometry, or calculus or in symbolic 
logic becomes one of ordering sequences of logic to get from 
point A to point B.  Setting aside for the moment the issue of 
getting there in the shortest distance, one of logic 
optimization, the complexity quickly degenerates into 
connections among the sequences.  What makes programming 
difficult is not the language used, which regardless of syntax 
difficulty is nevertheless manageable, but getting the 
sequences and the connections correct.  It requires a level of 
skill in logical thinking, a discipline unfortunately not 
emphasized properly in our education systems.

People think well in the small, but not in the large.  There's a 
certain minimal size, a logical sequence as it were, in which 
any given individual can basically write error free.  
Somewhere above there he increasingly becomes error-prone.  
Logic programming allows us as people to write in the small, 
thus essentially error-free, while it does the larger 
constructions, the writing in the large, with the same 
error-free habit.

There you see the advantage of logic programming, the basis 
of declarative programming languages, over imperative 
languages, which by their nature force humans to have to 
write in the large.  In short you let the software as part of its 
completeness proof take unordered source and transform it 
into an optimal logical form.

At its heart is not a reduction in writing but tremendous 
reduction in rewriting associated with reorganization.  In terms 
of cost and time, the two major components of human effort, 
a reduction of millions to one.  At that cost and rate you do 
not care what little rewriting you do in the small that 
multiplies greatly the rewriting the software must do each 
time in the large.

In the nature of our business we have the problem set, reality, 
and the solution set, our source code.  We have in that reality 
the dynamics of change whose nature and rate varies 
randomly.  We have to reflect those dynamics in our solution 
set.  That's the basic mapping operation for which we use 
programming languages.  The goal is to support a change 
dynamics of the solution set equal to or greater than that of 
the problem set: in short never on average have a backlog.

So far with any programming language we have not achieved 
that.  Not one.   The latest classical failure, one whose 
backlog increases faster than the methodology it replaced, 
you fondly refer to as object-oriented.  Otherwise we would 
not have such things as the "Agile Manifesto", agile modelling, 
or XP (eXtreme Programming).  They too will fail...and fall 
from grace.

You started out proposing an integrated system including an 
OS, which has to ultimately come down to writing instruction 
sequences, and then suggesting a non-writing (visual) 
interface.  You have two worlds you need blend here, one 
which cannot exist on its own (visual) and one which can 
(written).  You have to be careful when you casually 
disregard who either does or owns the written.