From: Mikito Harakiri on
Patrick May wrote:
> The most common language for manipulating tables is SQL and
> it is not as powerful as general purpose OO languages.

There are two incorrect assertions here:
1. What power do you have in mind, computational power? Then you made
it sound like it is OO that added more power, while in fact procedural
programming without object extensions is as powerful as procedural
programming with them.
2. Is SQL really less powerful? What computational feature is exactly

From: topmind on

Christian Brunschen wrote:
> In article <1137996532.423030.167400(a)>,
> topmind <topmind(a)> wrote:
> >(Part 1 of reply)
> >

> >Back in my desktop-DB days, I created a lot of temporary tables to do
> >things such as joins, filtering, and aggregation for task-specific
> >temporary uses. The results were not kept beyond the task/module. Thus,
> >I was using DB tools *without* any sense of "lasting".
> >
> >What would *you* call that? "Persistence" does not apply there.
> You are still using a persistence mechanis; you're just choosing to not
> use it for persistence.

Again, persistence is one of MANY features of a DB.

> A file system is a persistence mechanism; lots of
> applications put data into temporary files, which they delete after
> they're done with them, sometimes because the available storage in the
> filesystem is larger than in main memory (Photoshop, I believe, used to do
> that, and maybe still does). This non-persistent use of the filesystem
> doesn't make a filesystem any less of a persistence mechanism.

They usually do that because the RAM system is limited, not because
they want any special features of the the disk system.

> The relational model, and SQL, were developed specifically for persistent
> databases.

Because RAM was too expensive to consider non-persistence DB's back
then. The history is generally irrelavent. I don't care what they did
in 1965; It does not change what I do now. LISP was originally a
demonstration tool only. The author never set out to create a new
production language. But LISP fans are not going to be halted by
ancient intentions.

> You can use them in a non-persistent manner, but that is
> essentially using them contrary to their original intent and purpose.

DB's have a lot of features *besides* persistence, and I use DBs for
those features. Label DB's whatever you want, but I find those other
features useful. You guys are playing a label game. Focus on potential
usage, not your pet classification or what happened 50 years ago.

> By the way, how do you create and destroy these temporary tables? i.e.,
> does the dbms manage their lifecycle for you, creating them as necessary
> and removing them when you no longer need them, or do you have to perform
> either or both of those steps yourself?

Some table-oriented tools auto-delete them, some are RAM-only, while
others require manual intervention. (The ideal system would offer all
of these options.)

> >I agree that code does some things better and DB other things, and one
> >uses them *together* in a Yin-Yang fashion. They compliment each other.
> Relational Databases and SQL are tools for the specific task of storing,
> accessing, modifying data - they are single-purpose tools (see definitions
> below). They are 'general-purpose' _within their specific area_, as they
> are not specific to any particular data access/storage/manipulation tasks,
> but they are 'general-purpose' _only_ within their _specific_ domain,
> which is the storage of data.


> A 'general-purpose' programming language is
> one that allows one to write solutions to essentially arbitrary problems
> using it, possibly with some specific exceptions (such as, 'python is a
> general-purpose programming language, but due to its interpreted nature,
> it shouldn't be used for writing interrupt handlers').

You mean "Turing Complete". We have been over this already. I don't
expect a query language to be TC to be considered "general purpose"
because one can and perhaps should use multiple tools such that one
should not EXPECT to have one tool/language do everything. Your "do
everything" assumption is a poor assumption.

> One thing to remember is that a RDBMS does _not_ do _anything_ that one
> can't do in code on one's own - they are essentially just a pre-written
> library, with a little domain-specific language as part of its interface -
> whereas on the other hand, _most_ of the things you can fo in _code_,
> _cannot_ be done in an RDBMS.

Irrelavent. I don't assume a single tool has to carry the entire load
of an app.

