Where to put the complexity?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Where to put the complexity?

Phil B
I've been peeking around the image a bit lately and ran across something
that got me thinking about this question: several of the exception
subclasses seem to be largely one-shot affairs.  Granted, the main
categories like Notification, Error, Halt etc. are used all over the
place, have different behaviors and given the importance of what they
convey, provide value.

However, when you start looking at the 3rd+ level Exception subclasses,
some of them look a little sketchy to me.  I'm not talking about more
widely used exceptions like ZeroDivide but rather things like
ReparseAfterSourceEditing... unless I'm missing something, it is raised
in 3 places (in 2 classes) and handled in 1 just so that a very specific
message can be sent to what appears to be a single listener.  Is it
worth having a class for this vs. raising the more general Notification
and then checking for a #ReparseAfterSourceEditing signal, and if it
isn't, re-raise Notification in its sole handler?

This is a specific example of the more general question of where to draw
the line on having single, or very limited, use classes and methods vs.
adding a tiny bit of complexity in one or two methods to simplify the
overall image or package in question.  Thoughts?  The core image part of
the question is directed to Juan (i.e. should I bother reworking things
like this and submitting pull requests when I see them?) but I was also
curious what others thought about this from the standpoint of general
coding style...

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

KenDickey
On Mon, 29 Jun 2015 07:09:43 -0400
"Phil (list)" <[hidden email]> wrote:
> ..  Is it
> worth having a class for this vs. raising the more general Notification
> and then checking for a #ReparseAfterSourceEditing signal, and if it
> isn't, re-raise Notification in its sole handler?
> ..
> This is a specific example of the more general question of where to draw
> the line on having single, or very limited, use classes and methods vs.
> adding a tiny bit of complexity in one or two methods to simplify the
> overall image or package in question.  Thoughts?  

I would say the overriding goal is clarity.

It is important work to refactor code to have the same behavior but be easier to understand.

A Smalltalk style goal is to have small methods which do things clearly.  This tends to lead to lots of small methods.

Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap.  

Look at class #PartsBinMorph.  Would you say the having the additional class is wasteful?

It is a tough balance.  Aesthetics and restraint require judgement and we don't always get it right.  It takes time.

I only have so many life hours left.  I feel my time is valuable.  I prefer to understand.

Thank you so much for taking the time to make Cuis more comprehensible.

$0.02
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Juan Vuletich-4
Hi folks,

On 6/29/2015 10:51 AM, Ken.Dickey wrote:

> On Mon, 29 Jun 2015 07:09:43 -0400
> "Phil (list)"<[hidden email]>  wrote:
>> ..  Is it
>> worth having a class for this vs. raising the more general Notification
>> and then checking for a #ReparseAfterSourceEditing signal, and if it
>> isn't, re-raise Notification in its sole handler?
>> ..
>> This is a specific example of the more general question of where to draw
>> the line on having single, or very limited, use classes and methods vs.
>> adding a tiny bit of complexity in one or two methods to simplify the
>> overall image or package in question.  Thoughts?
> I would say the overriding goal is clarity.
>
> It is important work to refactor code to have the same behavior but be easier to understand.
>
> A Smalltalk style goal is to have small methods which do things clearly.  This tends to lead to lots of small methods.
>
> Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap.
>
> Look at class #PartsBinMorph.  Would you say the having the additional class is wasteful?
>
> It is a tough balance.  Aesthetics and restraint require judgement and we don't always get it right.  It takes time.
>
> I only have so many life hours left.  I feel my time is valuable.  I prefer to understand.
>
> Thank you so much for taking the time to make Cuis more comprehensible.
>
> $0.02
> -KenD

I fully support Ken. I don't think that a general answer is correct in
all cases here. It is a matter of making code easy to understand. But
also making it consistent and pretty.

In general, I don't like making general classes know much about details
of specific use cases. But there might be exceptions.

If you feel like experimenting with this kind of stuff, send your
suggestions to the mail list so we can discuss.

In the particular case of ReparseAfterSourceEditing, I agree that a
class that does nothing is a bit strange. But, what is the alternative?
How would the sole exception handler know what to do with a general
Notification? I think the handler looks quite reasonable right now. And
the pollution of the global space might be tolerable if the alternative
is more convoluted code...

$0.02, not really a strong opinion.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Phil B
On Mon, 2015-06-29 at 13:23 -0300, Juan Vuletich wrote:

