🚀 go-pugleaf

Dan Bernstein's comments are   >   and >> >
earlier comments of mine are           >>
>> >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)
>I don't know what you mean by ``interface code.''

By 'interface code' I mean high-speed-real-time-state-machine type
stuff.  Examples include device drivers and editor screen/buffer
management.

>> (Also note that there are a number of efficiency problems with C,
>> having to do with the semantics of C pointers.
>No. Aliasing is a problem for *optimizers*. Except on vector machines it
>does not create problems for code written efficiently.

All languages have problems when they cannot express some basic
operation of the underlying machine.  Aliasing is a problem I find
amusing, that's why I pointed it out.  

As for efficiency, I would claim that except for what I called
interface code (lotsa small highly serial operations) dynamic typing
does not create problems for code written efficiently.

Of course, for many purposes pointers and dynamic typing are
synonomous (or 'functionally equivalent').  I suppose that proves
something... 

>> What I have claimed is that I can solve problems faster
>> in a dynamically typed language than in a statically typed language.
>I firmly believe that the speed of problem-solving in any language is
>based mostly, if not almost entirely, on how much already-written code
>you can apply to the problem. There is no reason beyond religion to
>believe that dynamic typing helps reusability.

Speed of problem solving also depends on how easily you can change the
domain of the problem.  And on how familiar you are with the
programming language.  And on how much work you lose when you find a
problem (which is equivalent to how much more work you must do before
you can 'pick up where you left off').  And on how fast the machinery
is.  And on the number of keystrokes you must type.  And on how well
you understand the problem.  And on how fast you learn.

The system I use allows me to restart with minimal backtracking.  That
means no recompilation, no reinitialization, no repeated file ops
(unless, of course, that's what went sour).  And since I never had to
compile the program in the first place (compilation is a stage that we
OCCASIONALLY use AFTER development), I think that's pretty fast.  Is
that religion?

>> >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.
>Yes, please do.

Ok:

That routine was intended to compress integers.  He wrote several
routines and found they all gave around a 2:1 compression ratio for
typical data.  So he picked the one that was usually the fastest.
Turns out that compilation (even re-writing in the style that the
compiler favors) does not significantly increase speed.  He's going to
try and get it hand-assembled.

Meanwhile (today) we was working on how word-inversion data gets
distributed to file.  (Quote: "I'm running inversion on large numbers
of documents for speed, but it's taking several hours to post the hits
for a hundred fifty thousand words.")  Since he hasn't solved that one
yet, I don't know what the solution is.

Incidentally, I gave him a copy of an article on text compression I
found in gnu.misc.discuss.  Article was by some guy named Dan
Bernstein--ever hear of him ;-)

Raul Rockwell