Re: Relational-to-OOP Tax

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
It sounds like you need to learn some patterns for decoupling
your presentation and business rules. Look up MVC and some more
recent enhancements. Careful, though, that might be getting
dangerously close to the "OO Paradigm" for your taste.

MVC sucks IMO.

What a surprise.

Decoupling only makes sense if you are likely to switch GUI systems,
which is too rare to bother paying a constant complexity tax for.

Decoupling helps to address non-functional requirements such as
maintainability, extensibility, scalability, and resiliency. Tightly
coupled big balls of mud are an indicator of poor quality software.

Prove your claim regarding simplification or retract it.

Freeb already gave one.

I've seen no such thing. It's very easy for you to claim it,
but without a reference to a specific section in a specific post,
it's no more supported than any of your other claims.

Well, I am not in a mood to go hunt it down for you.

Another failure to support even your most trivial of claims. I'm
shocked.

Wrapping is objectively more code for single- use SQL than
in-line. And similarly, an IF or case statement connected to a
database attribute is objectively less code than a single-use
polymorphic dispatch on the same attribute.

You agreed earlier in this thread that lines of code is not
the only measure of simplicity.

It is one of many variables. Nobody has a consensus measure of
simplicity. I would present my design, and one could see how that
at least it is less lines of code. If readers want to claim it is
more complex for whatever reason, fine. To my mind it is simpler
and barring good objective metrics being found, *psychology* is what
matters.

It sounds like you're simply going to provide a highly coupled,
big ball of mud and claim that fewer lines of code means it is
simpler, ignoring your previous admission that lines of code is not a
good metric and ignoring any of the benefits of the implementation you
are comparing it to. Basically, I expect you'll address only a small
portion of the functional and non-functional requirements addressed by
Mr. Martin's example, but nonetheless claim victory in your own mind.
Gee, I can hardly wait.

In order to support your claim, you need to demonstrate a solution
that "embrace[s] the DB" and is simpler by some well-defined metric
while still providing the same functionality and benefits of the
implementation you are critiquing.

I don't remember claiming I could objectively do so, beyond code
size.

You expressly agreed that code size is not a good measure of
simplicity.

Having fewer tools cannot result in higher quality software
than having more tools and *knowing how to use them*.

It does when you are consider staffing and learning curves.

No, it cannot. If people don't know how to use the tools, they
won't. Those who can, will use them and will train others.

It's not at all hard to say. Better developers manage to work
with multiple paradigms simultaneously, choosing the techniques
best for the problem at hand.

Not necessarily. You create code that can only be understood by
those schooled in multiple paradigms. This means that as long as the
code exists, multi-paradigmers have to be hired. This will delay
hiring (more time to find) and make them more expensive. Unless the
benefits of doing such are significant, they will not outweigh the
staffing drawbacks.

It's not that hard to find developers experienced with, or at
least willing to learn, many different techniques. In fact, I would
argue that such is part of the definition of "good developer".

You seem to be viewing this from a programmer's perspective, not a
business owner's.

On the contrary, I'm looking at it from the perspective of
providing high quality software with measurable business value. That
requires good developers.

Further, a certain percentage of such people use multiple paradigms
as a form of Mental Masturbation. They mix techniques simply because
they are bored or perhaps as a form of job-security lock-in, not
because it results in more maintanable code.

By definition, these are not good developers. They're just as
foolish as those who limit themselves to a single set of techniques.

Anyone who can't learn how to use at least one each of a
procedural, object oriented, declarative, and functional language
with a reasonable level of competence isn't anyone I'd hire.

Your opinion is not the majority opinion on this.

How fortunate for you.

You're still hung up on the idea of "paradigms". Let it go.
It's obscuring your view of the more cohesive, integrated reality
beyond your self-limiting categories.

We don't have a better word for mix of approaches at this point.
'"Paradigm" is the best compromise word and everybody knows what it
means even if not perfect.

My point is that it obfuscates rather than illuminates. Think in
terms of techniques and idioms, not arbitrary categories.

If you find that task of learning new techniques and
approaches particularly onerous, perhaps you aren't in the right
industry for your talents. Have you considered a career in food
service?

You come across as such an arrogant prick, you know that?

Sticks and stones, Bryce baby, sticks and stones.

My question is not entirely facetious. If someone came into an
interview and whined "I only use relational techniques, that OO and
functional stuff doesn't 'fit my brain.' I'm not interested in
learning anything new, it'll just confuse me and make it harder for me
to solve problems. And by the way, I like to make up my own words
like 'betterment.'", I'd show him the door immediately.

I can see why you try so hard to hide behind a pseudonym, and it
has nothing to do with backlash against critics of OO. You constantly
argue in favor of willful ignorance, intellectual laziness, and
stupidity. Your lack of passion for learning shows that you do not
have the hacker nature.

C'mon, give it a chance. Stand in front of a mirror right now
and say "You want fries with that?" Feels natural to you, doesn't it?

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: Man gets nine years for spamming
    ... The point is, for me, blocking countries is ... especially where there are other techniques ... My company for example does a lot of business in China, ... Not even taking into account that most of the SPAM will spoof email ...
    (alt.computer.security)
  • SENIOR APPLICATION DEVELOPER
    ... challenging system development projects through cross-functional ... Business analysis skills - Must have experience with projects and ... Given that a candidate must manifest perseverance in solving problems ... better programming techniques to be applied to new and existing ...
    (comp.lang.basic.visual.misc)
  • Re: Mixing P/R philosophy with OO (within J2EE).
    ... experience with OO to understand that competent developers are most ... OO, procedural, relational, functional, and other techniques are ... who have actually delivered working enterprise-scale systems. ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... MVC sucks IMO. ... Indirection and wrapping create what I call "red tape" code. ... It's not that hard to find developers experienced with, ... least willing to learn, many different techniques. ...
    (comp.object)
  • Re: FileNet Integration Specialist
    ... Enterprise Content Management, Portal technology and Business Process ... project for new products or technologies. ... analysis techniques and tools; IT technical environment (ECM,Portal, ...
    (comp.doc.management)