> >> > A hammer is a general purpose tool, but that does not mean one is
> >> > supposed to ONLY use a hammer. You need to clarify your working
> >> > definition of "general purpose", and then show it the consensus
> >> > definition for 4GL.
> >>
> >> huh**2?!? A hammer is not a general purpose tool by any stretch of the
> >> imagination.
> >
> >Okay, then what is a "general purpose tool"? If I was going to put
> >together a tool box for a trip where the mission details are not given
> >ahead of time, I would certainly pack a hammer.
> Yes, but you wouldn't expect to be using the hammer _unless_ you
> encountered a problem that _specifically_ included nails.

Not true. They are good for pounding things into place, pounding them
out of being stuck, prying things off (with the back end), etc.

> If you
> encountered problems that included only screws, you'd never touch it;
> you'd be using your screwdriver set instead.

By that definition nothing can be "general purpose" because you are
incorrecting looking for an all-in-one tool. (A Swiss Army Knife is
actually a collection of many tools, not one tool.)

> >Only an idiot would
> >not. No, it is not a one-size-fits-all tool, and I don't expect one.
> >Good apps don't need a one-size-fits-all language because they can use
> >yin-yang complimentary tools.
> *sigh* Time for some rudimentary definitions:
> single-purpose
> useful for a single purpose, for a specific task, only
> multi-purpose
> useful for a number of specific tasks, but only a limited number still
> general-purpose
> useful for most tasks in general, though possibly with some specific
> exceptions

Okay, but even your own def does NOT require it to carry the entire
load, but simply be *used* for most things.

> all-purpose
> useful for absolutely everything
> A hammer is _not_ a 'general-purpose tool', because it isn't intended
> or useful for general tasks, but specifically for beating nails into
> stuff.

