Re: Are these all really true ?

Scott Nicol <scott@infoadv.mn.org>
Thu, 14 Sep 1995 20:14:25 GMT

          From comp.compilers

Related articles
Are these all really true ? gdevivo@conicit.ve.) (1995-09-07)
Re: Are these all really true ? ring@porky.cb.att.com (1995-09-13)
Re: Are these all really true ? Steve_Kilbane@cegelecproj.co.uk (1995-09-14)
Re: Are these all really true ? scott@infoadv.mn.org (Scott Nicol) (1995-09-14)
Re: Are these all really true ? lakeland@sans.vuw.ac.nz (1995-09-20)
Re: Are these all really true ? rfg@monkeys.com (1995-09-20)
Re: Are these all really true ? stefan.monnier@epfl.ch (Stefan Monnier) (1995-09-21)
Re: Are these all really true ? ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-09-21)
Re: Are these all really true ? carroll@auriga.cis.udel.edu (Mark C. Chu-Carroll) (1995-09-21)
Re: Are these all really true ? andrewn@kaleida.com (1995-09-21)
[20 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Scott Nicol <scott@infoadv.mn.org>
Keywords: OOP
Organization: Compilers Central
References: 95-09-076
Date: Thu, 14 Sep 1995 20:14:25 GMT

Here's an "industry" perspective.


>===== ACADEMIC ASSUMPTIONS - ARE THESE ALL REALLY TRUE ? ======
>* Strongly type language result in better programs.


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.


>* Performance is a language problem.


To some extent, but if you choose poor algorithms, no language
can save you.


>* Compilation is better than interpretation.


It depends on the language. Some languages lend themselves well
to interpretation, others to compilation. You will pay a run-time
performance penality for using interpretation (as opposed to
compilation), but, generally, the performance penalty is inversely
proportional to language "level". For many high level languages,
the performance penalty can be insignificant.


The other side of the interpreter/compiler coin is development
"performance". Generally, interpreters offer better performance
in this area.


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


OK.


>* Multi-threading is better than single threading.


Depends on the algorithm, language, machine, OS, ...


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


I think you must keep in mind the features and limitations of the
implementation language during the design phase.


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


Design is hard, but I wouldn't say testing and packaging are easy.


>* Formal specifications yield correct programs.


You can't prove correctness for anything other than the smallest
program. If specifications yield correct programs, there would
be no need for regression tests.


>* Applications contain a substantial number of algorithms.


OK.


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


Industry uses much more than this. Languages such as Visual Basic,
PowerBuilder, various 4GL's, COBOL, and many others are widely used
in industry. UNIX is still a very small part of the market.


>* Industry has better or worse tools.


This is too general, so I can't aswer it.


>* Industry runs on wrong hardware and software platforms.


"Wrong" really depends on your perspective. I thing "right" means
the computer system does roughly what you want it to do.


>* WYSIWYG is better for all applications.


Some call it WYSIAYG (What You See Is All You Get). There are many
situations where WYSIWYG is an impediment. For example, try globally
changing the style of section headings in an MS Word document...


--
Scott Nicol email: scott@infoadv.mn.org
Information Advantage, Inc. work: (612) 820-3846
Edina, MN home: (612) 488-5406
--


Post a followup to this message

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