From: James Rogers (jamesr@best.com)
Date: Mon Dec 02 1996 - 19:33:18 MST
At 12:44 AM 12/3/96 +0100, you wrote:
>> 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.
>
>Yes thats right. But in some obscure way the purpose of a high level
>language is not to make us able to do more. It is to make us able to do
>less, but do it more efficiently.
>
>Hardware - Binary code - Assembler language - c-code - multimedia tool
>
>As a software pro you certainly know about the different program levels.
>What i say is that it should be possible in some way to make a tool that
>will improve our tools for making tools. I could easily imagine languages
>like c++ or Java redone with a completely graphical interface that you
>could learn to use by using it. Done right it should speed up the software
>creation process. Perhaps it could even be so simple that artists and
>psychologist could use it to improve its own interface with. If this could
>be done recursively we could have a really strong tool in the end.
>Perhaps the tool could be so powerfull that it would be easy to make
>updates all the way back to the assmbly level.
>
This is sort of true, but not entirely. Assembly code, for example, was a
true improvement. There is nothing that you can do binary code that you
can't do in assembler. The improvement was that assembler more closely
matched the way humans thought when writing code. C on the other hand, was
only an improvement in development cycle efficiency, in exchange for a
decrease in run-time efficiency. Tailored development systems are both good
and bad, depending on the context. In the context of a specific
application, such as a multimedia tool, it can be very advantageous to have
a language that is specifically tailored to that application. On the other
hand, if you are required to program many different applications, it can be
a significant burden having to learn a new specialty language for every
application you are trying to develop. This is the strength of the C family
of languages. Although C is not specifically optimized for any particular
application, its versatility is well-suited for almost any type of
application. And with C++, the language can be customized to be well suited
for specific applications.
>
>> 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.
>
>Yes but it doesn't have to look like gibberish.
>
Whether or not it looks like gibberish depends on the programmer. If you
want to program at the assembly level, the code will *always* have to use
the very explicit and terse structure of assembly code, no matter how it is
represented. Programming at any level is restricted by the limits and
definitions of that level. By definition, if you are going to program at a
low level, it *will* look like low-level code. The level of a language you
work with is really dependant on how much of the true nature of the machine
you want to see and work with. High-level languages hide the true nature of
the machine at the expense of not being able to manipulate the details of
this nature. It is unavoidable.
>> Consider the mTropolis tool you described above 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++.
>
>Thats right. and it isn't supposed to. It was just an example. But still
>it's a pretty amazing example of how good an interface for a programming
>language can be. if you have acces to a Mac try and download the trial
>version and you will se what i mean.
As for mTropolis, yes, it may be a good interface to a programming language
IF you are interested in developing multimedia software. But what if you
are developing another type of application? I personally develop a broad
range of applications ranging from databases to network applications to DSP
software. No one tool as you have described will give me the ease of use
you describe AND be ideally suited for developing all these applications.
And what about large applications that have many different aspects? Without
a single, common underlying language, how would you integrate all the
components of that piece of software? I need a single tool that will allow
me to develop all my applications. Sure, this may require a certain level
of abstraction, but at least I don't have to learn a new language every time
I need to do a new type of application.
Admittedly, C/C++ is a intricate and complex language to learn. But the
plus side is that once you learn a couple languages and start developing,
you will find that these languages can be nearly as efficient and always
more flexible than the highly abstracted ones. And after you learn a couple
of the "difficult" languages, new (even difficult) languages will come very
quickly.
>> 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.
>
>This is exactly what i mean. What i don't like about the traditional
>languages is that the interface between the tool and the user is so weak.
>The user has to know to much to use the tool. Its very nonintuitive.
You are confusing knowing how to use the tool and knowing how to use the
computer. The design of tools like C and C++ reflect the nature of the
computer. This is important because the tools are specifically for the
purpose of controlling the nature of the computer. If it is nonintuitive,
it is because you don't yet know enough about the way a computer works to
program it.
>As far as i know no one has still to try to make a graphic programming tool
>that can be used for serious system development, and i don't mean something
>like Visual c++ or any of those kind of interfaces they are just a hack.
>
This is because every time you abstract the language from the machine, the
language becomes less useful as a general programming tool. You cannot do
serious system development if you don't understand how the system works.
And understanding how the system works requires the knowledge that makes the
usefulness of languages such as C and C++ apparent. Those languages make
more sense than the really high-level ones if you understand what is
actually going on.
For some uses, I can understand what you are saying. Some things, like
multimedia, don't have a very large custom code component, and are therefore
easily abstracted. Other applications, such as database or systems
development, require very thorough knowledge of data structures, algorithms,
and fundamental constructs of computer science, no matter which way you
slice it. You cannot effectively develop some applications without having
the detailed knowledge you seek to avoid via highly abstracted tools.
>> 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.
>
>I want the tools to help the humans express what they want. I want the tool
>to be something that you learn to use by using it.
Somehow, this statement doesn't make sense to me. You always have to have a
minimum base of knowledge before you can attempt to use any tool.
>Everybody (almost) agrees that the GUI is a better way to comunicate with a
>computer than a command language. Everybody except system developers. Eh...
>things that makes you go hmmm...
Actually, a lot of CAD types prefer keyboard control to mouse control
because it requires less work, even though they work in a graphic
environment. GUIs are the anti-christ of ergonomic efficiency.
As most programmers will tell you, *IF* you know what you are doing, a
command language is always more powerful and efficient than a GUI. So for
system developers, a command language *is* a better way of communicating. A
keyboard is always faster than a mouse and a command interface contains far
less extraneous information than a graphical one. I almost always get more
development work done with a good text editor than with a fancy graphical
environment.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:35:52 MST