Re: Are these all really true ?

> ===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======


> * Strongly type language result in better programs.


Obviously a language without strong types can have programs as good as a
language with strong types, however a language with strong types, it is
easier (IMO) to develop a good program.


> * Performance is a language problem.


No, but what do you mean by performance, do you mean exactly the same
program? if that is so then merely changing the algorithm will have a far
greater impact than changing the language. Working on the (IMO totally
valid) premise that assembler can be the most efficient, some languages
can be translated to better assembly than others (ofcourse the quality of
the compiler is important here)


> * Compilation is better than interpretation.


Both are very useful, however interpretation takes more memory and runs
slower. The advantage is it is easier to develop and make minor changes
in a language with an interperater. Now if you add up the time saved in
running the program then I suspect you will find it always best to have a
compiler (even if an interpreter was used in development).


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


Which would most users prefer, for a program to be 10% faster or to use
10% less memory? and while I haven't looked very much into memory
optimization I suspect it would be easier to get the 10% speed then the
10% memory.


> * Multi-threading is better than single threading.


Well I certainly think so!


Why would you possibly want to go back to single threading?


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


No knowledge... I think more that the details can be worked out later, any
programmer good enough to write specifications and design programs will
have enough experience (IMHO) to know whether something can be implemented
or not immediatly.


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


Not so sure about testing but certainly I think the hard parts in
programming (or atleast the parts I don't enjoy) occur when there is a
flaw in the design. Given a good design, coding it in is generally easy,
you can clearly see exactly what each bit/procedure/whatever should return
and that kind of programming is generally easy.


Basically programming with a good design is easy, programming with a bad
design is hard but why not make the design good if it doesn't cost time
overall?


> * Applications contain a substantial number of algorithms.


How do you define algorithms here? Using a definition of functional
mapping, ofcourse they do!


Algorithms in the sence of 'depth first ....' will probably not occure
very much at all, but they are the areas in which good programming makes
more difference than bad.


> * Industry has better or worse tools.


Ummmmmmm this reads like p v ~p to me... perhaps you could explain what
you meant?


> * WYSIWYG is better for all applications.


Not all, but IMO most. Do you mean graphics or 'WYSIWYG' here? (expanding
the acrynym) if the former, then certainly there are applications where a
graphical design is probably worse than a non graphical one, non graphical
designs (in this sence) constrain input to a very small number of choices,
if you have an application where there is very little (or no) user input
then you could get by perfectly well without graphics.


If you meant WYSIWIG then when is it better to have graphics in a
different shape to what is printed?


--

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