Theory vs Practice 5

[CajunCenturion]

I'll start this show.

Theory is very important, not only in today's computing environment, but it always has been. The beauty of the academic world is that they have the luxury of researching theorectical ideas and constructs to provide the rest of the world with a best-case scenario. Its great that we have wonderful academicians who pursue the lofty goal of mathematical provable perfection.

In the business world, the role of IT is to utilize the technology to solve business problems, being bound by both time and budgetary contraints. Because of the contraints, trade-offs must be made, with the focus being on solving the problem.

Bottom line - we need both.

We need theorists and researchers finding better ways to do things, but we also need practitioners to deal with the real-world problems. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[rycamor]

Of course we need both. The real question is: what is and what should be the relationship between them? Should theoreticians be glorified salesmen for this or that technology vendor? Should they take polls about popular viewpoints and only provide opinions that appease the majority? Unfortunately, in today's big-money IT world, this is what happens all too often. (In fact, whole universities commonly identify themselves as a Microsoft-centered or a Java-centered institution, etc...)

In the thread that started this discussion ( thread656-350049 ), I just happened to bring up the idea that practitioners would do well to search out some theory--in fact, to go to the source of an idea. Most developers end up doing nothing but reading how-to books and other derivative work without ever taking a look at the "core" ideas from which the technology in question sprang. Even a cursory look at originating ideas in any field can do a lot to clear up misconceptions or misplaced priorities.

The reason I mentioned the

http://www.dbdebunk.com

site is because it deals with some of the core areas behind the field of data management. Of course, when I mentioned this site, I received several interesting responses, which I will attempt to answer in the following posts: -------------------------------------------

Big Brother: "War is Peace" -- Big Business: "Trust is Suspicion"
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[rycamor]

RESPONSE to petermeacham in Thread656-350049 :

rycamor Look anyone who writes

"if we cannot distinguish the two "6"s from one another somehow, we cannot even tell there are two of them"

is so clearly talking complete twaddle.

In terms of relational algebra, and computationally speaking, I disagree. In the real world, we tell the difference between multiple identical things by the fact that there still IS something distinguishing them, such as their placement in physical space. In fact, we line them up and count them to make sure. Thus, they are no longer in fact identical: they are distinguished (at the very least) by their physical placement. This is a unique attribute, since no two things can occupy the same place at the same time. C.J. Date is only making the point that there must be some distinguishing fact about multiple identical values, in order for us to know that they are multiple, and in fact to count them. This is not up to opinion; it is a simple fact of reality. Thus, in computing, if we have duplicate values, we differentiate them by order. This one is first, this one is second, etc... The reason this is considered critical in relational database talk is that physical placement or ordering is not supposed to be used to identify values in a database. Thus C.J.Date argues that duplicates (duplicate rows, specifically) should not be allowed, because they impose physical ordering, and actually create more complexity inside the DBMS. Essentially, it boils down to this statement: the person designing a particular database should decide for him/herself exactly what the distinguishing factor should be (such as a unique incremented primary key, if there is no other way to differentiate rows), rather than leave it up to the DBMS to decide for them. This forces you to think about why you have these duplicate values, and assign at least some minimal meaning to them.


I agree about Pascal being a lunatic. I particularly liked his attitude that if anyone disagreed with him, he was a stupid person who understood nothing.

I read through quite a lot of the site whilst having a coffe and thought that
a) it must be difficult to live so removed from reality.
b) it must be difficult to to achieve that level of pomposity.

I would be the first to agree that Pascal himself can be unpleasant at times. I have even had a couple of email exchanges with him. (Interesting though... he is not too snobbish to respond, even to a nobody like me ;-)). But his personality is not the deciding factor about whether his ideas have merit. Yes, he can be overbearing and he responds quite brusquely to other peoples' ideas, but he does not usead hominem arguments, such as you have used against his ideas. He actually asks anyone challenging him to provide a logical argument. An idea should stand or fall on its own merit. So, what are the logical arguments against his ideas? So far, most of what I have seen amounts to blustering.

I am personally interested in these arguments because I favor reasoned, logical discourse as a way to move toward the truth as much as possible. I have nothing emotionally invested here. If Pascal and Date could be proven wrong, I would love to hear the arguments.

