Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornell!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!news.alpha.net!uwm.edu!spool.mu.edu!howland.reston.ans.net!xlink.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: The new paper and static binding in dylan.
Message-ID: <1995Feb27.162850.10467@wavehh.hanse.de>
Organization: The Internet
References: <3iqht0$aa6@narnia.ccs.neu.edu>
Date: Mon, 27 Feb 95 16:28:50 GMT
Lines: 65

I think that paper has some weak points and some of them should be
changed to make it useful for the dylan community.

- The paper is not concrete enough about what exactly Dylan
  does. Especially, it looks bad that none of the drawbacks of Dylan
  is named. 

For example, it doesn't say whether Dylan will offer static
binding. As a technical reader I find this particular information much
more important that all the weak comments about Dylan's performance.

To reach C++'s speed, Dylan has to be able to do static binding and
inlining and carry that out so far that the necessary information is
taken into containers to operate on elements.

I don't know very much about compiler technology for modern dynamic
languages, but as far as I can imagine, Dylan will not offer inlined
calls that far. I think static binding on container's elements is
possible only when the whole container code is duplicated for each
types as it is the case in C++'s templates and not for containers that
have (dynamically) typed elements (Note: I know that the C++ way has
enormous drawbacks).

And static binding at all will be difficult in a language that is as
runtime-flexible as Dylan, although I can imagine a mechanism to
analyze an object over it's livetime.

Maybe one of the implementor can comment on this. Is this evaluated
yet? I'm really interested. 

Please don't start a language war here, that's up to comp.object :-)




Here are some more points on the paper:

- Ballard names that the performances difference between Smalltalk and
  C++  is 10 to 20 times.

This can only be wrong. The difference depends too much on
applications and implementation, I would never give such a concrete
number. For me, reading such numbers let me see the entire paper in a
different light.

- Almost everything Ballard says about Objective-C is inaccurate.

- I think the statement "The performance penalty for this flexibility
  (an objects ability to change it's type) is very high." is not quite
  right.

This capability forbids static binding and inlining, but in a
language that doesn't provide this anyway there is only a small
additionally overhead for changeable dispatch tables.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin.Cracauer@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
 No guarantee for anything. Anyway, this posting is probably produced by one
 of my cats stepping on the keys. No, I don't have an infinite number of cats.
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin.Cracauer@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
 No guarantee for anything. Anyway, this posting is probably produced by one
 of my cats stepping on the keys. No, I don't have an infinite number of cats.
