Re: Small Methods - a ramble

Ron Jeffries wrote:
> > Now most of us who read larger methods are used to doing the
> > reverse. We look at a big blob of code and figure out little chunks
> > of it. Then maybe we comment the code or make a note or just leave
> > the figuring out to the next person.
> >
> > Tiny methods -- when you get used to them -- are IME /much/ easier
> > to write and to work with.
> >
> > Editor-based languages like Ruby, Java, C++, encourage longer
> > methods because we have to search with our eyes to figure things
> > out.
> >
> > What does this mean? I don't know. I think it might mean that a
> > browser for Ruby or Java or C++ would be really good. Visual Age for
> > Java is really wonderful in the hands of people who learn to work in
> > the browser mode.

As you probably know, Ron, I've hung out with Smalltalkers for a long time, 
but I've never fallen in love with Smalltalk. Part of that is a personal 
quirk. I have an uncommonly bad short-term memory for a programmer. When 
I'm bouncing around in Smalltalk browser windows, it's easy for me to 
forget context - why am I looking at this method? Emacs lets me manage my 
attention better than the Smalltalk browser, as do the (somewhat) larger 
methods in editor-based languages like Ruby.

But I think there's a bit more to it than that. The literary critic Stanley 
Fish talks about "interpretive communities". Different schools of readers 
internalize different ways of looking at texts, different theories of how 
to read. People cannot easily "step outside" their internalized way of 
reading; they see what (and how) their theories tell them.

And, because readers are also writers, you get reinforcing loops. As a 
simple example, some readers are taught that where poets break lines is 
significant. Each line break completes a thought, even when it's not at a 
sentence boundary. When poets know that, they start playing games with line 
breaks. So now line breaks become even more significant.

To me - maybe an interpretive community of one - the physical arrangement 
of code is important. If two methods have something to do with each other, 
I put them close together. It usually means something significant if two 
classes share a file. Browser technology has something to do with this - I 
semi-consciously try to arrange methods so that you can grasp some whole 
story using two Emacs windows and a little scrolling, because that's the 
easiest way to use Emacs - but that's not all there is to it. I think 
physical arrangement gives cues that senders/implementers browsing doesn't, 
and that's probably a consequence of being conscious of files in a way 
Smalltalk programmers aren't. I sometimes explicitly think of a source file 
as a story being told to a new reader about the code, a story intended to 
be read linearly first time through. (And the first thing I do when reading 
someone else's code is scan through files linearly, just looking for 
interesting things at all levels of detail. That feels quite different than 
looking at a class in the Smalltalk browser.)

(Note: anyone looking at my code can tell that all this graspability and 
narrative structure is more a goal than something I consistently achieve.)

I bring up interpretive communities because it can be hard to talk between 
them. So much is implicit, hard to articulate. Their practices and tools 
are all intertwined and self-reinforcing, so it's misleading to talk about 
anything in isolation. Often, the same words have different connotations.

I think it would be neat if Rubyists coalesced into an interpretive 
community the way Smalltalkers have. In the spirit of diversity, I hope 
that community bears the same relationship to Smalltalk's as the Ruby 
language does to Smalltalk: partly inspired by, but different than. What 
can we do with a file-aware approach? How would a good browser and good 
programming practice take account of the way Ruby has no declarations, just 
executable code? And so forth.

All of which is not to say that a Ruby browser shouldn't support small 
methods. The Subject *does* say "ramble".

At 05:45 PM 1/13/02, David Alan Black wrote:
>It's interesting -- you're looking at code as a narrative form, and
>not narrative in the sense of being executed in a certain order, but
>more in the sense of containing a story, possibly oblique to the order
>of execution.  (I don't know that I'm adding anything to what you're
>saying -- I just always find unusual or unexpected narrative forms
>intriguing.)

There's a branch of literary criticism called "reader-response criticism". 
It's about analyzing literature by thinking about its effect on a 
(hypothetical) reader. Some of the techniques are relevant to reading code, 
I think, and I intend to finish a paper on that someday.

In particular, reader-response criticism people distinguish between 
different types of readers. Programmers typically write to two readers: the 
computer and some sort of idealized reader, who basically knows the same 
things the programmer knows at the moment of writing. Programmers might 
write better code if they thought more explicitly about the intended reader.

Stanley Fish's "affective stylistics" reminds me of Ron's narrative of 
reading Smalltalk-style Ruby code. In affective stylistics, you scan chunks 
of text and ask "What is the reader thinking at this point? What questions 
does she have? What does she think she knows?" You (if you are Fish) pay 
special attention to how the text tricks the reader, keeps her off-balance, 
when the overall message of the text is something like "there is no 
certainty". (That is, he likes to show how texts *make* the reader 
uncertain, not just tell her that she should be.)

I read Fish because, well, I'm weird. But I'm also interested in the ways 
that code unintentionally tricks the reader. The rather simple techniques 
of affective stylistics might help programmers write better, be better at 
finding "code smells".

----

Refs:

Stanley Fish, _Is There a Text in This Class?: The Authority of 
Interpretive Communities_. An easy read, especially for literary theory. 
I'd read the introduction last. The first chapter, "Literature in the 
Reader: Affective Stylistics", is quite convincing.

Jane Tompkins (ed.) _Reader-Response Criticism_. Has the key Fish papers, 
as well as stuff from other authors. The readability of the papers varies 
widely. Pretty accessible, in general.

Richard Rorty, _Philosophy and Social Hope_. A collection of essays, some 
about how hard it is to talk to other interpretive communities.

--
Brian Marick, [e-mail]
www.testing.com - Software testing services and resources
www.testingcraft.com - Where software testers exchange techniques
www.visibleworkings.com - Adequate understanding of system internals