Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!news.tc.cornell.edu!newsserver.sdsc.edu!news.cerf.net!mvb.saic.com!news.mathworks.com!uunet!in1.uu.net!nntp.crl.com!pacbell.com!amdahl.com!amd!netcomsv!uucp3.netcom.com!slcgate!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Ok to use #perform:? [was Re: TopHat new -- Smalltalk With Style]
Message-ID: <1995Aug2.174305.6565@slc.com>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <n1405356834.85007@smtpgwprod.ny.jpmorgan.com> <1995Jul31.210415.28910@slc.com> <rshapiro-0108950804330001@esb.bbn.com>
Date: Wed, 2 Aug 1995 17:43:05 GMT
Lines: 61

rshapiro@bbn.com (R Shapiro) writes:
> In article <1995Jul31.210415.28910@slc.com>, aland@servio.slc.com (Alan
> Darlington) wrote:
<snip> 
> >#perform:...  This makes
> >an application more difficult to understand and maintain. 
> 
> Nonsense. 

What?!?  Are you saying that a complex problem requiring #perform:
is no more difficult than a simple problem that does not???  The
lack of "senders" is just one aspect of the increased difficulty.
Even if the alternative implementations are worse (as you indicate
below), this is still more difficult to understand in a fundamental
way.

> See the recent example, discussed to death, of how to implement
> a large "switch" statement. The version which uses #perform is more
> modular and *easier* to maintain than the alternatives (dispatch tables,
> spurious classes, and the like). Is it hard to understand? Your average
> C/C++/Pascal programmer might find it puzzling.

Of course it is hard to understand - ask any novice Smalltalker.  :-)

> But then that's true about
> all of the truly dynamic aspects of languages like Smalltalk and Lisp.
> That certainly doesn't mean such features shouldn't be used, it just means
> you have to learn how to use them effectively.

Doesn't this imply that #perform: is more difficult in some sense?  And
that you should avoid it if simpler implementations exist?

> So, is it ok to use #perform? Not only is it ok, but the presence of a
> method like this is one of the more valuable aspects of dynamic languages
> like Smalltalk. Its use just requires a little more responsibility on the
> part of the developer.

Actually, it is an essential part of the language for any serious work.
As one of four developers of a Smalltalk financial application
(commercially available, with 1030 classes, 19,000 methods, and 190,000
lines of code), I have had a LOT of experience in using all the tricks
of the trade.  For performance and flexibility, we wrote a lot of "ugly"
code (actually, I'm pretty proud of it).

This does NOT mean (as you perhaps imply) that this is free of cost.
These portions of our code were the most difficult to understand (i.e.
relearn in order to fix bugs and add enhancements) and maintain, and
very difficult for a new programmer to learn.

I sometimes wonder if this is an indication of some fundamental
shortcoming in Smalltalk.  Anybody have any ideas?

> -- 
> rs/rshapiro@bbn.com

I actually think we agree for the most part, but this is more fun than
fixing bugs...

Cheers,
Alan

