The problem with your idea is in the implementation. Developing a
tool/language as you have described it is in some ways the Holy Grail of
software development. Almost by definition, having detailed control over
the operation and features of a piece of software will add complexity to the
source code and development. C++, although complicated, allows a high level
of abstraction from the code development. Object-oriented languages
encourage "black box" objects that can be extended and reused without
knowing the details of the code involved. You could build a very complex
application by gluing together pre-made objects and writing very little
source code, without the slightest concept of what was actually contained
inside the objects. This is the power of the paradigm.
At the same time, to have true freedom in application development, you must
be able to write the low-level code yourself and develop your own objects
from scratch. Otherwise you would be forced to use the objects and tools
available, limiting the freedom and range of applications and features you
could develop. Consider the mTropolis tool you described above. It has
been abstracted to the point that it is very easy to learn and develop
applications in. Although, I have never used it, I guarantee that it
doesn't have all the features and options you would have if you coded the
same application yourself using C++.
Suppose you built a programming tool for building software at a very
abstracted level. If you told it "Build me a wordprocessor", it would pop
out a wordprocessor. But how would you control the features? So you tell
it explicitly what features you want in this word processor. But then you
would be faced with the problem of controlling the features of each
particular feature, properties of each feature, the interface of each
feature, the limits of feature complexity, etc. By the time you defined
every aspect of every property of this piece of software, actually coding it
would take very little time by an experienced programmer. In fact, a
properly thought out and designed C++ program that takes advantage of
existing objects doesn't take much more time to actually write than an
identical program written in highly abstracted object-oriented languages.
The difficulty in software development isn't in the coding. It is in
defining the features you want, the properties of these features, and how
the features interact with each other. This engenders a level of complexity
that cannot be avoided.
And, in fact, there are graphical tools that allow you to develop detailed,
complex applications in C++ based entirely on a graphical design interface,
with essentially no code writing. But using these tools requires that you
have a very good understanding of the capabilities and features of the
software that you want it to write. The problem is, most people don't
*want* to think about the software they want. They just want software to be
magically generated, that magically knows exactly how you wanted it to
operate in exactly the way you wanted.
The limitation, therefore, isn't in the tools themselves, but in the ability
of humans to express exactly what they want the tools to do.
-James Rogers
jamesr@best.com