Re: SproutMethod.pdf

From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 11/20/03 

Date: Thu, 20 Nov 2003 11:45:28 -0800

Ron Jeffries wrote:
>>For example, the armies of unqualified programmers are illusioned about
>>these refactoring thingies and OO voodoos, to the point that they
>>literally forget that they have to make a transformation from Point A to
>>Point B.
>
>
> I don't understand this point. If they get the code written that they need --
> and they do -- in what sense has something important been forgotten?
>
>

The code is ugly, bulky and it underperforms.

>>It even shows on your latest article on bowling :) Common, if
>>you were Dijkstra's student he'd have looked upon you disapprovingly:
>>what the hell do you waste so many lines of code for ?
>
>
> Were you Dijkstra's student?

No.

> Is that how you know what he would say?

I would imagine.

>>The Frame classes
>>and the whole OO aparatus can only be make points at "artistic
>>impression".
>
>
> I gather that you haven't read the next article, with a procedural version that
> is about one-fifth the size. There is an interesting discussion going on on the
> mailing list right now about when and whether one would go to the more OO
> solution.

Ok, now I've read it. When to go to the more OO solutiopn, nmeaning the
first article ? Never.

> It might be that you are reading things into my articles that are not intended
> to be there, or that you're not reading things that are intended to be there.
>

You mean the code from the first article was not intended to be there ? :)

> I'm writing about how one does TDD, and how the design can evolve -- in /any/
> direction -- while using that technique. If you, or someone else, wanted to
> write a similar article about solving a problem, ideally the same problem, using
> some other approach, that would be fine.
>

Not really. I mean, common, how can someone right an article to resolve
a simple loop ?

> My articles show every step, so that readers can get a sense of how I think and
> how long it takes. I think that's of value.
>

Well, I am very much unsure about that. I don't doubt your intentions,
but I doubt that the results are as intended.

>
>>Nobody seemed to be concerned anymore with keeping the LOC
>>low, anymore as long as you can keep methods in 5 lines or less. So more
>>or less, the classical basis of programming: how to write loops, how to
>>avoid bad control flow structures, how to maintain invariants is lost.
>
>
> Yes, those things are in fact no longer well understood, and I have to admit
> that I rather miss them. I suspect that I program intuitively with invariants in
> mind, and I would guess that you do as well. (You might think more directly
> about them than I, owing to your greater familiarity with and attention to this
> kind of thing, but I suspect that most of the time you "just write" the right
> kind of loop. Is that a fair description of what you experience?)
>

Sure, in the second article. I mean for trivial loops it's trivial, you
don't have to formalize, you just write (provided that you alsop read).
But anything beyond trivial there's already a danger.

And there's already a danger that you wrote the first article and just
introduced unnecessary entities that will later on polute the
namespaces, and about which you can no longer "reason locally".

That's one of the essential feature that has been forgotten, inspite the
initial effort made by OO fathers to improve exactly this: the locality
of reasoning. Objects are suppose to make sense on their own, therefore
it is a waste to have tons of classes: most of them are either too
trivial and serve more as synctactic sugar to bundle data together,
other have some state transition operation that you cannot look at and
say, OK this is not only correct but it also make sense. The intention
and the correctness of that state update is revealed only if you put the
puzzle back together again, and follow a complete use case by jumping
through all the hooplas over a miriad of methods in different classes,
some of which are called so indirectly (grace to the popularity of
Design Paterns book) (i.e. through Factories, Observer and other funny
design artifacts), so that the overall "Shape Of Software" has a warm
fuzzy OO feeling attached to it, however the quality of the design is
obviosly worst: for example we can quantify it based on the effort of a
first reader to read the code and judge it correct and make a trivial
modification.

For practical examples: Take John Elrick posted code to my response (in
the very fancy language Ruby). We won't count that the algorithm is
wrong, but we should count that it takes us significantly more effort to
judge it wrong, than if he'd wrote it in good old Pascal.
For a non-trivial example from my experience: download the
Jakarta-Tomcat source code and try to figure out how you can modify the
algorithm by which they decide that a JSP needs or does not need a
recompilation (caching of JSP compiled classes). You'd think (like I
did) that is a trivial thing to do but it is highly non-trivial and
painful. For a comparison, try to find in the Apache source code how
they discard the cached pages.

OO code these days is much harder to read and reason about than
procedural code, but that was not the intention ! Exalting features like
dynamic typing and lack of variable declaration (like in Ruby example,
where instance variable just pop their heads when they are used), makes
it even worse.

>
>>The lack of a mathematical "coolness" (in Miles Davis kind of way), can
>>also be seen and quantified in the design disaster of many OO
>>frameworks, that are designed based on just a "OO hunch" with no clear
>>objective measure of what there is to look for in a good design.
>
>
> I'm not thinking of one just this moment, but I share the general impression of
> a lack of coolness of that kind. Those skills have been valuable to me, and in
> my math period I came to value that kind of elegance.
>

For example: if somebody encoded relational algebra in the various OO
APIs for managin "relationships" (aka association), it would be bloody
obvious that it covers pretty much all your needs, and the client code
can be bloody obvious that it is correct.