But, I think it is a little unfair of 'real world' practitioners to ridicule theoreticians without seriously examining their claims. Theory is hard work. Yes, Date may use terminology that is a little heavy at times, but he is attempting as much as possible to find logical absolutes which can benefit us all. -------------------------------------------

Big Brother: "War is Peace" -- Big Business: "Trust is Suspicion"
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[rycamor]

RESPONSE to strongm in Thread656-350049 :

>none of the major vendors have implemented a truly relational DBMS

Anyone want to answer the answer the question "why"? It might just be that where the real world meets academic theory, the real world wins. It isn't necessarily the theoretical 'best' solution, just the most cost-effective, practical solution. The realms of human endeavour have more often than not resulted in such solutions.

And this is why McDonald's is the single largest seller of food, but would you be willing to argue that it is the "best practical solution", and there is no point in striving to achieve better? The real world is multifaceted. What holds in one area does not necessarily hold in the other. Yes, for McDonald's it was a combination of cost-cutting economies of scale, good marketing, luck, and the fact that most people's tastes can be compromised for convenience.

However, I never considered what "most people" accept as a reason to choose anything.

In the software world, we see the same thing: for some companies, it is more financially rewarding to create mediocre software, and put more money into marketing hype, carefully schemed business tactics, even downright deceit rather than simply make good software. (I won't name names, but we know who we are talking about).

But the database world is a puzzling one, even counter-intuitive. In many ways, it is actually easier to build a truly relational DBMS, because there are less complex workarounds needed, as well as arcane special cases to code around, etc... In fact, even though the most expensive DBMS in the world has not produced a relational DBMS is 20+ years of R&D, a small company by the name of Alphora managed it, starting with developers who had never even heard of relational database theory, until they stumbled across the writings of C.J. Date. In fact, they actually implemented it with Date's own "theoretical" query language called Tutorial D. I'm not saying that Alphora's DBMS is a perfect product, or the end-all and be-all, but the fact is that they accomplished this specific feat, without the vast resources of an Oracle or an IBM, says something.

Will Alphora succeed as a company? Who knows. But my point is, it's not about the feasibility (or as you say "the most cost-effective, practical solution&quot, but simply about public acceptance, and willingness of people to try new things. In almost any field of human endeavor, the best are rarely the most popular. But that is because of failings in the rest of us, rather than failings in the best of us. -------------------------------------------

Big Brother: "War is Peace" -- Big Business: "Trust is Suspicion"
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[CajunCenturion]

On the relationship between the theoretician and the practitioner. Should they be glorified salesman? No, but unfortunately, they have to pay homage to those who are paying the bills. While working on my doctorate, I was part of a team "doing research" on system development, but this research was being funded by Texas Instruments. In one sense, we were doing real research, investigating various unconventional ways of approaching certain problems, but on another level, we were involved in product development, because the results of our labors were designed to provide TI with a return on their investment.

There are only so many pure research dollars available, so when a university identifies themselves as Microsoft-centered, my stomach does a quarter turn to the left, but rights itself knowing that the university is getting much needed funds, some of which are used for pure research. (I know I can't be sure of this, but it helps to think positive and give the benefit of the doubt to the university.)

I agree that developers should understand some theory. All too many developers today are self-taught, or come thru the local certification school and yes they can write some programs and be productive programmers. But the quality of their work mirrors the quality of their education. The shallowness of their solutions is, IMHO, a direct reflection of their lack of theorectical understanding of the technology.

Of course, there are exceptions at both ends of the spectrum, and those who had the pleasure/misfortune of experiencing the exceptions will no doubt tell their story , making broad generalizations, and in doing so, perpetuate a deteriorating situation.

Another reason that none of the major vendors have implemented a truly relational DBMS, is that the relational model is a logical model, and at least at its inception explicitly went out of its way not to dictate any sort of physical implementation. When you couple that with the fact that the Relational Model is based on the mathematical theory of relations and relational calculus, its no wonder that no vendor has built one. I'm not sure many vendors even know that the relational model is mathematically defined. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[rycamor]

Yes, you have a point, but even then, that point should only go so far. Artists and theoreticians have always been obligated to pay homage to a benefactor of some sort, but when that research becomes only about that benefactor, it just demonstrates the shallowness of both parties. I'm not saying all researchers are like this, but let's face it, the last few years have seen so much corruption in the field of research that it is time for a little balance.

Yes, the relational model is still explicitly NOT about physical implementation. That's the beauty of it. I don't see how that freedom makes it harder to implement a relational DBMS. In fact, the implementation developers can do whatever they please on the physical storage side to optimize access to the data. But, since most vendors based their implementation on SQL, which was intended as just a temporary prototype, they were also led into thinking in terms of "rows" and "columns", and in turn made the decision that logical rows and columns would be represented physically. That is, each record involves a physical storage of one distinct piece of data, and the data is ordered according to the rows and columns of the logical table, in a 1-to-1 way, rather than allowing for internal redistribution of the data based on views, queries, constraints, etc... (Then of course, they invented the partial work-around of indexes). This places extreme restrictions on the ability of the DBMS to optimize for performance. It is the whole reason we see all these arguments currently about "denormalization for performance" and "post-relational" databases. -------------------------------------------

Big Brother: "War is Peace" -- Big Business: "Trust is Suspicion"
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[CajunCenturion]

Can't argue with that.

An interesting piece of work that was done more years ago that I care to admit to having been involved with, was the development of a purely relational view of a CODASYL Network-Structured Database implementation.

In this case Network has nothing to do with LANs or WANs, but rather, a set based approach for database storage, which at that time was called a network-structured database.

At the time I left that project, it was by no means ready for prime-time, but in what tests we had done to that point - we were running circles around INGRES. Out intent was to marry the performance capabilities of the CODASYL model while presenting the Relational model view of the database. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[petermeachem]

C.J. Date is only making the point that there must be some distinguishing fact about multiple identical values, in order for us to know that they are multiple, and in fact to count them.

I really don't mind people sitting about in universities pondering on the meaning of life. Someone has to do it. I don't mind people coming up with statements like the above. It's not unlike the 'I cannot prove you are there, all of this might be just my imagination'. Bit of childish amusement never hurt anyone.

What I do object to is people pretending that this sort of argument has any sort of practical value. And worse, that anyone who does not agree with their point of view has the intelligence of a cabbage. For all I know, a purely relational database might be 10% faster or 10% smaller or something. Who cares? Not I. Life is a compromise. It must be better to have something that actually works rather than a mathematical model of what something would be like if anyone could build it.

I don't know, but I assume these people are funded in a university by some outside organisation. Said organisation then has the kudos of having 'a great thinker' onboard. The great thinker then makes money by doing lectures. If they stopped coming up with wacky ideas, the money would stop coming in.

Look at our own Captain Cyborg. He has to come up with new things to keep in the public eye and keep the money coming in. Same as Geri Halliwell. Peter Meachem
peter @ accuflight.com

 

[petermeachem]

C.J. Date is only making the point that there must be some distinguishing fact about multiple identical values, in order for us to know that they are multiple, and in fact to count them.

I really don't mind people sitting about in universities pondering on the meaning of life. Someone has to do it. I don't mind people coming up with statements like the above. It's not unlike the 'I cannot prove you are there, all of this might be just my imagination'. Bit of childish amusement never hurt anyone.

What I do object to is people pretending that this sort of argument has any sort of practical value. And worse, that anyone who does not agree with their point of view has the intelligence of a cabbage. For all I know, a purely relational database might be 10% faster or 10% smaller or something. Who cares? Not I. Life is a compromise. It must be better to have something that actually works rather than a mathematical model of what something would be like if anyone could build it.

I don't know, but I assume these people are funded in a university by some outside organisation. Said organisation then has the kudos of having 'a great thinker' onboard. The great thinker then makes money by doing lectures. If they stopped coming up with wacky ideas, the money would stop coming in.

Look at our own Captain Cyborg. He has to come up with new things to keep in the public eye and keep the money coming in. Same as Geri Halliwell. Peter Meachem
peter @ accuflight.com

 

[rycamor]

Peter,

But, Date is making the seemingly simple point for a reason: DBMS systems have ignored this fact for years, to their detriment. It's not just an intellectual exercise.

I challenge you to read any two chapters of C.J. Date's INTRODUCTION TO DATABASE SYSTEMS (now in it's 7th edition) and argue that there is no practical value in it. That's the whole reason the relational database model was established. There were very real practical problems with all the other data models in use at the time.

OK. just for the sake of argument, let's assume that Dates discussion on duplicates is silly (it isn't). You are basing your disdain of a whole field of thought on this single article? This is not practicality, my friend. This is willful ignorance.

