Design Attitudes

> 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

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

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

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