Re: Are these all really true ?

Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) writes:
> gdevivo@conicit.ve (Gabriela de Vivo (UCV).) writes:
> > ===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY 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.


What a succinct observation! Wish I'd said that.


> > * Performance is a language problem.


I'm not sure I know that this statement means. Does it mean that
performance is due to an inappropriate choice of language? If so, then I'd
say that's hardly ever true. Performance problems are usually a problem of
inappropriate choice of algorithm. The next most likely cause, in my
experience, is just too much work and not enough horsepower.


Alternatively, perhaps this statement means that performance problems are
due to bad implementation of the language. Again, I wouldn't agree with
that one either.


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


It is true that there are some choices one can make in
which you can trade "a little" memory for a lot of speed, and that's
generally a good choice. Unfortunately, most applications today treat
memory as being much cheaper than it really is.


> 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.


Agreed!


> > * 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.


Hmm, actually there are a lot of algorithms in most compiler optimizers
that could benefit from parallel processing.


Besides, whether multi-threading is better depends on whether there are
additional CPU resources available. Multi-threading isn't worth very much
if you're still compute-bound and all those threads still have to run on a
single CPU.


So, if you have a compute-bound application but you also have multiple CPUs
available, multi-threading is still likely to be a win.


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


I'd disagree. With that approach one can easily specify (and design)
features that either cannot be implemented or that cost far too much to
implement for what they are worth.


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


Testing, if you intend to do a thorough job, is an order of magnitude (at
least) harder than programming. I'd put it basically on a par with design.


> > * Formal specifications yield correct programs.


I think there is far too little data on which to base a conclusion. I
believe that, as the application gets larger and more complex, a formal
specification becomes large and complex also, and therefore harder to
understand and more susceptible to errors. Even if you get such a
specification correct, how good are the chances that the program will
follow it?


> > * 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?).


I agree. Also, "industry" usually runs hardware and software that are
several years old and at least borderline obsolete, because the hardware
and software for a major project are chosen years before the project gets
to the field.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

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