Collection interfaces

[Steve Wart]

I notice comp.lang.java has been missing from your incessant tirades.

How about this: OO has widespread market acceptance.

You want metrics? Look here: http://www.monster.com.

Understanding OO is a good career move; science is irrelevant. I doubt that
anyone can "prove" anything about this industry that doesn't have a dollar
sign associated with it. Most OO people I know do it because they can make a
good living at it and they find it intellectually satisfying.

Please take your discussion to comp.table.programming (I hear it's the next
big thing).

Maybe if you identify yourself you'll be taken more seriously. Better yet,
go soak your head.

I apologize to all affected for responding to an anonymous troll.

Ugh.

Steve

"Topmind" <topmind at technologist.com> wrote in message
news:MPG.15085517debf4b649896ca at news.earthlink.net...
>
> >
> >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-
>