Re: Relational-to-OOP Tax

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
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.

No, you didn't. If you think you did, provide the exact quote.

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.

It is completely relevant when the purpose is to create the best
possible end product. Ignoring and refusing to learn new techniques
is not the path to quality.

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.

Once again you've got it backward. You are the one making the
claim above. It is up to you to support it or retract it.

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.

I'm not sure what you're referring to "per above", but I haven't
had a huge amount of difficulty hiring developers experienced in a
range of techniques.

Most programmers don't have time to master 5 or so paradigms.

You seem to be hung up on the word "paradigm". Object oriented,
procedural, functional, relational, and other "paradigms" are just
names given to sets of techniques and idioms. The boundaries of the
sets are not clearly defined and there is extensive overlap. Let go
of the words and focus on becoming a better developer by learning new
techniques, regardless of what arbitrary set they happen to be part of
today.

If the best solution to a customer's problem requires that I
encapsulate SQL in a function that I invoke within a closure passed to
a polymorphic (multi)method of a class for later evaluation by a rules
engine, that's what I'll do. Thus far the Pure Paradigm Furies have
failed to strike me down.

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.

You are arguing that ignorance is superior to knowledge.

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.

Not in my experience. Good developers, such as the ones I try to
work with frequently, have no difficulty using combinations of
techniques and idioms. Interestingly, none of them find the concept
of a "paradigm" particularly useful. Let it go.

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

In other words, I proved that point so thoroughly that even you
can't see how to squirm around it.

Transcend paradigms,

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: Relational-to-OOP Tax (was: Critique of Robert C. Martins...)
    ... Every paradigm has things it probably does slightly ... some support for that assertion. ... languages like Common Lisp and C++ that are considered multiparadigm. ... MY baseless assumptions? ...
    (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)