Re: SQL

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
> > The ability to model behavior as well as data makes general
> > purpose languages better able to model the problem domain than is
> > SQL.
>
> If you design right, you can *shift* much behavior to being data and
> DB operations instead.

Depending on the requirements, some functionality can be
implemented using set operations, certainly. "Much" is pushing it,
especially when one limits oneself to non-gratuitous use of those
operations.

> SQL is close to being Turing Complete.

In other words, SQL is not Turing complete. That addresses your
original question:

> > > But how are tables less close to the domain than classes,
> > > methods, and attributes?

We're done with that one.

> Plus, OO is usually crappy at modeling behavior, at least in the biz
> domain. OO is only nice when things split up into nice hierarchical
> taxonomies. Most things don't in reality, so what is left is a mess.

You've been challenged on this assertion in the past and failed
to defend it. The history is available via Google for anyone to see.
Unless you've got more to back up your nonsense than you did before,
repeating this is intellectually dishonest.

> > > > Proliferation of get/set methods is a code smell.
> > > > Immutable objects are to be preferred.
> > >
> > > This is not the censuses in the OO community.
> >
> > Yes, it is. Josh Bloch recommends immutability explicity in
> > "Effective Java" and gives solid reasons for his position.
> > Proliferation of getters and setters violates encapsulation, one
> > of the defining characteristics of object technology. Some
> > research will show you that OO designs focus on behavior, not
> > state. You should also check out the Law of Demeter and similar
> > guidelines that provide further evidence that excessive use of
> > accessors and mutators is not good OO form.
>
> Almost all of these have a fair amount of disagreement among OO
> proponents. Check out c2.com.

Interesting. I provide explicit examples of what are generally
accepted as good OO principles and practices and you refer to a random
website. If you have real documentation of getter/setter
proliferation being an accepted OO technique, produce it.

> > > I would note that a lot of the issues you mentioned, such as
> > > performance, scalability, resiliency, and recoverability can be
> > > obtained by purchasing a "big-iron" RDBMS such as Oracle or
> > > DB2. The configuration and management of those issues is then
> > > almost a commodity skill and not as tied to the domain as a
> > > roll-your-own solution would be (which OO'ers tend to do).
> >
> > It is statements like this that strongly suggest that you
> > have never developed a large, complex system.
>
> No, because I break them up into peices so that they don't grow to
> be one big fat EXE. The Big-EXE methodology has a high failure rate.

Modularity is not exclusive to imperative programming. It is
also not the silver bullet that slays the complexity lycanthrope.

> > The vast majority of businesses that need systems of this
> > complexity have legacy software consisting of a number of COTS
> > applications and custom components, none of which were designed to
> > work with each other. These have been selected or developed for
> > good business reasons and cannot be aggregated and run on a single
> > piece of kit, no matter how large.
>
> Agreed, but what does the existence of legacy apps have to do with
> your scaling claim?

The existence of legacy systems is just one reason why your
suggestion of using '"big-iron" RDBMS such as Oracle or DB2' cannot
solve the complex problems of large organizations.

> I did not mean to suggest that everything should be centralized.

That is what you suggested above.

> It depends on the kind of business. If the vast majority of
> operations/tasks needed are per location, then regional partitioning
> works well. If not, then a more centralized approach is needed. For
> example, airline reservation and scheduling systems would make a
> poor candidate to partition by location because of the
> interconnectedness of flights. However, individual stores in a big
> franchise can operate most independently.

Your lack of experience with large, complex systems is showing,
again. Basically you're suggesting one or more monolithic processing
hubs -- the simple CRUD/USER stuff you're used to writ large. Are
those the only kinds of problems you're used to?

> > > "Security" is mostly just massive ACL tables.
> >
> > That is profoundly . . . naive. I strongly urge you to read
> > everything you can find by Bruce Schneir, join the cryptography
> > mailing list run by Perry Metzger, and not say another word about
> > security until you understand why your statement is so deeply
> > embarrassing to you. For a quick, very small taste of why ACL
> > tables don't even begin to scratch the surface of the problem,
> > read http://www.isi.edu/gost/brian/security/kerberos.html.
>
> I see no mention of ACL's there.

That's my point.

> If you have a specific case of ACL's crashing and burning, post it
> here and let's take a look at it. (Note that there are a lot of
> variations of ACL's, so a flaw in one kind is not necessarily a
> general flaw in ACP concepts.)

I never claimed that ACL's crash and burn. I said that ACLs
barely scratch the surface of the security requirements of a large
distributed system. Clearly you don't have any experience with such.

> Again, use evidence instead of patronizing insults. It is a bad
> habit of yours.

I can see how my habits of calling bull*** when I smell it and
not suffering fools gladly would be considered "bad" by someone with
your proclivities. That doesn't change the fact that your claim that
"massive ACL tables" address the security requirements of large
distributed systems is ridiculous on its face. Patronization is the
best you can expect when you spew nonsense like that.

> > CRUD applications are, however, not particularly complex as
> > software systems go. Your claims otherwise indicate a lack of
> > experience with anything else.
>
> Again, please use evidence to prove me wrong instead of patronizing
> insults. It is a bad habit of yours.

How is that patronizing? It's a simple statement of fact. There
is a reason why the CRUD work is typically given to new hires and
junior developers.

> Propose a way to measure "complexity", and then apply it to CRUD
> apps. That is how you make a point. Anecdotes and private personal
> opinions mean very little here. They are a dime a dozen.

If you're seriously suggesting that CRUD applications are equal
in complexity to compilers, telco OSS/BSS, MRP/ERP, or risk analytics,
just to pull a few examples off the top of my head, then that reflects
more on your experience than on the veracity of your claim.

> > On the other hand, there are some delightfully complex
> > software systems that consist of only a few hundred lines of code.
> > Functional languages seem especially good for this. See one of
> > Peter Norvig's books for a few examples.
>
> Most FP demonstrations of such are "toy" or "lab" examples.

Dismissing out of hand systems of which you know nothing. That's
a bad habit of yours.

I'd be tempted to ascribe your apparent need to continue
discussions ad nauseam to some form of obsessive-compulsive disorder,
but I don't have a background in psychology so I won't. You should
try that not-talking-about-things-you-know-nothing-about approach
sometime.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, CORBA, UML)
.