> Hi folks,
>
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > On Mon, 29 Jun 2015 07:09:43 -0400
> > "Phil (list)"<[hidden email]>  wrote:
> >> ..  Is it
> >> worth having a class for this vs. raising the more general Notification
> >> and then checking for a #ReparseAfterSourceEditing signal, and if it
> >> isn't, re-raise Notification in its sole handler?
> >> ..
> >> This is a specific example of the more general question of where to draw
> >> the line on having single, or very limited, use classes and methods vs.
> >> adding a tiny bit of complexity in one or two methods to simplify the
> >> overall image or package in question.  Thoughts?
> > I would say the overriding goal is clarity.
> >
> > It is important work to refactor code to have the same behavior but be easier to understand.
> >
> > A Smalltalk style goal is to have small methods which do things clearly.  This tends to lead to lots of small methods.
> >
> > Specializing classes for one or just a few methods may seem wasteful, but computer resources are cheap.
> >
> > Look at class #PartsBinMorph.  Would you say the having the additional class is wasteful?
> >
> > It is a tough balance.  Aesthetics and restraint require judgement and we don't always get it right.  It takes time.
> >
> > I only have so many life hours left.  I feel my time is valuable.  I prefer to understand.
> >
> > Thank you so much for taking the time to make Cuis more comprehensible.
> >
> > $0.02
> > -KenD
>

Thanks for the feedback Ken.  I wasn't concerned with the computing
resources (at all) but rather the overall system complexity that results
from these one-shot types of classes and methods.  i.e. is it worth an
extra class or method here and there to save 1-2 lines of code in a
single, or even a couple, method(s).  Just spit-balling there are
probably ~100 (maybe as many as 200) classes, and who knows how many
methods, like this left in Cuis.  Agreed that this is getting into an
area of diminishing returns.

One thing that is different to me about PartsBinMorph, at least at first
glance, is that it involves both state and behavior.  I was really
thinking more of the extremes where classes exist purely to do one or
the other since they are often at best saving 1-2 lines of code
somewhere else.

> I fully support Ken. I don't think that a general answer is correct in
> all cases here. It is a matter of making code easy to understand. But
> also making it consistent and pretty.
>
> In general, I don't like making general classes know much about details
> of specific use cases. But there might be exceptions.
>
> If you feel like experimenting with this kind of stuff, send your
> suggestions to the mail list so we can discuss.
>
> In the particular case of ReparseAfterSourceEditing, I agree that a
> class that does nothing is a bit strange. But, what is the alternative?
> How would the sole exception handler know what to do with a general
> Notification? I think the handler looks quite reasonable right now. And
> the pollution of the global space might be tolerable if the alternative
> is more convoluted code...
>

And thank you Juan.  In the case of these one-shot exceptions, I was
thinking that the information could be communicated via the signal:
text.  i.e. rather than raising ReparseAfterSourceEditing, one could
instead raise Notification signal: #ReparseAfterSourceEditing.  However,
that would require that the exception handler trigger on Notification,
check the signal text in the handler, and if it isn't
#ReparseAfterSourceEditing re-raise the Notification if it determines
that it's not handling it after all.

> $0.02, not really a strong opinion.

I could go either way on this as well which is why I asked...

>
> Cheers,
> Juan Vuletich
>

Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Dan Norton
In reply to this post by Juan Vuletich-4
On 29 Jun 2015 at 13:23, Juan Vuletich wrote:

> Hi folks,
>
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > On Mon, 29 Jun 2015 07:09:43 -0400
> > "Phil (list)"<[hidden email]>  wrote:
> >> ..  Is it
> >> worth having a class for this vs. raising the more general
> Notification
> >> and then checking for a #ReparseAfterSourceEditing signal, and if
> it
> >> isn't, re-raise Notification in its sole handler?
> >> ..
> >> This is a specific example of the more general question of where
> to draw
> >> the line on having single, or very limited, use classes and
> methods vs.
> >> adding a tiny bit of complexity in one or two methods to simplify
> the
> >> overall image or package in question.  Thoughts?
> > I would say the overriding goal is clarity.
> >
> > It is important work to refactor code to have the same behavior
> but be easier to understand.
> >
> > A Smalltalk style goal is to have small methods which do things
> clearly.  This tends to lead to lots of small methods.
> >
> > Specializing classes for one or just a few methods may seem
> wasteful, but computer resources are cheap.
> >
> > Look at class #PartsBinMorph.  Would you say the having the
> additional class is wasteful?
> >
> > It is a tough balance.  Aesthetics and restraint require judgement
> and we don't always get it right.  It takes time.
> >
> > I only have so many life hours left.  I feel my time is valuable.
> I prefer to understand.
> >
> > Thank you so much for taking the time to make Cuis more
> comprehensible.
> >
> > $0.02
> > -KenD
>
> I fully support Ken. I don't think that a general answer is correct
> in
> all cases here. It is a matter of making code easy to understand.
> But
> also making it consistent and pretty.
>
> In general, I don't like making general classes know much about
> details
> of specific use cases. But there might be exceptions.
>
> If you feel like experimenting with this kind of stuff, send your
> suggestions to the mail list so we can discuss.
>
> In the particular case of ReparseAfterSourceEditing, I agree that a
> class that does nothing is a bit strange. But, what is the
> alternative?
> How would the sole exception handler know what to do with a general
> Notification? I think the handler looks quite reasonable right now.
> And
> the pollution of the global space might be tolerable if the
> alternative
> is more convoluted code...
>

