🚀 go-pugleaf

In article <7988:Mar2700:09:2691@kramden.acf.nyu.edu> 
>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 
>
>>   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.
>
>
>---Dan

Concerning dynamic typing and nice environments,
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

  Saber-C provides a far superior debugging environment to anything
  I've seen for Lisp. Shall I conclude that static typing helps
  debugging?

Having used all of them, I state that Allegro Composer, Lucid's SPE
and the Symbolics Lisp Machine are all FAR superior to Saber-C.  But,
you've missed the point.  Saber-C works as well as it does because
they've implemented a version of C with dynamic typing, as well as an
interpreter.

Other people are dealing with your heterogeneous collection arguments.
Concerning your byte-copying example, again, this doesn't have
anything to do with statis or dynamic typing.  If you want to program
in portable machine code, have a ball.

  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?

C++ is commonly TRANSLATED to C, not implemented on top of C.  How can
a compiler do inlining if it doesn't understand what you're doing?
--
John Burger                                               john@mitre.org

"You ever think about .signature files? I mean, do we really need them?"
  - alt.andy.rooney