|[10 earlier articles]|
|Re: Are these all really true ? firstname.lastname@example.org (1995-09-21)|
|Re: Are these all really true ? email@example.com (1995-09-23)|
|Re: Are these all really true ? firstname.lastname@example.org (Stefan Monnier) (1995-09-25)|
|Re: Are these all really true ? email@example.com (1995-09-25)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-09-25)|
|Re: Are these all really true ? email@example.com (1995-09-26)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-09-27)|
|Re: Are these all really true ? J.Biddiscombe@rl.ac.uk (The Lord of Darkness) (1995-09-27)|
|Re: Are these all really true ? email@example.com (1995-09-28)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-09-28)|
|Re: Are these all really true ? email@example.com (Rodney Bates) (1995-10-03)|
|Re: Are these all really true ? firstname.lastname@example.org (Jeremy Carroll) (1995-09-29)|
|Re: Are these all really true ? email@example.com (Stefan Monnier) (1995-10-02)|
|[7 later articles]|
|Date:||Wed, 27 Sep 1995 01:04:55 GMT|
"John Carter" <ECE@dwaf-hri.pwv.gov.za> writes:
>* Compilation is better than interpretation.
If you have the time to write the compiler. Whipping up an
interpreter is relatively easy.
During development, interpretation is often superior. My edit-run
loop with Smalltalk, Prolog, or Lisp (even perl) sure beats the
edit-[make]-compile-link-run loop using C++.
Good interpreters, with nice debug features aren't necessarily easy to
"whip up" either; but easier than compilers.
>* Multi-threading is better than single threading.
Multithreading can be a real bitch to debug.
But some problems are simply intrinsically multithreaded, others
Multi-TASKING (multi-processing) is better. Multi-threading is an
ugly hack because most OS people don't know how to do fast
multi-tasking systems (it can be done: one high-performance telephone
switch uses multi-tasking and message passing). In the degenerate
case (a single CPU), multi-tasking is coroutining with a nicer syntax.
Related stuff: constraint (logic) programming, lazy evaluation (ML,
>* Specification and design can be performed with no knowledge of
Whilst Murphy exists and we are finite, wrong-wrong-wrong.
Even Dijkstra agrees that design is a simultaneous top-down and
bottom-up process; sometimes one part predominates over the other, but
both must be kept in mind (most C programmers do bottom-up; most
"architects" do top-down; hence the many messes we see).
>* Applications contain a substantial number of algorithms.
Most programs today use very few algorithms (especially business
programs or stuff that's GUI-intensive).
On the other hand, we can't afford the attitude of "now that we've got
good optimizing C compilers, we don't need to worry about algorithms"
>* WYSIWYG is better for all applications.
What You Want Is What You Get is the holy grail. WYSIWYG is merely a
crutch. A truncheon with which to beat recalcitrant packages into
yielding the desired result. (Marketing is the science of convincing
us that What You Get Is What You Want.)
Hmm. What Will Work Is What You Get might be even better.
WYSIWYG = What You See Is ALL You Get.
e.g., you might want to use SGML instead of WYSIWYG, if content is
more important than appearance (content can always drive appearance).
Peter Ludemann firstname.lastname@example.org
ExperNet phone: +1.415.949.8691
Systems Architect fax: +1.415.949.1395
KNS Project Leader
Return to the
Search the comp.compilers archives again.