Making code easy to understand is very valuable. Simple things should be simple to
accomplish, but achieving this in an API may not always be easy.

This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could
not get a new window with a PluggableListMorph to work like another one which had exactly
the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword
needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure
what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in
the future. :)

I'm just saying we should do anything we can to enhance clarity as well as simplify.

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Nicolas Cellier


2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
On 29 Jun 2015 at 13:23, Juan Vuletich wrote:

> Hi folks,
>
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > On Mon, 29 Jun 2015 07:09:43 -0400
> > "Phil (list)"<[hidden email]>  wrote:
> >> ..  Is it
> >> worth having a class for this vs. raising the more general
> Notification
> >> and then checking for a #ReparseAfterSourceEditing signal, and if
> it
> >> isn't, re-raise Notification in its sole handler?
> >> ..
> >> This is a specific example of the more general question of where
> to draw
> >> the line on having single, or very limited, use classes and
> methods vs.
> >> adding a tiny bit of complexity in one or two methods to simplify
> the
> >> overall image or package in question.  Thoughts?
> > I would say the overriding goal is clarity.
> >
> > It is important work to refactor code to have the same behavior
> but be easier to understand.
> >
> > A Smalltalk style goal is to have small methods which do things
> clearly.  This tends to lead to lots of small methods.
> >
> > Specializing classes for one or just a few methods may seem
> wasteful, but computer resources are cheap.
> >
> > Look at class #PartsBinMorph.  Would you say the having the
> additional class is wasteful?
> >
> > It is a tough balance.  Aesthetics and restraint require judgement
> and we don't always get it right.  It takes time.
> >
> > I only have so many life hours left.  I feel my time is valuable.
> I prefer to understand.
> >
> > Thank you so much for taking the time to make Cuis more
> comprehensible.
> >
> > $0.02
> > -KenD
>
> I fully support Ken. I don't think that a general answer is correct
> in
> all cases here. It is a matter of making code easy to understand.
> But
> also making it consistent and pretty.
>
> In general, I don't like making general classes know much about
> details
> of specific use cases. But there might be exceptions.
>
> If you feel like experimenting with this kind of stuff, send your
> suggestions to the mail list so we can discuss.
>
> In the particular case of ReparseAfterSourceEditing, I agree that a
> class that does nothing is a bit strange. But, what is the
> alternative?
> How would the sole exception handler know what to do with a general
> Notification? I think the handler looks quite reasonable right now.
> And
> the pollution of the global space might be tolerable if the
> alternative
> is more convoluted code...
>

Making code easy to understand is very valuable. Simple things should be simple to
accomplish, but achieving this in an API may not always be easy.

This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could
not get a new window with a PluggableListMorph to work like another one which had exactly
the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword
needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure
what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in
the future. :)

I'm just saying we should do anything we can to enhance clarity as well as simplify.

 - Dan


Since you are using the right keywords, maybe it's time to view it again
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Peter van Rooijen-2
Hi all,

I believe that a class can be justified simply because it gives you
an intention revealing name in the code, and room to put a
class comment (possibly an extensive one).

Especially with exceptions it can be difficult to understand
what exactly the exception is for, and a class comment can
be extremely helpful.

So, one thing that I am saying is that a class with NO behavior
but a well-chosen name, superclass and a clear class comment, can
be a very valuable part of a system.

Another thing I believe is that a class by itself is not very complex.
Complex in the sense of adding to the overall complexity of the system.

I have been interested in complexity and reducing it for a very long time
(since before I started with Smalltalk) and I have often thought about
the rules one would put into a tool that automatically measured the
complexity of a system of code.

One application of such a tool would be refactoring. Generally, after I
refactor, all my old tests should still run, but also, my overall complexity
should be lower.

At least, that was my thinking, and a tool that measures
complexity could help with that. In a sense it would be a more
sophisticated version of the "rule of three".

In any case, I never implemented such a tool, but did develop a set of
heuristics/rules that I let guide me to decide whether I should extract
methods, extract classes, etc. Part of these heuristics was that a class
by itself did not add that much.

I don't remember most of my rules although I probably still follow them
intuitively. Perhaps a class added more complexity than a method, but not
more than two methods, I don't really know.

I wonder what others do to decide how to factor code.

Cheers, Peter



On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <[hidden email]> wrote:


2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
On 29 Jun 2015 at 13:23, Juan Vuletich wrote:

> Hi folks,
>
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > On Mon, 29 Jun 2015 07:09:43 -0400
> > "Phil (list)"<[hidden email]>  wrote:
> >> ..  Is it
> >> worth having a class for this vs. raising the more general
> Notification
> >> and then checking for a #ReparseAfterSourceEditing signal, and if
> it
> >> isn't, re-raise Notification in its sole handler?
> >> ..
> >> This is a specific example of the more general question of where
> to draw
> >> the line on having single, or very limited, use classes and
> methods vs.
> >> adding a tiny bit of complexity in one or two methods to simplify
> the
> >> overall image or package in question.  Thoughts?
> > I would say the overriding goal is clarity.
> >
> > It is important work to refactor code to have the same behavior
> but be easier to understand.
> >
> > A Smalltalk style goal is to have small methods which do things
> clearly.  This tends to lead to lots of small methods.
> >
> > Specializing classes for one or just a few methods may seem
> wasteful, but computer resources are cheap.
> >
> > Look at class #PartsBinMorph.  Would you say the having the
> additional class is wasteful?
> >
> > It is a tough balance.  Aesthetics and restraint require judgement
> and we don't always get it right.  It takes time.
> >
> > I only have so many life hours left.  I feel my time is valuable.
> I prefer to understand.
> >
> > Thank you so much for taking the time to make Cuis more
> comprehensible.
> >
> > $0.02
> > -KenD
>
> I fully support Ken. I don't think that a general answer is correct
> in
> all cases here. It is a matter of making code easy to understand.
> But
> also making it consistent and pretty.
>
> In general, I don't like making general classes know much about
> details
> of specific use cases. But there might be exceptions.
>
> If you feel like experimenting with this kind of stuff, send your
> suggestions to the mail list so we can discuss.
>
> In the particular case of ReparseAfterSourceEditing, I agree that a
> class that does nothing is a bit strange. But, what is the
> alternative?
> How would the sole exception handler know what to do with a general
> Notification? I think the handler looks quite reasonable right now.
> And
> the pollution of the global space might be tolerable if the
> alternative
> is more convoluted code...
>

Making code easy to understand is very valuable. Simple things should be simple to
accomplish, but achieving this in an API may not always be easy.

This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could
not get a new window with a PluggableListMorph to work like another one which had exactly
the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword
needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure
what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in
the future. :)

I'm just saying we should do anything we can to enhance clarity as well as simplify.

 - Dan


Since you are using the right keywords, maybe it's time to view it again
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Phil B
On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all,
>
>
> I believe that a class can be justified simply because it gives you
> an intention revealing name in the code, and room to put a
> class comment (possibly an extensive one).
>

I believe that's the thinking that results in most of the current
Exception subclasses.  I personally don't care for it, but will go with
the consensus which seems to be OK with it.

>
> Especially with exceptions it can be difficult to understand
> what exactly the exception is for, and a class comment can
> be extremely helpful.
>

But Exceptions have a #signal: value which could also easily convey that
information.  (that's not always true, but the point is there are other
ways to convey the information other than subclassing)  Also keep in
mind that many exceptions, such as the one I was pointing out, are never
even seen by the user: they are used as an alternate messaging channel
by the code.

>
> So, one thing that I am saying is that a class with NO behavior
> but a well-chosen name, superclass and a clear class comment, can
> be a very valuable part of a system.
>
>
> Another thing I believe is that a class by itself is not very complex.
> Complex in the sense of adding to the overall complexity of the
> system.
>

True, a single class by itself is not very complex.  Multiply that by
100x or more and the story changes.  To me, one of the more obvious
aspects of complexity is the aggregate # of classes/methods/lines of
code in a system.  In this particular case, I was wondering out loud if
this particular trade-off (i.e. creating a class to save 1-2 lines of
code) was worth it.  I find it interesting that exception handling is
one of the younger parts of Smalltalk and, to me at least, it really
stands out as being rather strangely implemented in terms of the class
hierarchy.

>
> I have been interested in complexity and reducing it for a very long
> time
> (since before I started with Smalltalk) and I have often thought about
> the rules one would put into a tool that automatically measured the
> complexity of a system of code.
>
>
> One application of such a tool would be refactoring. Generally, after
> I
> refactor, all my old tests should still run, but also, my overall
> complexity
> should be lower.
>
>
> At least, that was my thinking, and a tool that measures
> complexity could help with that. In a sense it would be a more
> sophisticated version of the "rule of three".
>
>
> In any case, I never implemented such a tool, but did develop a set of
> heuristics/rules that I let guide me to decide whether I should
> extract
> methods, extract classes, etc. Part of these heuristics was that a
> class
> by itself did not add that much.
>
>
> I don't remember most of my rules although I probably still follow
> them
> intuitively. Perhaps a class added more complexity than a method, but
> not
> more than two methods, I don't really know.
>
>
> I wonder what others do to decide how to factor code.
>

