[Cuis] Where to put the complexity?

[Phil (list)]

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 <dnorton at mindspring.com>:
> >     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)"<pbpublist at gmail.com>  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
> >     Cuis at jvuletich.org
> >     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> > 
> 
> 
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org