Who cares? I care. It's not about a 10% difference in prformance. It's qualitative, not quantitative. I would love to be able to use a truly relation DBMS. I can't use the Alphora product I mention above because it doesn't run on Unix, but I love the idea of power you can have, which SQL doesn't give you. My personal reasons for interest are very practical.

It must be better to have something that actually works rather than a mathematical model of what something would be like if anyone could build it.

Did you even read my post above? Someone did build it, and it wasn't some impossibly arcane intellectual exercise. They did it for directly practical reasons: a more capable data modeling language actually makes it much easier and quicker to design applications in general.

Yes, life is a compromise, but shouldn't we struggle to reduce compromise as much as possible? Why seek out and create compromises where none need exist? This is exactly what the database industry has done. And it is just because we the users are so un-demanding, that they can keep on doing this and charging us more and more for the favor.

Please... calling this a "bit of childish amusement", comparing Date to Captain Cyborg (clownish publicity-seeker)?

Here is a perfect example of the practical consequences of ignoring clear thinking in this area: VeriSign's WHOIS database has so many errors in it that they may actually be forced to stop selling domain name services.

http://slashdot.org/article.pl?sid=02/09/04/2051240&mode=thread&tid=99

. I'm sure the internal decision making in VeriSign went something along the lines of "Let's just focus on practicality, and not worry about theoretical correctness in our data management. We need it done yesterday, so let's not worry about tomorrow."