You might want to take a look at Moose http://www.moosetechnology.org/
It's a tool to help you analyze and understand a given body of code.
It's a bit fragile/brittle/incomplete, but right now it's about the best
I've found to date to try to analyze and quantify complexity.  Also, you
could take a look at the work VPRI is doing related to FoNC/STEPS as
minimizing complexity is core to what they are working on.

>
> Cheers, Peter
>
>
>
>
>
> On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier
> <[hidden email]> wrote:
>        
>        
>         2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
>                 On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>                
>                 > Hi folks,
>                 >
>                 > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>                 > > On Mon, 29 Jun 2015 07:09:43 -0400
>                 > > "Phil (list)"<[hidden email]>  wrote:
>                 > >> ..  Is it
>                 > >> worth having a class for this vs. raising the
>                 more general
>                 > Notification
>                 > >> and then checking for a
>                 #ReparseAfterSourceEditing signal, and if
>                 > it
>                 > >> isn't, re-raise Notification in its sole handler?
>                 > >> ..
>                 > >> This is a specific example of the more general
>                 question of where
>                 > to draw
>                 > >> the line on having single, or very limited, use
>                 classes and
>                 > methods vs.
>                 > >> adding a tiny bit of complexity in one or two
>                 methods to simplify
>                 > the
>                 > >> overall image or package in question.  Thoughts?
>                 > > I would say the overriding goal is clarity.
>                 > >
>                 > > It is important work to refactor code to have the
>                 same behavior
>                 > but be easier to understand.
>                 > >
>                 > > A Smalltalk style goal is to have small methods
>                 which do things
>                 > clearly.  This tends to lead to lots of small
>                 methods.
>                 > >
>                 > > Specializing classes for one or just a few methods
>                 may seem
>                 > wasteful, but computer resources are cheap.
>                 > >
>                 > > Look at class #PartsBinMorph.  Would you say the
>                 having the
>                 > additional class is wasteful?
>                 > >
>                 > > It is a tough balance.  Aesthetics and restraint
>                 require judgement
>                 > and we don't always get it right.  It takes time.
>                 > >
>                 > > I only have so many life hours left.  I feel my
>                 time is valuable.
>                 > I prefer to understand.
>                 > >
>                 > > Thank you so much for taking the time to make Cuis
>                 more
>                 > comprehensible.
>                 > >
>                 > > $0.02
>                 > > -KenD
>                 >
>                 > I fully support Ken. I don't think that a general
>                 answer is correct
>                 > in
>                 > all cases here. It is a matter of making code easy
>                 to understand.
>                 > But
>                 > also making it consistent and pretty.
>                 >
>                 > In general, I don't like making general classes know
>                 much about
>                 > details
>                 > of specific use cases. But there might be
>                 exceptions.
>                 >
>                 > If you feel like experimenting with this kind of
>                 stuff, send your
>                 > suggestions to the mail list so we can discuss.
>                 >
>                 > In the particular case of ReparseAfterSourceEditing,
>                 I agree that a
>                 > class that does nothing is a bit strange. But, what
>                 is the
>                 > alternative?
>                 > How would the sole exception handler know what to do
>                 with a general
>                 > Notification? I think the handler looks quite
>                 reasonable right now.
>                 > And
>                 > the pollution of the global space might be tolerable
>                 if the
>                 > alternative
>                 > is more convoluted code...
>                 >
>                
>                
>                 Making code easy to understand is very valuable.
>                 Simple things should be simple to
>                 accomplish, but achieving this in an API may not
>                 always be easy.
>                
>                 This weekend I spent lots of "quality time" with the
>                 debugger, trying to figure out why I could
>                 not get a new window with a PluggableListMorph to work
>                 like another one which had exactly
>                 the behavior I wanted. The bug was that a method
>                 referred to by the #indexSetter: keyword
>                 needed to send the #selectedItem: message, which is
>                 not mentioned by keyword. Not sure
>                 what the answer is for that one but I'm working on
>                 notes to try to avoid that stupid mistake in
>                 the future. :)
>                
>                 I'm just saying we should do anything we can to
>                 enhance clarity as well as simplify.
>                
>                  - Dan
>                
>                
>        
>        
>         Since you are using the right keywords, maybe it's time to
>         view it again
>        
>         Simple made easy
>         http://www.infoq.com/presentations/Simple-Made-Easy 
>        
>        
>                 _______________________________________________
>                 Cuis mailing list
>                 [hidden email]
>                 http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>                
>        
>        
>        
>         _______________________________________________
>         Cuis mailing list
>         [hidden email]
>         http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>        
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Juan Vuletich-4
In reply to this post by Nicolas Cellier
On 7/1/2015 9:52 AM, Nicolas Cellier wrote:
> ...
>
> Since you are using the right keywords, maybe it's time to view it again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy

Thanks Nicolas. This is absolutely wonderful! Really inspiring.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Juan Vuletich-4
In reply to this post by Peter van Rooijen-2
On 7/1/2015 5:10 PM, Peter van Rooijen wrote:
> ...
>
> I don't remember most of my rules although I probably still follow them
> intuitively. Perhaps a class added more complexity than a method, but not
> more than two methods, I don't really know.
>
> I wonder what others do to decide how to factor code.
>
> Cheers, Peter


To me Smalltalk code is an expression of human knowledge. I refactor
code when I understand better, to express that new understanding.

Writing code is like writing course material, or a technical book on
some subject. Good code is like a good book. You read it and understand.
That's the gold standard.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Dan Norton
In reply to this post by Nicolas Cellier
Hi,

I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The
question is how to view it without disabling my antivirus plus surrendering a bunch of
"required" info. BTW I'm running Win7, IE, and ESET.

Any other possibilities?

 - Dan

On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:

>
>
>
> 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
>     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>    
>     > Hi folks,
>     >
>     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>     > > On Mon, 29 Jun 2015 07:09:43 -0400
>     > > "Phil (list)"<[hidden email]>  wrote:
>     > >> ..  Is it
>     > >> worth having a class for this vs. raising the more
> general
>     > Notification
>     > >> and then checking for a #ReparseAfterSourceEditing signal,
> and if
>     > it
>     > >> isn't, re-raise Notification in its sole handler?
>     > >> ..
>     > >> This is a specific example of the more general question of
> where
>     > to draw
>     > >> the line on having single, or very limited, use classes
> and
>     > methods vs.
>     > >> adding a tiny bit of complexity in one or two methods to
> simplify
>     > the
>     > >> overall image or package in question.  Thoughts?
>     > > I would say the overriding goal is clarity.
>     > >
>     > > It is important work to refactor code to have the same
> behavior
>     > but be easier to understand.
>     > >
>     > > A Smalltalk style goal is to have small methods which do
> things
>     > clearly.  This tends to lead to lots of small methods.
>     > >
>     > > Specializing classes for one or just a few methods may
> seem
>     > wasteful, but computer resources are cheap.
>     > >
>     > > Look at class #PartsBinMorph.  Would you say the having
> the
>     > additional class is wasteful?
>     > >
>     > > It is a tough balance.  Aesthetics and restraint require
> judgement
>     > and we don't always get it right.  It takes time.
>     > >
>     > > I only have so many life hours left.  I feel my time is
> valuable.
>     > I prefer to understand.
>     > >
>     > > Thank you so much for taking the time to make Cuis more
>     > comprehensible.
>     > >
>     > > $0.02
>     > > -KenD
>     >
>     > I fully support Ken. I don't think that a general answer is
> correct
>     > in
>     > all cases here. It is a matter of making code easy to
> understand.
>     > But
>     > also making it consistent and pretty.
>     >
>     > In general, I don't like making general classes know much
> about
>     > details
>     > of specific use cases. But there might be exceptions.
>     >
>     > If you feel like experimenting with this kind of stuff, send
> your
>     > suggestions to the mail list so we can discuss.
>     >
>     > In the particular case of ReparseAfterSourceEditing, I agree
> that a
>     > class that does nothing is a bit strange. But, what is the
>     > alternative?
>     > How would the sole exception handler know what to do with a
> general
>     > Notification? I think the handler looks quite reasonable right
> now.
>     > And
>     > the pollution of the global space might be tolerable if the
>     > alternative
>     > is more convoluted code...
>     >
>
>     Making code easy to understand is very valuable. Simple things
> should be simple to
>     accomplish, but achieving this in an API may not always be
> easy.
>    
>     This weekend I spent lots of "quality time" with the debugger,
> trying to figure out why I could
>     not get a new window with a PluggableListMorph to work like
> another one which had exactly
>     the behavior I wanted. The bug was that a method referred to by
> the #indexSetter: keyword
>     needed to send the #selectedItem: message, which is not
> mentioned by keyword. Not sure
>     what the answer is for that one but I'm working on notes to try
> to avoid that stupid mistake in
>     the future. :)
>    
>     I'm just saying we should do anything we can to enhance clarity
> as well as simplify.
>    
>      - Dan
>
>
> Since you are using the right keywords, maybe it's time to view it
> again
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
>
>     _______________________________________________
>     Cuis mailing list
>     [hidden email]
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Juan Vuletich-4
Hi Dan,

