[squeak-dev] Design Attitudes

Ron Teitelbaum ron at usmedrec.com
Fri Dec 17 15:36:21 UTC 2010


Hi Chris,

There is also something to be said about simplicity.  It makes sense to put
the time into extensibility when you find you need to extend something.
Before that point it can do more to obscure the code.  If something becomes
overly complex or opaque then the design might support expansion but people
may opt for simplifying the design to make it easier to understand where
they actually extended the code. 

Ron Teitelbaum


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-
> dev-bounces at lists.squeakfoundation.org] On Behalf Of Chris Cunnington
> Sent: Thursday, December 16, 2010 11:42 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [squeak-dev] Design Attitudes
> 
> This whole exchange about Gofer has been interesting. I don't just think
it's a
> random bump between two programmers. I think it's about two
> programmers who have different attitudes towards design. Do you build a
> tool for a specific purpose and no more? Or do you build it with the
potential
> to be readily adapted to a future purpose?
> 
> I believe Dale when he says that if you don't build all this Lukas-esque
> redundancy that a design is hard to modify. That you'd get locked up in
the
> methods, when you want the flexibility of a design with lots of classes.
But
> remember - Dale didn't design Gofer. He adapted it. Would he have built it
> with the academic rigor that is clearly Lukas's metier?
> Would his boss stand for that kind of fiddling? I'm willing to bet Dale
benefits
> from this design attitude, but that he wouldn't do it himself from
scratch.
> 
> If people want to look for a difference between Squeak and Pharo, I think
> this is emerging as a possible difference. Neither is right or wrong. If
you
> need a tool for a specific purpose and you're skilled -- you can build one
in
> half an hour from scratch. Do you want to take five times that long to
build
> something with more classes, so you can save time in the future by having
to
> do less in the future?
> 
> Neither is right, but I have sympathy for people who have strong feelings
> one way or another. For me Seaside suffers from an explosion of classes
that
> I've begun to loathe. I don't want a framework that can be adapted to
> anything. I want one that does one specific thing. That's all. And Pier,
as far as
> I can tell, does nothing. Zero.
> 
> Some people will baulk at that statement. And I'm sure that if I
understood it
> better, I'd see that Pier can do anything. And I'd only have to make a
small
> series of adjustments to harness real power. I don't want that, though. I
> don't want to have to guess what the code is supposed to be for.
> 
> When I read strange code I want to have it tell me in bold terms what its
> clear, stark intent is. I want it to be as blunt as I am. I want the code
to scream
> at me: "This is what I do!" (Actually, I like code that says things like:
"This is
> what I do, and if you don't like it, then you
> can...")
> 
> And now that we've learned this interesting lesson, let's now resume
> detente, Perestroika, Entspannung, whatever.
> 
> Chris





More information about the Squeak-dev mailing list