Re: We need better tools to make better tools.

James Rogers (jamesr@best.com)
Sun, 01 Dec 1996 19:52:04 -0800


>I have programmed a bit in c++ and i hated every moment of it. That
>language is very powerfull but the interface is really really bad.
>
>There's a new multimedia tool out now that builds on the object oriented
>principle as well that is called mTropolis. http://www.mfactory.com It is
>really powerfull but won't quite fit as a tool to make tools. It is a
>multimedia development tool and very efficient as such. It has a graphic
>metaphor that makes true object oriented programming seem very simple.
>(Learned in a day or less.)
>
>What we need is a development tool with the power of something like c++ or
>Java combined with the ease of use of something like mTropolis. The tool
>should have an emphasis on being extensible in a way that would make it
>easy to use it to make new and improved tools with.
>
>When we have that we will develop new tools to develop new tools with.
>
>Something like c++ really doesn't make it a lot easier to make new
>languages with. It doesn't know enough about computers, Computer-languages
>and operating systems. It is implicit in the language that the programmer
>must know it all to use for making next gen tools.
>
>That is what i think is an original idea here. That the software should
>"know" something about what it's supposed to be used for in the next
>generations. It must be designed to be a tool to make tools with.

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