Re: Are these all really true ?

Corrin Lakeland (lakeland@sans.vuw.ac.nz) wrote:
: > ===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======


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


Interpreted code can use considerably less memory than directly executed
code if a good representation is used. Look at the compilers (such as
Microsoft's) that have an option for generating intrepreted code as a space
saving mechanism.


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


Memory is only free provided you are not using it all.
In the embeded application world memory can be very limited. In a virtual
memory environment you may have as much as is on your disk space, but if your
working set goes over the amount of real memory available then your
performance will suffer badly. You program may go faster if you make it
smaller rather than faster. You get similar effects with caches too.
The best optimizations both reduce memory and increase speed.


: > * 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?


Testing is only easy if someone did a good job of designing the testing in
at the start.




: > * 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?


Beter than what?


In most cases you need to see information on how it got what you will get as
well as what you get. For a word processing example is that a hard or soft
return at the end of the line? [It makes a difference if the document is
printed on a different paper size.] You also often need to see a transformed
view of what you get rather than the actual truth. If I am simulating a
nuclear explosion I don't want shock-waves and gama-rays comming out of my
VDU. If I design an IC I want to see the design at a useful scale, not actual
size (a few mm across).


How many programs have you written only using WYSIWYG? Ie you can only see
the output from the program. Not the code it executes to get there?


--
Stephen Baynes baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton
United Kingdom
--

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