Academic Assumptions-Are these all really true?

I am partly to blame for this thread as I put my ECOOP notes on the net.
I feel I should clarify the context and origin of this list.


These points were raised by Dave Thomas at this year's ECOOP conference.
Dave Thomas used to be an academic but is now the president of OTI.
His company is specialized in delivering Smalltalk applications. They
are pretty successful, have offices all over the world and many corporate
clients.
A good indicator of succes: When the people at IBM wanted to have Smalltalk
running on their platform, they hired OTI to implement it.


Dave Thomas said that there are some assumptions which he encounters
frequently in academia and which bother him. The list is


*Strongly typed language result in better programs.
*Performance is a language problem.
*Compilation is better than interpretation.
*Memory is free, speed is what is worth optimizing.
*Multi-threading is better than single threading.
*Specification and design can be performed with no knowledge of implementation.
*Programming, testing, packaging are easy, design is hard.
*Formal specifications yield correct programs.
*Applications contain a substantial number of algorithms.
*Industry uses ... C++, CORBA, Windows, UNIX, ...
*Industry has better or worse tools.
*Industry runs on wrong hardware and software platforms.
*WYSIWYG is better for all applications.


Dave Thomas justified all of these points.


I hope that memory serves [usually it does not]:


----------------------------------------------------------------------------
1 - Strongly typed language result in better programs.


Dave Thomas mentioned a study [I am not sure about that] of errors in Smalltalk
code which found that type errors are a negligible portion of the errors
occurring in Smalltalk code written by professional Smalltalk programmers.


[The key word here is professional. Mr. Thomas did mention that types are
useful for novice programmers.]


Pointers and memory allocation may well be bigger problems than type errors.
----------------------------------------------------------------------------
2 - Performance is a language problem.


The language plays only a small role on the overall performance of programs.
[This is was an attack against the widespread belief that
C++ == Good Performance for Delivery Applications
and
Smalltalk == Slow Performance for Toy Prototypes
]
----------------------------------------------------------------------------
3 - Compilation is better than interpretation.


His point was that compilation to native code yields faster executables.
But, these executables are usually larger and less portable than an
interpreted version. The speed advantage is often overstated.
Portability and compact code may be more important. Dave Thomas mentioned
that they use the same Smalltalk code inside an oscilloscope and in a
mainframe. He also said that for the oscilloscope it would have be very
difficult to get the equivalent functionality in C++.
----------------------------------------------------------------------------
4 - Memory is free, speed is what is worth optimizing.


Dave Thomas had a slide titled: "Smalltalk on a Watch". He said that in many
real world applications memory is the real bottleneck. [It is unlikely that
we will be able to extend the memory of a watch to the 32MB required by
the SELF system any time soon... I know it is not a good example... still...]
----------------------------------------------------------------------------
5 - Multi-threading is better than single threading.


Multi-threading is a mess.
----------------------------------------------------------------------------
6 - Specification and design can be performed with no knowledge of
implementation.


Wrong... but often advocated in formal specification circles.
----------------------------------------------------------------------------
7 - Programming, testing, packaging are easy, design is hard.


Dave Thomas deplored the academic tendency to frown on programmers as mere
hackers. He also talked about the difficulty of packaging software so that
it may run out of the box on different hardware and software configurations.
----------------------------------------------------------------------------
8 - Formal specifications yield correct programs.


No.
----------------------------------------------------------------------------
9 - Applications contain a substantial number of algorithms.


Applications are 90% boring code.
----------------------------------------------------------------------------
10 - Industry uses ... C++, CORBA, Windows, UNIX, ...


OTI is a counter example as they make a good living selling Smalltalk apps
to banks and insurance companies.
----------------------------------------------------------------------------
11 - WYSIWYG is better for all applications.


Mr. Thomas mentioned having to change 1000 screens created with a WYSIWYG
tool to add one extra field on each of them.
He said something about the need of a LATEX for GUIs.


....


~jan


__________________________________________________________________________


Jan Vitek | Prefix: +41 22
Centre Universitaire d'Informatique, University of Geneva | Tel: 705.7662
24, rue General-Dufour -- CH-1211 Geneva 4 -- SWITZERLAND | Sec: 705.7770
E-mail: jvitek@cui.unige.ch | Fax: 320.2927
URL: http://cui_www.unige.ch/OSG/Vitek/HomePage.html | Home: 349.6722
--

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