I may be ranting here, but this is a subject I feel passionately about. Practicality is good, but temporary convenience, can often lead to bigger headaches down the road. Computing is one of the few industries where you can get away with this. To paraphrase one of F. Pascal's better analogies: what if engineers said "to hell with theories of physics and structural engineering" when they design a bridge? Would you want to cross that bridge? -------------------------------------------

Big Brother: "War is Peace" -- Big Business: "Trust is Suspicion"
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[petermeachem]

It's not just an intellectual exercise.
Yes it is!

what if engineers said "to hell with theories of physics and structural engineering" when they design a bridge? Would you want to cross that bridge?

I think we are talking about the difference between science and engineering here.

I don't think the theories of physics come into bridge design directly. Some may affect metallurgy. Structural design involves estimating loads and calculating stresses and strains making assumptions all the way. Like 'all joints are pin-joints'. You then add a bit on depending on your experience and past bridge designs. This is probably why the pedestrian bridge across the Thames wobbled. It's now got dampers all over it.

Had a scientist designed it, it probably wouldn't have got built at all yet. If it did get built, it could be theoretically brilliant, but possibly look awful.

I'm not really trying to wind you up rycamor, don't take it personally. I'm sure Dataphor is quite delightful. Hasn't exactly set the world on fire though has it. Peter Meachem
peter @ accuflight.com

 

[sleipnir214]

(rycamore, before I get started, you speak glowingly and with authority about Alphora. I know nothing about it. Can you cite some sources, please?)

I have two questions for Mr. Pascal:[ul][li]Would you cross a bridge designed by a theoretical mathematician?[/li]and[li]If I ask to borrow your car, and you ask me if I know how to drive, and I answer "Sure. In theory", would you still give me the keys?[/li][/ul]

To answer F. Pascal's rhetorical question about engineering and bridges: My practical answer is, "Depends on how many people cross it before I do." In 55BC, Julius Caesar's combat engineers built a 400m wooden bridge across the Rhine River in 10 days. Caesar's engineers could not possibly have known more theory than Aristolean physics, much of which has been shown in the modern era to be incorrect. Now I have to say, I would not have liked being the first legionnaire to walk across that bridge. But by the time the 10000th had crossed, I'd feel pretty confident in the engineers' work.

I am a great proponent of knowledge of theory. I tell Tek-Tips posters on a regular basis to learn more of the theory behind what they do. From a practical standpoint, knowing theory is the only way to refill your professional bag of tricks when you empty it.

I also agree that adherence to Blackwell's Law of Strategic Laziness, which states, "It is always cheaper to do it right in the first place" is a good idea.

But Pascal's rhetorical question is specious. A good engineer must know the limits of the theories behind what he is doing, because theories most often fail at the point where theory meets physical reality. That's where information theory can be so much fun -- since it has no physical reality, it is possible to endlessly argue specific points. At no time can someone say the equivalent of, "Okay, lets find two balls the same diameter and of different weights and drop them off the Tower of Pisa. We'll settle this once and for all."

