TITLE: Sometimes, We Need to Make a Better Tool
AUTHOR: Eugene Wallingford
DATE: October 12, 2017  3:35 PM
DESC: 
-----
BODY:
 I learned about a couple of cool CLI tools from Nikita Sobolev's
<A HREF="https://dev.to/sobolevn/using-better-clis-6o8">
   Using Better CLIs</A>.
 <TT>hub</TT> and <TT>tig</TT> look like they may be worth a deeper
 look.  This article also reminded me of one of the examples in
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2017-10.html#e2017-10-10T16_10_03.htm">
   the blog entry I <TT>rm</TT>ed</A>
 the other day.  It reflects a certain attitude about languages
 and development.

 One of the common complaints about OOP is that what would be a
 single function in other programming styles usually ends up
 distributed across multiple classes in an OO program.  For example,
 instead of:
<PRE>
    void draw(Shape s) {
       case s of
          Circle : [code for circle]
          Square : [code for square]
          ...
    }
</PRE>
 the code for the individual shapes ends up in the classes for
 <TT>Circle</TT>, <TT>Square</TT>, and so on.  If you have to change
 the drawing code for all of the shapes, you have to track down all
 of the classes and modify them individually.

 This is true, and it is a serious issue.  We can debate the relative
 benefits and costs of the different designs, of course, but we might
 also think about ways that our development tools can help us.

 As a grad student in the early 1990s, I worked in a research group
 that used VisualWorks Smalltalk to build all of its software.  Even
 within a single Smalltalk image, we faced this code-all-over-the-place
 problem.  We were adding methods to classes and modifying methods
 all the time as part of our research.  We spent a fair amount of time
 navigating from class to class to work on the individual methods.

 Eventually, one of my fellow students had an epiphany: we could
 write a new code browser.  We would open this browser on a
 particular class, and the browser would provide a pane listing and
 all of its subclasses, and all of their subclasses.  When we
 selected a method in the root class, the browser enabled us to
 click on any of the subclasses, see the code for the subclass's
 corresponding method, and edit it there.  If the class didn't have
 an overriding method, we could add one in the empty pane, with the
 method signature supplied by the browser.

 This browser didn't solve all of the problems we had learning to
 manage a large code base spread out over many classes, but it was
 a huge win for dealing with the specific issue of an algorithm
 being distributed across several kinds of object.  It also taught
 me two things:
<UL>
<LI> to appreciate the level of control that Smalltalk gave
     developers to inspect code and shape the development
     experience </LI>
<LI> to appreciate the mindset that creating new tools is the way
     to mitigate many problems in software development, if not to
     solve them completely </LI>
</UL>

 The tool-making mindset is one that I came to appreciate and
 understand more and more as the years past.  I'm disappointed
 whenever I don't put it to good use, but oftentimes I wise up and
 make the tools I need to help me do my work.
-----