It plays without problems in Chrome on my Win7 PC. No need to supply any
info at all.

HTH,
Juan vuletich

On Thu, July 2, 2015 10:15 pm, Dan Norton wrote:

> Hi,
>
>
> I would like to view this, especially since it is recommended by Nicolas,
> Paul, and Juan. The
> question is how to view it without disabling my antivirus plus
> surrendering a bunch of "required" info. BTW I'm running Win7, IE, and
> ESET.
>
>
> Any other possibilities?
>
>
> - Dan
>
>
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
>
>
>>
>>
>>
>> 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
>> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>>
>>
>>> Hi folks,
>>>
>>>
>>> On 6/29/2015 10:51 AM, Ken.Dickey wrote:
>>>
>>>> On Mon, 29 Jun 2015 07:09:43 -0400
>>>> "Phil (list)"<[hidden email]>  wrote:
>>>>
>>>>> ..  Is it
>>>>> worth having a class for this vs. raising the more
>> general
>>> Notification
>>>
>>>>> and then checking for a #ReparseAfterSourceEditing signal,
>> and if
>>> it
>>>>> isn't, re-raise Notification in its sole handler? ..
>>>>> This is a specific example of the more general question of
>>>>>
>> where
>>> to draw
>>>>> the line on having single, or very limited, use classes
>> and
>>> methods vs.
>>>>> adding a tiny bit of complexity in one or two methods to
>> simplify
>>> the
>>>>> overall image or package in question.  Thoughts?
>>>> I would say the overriding goal is clarity.
>>>>
>>>>
>>>> It is important work to refactor code to have the same
>>>>
>> behavior
>>> but be easier to understand.
>>>>
>>>> A Smalltalk style goal is to have small methods which do
>>>>
>> things
>>> clearly.  This tends to lead to lots of small methods.
>>>>
>>>> Specializing classes for one or just a few methods may
>>>>
>> seem
>>> wasteful, but computer resources are cheap.
>>>>
>>>> Look at class #PartsBinMorph.  Would you say the having
>>>>
>> the
>>> additional class is wasteful?
>>>>
>>>> It is a tough balance.  Aesthetics and restraint require
>>>>
>> judgement
>>> and we don't always get it right.  It takes time.
>>>>
>>>> I only have so many life hours left.  I feel my time is
>>>>
>> valuable.
>>> I prefer to understand.
>>>
>>>>
>>>> Thank you so much for taking the time to make Cuis more
>>>>
>>> comprehensible.
>>>>
>>>> $0.02
>>>> -KenD
>>>>
>>>
>>> I fully support Ken. I don't think that a general answer is
>>>
>> correct
>>> in all cases here. It is a matter of making code easy to
>> understand.
>>> But
>>> also making it consistent and pretty.
>>>
>>> In general, I don't like making general classes know much
>>>
>> about
>>> details of specific use cases. But there might be exceptions.
>>>
>>> If you feel like experimenting with this kind of stuff, send
>>>
>> your
>>> suggestions to the mail list so we can discuss.
>>>
>>> In the particular case of ReparseAfterSourceEditing, I agree
>>>
>> that a
>>> class that does nothing is a bit strange. But, what is the
>>> alternative? How would the sole exception handler know what to do with
>>> a
>> general
>>> Notification? I think the handler looks quite reasonable right
>>>
>> now.
>>> And
>>> the pollution of the global space might be tolerable if the alternative
>>>  is more convoluted code...
>>>
>>
>> Making code easy to understand is very valuable. Simple things
>> should be simple to accomplish, but achieving this in an API may not
>> always be easy.
>>
>> This weekend I spent lots of "quality time" with the debugger,
>> trying to figure out why I could not get a new window with a
>> PluggableListMorph to work like
>> another one which had exactly the behavior I wanted. The bug was that a
>> method referred to by the #indexSetter: keyword needed to send the
>> #selectedItem: message, which is not
>> mentioned by keyword. Not sure what the answer is for that one but I'm
>> working on notes to try to avoid that stupid mistake in the future. :)
>>
>> I'm just saying we should do anything we can to enhance clarity
>> as well as simplify.
>>
>>  - Dan
>>
>>
>>
>> Since you are using the right keywords, maybe it's time to view it
>> again Simple made easy
>> http://www.infoq.com/presentations/Simple-Made-Easy
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Phil B
In reply to this post by Dan Norton
You're probably trying one of the download links.  You can stream the
video as long as JavaScript is enabled.  If you can't temporarily do
this in IE, I'd highly recommend keeping Firefox+NoScript around as it
lets you temporarily enable JavaScript & cookies for this type of
scenario.

On Thu, 2015-07-02 at 21:15 -0400, Dan Norton wrote:

