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


Patrick May wrote:
"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.

I supported it in the message you are replying to.


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.

Most such books don't give such conditions. I will agree that it is
not stated in a definitive legalistic form, but it is *strongly
implied*.

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.

[snip]

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.

No, it is not. Every paradigm has things it probably does slightly
better. Following your logic, paradigm potpurri would make for better
software. I disagree. For one it would require programmers
knowledgable in myraids of paradigms, which is impractical.
Functional, logical, relational, OOP, AI, etc. That would be a
staffing headache.

Further, that is your opinion, not nec Martin's.


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.

Perhaps, but irrelavent. We are talking about the end product. If
blowing your nose hard makes you think better, go for it.


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

Show me typical complex behavior in a biz app that relational chokes
on. (Yes, there are exceptions, but I am asking for "typical", not
blue moons.)


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.

Why won't you answer the question? Is translation free, yes or no?


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.

Perhaps, but that is not realistic for staffing purposes, per above.
Most programmers don't have time to master 5 or so paradigms. After 42
or so one is expected to go into management or the like. The shelf-
life of a typical programming career is not long enough to make it
realistic. And it is not part of Martin's book.


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.

Not necessarily, per above. In my opinion it is best to pick a few
complimentary tools and master them than a mishmash potpurri of tools
with similar uses. There are a few people who can and do master most
paradigms, but that is the exception.

[snipped links to past he-said-she-said fights. Nobody cares about our
old squabbles and it proved fruitless the last time we did it because
you think weird and interpret my writing in an odd way that takes too
long to correct, wasting time on nothing.]

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.

In progress. If you want it faster, then you will have to pay me.


Sincerely,

Patrick

------------------------------------------------------------------------

-T-

.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... Ignoring and refusing to learn new techniques ... It is up to you to support it or retract it. ... Multiparadigm languages offer a great deal more ... You seem to be hung up on the word "paradigm". ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... Ignoring and refusing to learn new techniques ... It is up to you to support it or retract it. ... Multiparadigm languages offer a great deal more ... You seem to be hung up on the word "paradigm". ...
    (comp.object)
  • Re: Meyer(s) gets it wrong
    ... > One can also think of OOP as, among things, a paradigm with support ... *program* *design* method, named OOP, to such a high level. ... stuctured languages seem to fit the analogy better than OOPLs ...
    (comp.programming)
  • Re: Why is OO Popular?
    ... >> Children understand certain things behave in certain ways. ... >> using object oriented languages. ... becoming more and more distributed and the object paradigm has very good ... 'complex systems', where you have to almost embrace complexity to an extent. ...
    (comp.object)
  • Re: Alexandre Bergel <bergel@iam.unibe.ch>
    ... A very few of new languages are module-based. ... I suspect this is because OO provides for modularization at several ... responsibilities) and operations. ... > and not to replace the object paradigm. ...
    (comp.object)