Re: Relational-to-OOP Tax (was: Critique of Robert C. Martin's...)

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
Let me reword it: Nobody can/will prove it objectively worse.

That's not a rewording, that's an attempt to squirm out of your
burden of proof.

It would be like asking somebody to prove that Santa does not
exist. It is not possible (unless simultaneous video-cams are
put on every spot).

If you can't prove it, retract it and stop making such claims.

I am not implying that something is better.

Yes, you are. You clearly stated in the post that started this
subthread that "If you embraced the DB instead of spend all your code
wrapping it, the app would be noticably simpler." That is a clear,
positive claim that you have been trying desperately to squirm out of
supporting.

You are the one infesting a forum for the discussion of object
technology with your unsupported claims that object orientation is
flawed.

No, my stance is that people keep implying it is objectively better,
that heavily wrapping the database is always "good", that
polymorphism over IF statements is always "good", that procedural is
"messy", etc.

I haven't seen anyone with a demonstrated understanding of OO
techniques claim that those techniques are always optimal in all
contexts. That seems to be a characteristic exclusive to the
relational one trick ponies. What I do see is you arguing against
strawmen of your own creation, and still losing.

The burden of proof is on you to prove your claims. The only
participants in this newsgroup who are claiming that one paradigm
suffices for all domains are the relational one trick ponies.

I never claimed that relational was objectively better, only that it
is not objectively worse.

First, that's a positive claim for which you have the burden of
proof. Second, the only people I see portraying this as some kind of
mutually exclusive decision are you and one or two others who think
that only relational techniques are needed in any domain. The people
discussing OO in this newsgroup, like the ones I generally work with,
see all of these techniques as useful additions to their virtual
toolboxes.

Your claims boil down to the idea that having fewer options is
more likely to result in quality software than having more. That's
preposterous on its face. Even if you don't use the additional
techniques, knowing them will enable you to view a problem from more
perspectives and come up with a better solution.

However, it logically follows that if you are using a relational
database, then designing the application close to it rather than
trying to wrap it away in OO classes and conventions will simplify
the design because one is not translating from one paradigm to
another.

If you're thinking of a CRUD system, then you're correct. For
any system with more complex behavior, you're going to need to provide
some support for that assertion. (I'm not holding my breath.)

Do you think translating between paradigms is cost-free? I expect an
answer.

I expect honest, rational people to support their claims or
retract them.

I don't find your question coherent as stated. I frequently use
languages like Common Lisp and C++ that are considered multiparadigm.
Multiparadigm languages offer a great deal more flexibility than more
constrained languages like Java. Solutions that are infeasible in a
less flexible language become the most elegant alternative when the
appropriate constructs are available.

The closest I can come to an answer to your question is the
observation that a having variety of options is better than lacking
options.

It's posts like this that swing me from the opinion that
you're simply deluded and inexperienced to the view that you are
deliberately trolling with malice aforethought. You consistently
make sweeping claims with absolutely no support and, when pressed,
retreat to "It's just my opinion, you shouldn't treat it like a
real claim."

Well, that is not me. You are characterizing somebody else.

Check out these posts and the surrounding threads, found with
minimal Googling:

http://groups.google.com/group/comp.object/msg/beb22154219db17a?dmode=source
In which you dismiss a claim on your part as an "off-the-cuff
remark" after much squirming.

http://groups.google.com/group/comp.object/msg/f6a781114b37962b?dmode=source
In which you fail to support your claims again, and after several
interactions say "I forgot 'in my opinion'."

This is definitely a consistent behavior of yours.

You squirm and twist to avoid the burden of proof that clearly
accrues to your baseless assertions. You demand code, but refuse
(or are unable) to provide your "superior" version for review.

MY baseless assumptions? The topic is Martin's baseless assumptions.

No, this subthread started when you made the baseless and still
unsupported assertion that "If you embraced the DB instead of spend
all your code wrapping it, the app would be noticably simpler."

Prove it. Let's see your code.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.

Relevant Pages

  • Re: Nice little swarm were having in Yellowstone today, eh?
    ... Better analysis and planning needs your support. ... techniques could potentially help define the system much better. ... conduct a limited bathymetric survey to detect uplift on the Lake bottom. ... In short, don't give up just yet as your efforts may be able to force USGS, ...
    (sci.geo.earthquakes)
  • Re: Bruggens Paris Beethoven, 2006
    ... Please disprove my claim that he uses anachronistic instruments and ... techniques for his "authentic" performances. ... Why don't you support your assertion first? ...
    (rec.music.classical.recordings)
  • Re: Bruggens Paris Beethoven, 2006
    ... Please disprove my claim that he uses anachronistic instruments and ... techniques for his "authentic" performances. ... Why don't you support your assertion first? ... Then we have methods, instruments, ...
    (rec.music.classical.recordings)
  • Re: Paxman Valenta Powered H.S.T./InterCity 125 Class 43 Power Cars
    ... was to do with manufacturers support. ... IMHO fitters likes or dislikes should never impact on availability or ... or training or techniques or skills or time to do work all need to be ... planned into any job - but likes or dislikes no. ...
    (uk.railway)