> Hi,
>
> I would like to view this, especially since it is recommended by Nicolas, Paul, and Juan. The
> question is how to view it without disabling my antivirus plus surrendering a bunch of
> "required" info. BTW I'm running Win7, IE, and ESET.
>
> Any other possibilities?
>
>  - Dan
>
> On 1 Jul 2015 at 14:52, Nicolas Cellier wrote:
>
> >
> >
> >
> > 2015-06-30 0:17 GMT+02:00 Dan Norton <[hidden email]>:
> >     On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
> >    
> >     > Hi folks,
> >     >
> >     > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> >     > > On Mon, 29 Jun 2015 07:09:43 -0400
> >     > > "Phil (list)"<[hidden email]>  wrote:
> >     > >> ..  Is it
> >     > >> worth having a class for this vs. raising the more
> > general
> >     > Notification
> >     > >> and then checking for a #ReparseAfterSourceEditing signal,
> > and if
> >     > it
> >     > >> isn't, re-raise Notification in its sole handler?
> >     > >> ..
> >     > >> This is a specific example of the more general question of
> > where
> >     > to draw
> >     > >> the line on having single, or very limited, use classes
> > and
> >     > methods vs.
> >     > >> adding a tiny bit of complexity in one or two methods to
> > simplify
> >     > the
> >     > >> overall image or package in question.  Thoughts?
> >     > > I would say the overriding goal is clarity.
> >     > >
> >     > > It is important work to refactor code to have the same
> > behavior
> >     > but be easier to understand.
> >     > >
> >     > > A Smalltalk style goal is to have small methods which do
> > things
> >     > clearly.  This tends to lead to lots of small methods.
> >     > >
> >     > > Specializing classes for one or just a few methods may
> > seem
> >     > wasteful, but computer resources are cheap.
> >     > >
> >     > > Look at class #PartsBinMorph.  Would you say the having
> > the
> >     > additional class is wasteful?
> >     > >
> >     > > It is a tough balance.  Aesthetics and restraint require
> > judgement
> >     > and we don't always get it right.  It takes time.
> >     > >
> >     > > I only have so many life hours left.  I feel my time is
> > valuable.
> >     > I prefer to understand.
> >     > >
> >     > > Thank you so much for taking the time to make Cuis more
> >     > comprehensible.
> >     > >
> >     > > $0.02
> >     > > -KenD
> >     >
> >     > I fully support Ken. I don't think that a general answer is
> > correct
> >     > in
> >     > all cases here. It is a matter of making code easy to
> > understand.
> >     > But
> >     > also making it consistent and pretty.
> >     >
> >     > In general, I don't like making general classes know much
> > about
> >     > details
> >     > of specific use cases. But there might be exceptions.
> >     >
> >     > If you feel like experimenting with this kind of stuff, send
> > your
> >     > suggestions to the mail list so we can discuss.
> >     >
> >     > In the particular case of ReparseAfterSourceEditing, I agree
> > that a
> >     > class that does nothing is a bit strange. But, what is the
> >     > alternative?
> >     > How would the sole exception handler know what to do with a
> > general
> >     > Notification? I think the handler looks quite reasonable right
> > now.
> >     > And
> >     > the pollution of the global space might be tolerable if the
> >     > alternative
> >     > is more convoluted code...
> >     >
> >
> >     Making code easy to understand is very valuable. Simple things
> > should be simple to
> >     accomplish, but achieving this in an API may not always be
> > easy.
> >    
> >     This weekend I spent lots of "quality time" with the debugger,
> > trying to figure out why I could
> >     not get a new window with a PluggableListMorph to work like
> > another one which had exactly
> >     the behavior I wanted. The bug was that a method referred to by
> > the #indexSetter: keyword
> >     needed to send the #selectedItem: message, which is not
> > mentioned by keyword. Not sure
> >     what the answer is for that one but I'm working on notes to try
> > to avoid that stupid mistake in
> >     the future. :)
> >    
> >     I'm just saying we should do anything we can to enhance clarity
> > as well as simplify.
> >    
> >      - Dan
> >
> >
> > Since you are using the right keywords, maybe it's time to view it
> > again
> > Simple made easy
> > http://www.infoq.com/presentations/Simple-Made-Easy
> >
> >     _______________________________________________
> >     Cuis mailing list
> >     [hidden email]
> >     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Where to put the complexity?

Dan Norton
On 2 Jul 2015 at 22:03, Phil (list) wrote:

> You're probably trying one of the download links.  You can stream
> the
> video as long as JavaScript is enabled.  If you can't temporarily
> do
> this in IE, I'd highly recommend keeping Firefox+NoScript around as
> it
> lets you temporarily enable JavaScript & cookies for this type of
> scenario.
> [...]

Thanks, Phil. That's better.

 - Dan


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org