Re: Are these all really true ?

gdevivo@conicit.ve (Gabriela de Vivo (UCV).) writes:
>===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======
>* Strongly type language result in better programs.


Depends on what your appliation domain is. If you are writing AI adaptive
system type code then adherence to typing leads to horrible code. This
sort of domain is where non strongly typed languages like LISP are a
dream.


>* Performance is a language problem.


One of my pet topics! To my mind this comment is undoubtedly true (with
the proviso that no amount of good semantics will help an inefficient
algorithm). Language design (semantics) has strong impact on performance,
memory usage, etc. As an example the less referentially transparent
your semantics is the less invariance related transformations (e.g common
sub-expressions, loop invariance, etc your compiler will be able to
do, and hence the less efficient your object code will be. Likewise the
choice of atomic data types has a huge performance impact. In scientific
computing for example the array is *the* atomic data type -- languages
which don't provide it don't have good performance (witness the continued
life of Fortran). Another example is OO computing. Adding OO to a language
certainly increases the expressiveness of the language, but at the cost of
performance (the dynamic lookups that go on). The list of ways in which
semantics effects performance is endless. Hence performance is a language
problem.


>* Compilation is better than interpretation.


What does "better" mean? Compiled code certainly runs quicker than
interpreted code (the asymptotic lower bound on the speed of interpreted
code is the "equivalent" compiled code). But interpreted code usually
offers other benefits since the source code and object code are "closer".
Of course quality implementations reduce differences between compiled
and interpreted, but still ...


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


Disagree. Specification and design start with a goal in mind. If a
designer has no knowledge of implementaton he cannot know whether
his design parameters are realisable in an implementation, and hence
whether his design will realise his goal. Of course a designer does
not need to know everything about implementation, but he needs to
know enough to provide a reality check on the design.


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


Not sure if I agree. All these activities are hard but for different
reasons. Design is hard since you need to understand the "big picture".
Programming is hard since you need to understand details -- to ensure
bug free code that is also optimal (you really need to know about
algorithm development to program well). Testing is hard because you
need to be very analytical and patient. "Packaging" -- I am not sure
I know what it means, but in my understanding of it, packaging is
a sub-activity of design.


>* Applications contain a substantial number of algorithms.


In general I don't think this is true. A lot of applications don't contain
any significant algorithms. They just use bog standard algorithms. I am
not criticising. For many applications thats all you need.


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


True, unfortunately (at least wrt C++, Windows, and Corba).


graham
--

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