Collection interfaces

[Alex Martelli]

"Topmind" <topmind at technologist.com> wrote in message
news:MPG.1506cf3293b094b49896c1 at news.earthlink.net...
>
> > Before you knock
> > it, TRY it -- pick a pilot project of suitable size, a team
> > ditto, and have a go at it with eXtreme Programming
>
> Sure, hack-it-til-it-works indeed does work after enough

XP is _not_ "hack it til it works".  Do you know _anything_
about it, and are just being deliberately dense, or do you
enjoy speaking of what you know not...?

> time. But whether it produces a better system in the
> long run is another issue. Without better metrics, it is
> just Yet Another Methodology to add to the heap.

I've often noticed that demanding metrics is the last
line of defense of the conservatives in our field against
innovation -- since nobody's really funded to run serious
(and hugely costly) controlled experiments, such demanders
can rest reasonably tranquil that they won't be faced with
such metrics.  Unfortunately, the world has this habit of
passing them by anyway.


> How about you try heavy table-oriented programming for a
> few years.

Been there, done that, more or less whatever you mean by
"table-oriented programming" -- after all, I _have_ been
programming for well over a quarter of a century, in a
reasonably vast variety of paradigms.  From the jump table
of well-constructed, speedy machine-code, to the SQL Table
of relational-DB programming, I've done more tables than
the average Parisian cafe has on the sidewalks on a bright
and warm spring day...


> > code test-first, *refactor mercilessly*,
>
> I would rather use task-orientation and avoid
> excessive refactoring to begin with.

...then your resulting sources will never be as good,
clear, clean, maintainable, and high-quality, as those
of a better programmer, who DOES refactor every time
the occasion affords.

> "Refactoring" is a euphemism for "OO is not
> change-friendly after all".

Refactoring is not necessary _only_ in OO, of course.

And, depending on the axis of change, any paradigm
can result in code that is hard to change to meet
the new/changed needs at equally high quality -- the
dimensionality of the space of requirements is so
high, that, unless you do anticipate the principal
axes of requirement-changes roughly correctly, you
do have work ahead of you.  The best a paradigm and/or
methodology can do for you is let you have a few more
dimensions -- a few more axes of possible change --
among those you can meet more easily.  _A few_ are
the operative words here.

You still need design ability, flair, and a decent
amount of domain-specific experience somewhere in
the team, to enjoy a substantial chance of delivering
LARGE software-systems that present all the desired
quality attributes, including of course the ability
to change to meet the changing challenges of the
application domain.  Increasing that chance is all
one can ask of any language/paradigm/methodology --
there STILL is no silver bullet.


