Falling in love with D, but...

[Peter Verswyvelen]

Indeed, Smalltalk was really cool, revolutionary maybe. But for
some reason, it never really took of did it? It's still alive, so
it might still one day reach a huge audience...

As you said, a good IDE should at least seperate the model from
the view = model/view/controller design pattern from...
Smalltalk! ;-)

*** warning *** random confusing brainstorm follows...

The way I see it, is that you actually have a "core-model" which
is the representation of the language in a format suitable for the
machine. Attached to this core-model are many meta-models that
hold meta-data required for the views that represent this language
in a human readable and editable form (for example, the XY
position of a flowgraph node or comments). This model is not the
same as the compiled module; it is much closer to the intermediate
structure between the frontend and backend (some kind of decorated
AST?). It is this model that is THE source (read D source ;-), and
that is stored on disk, NOT the text which is a lossy
representation of the model. E.g. it would become impossible to
use a plain text editor to edit the textual representation,
because this would break the links between the view and the model.
So the model can be represented both textual and visual, and might
support many different textual and visual languages. And yes, when
using text, it would be great to be able to finally get rid of the
ASCII format, and have rich text with math formulas, multimedia,
interactive applets, etc, much like the web, but cleaner (I really
hate web technology, it seems to be invented by managers instead
of computer scientists ;-). The underlying format of this "rich
text" should again be the core-model, just as Scheme/LISP trees
can be used to describe any datastructure using the language
itself (e.g. a language must allow the creation of embedded mini-
languages)

A (bad) example of this is Microsofts .NET assembly format. Using
a tool like Reflector you can reverse engineer the assembly into
C#, Visual Basic, C++, Delphi, F#, etc... (I guess the same goes
for Java class format?) Of course, this is NOT the way it should
be, because this assembly format seems way too low-level, and it
misses metadata needed for good representation. One can use a tool
like Phoenix to get a higher level model from that, but this looks
like the world upside down.

I think it is impossible to come up with one view/representation
that is suitable for all needs. Some people might prefer a textual
approach (which could be imperative, functional, OO, logical, etc
by preference), others would prefer visual representations, and
most of us will prefer a combination (as you said, UML for the
overview, text for the implementation, maybe some flow-graphs or
state-machines using visuals, etc). But the model should be
the "single-point-of-definition", so that the different views
don't get out of sync and so that fully round trip engineering is
possible (I believe all good UML tools already do today). The same
goes for documentation and all other "derived" code; it should be
stored into the model objects.

By e.g. using unique numbers inside the model instead of symbols
and strings to identify entities (compare with numeric primary
keys in SQL), cross module refactoring and version control merges
become much less of a problem. Today one must make sure to include
*all* models in a project when refactoring, otherwise you're
screwed. A golden rule in OO is that if you can't find a good
name, your design must be wrong... But this means I always have
bad designs because getting those names right the first time is
d*mn difficult! Okay, lets take an other example, Microsofts
WPF... It has a method called "FindName". What does it? I believe
it finds an element in the tree by name, and returns a reference
to that element or null when not found. Well, IMHO that should be
named FindElementByName or at least FindByName, so lucky for me,
even the "pros" don't get it right the first time ;-) So we can
conclude that *humans* never get it right the first time (and
maybe even GOD needed 7 refactorings instead of 7 days to create
the universe ;-), so a good IDE, language and filesystem should
have refactoring support very high on their requirement list.
Furthermore because we can't do it alone (okay, excluding Walter ;-
), version control and team support must be very high too (without
the need to perform SVN CLEANUP all the time...) The same goes for
testing, fast turnaround times, textual+visual debugging, etc... D
provides a lot of this, but I think the (r)evolution will only
happen when all these things are integrated in one big masterpiece
working in harmony, instead of trying to get decade old systems
and ideas to work together.

Major advances in science do not happen by inventing something
new, but by presenting existing ideas in a way accessible to many
(btw, this is not my quote, I believe comes from the E - The story
of a number ;-) Liebnitz and many others prooved that, and I think
Anders Hejlsberg also proved it; see Turbo Pascal, Delphi, C#,
LINQ, just to name a few. When I first tried Symantec C++, I hoped
it would happen too, but - sorry Walter - Symantec made a huge
mess of your amazing C++ technology; I can't tell you the
frustration I got after buying Symantec C++, its still on my list
of the buggiest IDEs I ever bought, together with Borland C++
Builder (after which I abandoned Borland and sold my soul to the
Visual C++ devil ;-) Well, the big yellow Symantec C++ box that
contained enough books to fill a libary still looks cool tough,
and the visual debugger that could show the relation between
objects at runtime, man that was cool for its time, if only it
would not have crashed all the time. Okay, I really got carried
away here, and I might find myself on thin ice now :)