However, the ugly reality is for example in the EJB specs (as well as
Hybernate and lots of other O/R) mapping, they come with all those
unncessary discussions about one to many, many to one, many to many,
etc, etc making an unneccesary and ugly read on all those little cases,
and including side effects of adding elements to collections
implementing "framework managed" associations/relationships. On top of
this ad-hockery, EJB falls flat on its face (for the all the millions of
$ from Sun's pockets ) on handlig something as trivial as a ternary
relationship. That's just one of the more obvious example of lack of
mathematical coolness, but trust me, it is widely deployed and widely
used, and it is just the next generation of COBOL.

> However, I find, as I gather you do, that the applicability of the techniques
> isn't broad. Refactoring and the other techniques that I write about are in fact
> easier to do and, I believe, more broadly applicable.
>

There is a core of software artifacts where these techniques *should* in
my opinion be applied: that is the computing infrastructure. THe thing
that we rebuild and rebuild again year after year, and we never seem to
be approaching a fix-point.

Now I was discussing with a colleague: how cool this service oriented
architecture, he said. Oh well, I said, it was RPC, then we went through
CORBA, we went through Java RMI, now we are back to RPC and just changed
the encoding scheme, and we're so damn proud of it (nevermind that
transactions, security and other essential features were lost on the
road), and in the same time created countelss "interoperability" issues.

And I still don't have a damn messaging framework that meets my needs.

>>But where do I use proofs ? I do not use proofs per se, as they are too
>>expensive and I don't have IDE support, I'm too lazy bun to do it
>>otherwise. However, I believe that for the critical portions of my code
>>I can aquit myself of Dijkstra's "proof obligation" : be *able* to proof
>>that the program meets the required properties. And when the design is
>>driven by the need to meet specific properties, it will be much cleaner
>
>
> Yes, I'm sure that's true. Now if we knew a way to teach it that avoided the
> difficulty of being too expensive, requiring years of math practice to get the
> sense of what a proof should be like, and so on ... that would be nice.
>
> I believe -- but cannot prove -- that the comp sci notions of law of demeter,
> LSP, coupling and coherence, and so on, address properties of code which are
> similar to code which is generated in the proof/invariant style. Certainly those
> notions generate code that looks good to me and to many other thinkers in the
> biz.
>

I don't see how you can make the law of demeter a comp.science notion,
as for LSP if could only convince Alistair Cockburn that reflection
doesn't break it, and it is valid as a principle, next if we could only
convince Uncle Bob what exactly LSP is (by the way, I don't know who
hijacked LSP, but it was first and foremost about *provable* properties
of subtype implementation).

> The techniques of refactoring are more atomic, almost mathematical in their own
> way, and they are, I believe, much more accessible, learnable, with desirable
> results when used well. What's not to like about that?
>

Well, there's a lot not to like about that. Take the Refactoring book,
almost every refactoring method in there has a counter-method, and they
are under a "therefore-but" that makes it as clear as mud for
practitioners when to use it and when not to use it. Trust me, people in
the field are confused where all those refactoring should converge, it's
just if they "feel" like changing the shape of a particular code they
will do it.

Add to that the OO mantra that the average method should have 5 lines of
code, and you get to the point where the "visual and thinking space" of
an OO project (typically reflected in the way you navigate through
packages, classes and methods with a code browser) is polluted heavily
with non-essential concepts that are at best implementation tricks and
most of the time they are just ways to write more LOC with a fuzzy worm
OO feeling.

I think the next big book on Design Patterns and refactoring should be :
when and why not to apply each of them, with practical examples.

>>Sometimes I wished I could avoid that, but in the end I still can't.
>>
>>For example I'd be extremely grateful if you or anybody else would spare
>>me the pain for the next project. So give me a messaging framework that
>>can support out of the box:
>
>
> You listed some nice things to want ... and I don't know where to get them.
>

They are not only nice, they are kind of essential for my next project.
And it's about money, security, etc so some of the "exotic" feature now
really do become important. If I was writing the next unreliable chat,
I'd have made without.

But the thing is, of course I'll produce the functionality to make it
happen without some exotic features for the prototype and for the
purpose of letting the project flow, but in the end if those features
are not there, in the messaging layer it will at best be an workaround.
And I probably can't put them all myself, I have other entirely
different areas to take care of - including accounting for which I do
need a way simpler but nevertheless mathematical approach so that I can
mathematically cover my ass :). All in all, I do need to have fellow
engineers around me that can budge for a mathematical approach. I'll
grant them the luxury of fuzzy OO for all the other cool things to do in
a project.

But since the later fashions tend to go away from math, it becomes kind
of worrying, not only for my next project, but as a society that will
depend more and more on a safe, reliable secure, software
infrastructure. Just think about it: we do mostly informal proofs and
code reviews (when we do them at all), but in the same time we do not
invest enough in advancing state of the art so that in 20 years the next
generation could do it. Now I come to ask you: what is the likelyhood
that the latest blackout wasn't triggered or worsened by software bugs,
or loose software systems ?

>>Again if anybody can recommend something for real, (meaning more than
>>vendor whitepapers to document te above) I'd be extremely grateful.
>>
>>Now given the state of the art in CS, this kind of thing should have
>>existed a decade ago (everything minus C# and Java). As far as I know,
>>it isn't there, so I have to improvise.
>>
>>Can you conceive of meeting the above requirements without a
>>mathematically driven approach ?
>
>
> Yes, but I can believe six impossible things before breakfast.
>
> I know how to write good programs sometimes, using mathematics, but as you point
> out it is difficult, almost impossible in many situations.
>

As well, as it is difficult almost impossible to write test first in
other situation.

> Yet I have to write programs. So I use different tools, the ones that work best
> for me. What else would one have me do?
>

Of course. But I'd rather do away that this naive attitude like Computer
Science is reinvented again, all over.

It is nowadays almost funny how when I contribute something on usenet or
on wiki, somebody will jump at me: where are the unit tests ? You risk
growing a generation indoctrinated with such mantras like "if you can't
test it, it's not a requirement" or "if you don't write test first,
you're not doing a professional job", etc, etc.

I'd rather see fellow software engineers acutely aware that there are
many tools and many approaches.

> Regards,
>

Best,
Costin

Quantcast