I have to say that I, too, don't care the south end of a north-bound rat whether Oracle's or anybody else's database server software does or does not strictly adhere to the relational database model. What I care about is whether a software system based on Oracle's database server software can reliably keep track of my hotel reservation. ______________________________________________________________________
TANSTAAFL!

 

[CajunCenturion]

I think we need to realize that either extreme - all theory and no practical, or all practical and no theory - are equally destructive. There needs be a balance between the two.

Without theorectical research we not have object oriented programming. As an outgrowth of that research, OOP is now commonplace in the programming world. That does not mean that its perfect, nor is it finished. Practioners have already begun to use these concepts, while at the same time, improvements to this programming model are being addressed by theorists.

When Codd began his database research back in the late 60s early 70s, he embarked on a totally new approach to data management. The result of his research led to the development of the Relational model. Again, I'm not saying that its finished nor is it perfect. But that does not prevent practioners from taking advantage of what is known so far, no does it preclude theorists from continue to research and improve on the model.

Today, theorectical research is ongoing in neural networks, artificial intelligence just to name a couple. What practical benefits come from this research largely remains to be seen.

What you may consider to a trivial intellectual exercise today may very well be the foundation for the practioners of tomorrow.

The expansion of human knowledge comes from theorists looking for new and better ways to do things. The benefits to mankind come when practioners put that newfound knowledge to use. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[petermeachem]

The benefits to mankind come when practioners put that newfound knowledge to use.

Two good posts. The above quote is the crux. Endless theoretical discussions with no thought of practical application, and in fact dismissing practical application that might besmirch the pure theory, do not help anyone. Peter Meachem
peter @ accuflight.com

 

[strongm]

I just can't be bothered...

 

[rycamor]

I don't see where I can argue with Cajun Centurion's last post, or sleipner's, or petermeacham's. The only reason I discuss this stuff is because I seek practical results from the good ideas I can find. (And hopefully, to weed out the bad ideas)

I am just arguing the same point from the other side: it's not practical to completely dispense with theory, because theory exists to save us time (generalized, repeatable, etc...). Even when you make choices against the theoretically correct one, it's better to know why you are making them. Yes, we don't have to dismiss all applications just because they "besmirch pure theory", but just because a practical application exists, does that mean there is never any room for improvement?

I don't think it must always be like this:

|<--theory-- VS --practice-->|

Sometimes they push against each other, sometimes they both point the same way, or any range in between. Some theory is faulty, or fuzzy. Some theory has rigorous logic behind it. Some theory is empirical, meaning it's not directly provable, but rather a series of test cases, whereas some theory is self-evident, such as a mathematical proof (a=b and a=c, so a=c). The fun part is to actually make something concrete out of these ideas, but it's not always easy to know what's right. You have to make thoughtful choices. That's all I'm trying to do.


sleipner -- I can't speak with any authority on Alphora, not having tested the product yet. But, one of C.J. Date's collaborators (Hugh Darwen) speaks very positively about them:

http://www.dbdebunk.com/x_trdbms_impl.htm

I did try to download and test their evaluation copy, but it required Windows and the .NET framework, and my one Win2K station bombs out with .NET (needs an overhaul).

I have to admit I feel somewhat sorry for them, because I can see the amount of ridicule many will pile on them simply for trying to accomplish this. It's going to be an uphill battle for them. They have been persistently, but politely calling me (I didn't mind giving them my phone#), but I had to explain that I pretty much stick with Unix on the server side, so I won't be too eager to adopt, until they come out with one that will run as cross-platform .NET. -------------------------------------------

Big Brother: &quot;War is Peace&quot; -- Big Business: &quot;Trust is Suspicion&quot;
(

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html)

 

[petermeachem]

rycamor,

I had a look at the link. Notice that Alphora uses sql server back end presently. So presumably what they do is just to operate sql differently. So anyone could operate sql relationally if they wanted to. Just depends on how you choose to drive it. Peter Meachem
peter @ accuflight.com

 

[petermeachem]

Last word.

Also note that in the referenced article they didn't actually DO anything. Just talked about it... Peter Meachem
peter @ accuflight.com