Re: Are these all really true ?

gdevivo@conicit.ve (Gabriela de Vivo (UCV).) writes:
> ===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======


A question which demands an absolute answer, but which can't have one.
Are they generally true? Possibly. But I doubt if any are always true.


> * Strongly type language result in better programs.


I'd say so, but programmers are a weird bunch. We get annoyed at
our strongly-typed languages for getting in the way, and get
annoyed at our weakly-typed languages for not spotting our errors.


> * Performance is a language problem.


It is (a C compiler in Prolog *probably* runs slower than a
C compiler in C), but it's also a problem of algorithm choice,
language implementation, etc. Choose the right language for the
job, but don't expect it to solve all your other problems.


> * Compilation is better than interpretation.


Aha. Depends on the application. I've recently had experience of
two embedded systems tools, one a compiled solution, and one an
interpreted solution. The compiled one is much faster, but the
debugging capabilities of the interpreted solution is better. The
details aren't worth going into, but to emulate the interpreter's
behaviour in the compiled solution would require a massive increase
in the size of generated code.


> * Memory is free, speed is what is worth optimizing.


Actually, your algorithms are what is worth optimising. That way,
you might get more speed, and still use less memory. After all,
if you're running on a multi-user system, and you use just too
much memory, your process will spent most of its time in page
faults.


> * Multi-threading is better than single threading.


Again, depends on the application. Generally touted as excellent
for, say, GUIs and servers, but doesn't make a lot of difference
to the average compiler.


> * Specification and design can be performed with no knowledge of implementation.


Um. Depends on your contractual obligations, probably. :-)


> * Programming, testing, packaging are easy, design is hard.


Right, I'd say, except that proper testing is a pig.


> * Formal specifications yield correct programs.


"Might". Formal specification might yield correct programs. Depends on
the method used, the application, the tool support, and the designers
(who have to understand what they're doing, or all else is in vain).


> * Applications contain a substantial number of algorithms.


Well, yes, although some of them are not recognised as such, and
not formulated clearly. After all, if you remove the data structures
from the program, what you're left with is a pile of algorithms.


> * Industry uses ... C++, CORBA, Windows, UNIX, ...


Yep. Apart from CORBA. We occasionally buy products that claim
to conform to CORBA, but I haven't noticed a lot of people
spouting how CORBA support in their tools has changed their life.


> * Industry has better or worse tools.


Uh-huh. Pretty much, what we've got is a pile of tools which
were knocked together in a hurry, have no formal basis or testing,
appaulling documentation, and lousy interfaces. On the other hand,
they were built to perform a specific job, and they do it well.
Until all goes horribly wrong, and another article is posted to
comp.risks, of course. This is all in contrast to the more
formal, academic approach which results in a proven system, but
which doesn't actually do the job now required.


> * Industry runs on wrong hardware and software platforms.


Depends on your definition of "wrong". Generally, the hardware's
here, and no, you can't have budget for anything new, so you'd
better use it (actually, isn't this the same for almost everyone?).


> * WYSIWYG is better for all applications.


Usually, although whatever stops you from getting it wrong is
generally best.


steve
--
<Steve_Kilbane@cegelecproj.co.uk>
--

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