Falling in love with D, but...

[David B. Held]

[Snip discussion of graphical language...]

This is somewhat related to Charles Simonyi's idea of "Intentional 
Programming", which never really took off (probably because Simonyi 
didn't really know what he was talking about, despite becoming a 
billionaire and launching himself into space).  I think a lot of people 
are coming to the gradual realization that syntax isn't everything.  On 
the other hand, syntax is *something*.

For instance, "sequence, selection, and iteration" is not enough to 
express the notion of functions.  And while functions do not make a 
language strictly more powerful than a language without, they do make a 
language much easier to use.  In fact, languages have lots of features 
like classes and unions and exceptions and dynamic dispatch which are 
not fundamental but are convenient.  Many of these features interact 
with each other, and this combination creates an emergent synthesis that 
is perhaps difficult to capture in purely abstract terms.  Anyone who 
has used Lisp with some mechanism built on top of it (such as CLOS) can 
see that Lisp + library to implement a feature != language with feature 
built in.

This is why languages aren't really as interchangeable as one might like 
to believe just by looking at their ASTs.  Even languages which are 
directly related, like C and C++, can have major incompatibilities 
between them.  The only way you could make a "universal" graphical 
language would be to have an "underlying language" which was the union 
of all the features of all the languages in the "universe".  This is 
clearly not practical (or even possible).

Then there is the problem that text is much denser than graphics.  Many 
graphical languages I have seen have the problem that there are too many 
graphics and not enough information.  If one small program takes up an 
entire screen instead of a mere paragraph, nobody will want to use it. 
And many graphical languages are literally toys.  Take the language 
designed for Lego(TM) Mindstorms, for instance.  It's all "plug-n-play", 
but it's nearly impossible to write an interesting program with it. 
That's why people introduced C compilers for the Mindstorms kit.

That being said, I think a graphical language would be interesting if 
designed well.  I think one thing it would have to do is recognize that 
Text is King.  I think text is appropriate for the "units of 
programming", which generally tend to be functions.  Within a function, 
I don't see much point in having fancy graphics.  However, there is 
really no reason for functions to be lined up linearly within a file, or 
for classes to be serialized within a module.  Viewing these things 
iconically or even three-dimensionally might allow for interesting new 
forms of program visualization.  For instance, I think a 3D call tree 
could be a very powerful conceptual aid, as well as the module 
dependency graphs generated by tools like Doxygen.

Within a function, I believe we are already taking advantage of the most 
obvious graphical features by using syntax highlighting.  Some editors 
even allow you to manipulate the typeface itself for various syntax 
elements.  While using color to encode syntax was a joke of the past, I 
actually think it could be useful in a language that has a lot of type 
qualifiers.  Even now D has 'const', 'final', and 'volatile', with 
'invariant' on the way.  There was brief consideration for 'unique' and 
'lent', perhaps within a model that included 'owned' and 'shared'.  And 
honestly, there are many other type qualifiers that could be useful if 
it weren't so awkward to work with them.  Nobody would want to have to 
define overloads for functions like:

   void foo(const unique invariant ref T x);

But if you just defined:

   void foo(T x);

and the qualifiers on T were indicated with colors or icons, then 
perhaps adding type qualifiers to the language would not be seen as such 
a burdensome task.

Similarly, we have to prepend 'static' to many keywords to get the 
compile-time version.  There are many ways to mitigate this verbosity, 
but one way is to visually highlight metacode in a different way from 
non-metacode.  Folding is another useful feature that already exists, 
but is generally not employed to an arbitrarily high degree.  For 
instance, if there were a way to annotate certain code as "error 
handling" or "invariant checking" (outside of an invariant block, which 
has different semantics), then one could simply fold that code when 
inspecting a function to get an idea of the essence of the algorithm 
being employed without being distracted by try/catch or if/throw blocks.

I like the direction Eclipse has gone with instant searching (which they 
call "occurrences").  This, taken to its logical extreme, would allow 
for tooltips that do everything from show the set of known callees for a 
given function to statically inferring the throwable exceptions list.

But just being able to see many functions as sticky notes that can be 
manipulated independently and juxtaposed arbitrarily would be immensely 
powerful, IMO.  Being able to hover over a function call and have the 
function definition pop up in another window, or have a command to 
recursively expand all functions called from here down to a certain 
depth could make code exploration go from a painful chore to an exciting 
adventure (ok, that's a bit of marketing hype there, but you get what I 
mean).

The problem is that we write programs linearly, but they don't execute 
linearly.  So to trace the flow of a program, we hop around numerous 
files and modules scrolling this way and that trying to figure out 
what's going on.  Being able to see functions forming a visual call tree 
and zoom in on each one on demand would truly bring programming to life. 
  The funny thing is that none of this is particularly difficult or 
revolutionary...it's just a heck of a lot of hard and thankless work.

The connection back to Intentional Programming and 
programs-as-files-is-obsolete is definitely the idea that identifiers 
should probably all be numeric database keys, and programs should 
probably be stored in intermediate form with the visual form generated 
on the fly (which is what I understand you to be expressing).  That IL 
isn't completely language-independent, but it certainly does allow that 
program or library to be visualized in a multitude of ways.  It also 
allows refactoring to proceed much more accurately, because the compiler 
has a much better idea of what you mean.

Perhaps it is something of a pipe dream to imagine that Eclipse could be 
taken to this level, but I think it would be a fantastic progression in 
tool evolution if this were to happen.  The problem is that this kind of 
IDE is so fundamentally different from your average text editor that 
there may be nothing to leverage.  Anyway, if anyone is interested in 
working on something like this, I would definitely try to make some time 
available to help out.

Dave

P.S.  This could be accomplished for D by designing a database schema 
that stores programs in an intermediate form and generates D source from 
that form, which feeds directly to the compiler.  The IDE would let you 
"define classes", "implement functions", etc., rather than "write text". 
  This is how it would be able to generate the intermediate form 
directly.  It would still have to know about language syntax so that it 
knows how to look up references, etc., so it may need to keep everything 
in a full-blown D AST all the time.  It would be a challenge, no doubt, 
but it could be a really fun challenge.