Falling in love with D, but...

[Georg Wrede]

Peter Verswyvelen wrote:
> Such a code analyzer is a really useful tool indeed.
> 
> But as what I actually meant, is more like what Dan said: instead of taking text
> as the format of the "source" code, we should use a code-DOM or something
> structured like an AST, where symbols are either defined or referenced directly by
> pointer/id, not by name.  Code style and formatting is then pure meta data, just
> present to reconstruct a textual view in a particular style. Given other
> presentation related metadata (e.g. node X,Y positions), the code could just as
> well be presented using a graph with nodes and edges. In the fantastic "structure
> and interpretation of computer programs" video lectures made in the eighties this
> was already mentioned somewhere. If you want a crash course in programming, this
> is still amazing stuff:
> http://video.google.com/videoplay?docid=5546836985338782440&q=structure+and+interpretation+of+computer+programs
> 
> Now this already existed on the Commodore 64, in an assembly language editor: when
> you typed a line of assembly, it would be parsed immediately, and symbols got
> resolved lazely on the fly. There was no need to parse the whole program anymore,
> just linking was needed, so it was really fast (I believe the program's name was
> "Turbo Assembler", but it had nothing to do with Borland). Also, the code got
> automatically formatted and syntax highlighted, and symbol lookup was easy.
> Ofcourse, this is really simple because of the simplicity of assembler, but the
> principle remains.
> 
> Todays refactoring tools and intelligent editors have a really hard time to sync
> their internal code-DOM with the text; just deleting a curly bracket messes up the
> whole DOM, making refactoring a fuzzy adnd dangerous concept; clearly a more
> structured (and faster!) way of entering code could be enforced, but then of
> course we all should adapt, and we don't like that, the tools should adapt to us
> no? ;-)

Representing code as graphs with nodes and edges is IMHO not all too 
dependent on the underlying programming language. Basically you always 
have the same three parts in any imperative language (namely sequence, 
selection and iteration). Representing those graphically removes the 
need to be coupled to a specific programming language.

Of course you would represent structs and objects too, but behind the 
scenes they could just as easily be mapped to even a non-OO language, 
and you'd never know, unless you specifically wanted to alternate 
between the graphical and the textual representation.

If somebody created such a graphic environment (and wanted "the source 
code accessible too"), it would not be too much of an additional effort 
to also have several languages as alternate choices. You'd probably be 
able to switch on the fly between those programming languages.

After all, you'd be conjuring up the essence, the aspects, the actual 
logic, and the structure, instead of choosing between the syntactical 
choices or semantic details.


All this of course forgets the fact that the graphical representation 
constitutes a Programming Language per se! So, strictly speaking, the 
"underlying" programming language isn't even necessary. [1]

If you search in the archives, you'll see that I suggested this 
precisely same thing some three or four years ago in this very 
newsgroup. At that time it was D related, but today my view has changed, 
as you see here. :-)

In some sense (in addition to what's been said in this thread), the old 
Borland GUI editors did much of the same. Essentially the same program 
created the UI for both C++ and Pascal. It was bundled with both, only 
with a different language back-end, which probably only was a set of 
code snippets and rules in a database, from which it picked what it 
needed. They also had an equivalent code generator for character-UI 
programs that worked in the same way. Several prominent products were 
generated with it, for example the Alpha-Four database (a real gem!)

Of course, here you didn't use drag and drop to directly create language 
constructs, instead you drew up the UI and the input field connections, 
but the idea is pretty much the same.

Then you of course have the round-trip UML tools, some of which create 
code for more than one of Java, C++ and Pascal.


Back to the issue at hand, the essential part of such a tool is the 
actual "graphical programming language". The target audience should be 
carefully decided on, or the whole thing becomes just "a little for 
everybody, but not enough for anybody". (I suspect that within the 
foreseeable future we won't have enough know-how to create a really 
universal GUI-language. Later, it will become reality, though.)

This being a D newsgroup, the default idea is of course that of "a 
general purpose" thing, or even "a systems programming" thing. But I 
have a hard time imagining Linus Torvalds dragging iterative constructs 
across the screen for the ultimate core in a serious OS kernel project.

I admit that in the long run we seem to be headed towards practically 
all programming being drag-and-drop (or at that time, grab-and-drop, 
once the UI hardware becomes way more subtle and hominid centric).

But for the time being, developing, say, this graphical thing for 
"essentially all things D would be used in" would be a tall order. 
Rather, things like network programming, web servers, database front 
ends, or even middle-tier glue SW, robotics, toys (e.g. advanced 
Tamagotchi SW design, GameBoy apps), point-of-sale cash register SW, 
medical systems, would seem like a good idea.


It may be possible that for hard-core programming, the keyboard won't go 
away, not even in a thousand years. Think about it: we have computers, 
we have (or had) regular typewriters, the ball-point pen, dictaphones 
(small sound recording devices for notes and letters your secretary 
later typed for you), mobile phones, calculators, and whatnot. And still 
today the number of regular pencils around exceeds that of computers, 
mobile phones and calculators combined.

Speech recognition, GUI programming, AI, and whatever other /plate du 
jours/ all had their try, but we still bang away like nothing ever 
happened. Also, the interplay of writing, seeing, reading, and 
communicating, really is a paradigm that has proven itself in areas 
vastly more broad than computer programming. Anything where the meaning 
has to be universally understandable, unambiguous, or thoroughly fixed 
-- law, procedures, public statements, speaches, in-depth system 
descriptions, J. Edgar Hoover's files, medical record statements, 
species descriptions, cake receipes, the US Constitution...

So, "graphical programming" is unlikely to usurp "emacs programming" in 
our lifetime, in the general sense. But for some niches, it probably 
will be a killer.


PS, sorry, I didn't intend this to be a bazooka attack on you, or this 
thread in general. Just aired my 3.14 cents. :-)

----

[1] Upon proofreading, it occurred to me that if there does not exist an 
"underlying" programming language, then the graphical representation 
might have a lot more freedom to express ideas. But this is not even a 
thought, it's merely a hunch. I probably should think some more about it.

Of course, ultimately any such thing is representable by at least an 
Assembler listing, so one could argue there's _always_ a programming 
language as the back-end.

But then another could argue that it's having a _specific_ language here 
that hurts. If we pretend not to have any such language, then we're free 
to wave hands as we please and decide upon the meaning of such without 
(at least undue) restrictions.

Extremely interesting. And there'll be a heck of a practical difference 
between early implementations, I'm sure.