Re: UNCOL = Uncool?

Chris F Clark <cfc@world.std.com> schreibt:


>Moreover, with any of the above choices one gets an "optimizing"
>compiler for each of the supported languages for just the price of a
>single code generator port. That's a lot cheaper than writing
>n-optimizing compilers for your target.


Certainly you are right, from the viewpoint of a compiler
provider. But in practice other arguments may apply, as I want to
outline with a concrete example:


The Borland JavaBuilder is written in Java, and requires 96..192 MB of
RAM for a project, where Delphi would be happy with 64 MB of
RAM. Since I only had 64 MB of RAM at that time, every keystroke in
JavaBuilder resulted in a pause of seconds until minutes, where the
system was busy with swapping. This behaviour affects both the author
of some program, which cannot qickly input his code, and also affects
the user of the final program, which may feel the same penalty, due to
the choosen programming lanugage and model.


Now you may object, that I only should have more RAM, as I have in the
meantime. But there remain other points, which are subject to other
considerations.


The success of any programming project depends on 2 factors, the cost
of the implementation, and the acceptance of the users. The
implementation view was and is honoured by the existance of hundreds
of languages, each of which is dedicated to a specific kind of
problem, or is designed as a highly portable language. The marketing
success depends on the speed and consumption of resources at the user
site, which IMO is reciprocal to the same properties during
development. And consequently no development system can exist, which
can create the best application under all circumstances. No?


No! If we assume an UNCOL, equipped with cheap front- and back-ends of
any kind, then I'm sure it had been invented already.


But acutally the choice of a specific language enforces a specific
programming model, which will result in as more runtime overhead, as
OTOH it saves development time. The same effect will increase runtime
overhead with every abstraction from a specific target
platform. Choosing the most comfortable development system and the
most stupid programmers then will result in the least development
efforts, and in the least user acceptance. The acceptance will
increase with every deviation from a portable and universal
development tool, until finally assembler experts are tailoring the
project to a specific target platform.


Too hard? Maybe, but "cum grano salis" I think that my argumentation
is not very far from the actual (or general?) situation.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.