Re: Are these all really true ?

Scott Nicol <scott@infoadv.mn.org> wrote:
] >* Strongly type language result in better programs.


Strong typing is necessary to ensure a minimum of machine independence.
In case you meant staticly typed: static typing is good in that it generally
allows faster implementations and it forces you to structure your program a
little more. But dynamic typing can prove very useful at times, doesn't prevent
good structuring and can still produce very efficient code. On another hand,
type annotations are a good documentation too. I guess dynamic and static typing
should merge at some point.


] Better in what sense? There are fewer hidden side-effects, but
] side-effects aren't always a bad thing. It really depends on what
] the language is designed to do. For example, awk would be unusable
] if it were strongly typed.


awk is definitely not statically typed, but I don't know if I'd consider it as
strongly typed or not. Anybody cares to comment ?


] >* Performance is a language problem.


In the short term, it might be true. But lousy performance can be had from any
language. And good performance can often be had from most languages too, even
though some languages are a lot harder to compile efficiently.


] >* Compilation is better than interpretation.


It's all the same anyway: most interpreters preprocess the program (through
lexing/parsing/byte compiling/...) and it's often trivial to generate assembly
code from most intermediate representations: the isuue is more about how much
work is done to optimise the execution. Any developpement environment should
offer several optimisation levels from very low to as high as possible. The
lowest level of optimisation should enable "immediate" execution (the
compilation time should be negligible).


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


No. Memory is not free, far from it. Current CPUs spend so much time
idling that it gets more and more interesting to give them more work
in order to save a few memory accesses and even more so if you can
save cache misses.


cdr-coding is not very fashionable these days, but I still think it can be
very competitive (with current technology).


] >* Multi-threading is better than single threading.
] Depends on the algorithm, language, machine, OS, ...


It's good in that it allows parallel execution (I know parallelism has been
announced for years, but small SMPs are definitely getting common these days).
Else, it only makes sense if it eases design/implementation (as for GUIs).


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


If you really mean *zero* knowledge, I can only disagree.


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


Testing is hard. That's why CS people try to develop ways to avoid it
(formal verification and such).


] >* Applications contain a substantial number of algorithms.


So what ? They also contain a substantial proportion of code devoted to
interfacing and such. Does anybody know if bugs tend to show up more in
algorithms or in other "boring code" ?


] >* Industry runs on wrong hardware and software platforms.


Wrong hardware probably doesn't exist in the sense that you generally shouldn't
have to care what the hardware is.


] >* WYSIWYG is better for all applications.


WYSIWYG sucks just like color-movies: it's too often used to hide
fundamental deficiencies behind pretty pictures. Of course, "drowning
by numbers" is an amazing color movie, just like it's possible to
make a great WYSIWYG application. It's just a lot less frequent.




Stefan
--

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