Xref: utzoo comp.lang.misc:6941 comp.object:2791
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!asuvax!ncar!gatech!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc,comp.object
Subject: RE: blip [Re: Dynamic typing -- To Have and Have Not
Message-ID: <19MAR91.22493670@uc780.umd.edu>
Date: 19 Mar 91 22:49:36 GMT
References: <1991Mar16.052952.10201@cs.cmu.edu> <3523:Mar1803:21:0591@kramden.acf.nyu.edu> <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 62

Dan Bernstein writes:
>Of the languages that I've used much, I find Forth the most expressive.

Do you, perhaps, write a lot of interface code?  (Just curious)

> ...
>Expressiveness is nice. Anything syntactic is nice. But I don't need
>niceties. I need portability. I need fast compile times and run times so
>that the machine's turnaround time during testing and debugging doesn't
>become a significant part of my turnaround time. I need language power:

Ah yes, portability.  Portability currently means: C, Fortran, COBOL,
ADA, 8086 assembly, or maybe Pascal.  This will change in the future,
of course, and I'm working on making it change the way I want.  (Also
note that there are a number of efficiency problems with C, having to
do with the semantics of C pointers.  Thus any language which uses C
as an intermediate language is going to have the same efficiency
problems, no matter how tight the design.  This will get worse as
machine architectures migrate away from C's PDP-11 roots.)

Compile times become less important in an interactive environment, but
I will admit that the compiler I use is slow (most of the time spent
in the optimizer).  Part of that may be that I'm usually compiling on
a machine that's barely 22MIPS, with usually above 100 users (and I
usually keep my priority way down low, so I don't impact the system).
On top of that, there are literally hundreds of improvements I'd like
to see in the compiler.  Maybe eventually...  (Slow compilers have
existed in all languages.  That changes as customers demand more speed
(or in the case of GNU, and probably the old AT&T C compiler, that
changes with exposure).)

Language power, now, hmm... say 20 slug micron lightyears per
nanosecond per square year?  Yeah, I need that sort of stuff too...

>Actually, I have a reasonably good idea of what I'm talking about. My
>comments on dynamically typed languages are based not only on my
>experience but also on many objective and subjective articles by both
>detractors from and proponents of such languages. As a matter of fact,
>if you want to buck the establishment, it's your problem to prove that
>dynamically typed languages aren't as inefficient as most experiments
>have found them to be.

Nahh... if I want to buck the establishment, it's my problem to make
more money than them.  But in any event, I never claimed to have used
a dynamically typed language more efficient than a staticly typed
language (part of that has to do with the kinds of machines I've
worked on).  What I have claimed is that I can solve problems faster
in a dynamically typed language than in a statically typed language.
Of course I picked a job where that is a significant factor...

Of course, efficiency is also a matter of coding style.  As is
readability.  And what is good in one language is grungy in another.
(Thus throwing lots of free variables into any comparison of
languages.)  Hope you don't mind if I ignore your experiments and
articles, eh?

>Would you write a compressor in a dynamically typed language?

As a matter of fact, one of the guys at work was doing that several
weeks ago.  I should ask him how it came out.

Raul Rockwell