Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!xlink.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: The new paper and static binding in dylan
Message-ID: <1995Mar7.101504.10062@wavehh.hanse.de>
Organization: The Internet
References: <ab80efa101021004e4c8@[198.112.74.251]>
Date: Tue, 7 Mar 95 10:15:04 GMT
Lines: 78

stoney@cambridge.apple.com (Stonewall Ballard) writes:

[the other items are already discussed]

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

>Can you give me some examples? I'd like to remove inaccuracies if possible.

I'll send personal email on this.

>>>>
>- - 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.
><<<

>I suspect that you have been misled into thinking that Dylan forbids static
>binding and inlining.

Yes, in fact. I now understand that Dylan as defined in the DIM
allwows it. But it is not obvious, see my last question posted here.

But my point to complain was:

There are too many position papers that state - for example - that
Common Lisp can reach the speed of C. It can. And many of those papers
implies: C++ cannot be faster than C and CLOS is a part of Common
Lisp, so CLOS can reach C++'s speed.

Fact is that C++ allows highest efficience (= no message lookups at
runtime and inlining) for user-defind classes, while CLOS does not.
You can reach C's speed with Common Lisp if and only if you operate on
build-in types in both languages only. Those papers did immense damage
to the Lisp world, IMHO. The same applies for some papers on Smalltalk
and Self, that compare performance in one specific application domain
and don't clearly say so.

So, when you want to tell some manager that your new language can
reach the speed of static langauges and this manager previously read
such a paper and found it to be untrue for his applications, he will
not beleive a single word.

I highly recommend that you make some concrete examples why exactly
your new dynamic language differs from those dynamic languages that
has been presented the same way before.

As I learned, Dylan is in fact a language that can reach the speed of
C++ *without* narrowing that to specific applications. It is the first
dynamic langauge I now of (maybe Cecil). Your paper fails to transport
this to the reader. Dylan looks (from a performance standpoint) like
any other dynamic language and therefore will not make people try it
out.

In a word: I think you should try to transport the concept of static
binding and inlining and how Dylan manages that in a similar way for
'build-in' types and user-defined types. That is heavy stuff in a
marketing paper and you narrow the number of managers that will read
it. But without it you have a large number of readers that are not so
impressed that they try Dylan out.

Maybe it's the fault of those previous `work' that make people
sceptic about performance claims, but there's nothing you can do
about it.

A concrete paper will make it an attack against other dynamic
languages, because you have to explain why those language fail to give
an overall good performance. But as long as you are accurante (note
that Smalltalk has other optimization techniques) that is only fair.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin.Cracauer@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
