A revolutionary OS/Programming Idea
pjb@informatimago.com
pjb@informatimago.com
Fri Oct 3 17:51:02 2003
> Exactly. Take the power, flexibility, extensability,
> etc., of *nix, and apply it visually--you could think
> of it as a visual object scripting environment.
Those are only jokes.
The stuff of computers is symbols. Visually, you don't have symbols,
you have icons, and this is not the same.
Further, there is a reason why alphabetical approach (text editor)
works better than an ideographic, iconic or syntactic tree approach.
> Apperently, Linux is not supposed to be that hard, but
> I can't figure it out (not that I've tried very hard).
> If every command on the console, though, simply had a
> button, and acted like a visual application, I am sure
> I would be using it right now.
Perhaps, before investing much time implementing anything you could
try Commando in MPW (Macintosh Programmer Workshop), or if you can put
a hand on it, in A/UX: in the MPW shell, you type a command, an
elipsis, and execute that, and you get a dialog with all the options
that command can take, you can select input, output and error files,
etc. Very nice, puts a GUI on CLI commands. Check it and if you like
it, then you could envisage implementing something similar for unix
commands. That would not be too difficult either.
> Also, this visual filesystem is going to be slick. No
> popups telling you that files are transfering from one
> place to another, just automatic, and fast. Also it
> might be slightly 3d, where files are represented as
> boxes, and boxes are pushed and pulled on the z plane
> through the scroll wheel, or by clicking and holding
> on a button on the window bar while moving the mouse
> up or down. This way, one can move boxes into and out
> of other boxes, and have more organization space. But
> that is really secondary to the idea of a visual
> programming file system.
You can invent any scheme to organize your data and your objects.
Some prototypes have been implemented. The fact remains that file
systems are usually just trees.
> Aleric wrote:
>
> > That indeed holds for a novice, but experimentation
> > with structured
> > editors (see below) led the non-novices to get
> > annoyed with them and
> > shift back to editing strings.
> >
> > Now, it could well be that this was not a fair test
> > - maybe nobody tried
> > teaching somebody to program from scratch in a
> > structured editor, then
> > got them to attempt to use a textual syntax to see
> > how they got on. I
> > don't know. Anyone got a reference?
>
> Or, maybe those structural editors just sucked.
I would say the principle sucks. I may be wrong thought.
Another example is that of expression editors. Just try to use one of
these GUI expression editors, vs. some latex formula writting.
Really, to try to understand the problem, I think we could compare
alphabetics vs. ideographics, and the consequences in term of
philosophy and civilisation development.
Alphabetics works by composing small building blocs in little number:
26 letters and you're through. Any child can master the alphabet
before five. From there on, you just make logical, symbolic
compositions to build bigger elements: syllabes, words, sentences,
books.
Of course, it may seem that having to manipulate letters is a loss of
time when your problem is to write a book (or even a sentence). But I
say that on the contrary, this is the easily understood and mastered
basic building blocs that give us the ability to write the masterpiece
books.
While the little occidental children have learned these 26 letters and
the few combination rules to read and write syllabes, words and
sentences, they are soon able to read books and to start writting them
too.
At the same time, ideograms have to be learnt one by one and oriental
children spend their whole time just learning the words and are not
able to read anything before having learnt the words used.
While the principle of printing were known to the Chinese, they could
not implement it on a big scale, because they would have needed
enormous fonts, with thousands of words-ideograms before they could
start printing anything. On the other hand, with alphabets, you just
need a font with a few characters and you're set to print the Bible
and all the other books that help diffuse ideas and knowledge thru
your civilisation.
About computers, while there exist programs allowing you to write
seamlessly in any kind of script, there the complexity of
non-alphabetic scripts is made manifest in the complexity of the code
and the volume of data need to implement each of these scripts.
As for the level of source program editing, if you must do it with a
text editor, in which you enter the tokens characters by characters,
you only need to know a limited set of editing commands that can be
applied to all kind of data and all kind of data or control
structure. One small set of commands to master them all ;-) On the
other hand, if you must work with syntactic editors (better have then
graphical then), you need to have much more knowledge in the editor,
and many more commands very different and very specific to each
syntactic structure. Of course, you could not remember all these
different commands, so you implement help systems, like menus, pop-up
menus. Then the manipulations you have to do to enter your commands
are so complicated, needing so many steps to do one simple entry, that
you need to implement obscur shortcuts that only someone nearly
autistic can master.
Finally, the problem is that we want to write complex formal
expressions, where precision is most important and ambiguity prohibed.
> I've
> been research what visual editors there are for days,
> and none of them really do what I am talking about. I
> want a simple interface, similar to the windows
> explorer window--I want to right click on the editor
> area, go to Insert-->new file, click, and have it pop
> up--I want to open the file into a new window, right
> click editor area, go to Insert-->new Data
> Structure-->new Array, click, there it is--Then I want
> to right click on my array file and go to properties,
> and go to the "number of elements" text field and
> enter "50" and leave the other fields default, and
> then click save--Then I can open my array file, and
> walla, I have fifty new array-element files to play
> with.
Do you mean exactly as:
(defun open-array-file (n-elem)
(interactive "nNumber of elements: ")
(let ((i 0))
(while (get-buffer (format "Unnamed %d" i)) (setq i (1+ i)))
(find-file (format "Unnamed %d" i)))
(dotimes (i n-elem)
(widget-insert (format "Element[%4d]: " i))
(widget-create 'editable-field :size 40 "")
(widget-insert "\n"))
(use-local-map widget-keymap)
(widget-setup))
or as:
(defun open-file-array (n-elem)
(interactive "nNumber of elements: ")
(dotimes (i n-elem)
(find-file (format "Unnamed %d" i))))
I'm not sure to understand your last sentence; do you want an array of
file or a file containing an array of fields?
In any case, with the above character sequence, I can express both
cases formally and very precisely.
> [...]
> For those who still have no idea what I am talking
> about, I tried to illustrate the idea in notepad.
> Here it is below:
>
> Take this simple if algorithm:
>
> if x=2 then y=x+1
>
> Now set up in the 'abstract syntax tree' way:
>
> >if
> >>=
> >>>x
> >>>2
> >>then
> >>>=
> >>>y
> >>>+
> >>>>x
> >>>>y
We write it as: (if (= x 2) (setq y (+ x 1)))
> I would open the 'then' file, and have it open up only
> inside the the 'ifthen' file (unlike windows) and have
> nested windows, where the "file" and "edit" toolbar
> would pop up if I ran my mouse over that level of then
> hierarchy. Otherwise, I would dragndrop the folder out
> on to my desktop and double click it there to open it.
> Notice below, I have the mouse over
> Programming->Variables->Public.
Just have fun! First, type in NotePad:
(if (= x 2) (setq y (+ x 1)))
Then, do as you want to get in the text editor:
(cond
((= x 2) (setq y (+ x 1)))
((oddp x) (setq y (/ (- x 1) 2)))
(t (setq y (- x 1))))
wasn't it awfull?
Now try this:
- make a new folder,
- name it "if";
- open it;
- make a new folder inside "if";
- name it "condition";
- open it;
- make a new folder inside "condition";
- name it "=";
- open it;
- make a new folder inside "=";
- name it "x";
- make a new folder inside "=";
- name it "2";
- make a new folder inside "if";
- name it "then";
- open it;
- make a new folder inside "then";
- name it "setq";
- open it;
- make a new folder inside "setq";
- name it "var";
- open it;
- make a new folder inside "var";
- name it "x";
- make a new folder inside "setq";
- name it "expr";
- open it;
- make a new folder inside "expr";
- name it "+";
- open it;
- make a new folder inside "+";
- name it "x";
- make a new folder inside "+";
- name it "1";
close everything.
Now, do as you want, duplicate, rename, create or delete folders, but
get the same structure as:
(cond
((= x 2) (setq y (+ x 1)))
((oddp x) (setq y (/ (- x 1) 2)))
(t (setq y (- x 1))))
Happy?
By the way, you will have really BIG troubles when you'll want to do a
LISP syntactic editor, because the while the syntax of LISP is simple,
it's used like an alphabet, as a building block to higher level user
syntax.
So, you have: (if condition then-clause else-clause), but when you
see: (mystuff expr1 expr2 expr3 expr4), how do you label the arcs? So
you must revert to a basic tree structure with labels such as
"child-1" "child-2", etc, or to the real structure of LISP code, that
of lists, implemented over binary trees of car and cdr... Well, if you
want to edit LISP code with clicks in pop-up menus for each cons in
the source!
> These two dimensions give extra freedom to manipulate
> code.
At the cost of a big enslavement: that of the syntactic editor, which
constrains what you can write and how you can write it. Some will say
that it's a good thing that the syntactic editor allows you to write
only syntactically correct code. Unfortunately, were are not
computers. We need to write formally exact texts, but we cannot
produce them in their final and syntactically correct form out of our
brains. Remember that we're just building from little brics,
sometimes we have arches hanging in the air without their supports,
and we're constantly modifying our ideas about the problem and
therefore, the formulas we use to express it and its solutions.
Sculpting, cut-and-pasting, agregating, morphing. All these edit
operations cannot be done with 100% correct syntax. That would be a
big impediment if we had to use a syntactic editor to think our
programs. Another point I would explain with a little example of what
I do almost every days in my favorite text editor. Today, I needed to
write a group of INSERT SQL clauses. (So you would have invoked your
SQL editor and selected the INSERT syntactic structure etc...). I just
typed my first clause, ran it in mysql to be sure it was syntactly
correct. Then I duplicated and edited the copy. Then I remarqued that
I will have to do that 12 times in a systematical way, so I edited the
text of my INSERT clause, replacing in a completly unsyntactic way
some parts in the middle adding before and after some thing horribly
unSQL and arrived at this emacs lisp code:
(dolist (db '(afaa whoswho temp bamako sanga spectacles residences))
(insert (format "insert into db (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,Create_priv,Drop_priv,Grant_priv,References_priv,Index_priv,Alter_priv) values ('%%','%s','afaaadmin','Y','Y','Y','Y','Y','Y','N','Y','Y','Y');\n" db)))
Oops. You would have had to think about it before, you did not want a
SQL syntactic editor but a lisp editor! I assume you could come with
the same lisp source in a syntactic editor, no problem here. You would
probably have had to retype the whole SQL that now is just a string
literal. But then, this lisp source, I just executed it and it
produced 7 SQL INSERTs, with no complications, in the same text
buffer. Let me ask you, how will you lisp syntactic editor know that
the lisp source you just edited is generating SQL rather than LISP or
C and be able to select the right syntactic editor for the right part?
And of course one of the INSERT was not what I wanted so I just
clicked on the wrong word and corrected it, all with the same set of
basic commands to edit text, insert characters, etc.
> So this should be the standard window explorer for the
> whole OS.
Have a look at Smalltalk. You could try Squeak for example. There you
have inspectors and browsers that let you explore the whoe Smalltalk
OS, add or modify classes, methods and objects.
In conclusion, I think that syntactic editors is a wrong idea. We
don't lack the means to implement them, but they're uterly useless and
unergonomic.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.