Re: What databases have taught me
Date: Fri, 23 Jun 2006 13:07:06 GMT
Frans Bouma wrote:
> JOG wrote:
>>Well after a brief hiatus I have just ploughed through the whole 800 >>posts of the OO vs RM thread. Some discouraging stuff indeed. Over the >>last few years a study of database technology, helped greatly by >>discussions in cdt, has educated my opinions significantly, and >>perhaps my albeit slow progress can be illuminative to others.> die-hard database pundits who preach to implement everything of an
> Please also realize that in comp.databases*, a lot of people are
> application inside the DB, including BL.
I assume BL=business logic. What, exactly, is your objection to using predicate logic for dealing with logic? (Other than ignorance.) Exactly what formalism do you propose that surpasses the predicate calculus for dealing with logic?
>>- I started life as a procedural programmer. >>- I adopted OO and soon got the 'aha' click described by R. Martin. >>- I spent years coding large OO projects, with beautiful, elegant >>architectures. >>- I spent further years practically gnawing my arm off attempting to >>adapt my perfect OO designs as requirements inevitably shifted and >>exceptions arose. >>- I finally realised that my 'aha' was utterly illusionary, and that >>my code, being OO, was inevitably and irrecovably imprisoned in a >>hierarchical strait-jacket> on the experiences you got if they're the result of OO or the result of
> I don't know anything about you nor your projects, so I can't comment
> applying OO wrong.
From the little bit you write here, I know a lot about you. For instance, you know little or nothing about higher-level abstractions, the benefits of symmetric operations, the advantages of declarative techniques over procedural techniques, robust type systems, separation of concerns and probably a whole host of other fundamental concepts.
> What I can say is that if you don't realize that <insert tech /
> paradigm here>
The surest sign of a self-aggrandizing ignorant is the wanton use of the word 'paradigm' which has many meanings where for each meaning a better word exists.
is just a tool to get to the goal you want to achieve:
> an executable solution to the problem you want to solve
You further reveal your cognitive limitations with your presupposition that every solution to every problem must execute.
Although, I am sure you are blissfully unaware of it, the specific tools we are comparing are both formalisms. While I suppose one could argue that formalisms are "technologies" or "techniques", one would have to stretch things a little. Formalisms are not 'paradigms' by any of the myriad meanings of the word.
Formalisms are tools for expressing with rigour and precision amenable to mechanical manipulation. Mathematicians (and everyone engaged in programming is practising applied mathematics whether one knows it or not) have long recognized the importance of good formalisms for expressing concepts. Formalisms become doubly important in computing where a machine does the manipulation.
, that same
> tech/paradigm will sooner or later bite you because it will have
> limitations and shortcomings.
While I agree with JOG regarding the hierarchic straightjacket, I find OO much more damaging for other reasons, and your concluding phrase above demonstrates the point.
OO proponents in an effort to create some kind of mysticism have
systematically discarded existing precise vocabulary for imprecise
verbiage often using the same word to mean many different things. For
instance, established computing terms like variable, value, type, data,
state machine, etc. are lost in a haze of nebulous terms like object.
This mysticism incapacitates OO proponents. They invariably talk around
issues without ever naming them directly, which leaves one wondering
whether they really understand what each other are saying. Your
inability to identify a formalism as a formalism preferring instead to
call it a 'tech/paradigm' demonstrates my point.
I direct your attention to Dijkstra's comments on elixirs and the
illusion of power. I observe that OO is as damaging to minds as COBOL or
Basic, and I suggest Dijkstra's comments about them should apply equally
This mysticism incapacitates OO proponents. They invariably talk around issues without ever naming them directly, which leaves one wondering whether they really understand what each other are saying. Your inability to identify a formalism as a formalism preferring instead to call it a 'tech/paradigm' demonstrates my point.
I direct your attention to Dijkstra's comments on elixirs and the illusion of power. I observe that OO is as damaging to minds as COBOL or Basic, and I suggest Dijkstra's comments about them should apply equally to OO.
>>OO is hierarchy. Enforcing a hierarchy where none exists is an utterly >>dire and destructive artifice. If one does not recognize this, one is >>etiher wholly uneducated (given that the battle between >>hierarchy/networks and a relationship based models occurred decades >>ago) or has not been involved in enough large scale OO projects. Yet >>still this turgid "chinese doll" approach prevails through Java, C++ >>and the bastard child of them all, XML.> library. It often is implemented as a library with static methods in
> True, a good example is a Math library in an OO language runtime
> one big class or several different classes without state nor specific
> type, just a vehicle to hold the static methods together.
> That doesn't mean OO sucks, it means for functional problems which can
> be appearing in any domain, it might be best to use a functional /
> procedural approach instead of an OO.
Here again, you prove yourself ignorant of the meaning of procedural. All OO languages are procedural rather than declarative. While one or two functional OO languages exist, almost all are imperative.
Functional languages contrast with imperative languages. Declarative languages contrast with procedural languages.
OO is just an arbitrary and ad hoc collection of features useful for constructing large unpredictable state machines from small predictable state machines.
> The same applies to using OO-esk constructs in an procedural language.
> I think a lot here have seen or have written C-structs with function
> pointers to use some kind of OO-esk approach in their procedural
> programs because it would fit the problem better. That's not implying
> procedural languages suck, it illustrates there might be better
> solutions to that particular problem in that particular domain.
Are you seriously suggesting that C++ is any less procedural than C? Yikes!
>>I still code via OO as I currently have no other preferable tools. And >>yes, I still absolutely take pride in my crafted generic OO designs. >>However I now don't waste precious time trying to perfect them, >>because I know they are by definition inflexible, brittle and flawed. >>So I make them lightweight and replacable, aware of the limitations >>of the neanderthal paradigm that we are currently lumped with.> reality, but that could be caused by experiences I or others didn't
> I think that's, just judged by the sentence above, a flawed vision on
> experience, so I won't judge you on that.
If you didn't intend anyone to judge him on 'a flawed vision', why the hell did you suggest it in the first place?
Frankly, JOG's vision and his cognitive abilities are fine. I cannot say the same for you, and I do judge you on that.
I can understand how one who prefers nebulous terms like paradigm and object would conclude the danger of blindness. What I don't understand is the conclusion of the danger of blindness in others who prefer to say what they mean.
Take for example Object oriented data-access. Entities as
> objects in your program, working with object graphs, etc. it all
> matches the paradigm used and lets you make progress.
You used the word 'object' three times. Define the word. Define 'entity' while you are at it. What you wrote is meaningless gibberish.
Take the phrase: "Entities as objects in your program"
Let's assume for argument's sake that Entity means "some arbitrary concept named as a noun and associated with some artifact". When pluralized, it is not at all clear whether you mean multiple concepts or multiple artifacts. It is not at all clear whether "objects" means object classes or object instances. It is clear that you are talking about mapping some arbitrary concept to something in your program and that the 'something' is probably either a variable or a data type. However, since we are discussing an arbitrary concept, it hardly matters which. Some concepts will map to variables and some will map to data types.
The phrase "working with object graphs" presumably means working with pointers among variables, and I suggest that is usually just an onerous task forced on one by a lousy computational model.
The phrase "it all matches the paradigm used" does not in any way suggest which of the many meanings of 'paradigm' applies. If you mean the formalism or computation model, which is not really a paradigm in any sense of the word, the statement is pointless. Obviously, one must conform to whatever formalism or computational model one uses. One doesn't really have any other choice. Now does one?
The phrase "lets you make progress" doesn't really offer any useful information. A couple of days ago, I went fishing for brook trout. I walked about half a mile along the brook next to my house through dense alders, chest-high raspberry canes, ostrich ferns as tall as I am and one particularly thorny patch of wild rose vines. The alders, raspberry canes, ostrich ferns and rose vines let me make progress too. They didn't really do anything to facilitate my progress, though.
[straw man snipped]
>>So apologies for the rant, but I find the current status quo very >>frustrating. I can only hope that this situation will change as the >>field matures and hierarchy-where it does not belong finally dies a >>long overdue death.Received on Fri Jun 23 2006 - 15:07:06 CEST
> "Use the right tool for the job, Luke"
What makes you think OO is the right tool for any job?