Re: Are these all really true ?

Before I comment on anything else, I disagree that many of the following
assumptions have anything to do with academia. I'll point out examples
as I go.


>===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======
>* Strongly type language result in better programs.


This one is actually often debated in academic circles. Scheme, which
is one of the darlings of the academic language community, is not
strongly typed.


As for whether it's true... The answer is both yes and no.
It depends on the application you're implementing. For some applications,
the effort necessary to copy with heterogeneous data in a strongly
typed language is prohibitive - and so a weakly typed language is
preferable. On the other hand, strong typing, particularly with
a well designed type system, is a remarkably effective tool for
eliminating errors at compile time. (As a simple piece of anecdotal
evidence, I've never written in SML program which hasn't run perfectly
the first time it passes the compiler. The time system is sufficiently
strong that most of my logic errors also manifest as type errors.)




>* Performance is a language problem.


I don't know of *anyone* in academia who would say this. Performance
is an *implementation* problem.


>* Compilation is better than interpretation.


Again, this is not a clear-cut academic position. For *some* purposes,
compilation is preferable. For *some* purposes, interpretation is
preferable. And for some purposes, some combination, like bytecoding
or runtime compilation is preferable. I don't know of anyone in
academia who would state that compilation is always preferable.


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


This is a generally accepted belief, which has been losing support
recently. It was thought, until fairly recently, that as technology
advanced, the amount of available memory would continue to increase
exponentially. So, given that assumption, it is generally preferable
to optimize speed at the expense of size.


But as the ratio of processor speed to memory speed has been growing
exponentially, it's become apparent that in order to optimize speed,
you've got to optimize memory usage. It does no good to cut the number
of executed instructions if the processor is constantly stalled, waiting
on a memory address.


>* Multi-threading is better than single threading.


Again, I don't believe that this is a general academic position.


I would say that most people in academia believe that multithreading
is useful. It's a good thing to have available when you need it. But
no one believes that it's always needed, or that a multithreaded
application is automatically better than a single threaded one.


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


I don't think that anyone with any knowledge of software design would
actually say this. What's generally believed, and taught in most schools,
is that implementation *follows from* specification and design.


When you're doing design, you shouldn't do it in terms of a particular
implementation. You should do high level design in terms of what kinds
of behavior is required from your software. A good design says that
"This feature requires an ordered collection of data, which can be addressed
quickly, and allows rapid insertion of data in any position," rather
than saying "This should be implemented as a skiplist."


But no one suggests that the designers have no knowlege of implementation.


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


Again, I don't think that anyone says this.


I do think that it's generally believed that design is harder than
programming. But I don't think that anyone thinks that programming
is easy - just easier than design. And testing of real applications
is *extremely* difficult.


>* Formal specifications yield correct programs.


Formal verifications yield provably correct programs. But formal
specifications without verification do nothing except state the
design requirements in unambigious terms.


>* Applications contain a substantial number of algorithms.


This is a tautology. Of *course* applications contain algorithms - an
algorithm is nothing but a description of a computational procedure. If
the application does anything at all, it contains algorithms. If it
has a substantial number of features, it has a substantial number of
algorithms.


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


There is a common belief that industry uses C++. Also that Windows is
far more widespread in industry than Unix. But there's also an awareness
that there is still more code being written in COBOL than in all of
the other languages combined.


>* Industry has better or worse tools.


Yes. I'd say that industry definitely has either better or worse tools. :-)


>* Industry runs on wrong hardware and software platforms.


There is a lot of frustration in academia, because in the real world,
people are using operating systems that are literally decades behind
the state of the art. I mean, let's face it: one of the big selling
points of windows95, is that you can crash one application without
having it crash the whole OS. Real operating systems, both in academia
and industry, have been that way since the early 70s!


>* WYSIWYG is better for all applications.


I don't know of *anyone*, in academia or industry, who believes that
WYSIWYH is better for all applications. It's terrific for some things,
dreadful for others. Most academics seem to realize that - otherwise,
why do so many of us choose to use LaTeX instead of a commerical word
processor?


<MC>


--
|| Mark Craig Chu-Carroll: <MC>
|| CIS Grad, U of Delaware
|| PGP key available by finger
|| carroll@cis.udel.edu
[not early 70s, early 60's, actually, -John]
--

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