Re: Strong Typing, Dynamic Languages, What to do?

[Oscar Fuentes <ofv@wanadoo.es>]

Shriram Krishnamurthi <sk@cs.brown.edu> writes:

> Oscar Fuentes wrote:
> 
> > Abbreviating: it has no sense to say that somebody that doesn't know
> > what are you doing is capable of providing a better solution for your
> > problem than yourself.
> 
> Duh.  This is the basic fact underlying all of optimization theory.
> So what?  You haven't even begun to address my question.
> 
> - Your "logical demonstration" is only a proof of possibility, not
>   certainty.  (To be utterly pedantic, you've only used the dia
>   modality, not box.)  As Keith Cooper, a compiler optimization
>   wizard, memorably put it, "Information is not optimization."  Think
>   that over.

Well, my "demonstration" states that for, every given system, it is
_possible_ to create a manual memory management that performs at least
as well as the best GC system. If you mean that the manual memory
system must be programmed by a monkey, well, I admit that it is not
sure that you'll get such results :-)

And putting my Math hat on, I claim that is a certainty that, for each
given pair (application, GCS), we can create a memory management
system (MMS) that performs at least as fast as the given GCS _and_
there is no GCS that equals or exceeds the performance of an
application-dependent MMS for all applications.

Putting back my programmer hat on, I claim that is a certainty that we
can create a MMS than performs better than any existing GC system for
an arbitrary real-world application. Moreover, I claim that *you* know
this. :-)

> - In a sufficiently complex domain, even the implementor of the
>   special-purpose collector may not understand the details to know (a) 
>   how to exploit them or (b) that he has done so soundly.

See above.
 
> - The engineering of special-purpose collectors is highly
> non-trivial.  In many domains, it will take a while to match, much
> less beat, the performance of a finely-tuned general-purpose GC.

My experience shows the opposite. Again, see above.
 
> - Even if you could come up with a customized mechanism, there's no
>   guarantee that it will necessarily be better.  For instance, even if 
>   your domain guaranteed the exclusion of cycles, reference counting
>   will not *necessarily* be better than a copying GC.

Agreed. How about manually applying the GC scheme to those elements
that optimally benefits from them and applying better schemes to other
elements? You end with a system that beats the GC system applied to it
all ;-)
 
> - As a real-world programmer, you know all about cost-benefit
>   analysis.  Do the obvious thing here (analysis cost, creativity
>   cost, development cost, maintenance cost, ...).

This must be decided for every case, as we do with everything. Note,
however, that the statement you defied was under the heading 

"Other factors concerning speed might be:"

so we are talking about run-time performance here.
 
> - Even when you've done all this and decided you can build a better
>   mousetrap, your manager may come along and demand that your language 
>   run-time interact closely with code written in C++ by a guy who
>   insists C++ has _two_ features he absolutely needs.  Now what will
>   you do?

This is ironic indeed. The main reason because I'm not using mzScheme
embedded on my applications is 'cause I don't trust GC for getting rid
appropriately and on time of the objects allocated on the C++ code.

Even more ironic: that objects causes me zero work to deallocate on
the C++ side, but I must put guards around the Scheme code that uses
them to "guarantee" their deallocation. That "guarantee" (that, AFAIK,
is somewhat weak) absolutely disappears as soon as continuations
enters the picture.

A correction about this issue would be greatly appreciated.
 
> So instead of getting sidetracked into analyzing an empirical question
> through logic, let's get back to my question: how about some evidence?

If the arguments made on my previous msg did not convince you, what
kind of argument do you expect?

-- 
Oscar