> > This seems to show what blind alleys classical approaches can
> > lead one to -- ```Reorganization can be risky. Many managers do
> > not want programs altered except to add or fix features. If an
> > significant error occurs due to reorganization, then heads roll.
> > I have been told many times, "If it ain't broke, please don't
> > fix it."''' being the key quote from that paper.
>
> Well, they are the boss. Sell rework to them, not me.

Fortunately, given the current market for IT professionals (and
this comment applies to the last 25 years), no competent worker
in the field ever needs to be stuck for long under management
that is totally impervious to common sense and reason -- even
assuming that firm is not about to go bankrupt (which seems a
possibility, if they can't listen to reason:-), there are sure
to be dozens of lucrative and professionally interesting job
offers on one's desk.  "Think of it as evolution in action".


> > (But the ills are many indeed; the
> > "lava flow" anti-pattern, for example, is likely to be quite
> > pervasive in a development shops to which this article could
> > apply).
>
> What is this "lava flow" thing? I keep hearing it mentioned.
> More OO lore that nobody can keep up with. Scriptures
> build fast when the agnostics are silenced.

Brown, Malveau, McCormick and Mowbray, "AntiPatterns",
Wiley Computer Publishing, 1998, ISBN 0-471-19713-0.  As
it's been out three years, it's hard to accept your
classifying it as a recent work.  Note also that, while
published as part of the "Object Technology" series by
Wiley (which probably makes you allergic to it ipso facto:-),
most of it is perfectly applicable to software developed
under other paradigms (indeed, quite a few antipatterns
exhibit typical problems of _legacy_ software, which a
consultant is called in to solve).


> I have shown in great detail why procedural seems better able
> to deal with non-boundaried differences, and I have yet to

You have done no such thing (at least in your posts in
this thread, and the URL you mentioned here).

> see counter-arguments other than "you get used to code
> rework if you just give it a fancy name."
> I won't sell out to wasteful effort.

Effort that is wasteful, by definition, is well eschewed.
But changing code *and design* so that changing requirements
are well-reflected and optimally met, again by definition
of 'well' and 'optimally', is no waste:-).


> But the easy-to-componentize stuff is already for sale. Why

Some of it -- that which (in the conception of the backers,
venture capitalists, entrepreneurs, etc) enjoys a large
enough and profitable enough potential market.  Nowhere
like _all_ (nor even a majority) of the actual markets
have been tapped, much less saturated.

> would they bring in programmers if plug-and-play solutions
> were already available? (Report writers, sorters, DB's,
> GUI IDE's, communications, etc.)

There are no doubt databases for sale, but I doubt
that's what you're referring to, because it's not
software that's being sold, then, but data -- you
probably mean, database _management systems_ (DBMS's).

If some solution IS for sale in a given area, and
some capitalists and entrepreneurs are still desirous
to develop and sell programs in that area, they must
think that a better mousetrap can be developed to meet
those needs -- and they may well be right (my current
employer, for example, is busy experimentally testing
this thesis regarding 3D mechanical engineering design,
and ancillary applications such as product-data
management [PDM]).

It's not particularly different from the business
decision of opening a new restaurant in a town that
already has quite a few -- you'll win (make money)
if the market is not in fact saturated, and/or your
new restaurant can offer diners something they value
enough to pay you enough money for it.

It does not imply that your new restaurant cannot
possibly make profitable use of some existing recipes,
you know -- coming up with new recipes is just one
possible competitive differentiator, and there is a
lot of potential space in terms of execution and
delivery even if your fundamental recipes happen to
be very close to the competition's.


> What is left is stuff that has a jillion interconnections
> to other things such that putting a clean box around it
> is not practical. Components usually work for things where
> the algorithm is complex but the interfaces are small.
> In biz stuff the interfaces/links to many entities is the
> largest part.

...and interconnection-and-gluing components work wonderfully
well for _that_ kind of issues (scripting language interpreters
being a good example:-).

> Besides, you can characterize my development philosophy
> as "task componentization". AKA, a procedural module.

A philosophy is a wonderful thing to have -- it can no
doubt console you splendidly when you're rotting in jail,
for example (cfr. Boethius' "De consolatione philosophiae").
Or, in your case, apparently provide a high-faluting way
to justify your unshakable desire to keep working as you
always have (and, I guess, your grand-dad before you...?).
But, given the marketplace success that's likely to greet
your efforts, I'm sure the "consolation" part will come
in very handy for you, too, pretty soon:-).


> > Adopting the 'software that happens to appear to work when
> > not thoroughly tested is sacred and must not be touched' idea
> > is parallel to keeping a kid always on his/her side of the
> > street (except perhaps for emergencies such as schools and
> > doctors:-).  Not exactly conducive to optimal development
> > (be it of social skill and a healthy life, OR good software).
>
> I am not against re-arrangement. What I am complaining about
> is paradigms that *increase* the amount of re-arrangement that
> is required. OO appears to do such, partly because of the
> boundary/granularity issues.

Maybe "appears" is the operative word -- it LOOKS (to you) AS IF
object-oriented analysis/design/coding increases your 'rework'
efforts -- maybe because you lack the experience to do it well.

> The whole refactoring thing is side-effect of OO. The paradigm

No way -- just the _term_, I believe, tends to be used
originally in OO circles; and the reusable _patterns_ of
refactoring (just as those of other aspects of our jobs)
have mostly been identified and described inside an OO
worldview (OO admittedly does make it easier to handle
and describe design & other patterns -- a neat plus for it:-).

But -- without calling it that way, without the productivity
that reusable patterns or good tools can give me -- I _was_
doing refactoring 25 years ago (as were many other before
then); I've always loved the design and code I was turning
out, and strived for them to be clean, clear, high-quality,
and well attuned to the actual needs.  That's what you need
to refactor for.

> is starting to barf, and now the same people who sold you
> the barfers are now also selling barf bags.

Funny enough, I mostly use free tools -- books are, by far,
what I invest most money (and time) in, and they cover a
very wide range (I'm just as likely to pick up a new book
on functional programming, or more, than a new one on OO,
no matter that I don't currently use FP in my everyday
job but I do use OO -- exactly because I know less about
it, I desire books more, for example).


Alex