Collection interfaces

[Topmind]

>
>I've often noticed that demanding metrics is the last
>line of defense of the conservatives in our field against
>innovation 

So science be damned? At least it is official now.

I am *not* against innovation. I am against the overhyping
of fads without proof.

Relational DB's are newer than OO, does that mean that
OO defenders are "holdouts"?

If OO is an "experiment", then fans of it should admit
it as such. The road is littered with paradigms and
ideas that were over-hyped, and then shrank back 
to where they belong. Heavy top-down is an example
that ran about a decade in the limelight. Expert
systems, CASE, etc, are others.

I hope Table Oriented Programming hits hard and does
the same. All the OO celebs will squirm. Call me
cruel, but they deserve it. It deserves as much
of a chance for experimentation in the mainstream
as anything out there now.


> -- 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.

No, just learning by trial and error. 50 years from
now we will have a better perspective on this OO
experiment.


> Been there, done that, more or less whatever you mean by
> "table-oriented programming"

It may be purely subjective. I had an affinity for grids
and tables even in 2nd grade. Born to Table if you will.


> ...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.

My favorite approaches are *not* orthogonal to refactoring,
but simply *less* fragile or messed up if you refactor
regularly.


> 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

Well, my experience tells me that the "task axis"
is the most "business friendly" axis to build
along (being that multi-axis paradigms still need
a lot of work and thus we are forced to emphasize
one at the expense of others for now.)


>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

The SIZE thing again?

1. What is good for large size may not be optimal for
other sizes.

2. OO fans disagree about at what size OO shines in.

3. The task-centric approach is size friendly because
the task is mostly impervious to the rest of the
system (unless the task changes it's requirements, which
is an issue in any paradigm).

OO's noun-centricity seems more scale-poor in that
regard because schemas change when growth appears.
The 3-graph approach puts a layer between schema
changes and the task more or less.


> 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

For one, I don't buy the labor shortage crap. For example, try
to get a telecommuting job. If there was an IT labor shortage, then
bosses would fold on their demand to see a physical butt in a
physical chair.

Second, the percentage of PHB's is too great to avoid. 
The supply of non-PHB's is too low to satisfy the
desire of tech workers to escape them.


>> 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).

I don't know what you have not seen yet, but my collection
of examples is far greater than what the other side
offers as far as comparative examples. All I get from
them are the typical shape, animal, and stack examples
(and a few other "classics").

Regarding an internal* component view, I will believe it when I
actually see it work. Like much in OO lore, it sounds
wonderful on paper, but rubs rough with the nitty
gritty of reality. I guess that is what happens when
you design an entire paradigm around idealized shape,
animal, and stack examples.

* External components are quite successful, but nobody
has figured out how to apply it to internal systems
very well. BTW, OO is not a prerequisite for external
components.


> maybe because you lack the experience to do it well.

Well, youses all seem to lack the articulation skills/experience
to describe why granularity is not a problem. You still
have not found an easy way to override 1/3 of a method.
You just hand-wave that "experience will magically fix
it all". I seems like you just "get used to" refactoring
when it happens. IOW, tolerate bad weather because you
lived their for so long.

> But -- without calling it that way, without the productivity
> that reusable patterns or good tools can give me

Patterns are not native to OO and "good tools" can be built
to lessen the shortcomings of *any* paradigm. Name a p/r
fault and I could describe a potential tool to help.

-tmind-