🚀 go-pugleaf

In article <1991Mar26.172536.12178@linus.mitre.org> john@mingus.mitre.org (John D. Burger) writes:
> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>   You said it was ``fast enough,'' so obviously its run time is not
>   particularly significant. I claim that for most programs the
>   opposite is true, and dynamic typing can greatly increase the
>   turnaround time during development. You can measure the accuracy of
>   this claim by dividing the CPU time of test runs by the total
>   programming time, for various programs.
  [ ... ]
> As far as your measurements go, I haven't run any such experiments,
> and neither has anyone else.  But you know that.

On the contrary. Often I spend a considerable length of time working on
just one program. After the fact I have accounting records and various
other logs to look at, and it makes perfect sense to total up the time
spent running the program and divide it by the real time spent in that
session.

> Point
> blank, have you ever developed any significant program in Lisp?

What does ``significant'' mean? More than 10000 lines? No.

>   A ``REAL source level debugger'' and incremental compilation are
>   functions of the environment.
> Fine. Then the distribution of languages with these features should be
> independent of whether those languages have dynamic typing.  This
> doesn't appear to be the case, however.

Huh? The Forth environments I've worked with have incremental
compilation, and Saber-C provides a far superior debugging environment
to anything I've seen for Lisp. Shall I conclude that static typing
helps debugging?

>   Heterogeneous collections don't seem to be used in real applications
>   ---or do you have a counterexample?
  [ ... ]
> How would you represent logical formulae?  A predicate
> has a name and a collection of arguments: some are variables, some are
> constants, some are function terms.

Sounds like a union type to me.

> Concerning your "byte-copying" example, you don't appear to actually
> know Common Lisp.  Additionally, your example seems to hinge on the
> fact that C represents characters as 1-byte integers.

Obviously you misunderstood. Yes, the example *does* depend on the fact
that C regards all of memory as character-addressible. This is exactly
why the example *can't* be handled in Lisp.

>   The point is that someone who wants to use dynamic typing in C can
>   easily do so. I believe we agree here.
> The point is that lots of people feel they have to implement dynamic
> typing in C.  Doesn't that tell you something?

Lots of people feel they have to implement string functions in C.
Doesn't that tell you something? It tells me that the string functions
belong in a standard library. It sure doesn't tell me that the compiler
should grok strings.

> But anyway, we agree
> in the sense that, yes, dynamic typing can be implemented in C, but
> ORTHOGONALLY TO THE EXISTING TYPE SYSTEM.
  [ and orthogonality must imply that: ]
> The compiler can't know about it,
> and therefore can't optimize it.

Oh? How come C++ is optimized quite reasonably even though it's commonly
implemented as an orthogonal layer over C? How come so many of the
dynamic typing optimizations reduce to good inlining and data flow
heuristics---things that don't require the compiler to understand what
you're doing?

If your argument were true, then converting, say, X Windows to a
dynamically typed language would speed it up. After all, the dynamic
typing would be part of the compiler, and that *must* produce better
optimization than an orthogonal system, right? So how come programs in
dynamically typed languages are so slow?

---Dan