Chris,

You make some very good points ...

Though, if you look at the number of classes that I've used in 
Metacello, you might change your tune about how many classes would be in 
my gofer implementation:)

I like to say that "there is more than one way to skin a cat, but in the 
end the cat is skinned". So I hate to be critical of _how_ someone 
decides to skin the cat, when they are the one doing the work and 
_maintaining_ the project.

This discussion reminds me that in the late 80's and early 90's there 
was a bit of a trend where people were using Smalltalk to explore a 
problem space and evolve a design to the point where someone else could 
come in and implement the final solution in C.

Once you've discovered the key to a good API there are any number of 
ways to implement that API ... However, when you are in the process of 
searching for a good API and understanding the problem space treating 
classes as if they are free is a good way to give your implementation 
the room to grow in the directions that it needs to to find that sweet 
spot and there's nothing like Smalltalk for this work.

Once you've understood the problem the question then becomes "now that I 
know the solution, how would I implement it?" versus "now that I have a 
solution that is functional, is my time better spent doing something else?"

I'm not saying that this what Lukas is/was thinking, but it works for 
me. Monticello was badly in need of both a scripting API _and_ and 
programming API (which is how Metacello uses Gofer) and Gofer filled 
both of those requirements, so as far as I'm concerned the "cat got 
skinned".

The appeal of Smalltalk to me is that it is feasible to evolve systems 
using Smalltalk. As a software system evolves the assumptions that were 
made early on are no longer valid, so the challenge always seems to 
become "how do I add new functionality (and rewrite large chunks of the 
system) while maintaining fidelity to the original API"...

Of course, there are multiple answers to that question:)

Dale

  On 12/16/2010 08:41 PM, Chris Cunnington wrote:
> 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
>