I consider the equivalent of an app to be a "project", not a task. For
an entire project, such as building a car or a house, most likely you
will need a hammer at least once (even if you don't use nails).

> If it also has a back end that lets you pry nails out, it might be
> considered a 'multi-purpose' tool, but even that would be a stretch,
> because you're still only working on the 'nails' bit. Either way, it's not
> a 'general-purpose' tool by any stretch of the mind.

Is there such a thing WRT physical tools by your def?

> Actually, there's a saying that's apt, and which I think that 'topmind'
> very clearly exemplifies:
> "If all you have is a hammer, everything looks like a nail"

Like maybe.......Java?

> The point of which, of course, is precisely that a hammer is _not_ a
> general-purpose tool, but that if you are accustomed to working only with
> a specific limited toolset (and thus the associated set of problems it is
> intended to solve), there is a tendency to try to see all other problems
> as if theyy, too, were problems of that specific type. However, that is a
> fallacy, as there are problems which clearly don't fit into such a narrow
> mold.

That can apply to anybody. If you are truly experienced such that you
tried them all, then you could point to multiple areas where RDB'S

> Even topmind's own comments above show that he is fundamentally aware of
> this: he says that a hammer is _one of_ the tools he would pack, so he
> recognizes that there are many more tasks that he might encounter, but for
> which a hammer is not a useful tool. But he confuses 'general-purpose'
> with 'one-size-fits-all': Those are _not_ the same.

No, it appears to be you who is making that part of the definition.

> Of course, when it comes to computers, 'general-purpose' can frequently
> come very _close_ to being 'all-purpose' simply because there are very few
> problems that fall outside the 'general-purpose' area.
> Java is a 'general-purpose' language, because you can write all sorts of
> programms in it - from math-intensive scientific number-crunching, to data
> storage and access, to graphical user interfaces, to distributed systems,
> to ... etc. SQL _isn't_, because there are _vast_ areas of problems that
> SQL not just osn't intended to address, but simply _cannot_ address,
> however much you try to make it.

Addressed above.

> The need for 'yin-yang-complementary' tools arises in cases where it it
> difficult to create multi-purpose or general-purpose tools: construction,
> woodworking, metalworking etc, are all places where it is difficult to
> create such tools.

Are you saying that in Java you don't need DB's because you can write
your own concurrency management, join systems, aggregation systems,
etc? Perhaps, but that just means that you reinvented the DB the hard
way, and a proprietary one that new comers have to learn from scratch.
Reuse is out the door.


> And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true.


> The relational data model is specifically intended for data storage and
> access; it isn't intended to address anything beyond that.

If that was true, then they would be happy with a file system alone.
Besides, original intentions can mean squat, per above.


[re: Text schema example]

> But then you have taken what was an arbitrary stream of characters and
> already broken it up into a representation that better suits your specific
> model.

Nothing wrong with that.

> And I suspect that the code that would read an arbitrary stream of
> characters and puts it into your tables, was written in something _other_
> than SQL - because SQL is not good at the free-text processing that is
> necessary to get the data into a tabular format, because SQL is not
> general purpose.

You mean not Turing Complete, per above. Something does not have to be
TC to be "general purpose". Another example would be Regular
Expressions. They are not TC, yet are a general purpose string
matching/finding tool. (Maybe not the best either, but that is another


> // Christian Brunschen


From: topmind on

Patrick May wrote:
> "topmind" <topmind(a)> writes:
> > Patrick May wrote:
> > > "topmind" <topmind(a)> writes:
> > > > SQL is close to being Turing Complete.
> > >
> > > In other words, SQL is not Turing complete. That addresses
> > > your original question:
> >
> > No, because I never claimed "all".
> You asked "But how are tables less close to the domain than
> classes, methods, and attributes?" The answer is, they lack
> behavior. The most common language for manipulating tables is SQL and
> it is not as powerful as general purpose OO languages.

How does not covering the entire behavior spectrum make it "less close"
to the domain? It only means that its role is not to do the whole
enchalada. It is not *meant* to do the entire app from end to end. I
never claimed that about query languages or DB's. Being an end-to-end
tool is not a prerequisite for being useful or being "general purpose".

> > > > Almost all of these have a fair amount of disagreement among OO
> > > > proponents. Check out
> > >
> > > 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.
> >
> > Do you have the opposite?
> Provided right above. Here it is again, for your convenience:
> 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.
> Now, where is your evidence that proliferation of accessors and
> mutators is considered good OO practice?

One opinion means diddly squat. I believe the goal was "consensus".
Those who put accessors around everything did it due reading somebody's
mantra, not out of their own will. I didn't create the flame-wars
between the wrappers and non-wrappers, I only noted their existence.

> > > 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 am not following you here. If some of the processing has to be on
> > legacy systems then it has to be on legacy systems. The introduction
> > of a DB does not change that.
> Exactly. You stateed that:
> 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.
> This is simply not the case in real world systems. The existence of
> legacy systems is just one reason why your "just use a big database"
> approach won't meet NFRs such as performance, scalability, resiliency,
> and recoverability.

Are you saying your techniques better fit with legacy systems? I would
like to see a demo. I know many shops that copy data from legacy
systems into RDBMS so that they can more easily query, sift, and search
the data. One feature of legacy systems is that a good many cannot
handle a lot of data due to their age. Thus, current technology can
copy what is there into an RDBMS.

> The point here is that statements like the one above indicate
> more about the limited types of systems to which you apparently have
> some minimal exposure than they do about good software development
> practice. Experience in this newsgroup has shown that attempting to
> educate you about software outside of your tiny box is a waste of
> time. Hence, I simply point out when you are saying more than you
> think you are, and move on.

Perhaps because they use argument-from-authority instead of evidence
out of bad habit. You show me clear-cut coded proof, and I will change
my mind. Until then, the brochure-talk and black-box-bragging can take
a hike. OOer's seem so surprised and shocked when people ask for
evidence, as if they are above it. "Science is so 70's. Alan Kay made
science obsolete." (demonstrative quote only).

> I'll type more slowly. There is no mention of ACLs in the
> references I provided. The references I provided show how some
> important security issues are addressed. This demonstrates that your
> claim that '"Security" is mostly just massive ACL tables.' is
> nonsense.

Okay, I see where this went wrong. I meant security *could* be
implemented by massive ACL tables. I did not mean to imply it was the
current norm. I apologize for my wording there.

> > > > > 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.
> >
> > You have a strange sense of biz apps.
> You have a nasty tendency of equivocating between "CRUD
> applications" and "biz apps".

In practice the line is blurred. It used to be more separated into
"batch jobs" and "front-end" work, but now people expect instant
answers, so the line has been fading. There is sometimes a split
between "architects" and "coders", but this is largely because
architects know the domain better. But, architects are still often
involved with front-end/output design.

> Considered technical views of experienced software developers are
> valuable, especially for other developers with the experience to
> assimilate those views. You demonstrate your inexperience by
> repeatedly taking positions like the one above, which boil down to "I
> am unable or unwilling to understand your position, therefore mine is
> equally valid." Does that make you feel all warm and fuzzy inside?

One should not be expected to accept anecdotal evidence on face value
here. Opinions from experts and amatures point every which way. If
anecdotal evidence is all you have, then I am done here. Few come here
to read unjustified positions. There are plenty of other places to get
summary opinions.

> > > > > 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 gave them a chance to strut their stuff. If they can't strut
> > right, it ain't my fault.
> Yeah, I can see how systems like Macsyma, RAX (controlling Deep
> Space 1), Orbitz, the scheduling system for Gulf War 1, countless
> expert systems, [.....]

The challenge was *not* mere implementation. Even assembler has a lot
of implementations. They claimed "significantly less code". I gave them
a sample application and they made up every (lame) excuse under the
sun. But that is another matter. FP is not the topic.

> > Hey, weren't you blown away by others on your claim that
> > "relational" was mostly about links? [....]
> No, that wasn't me. [....]

I apologize if it was not you. I should have checked.

> Sincerely,
> Patrick


From: frebe on
> Codd's definition /is/ the RDB view; it is a specialized application of
> more general set theory...
Search for "relational model" at wikipedia and you will find no support
for this statement. There seem to be a conensus that Codd is the
creator of the relational model. I think it is important that we try to
keep to generally accepted definitions and not try to invent own
definitions to supports our claims.

>> Why would line number be the key?
> How else would you uniquely identify each line for individual access in
> a text file?
By a separate index file. Otherwise I would need a linear search to
find the records/lines I am looking for.

>> In what way does emedded identity attributes limits Codd's RDM to
>> persistence?
> It doesn't.
Good. But why do you use this argument for claiming the opposite?

> Just look at the titles of Codd's early books and papers and try to
> convince me that his research wasn't /focused/ on RDBs and persistence:

I don't find any persistence related word in these titles. It is only
in the OO world that Data Base == persistence. Outside this
subcommunity databases are used for much more, which I have already
many times pointed out. Search for "database" at wikipedia and count
the number of times the word "disk" or "hard drive" appear. Personally
I like the opening statement as a definition of database. "A database
is an organized collection of data."

> He was a researcher in IBM's hard disk division, for Pete's sake!
Does this makes his research invalid in other areas? Many research
results have proven to be useful in completly other areas. Does the
fact that Ivar Jacobson has a background in the telecom industry, makes
his work invalid in other areas?

> you might also look at Chris Date's work for descriptions of the RDM well beyond
> the RDB view.
Below is one quote from a article from Chris Date:
"In the first installment in this series, I said I expected database
systems still to be based on Codd's relational foundation a hundred
years from now. And I hope you can see, from what we've covered over
the past few months, why I believe such a thing. The relational
approach really is rock solid, owing (once again) to its basis in
mathematics and predicate logic. "

I don't think this support your claim that Codd's definition(s) is only
a subset of the relational model.

Fredrik Bertilsson

From: frebe on
>> Bull. UML is often a LOWER level of abstraction because it can take
>> much more code/language to specify the same thing.
> Another example of an utterly absurd assertion whose sole purpose is to
> drive an opponent who knows better crazy. I know you better so I'm not
> going to bite by dignifying such nonsense with a response.

Why is this so absurd? The guys making a RDMS might use UML for
designing the software, before coding.

Fredrik Bertilsson