Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe on 13 Feb 2007 08:46 > > Do you consider structures, objects and result sets as more > > high-level then relations? > > Do you consider a wrench to be higher level than a hammer? Your > use of the terms "high-level" and "low-level" in this context is > merely emotive. It doesn't reflect any meaningful concept with > respect to writing quality software. Do you consider Java more high-level than C? Normally it is very meaningful to use the terms high- and low-level. Why shouldn't it be meaningful for classifying data structures? Do you claim that the use of lists and maps could be considered being at the same level as using relational algebra? > Sometimes the solution calls for a structure, sometimes an > object, sometimes a set of tuples, sometimes a directed graph, and > sometimes other structures. Relations may be used for (logically) model tree structures, network structures, directed graphs and many other structures. A relational database may use directed graphs as indexes. > > As I have tried to explained to you before, the relational model > > makes a distinction between logical and physical data. Logical data > > is relations, and physical data is supporting data structures likes > > files, B-trees or hash tables, that are not visible to the user of > > the database. > > What you have failed to explain is why you think that only > relations should be used. They should be used because they are able to model almost all kind of information. > Are RDBMSs so much more complex than other software that only they > require other data structures? A RDBMS is indeed a solid pice of software. Other software obviously need to use low-level data structures if a suitable RDBMS is not availible. But if you use a RDBMS parts of the job is already done. You don't have to do it from scratch by yourself. You may compare it to goto statements. Nobody argues for using goto statements instead of while and if statements anymore. But goto statements are indeed needed in every pice of software as a low-level construction. Using pointers are almost equivalent to using goto. They both create code that is hard to understand and hard to maintain. The relational model aim to drop the use of pointers. > > I know that you consider this as an contradication > > It's not that I consider it a contradiction, it _is_ a > contradiction. You claim that only relations should be used and then > immediately add "except to implement databases." By your own > admission, relations are not always sufficient. If I claim: "You should not use goto statements, but the assembler code produced uses goto statements." Is this a contradication? You have to stop these stupid word games and start supporting your own claims instead. /Fredrik
From: Patrick May on 17 Feb 2007 21:55 "frebe" <frebe73(a)gmail.com> writes: >> > Do you consider structures, objects and result sets as more >> > high-level then relations? >> >> Do you consider a wrench to be higher level than a hammer? >> Your use of the terms "high-level" and "low-level" in this context >> is merely emotive. It doesn't reflect any meaningful concept with >> respect to writing quality software. > > Do you consider Java more high-level than C? Normally it is very > meaningful to use the terms high- and low-level. "Normally" in what context? Java has some features such as garbage collection that C++ lacks, so in that sense it can be considered higher level, but C++ templates are far more powerful than Java's generics. High level and low level depend on the context. > Why shouldn't it be meaningful for classifying data structures? The terms are technically meaningless, especially without context. By using them to describe data structures you are attempting to use emotive language to avoid meaningful discussion. > Do you claim that the use of lists and maps could be considered > being at the same level as using relational algebra? What do you mean, exactly, by "level"? >> Sometimes the solution calls for a structure, sometimes an >> object, sometimes a set of tuples, sometimes a directed graph, and >> sometimes other structures. > > Relations may be used for (logically) model tree structures, network > structures, directed graphs and many other structures. Building directed graphs from tuples is getting close to the category of "Stupid SQL tricks." That aside, if your claim that relations are the only data structure that should be used is based on the concept that it is possible, via sufficient circumlocutions, to construct other data structures out of relations, that becomes quite uninteresting. You're essentially admitting (again) that other data structures are required and encouraging the creation of them from a single, not always appropriate, primitive. > A relational database may use directed graphs as indexes. Those directed graphs are not built from relations. If relations aren't sufficient for an RDBMS, why should they be considered sufficient for all other applications? >> What you have failed to explain is why you think that only >> relations should be used. > > They should be used because they are able to model almost all kind > of information. First, "almost" isn't "all". Second, lists, for example, can also model a wide range of structures. Why should relations be preferred to lists? Why should any primitive be treated as sufficient in and of itself? >> Are RDBMSs so much more complex than other software that only they >> require other data structures? > > A RDBMS is indeed a solid pice of software. Other software obviously > need to use low-level data structures if a suitable RDBMS is not > availible. But if you use a RDBMS parts of the job is already done. > You don't have to do it from scratch by yourself. You didn't answer the question. Are RDMSs so much more complex than other software that only they require other data structures? Why should other applications limit themselves to a single primitive to construct their necessary data structures? >> > I know that you consider this as an contradication >> >> It's not that I consider it a contradiction, it _is_ a >> contradiction. You claim that only relations should be used and >> then immediately add "except to implement databases." By your own >> admission, relations are not always sufficient. > > If I claim: "You should not use goto statements, but the assembler > code produced uses goto statements." Is this a contradication? Not analogous. You have yet to show that relations are sufficient for all applications. You have repeatedly contradicted your own claim by admitting that at least one type of application, namely RDBMSs, require other data structures. > You have to stop these stupid word games and start supporting your > own claims instead. You've got to stop projecting. The stupid word games are all yours. I'm just trying to get you to rationally and logically defend your claim that relations are the only data structure that should be used. You have thus far spectacularly failed to do so. The primary reason for this is that your claim is ridiculous on its face. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: frebe on 18 Feb 2007 03:52 > > Do you consider Java more high-level than C? Normally it is very > > meaningful to use the terms high- and low-level. > > "Normally" in what context? Java has some features such as > garbage collection that C++ lacks, so in that sense it can be > considered higher level, but C++ templates are far more powerful than > Java's generics. High level and low level depend on the context. I just want to point out you methods of argumentation. You know that you can't claim C to be more high-level than Java. Instead you change the subject to C++ and starts yet another word game. > > Do you claim that the use of lists and maps could be considered > > being at the same level as using relational algebra? > > What do you mean, exactly, by "level"? Yet another word game. But if it makes you happier: Level of abstraction and power. But now back to the original question. Would you consider list operations (add, get, remove, etc) as powerful as relational operations (join, selection, projection, etc)? > >> Sometimes the solution calls for a structure, sometimes an > >> object, sometimes a set of tuples, sometimes a directed graph, and > >> sometimes other structures. > > > Relations may be used for (logically) model tree structures, network > > structures, directed graphs and many other structures. > > Building directed graphs from tuples is getting close to the > category of "Stupid SQL tricks." Why? > That aside, if your claim that relations are the only data > structure that should be used is based on the concept that it is > possible, via sufficient circumlocutions, to construct other data > structures out of relations, that becomes quite uninteresting. No, it just shows that the relational model is complete and powerful. There are many things you can't do with a network graph that can be done with relations (using predicate logic for example). But it is very hard to find examples of the opposite. > >> What you have failed to explain is why you think that only > >> relations should be used. > > > They should be used because they are able to model almost all kind > > of information. > > First, "almost" isn't "all". Second, lists, for example, can > also model a wide range of structures. Why should relations be > preferred to lists? Because you can fetch relational data using predicate logic. Lists only have the get operator. Why should lists be preferred to relations? > Why should any primitive be treated as sufficient > in and of itself? If you have a complete set of primitives that are sufficient (relational algebra), you have a comple model (the relational model). List operations are not a sufficient set of operations. > Why > should other applications limit themselves to a single primitive to > construct their necessary data structures? The main reason is the power of relational operators compared to operations for other data structures. They could be used for virtually everything (assuming you have a suitable relational database implementation availible), and the resulting application code will have much fewer lines of code than using other low-level data structures. /Fredrik
From: Patrick May on 18 Feb 2007 13:55 "frebe" <frebe73(a)gmail.com> writes: >> > Do you consider Java more high-level than C? Normally it is very >> > meaningful to use the terms high- and low-level. >> >> "Normally" in what context? Java has some features such as >> garbage collection that C++ lacks, so in that sense it can be >> considered higher level, but C++ templates are far more powerful >> than Java's generics. High level and low level depend on the >> context. > > I just want to point out you methods of argumentation. You know that > you can't claim C to be more high-level than Java. Instead you > change the subject to C++ and starts yet another word game. Actually, that was a reading error on my part. I misread C++ where you wrote C. The same point remains, though, and I note that you failed to address it. Your predilection for accusing others of playing word games, when in fact you are the only one doing so in this thread, grows old. For many application domains, Java's features provide abstractions that are better suited to the problems typical of that domain. In that sense and in that context, Java can be said to be "higher level" than C. In other domains, particularly those requiring access to hardware or development of high performance communication protocols, to give just two examples, the abstractions provided by C enable the creation of a superior solution. >> > Do you claim that the use of lists and maps could be considered >> > being at the same level as using relational algebra? >> >> What do you mean, exactly, by "level"? > > Yet another word game. But if it makes you happier: Level of > abstraction and power. Asking for clear definitions is a word game? You don't seem to have a clear definition of that term, either. In any case, given a language such as Common Lisp that has a vast collection of functions that operate on lists and other sequences, I don't see a difference in level of abstraction. If you do, please point it out explicitly. > But now back to the original question. Would you consider list > operations (add, get, remove, etc) as powerful as relational > operations (join, selection, projection, etc)? Those aren't the only operations possible on lists. Your question is therefore nonsensical. >> >> Sometimes the solution calls for a structure, sometimes an >> >> object, sometimes a set of tuples, sometimes a directed graph, >> >> and sometimes other structures. >> >> > Relations may be used for (logically) model tree structures, >> > network structures, directed graphs and many other structures. >> >> Building directed graphs from tuples is getting close to the >> category of "Stupid SQL tricks." > > Why? You are claiming on the one hand that relations are the only data structure that should be used and on the other hand that relations can be used to create "almost" all other data structures. You have not rationally justified making the effort of going through the extra hoops of creating other data structures from relations. It may be possible, but you've shown no clear value in doing so. >> That aside, if your claim that relations are the only data >> structure that should be used is based on the concept that it is >> possible, via sufficient circumlocutions, to construct other data >> structures out of relations, that becomes quite uninteresting. > > No, it just shows that the relational model is complete and > powerful. There are many things you can't do with a network graph > that can be done with relations (using predicate logic for > example). But it is very hard to find examples of the opposite. When you take time and space concerns into consideration, it's very easy to find such examples. The "nearest neighbor" example provided by, I believe, Mr. Kazakov is one such. Another example comes from a systems I implemented a few years ago. We had a directed graph of transactions that had be settled in the order specified by the edges. That is, a given transaction could not settle until all of the transactions it pointed to had settled or it had to settle at the same time as those transactions. The solution involved identifying all cycles in the graph, converting them to single, complex transaction nodes, and then doing settlement over the resulting directed acyclic graph. You might be able to do that with SQL, but it would take longer to implement and would not perform within the customer's time constraints. >> >> What you have failed to explain is why you think that only >> >> relations should be used. >> >> > They should be used because they are able to model almost all >> > kind of information. >> >> First, "almost" isn't "all". Second, lists, for example, can >> also model a wide range of structures. Why should relations be >> preferred to lists? > > Because you can fetch relational data using predicate logic. And, so? Not all uses of data structures are for fetching. >> Why should any primitive be treated as sufficient in and of itself? > > If you have a complete set of primitives that are sufficient > (relational algebra), you have a comple model (the relational > model). Sufficient for what? Just because you have a tool, the RDBMS, that is based on a formal mathematical model doesn't mean that you automatically can address all real world problems optimally with it. Common Lisp is based on the lambda calculus. Why should the relational model be preferred? >> Why should other applications limit themselves to a single >> primitive to construct their necessary data structures? > > The main reason is the power of relational operators compared to > operations for other data structures. They could be used for > virtually everything (assuming you have a suitable relational > database implementation availible), and the resulting application > code will have much fewer lines of code than using other low-level > data structures. That's another very broad claim. Are you actually asserting that implementations based on the relational model will always have "much fewer lines of code" than implementations based on any other paradigm? That's an extraordinary claim that requires extraordinary evidence. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: frebe on 19 Feb 2007 13:12
> >>>> Do you consider structures, objects and result sets as more > >>>> high-level then relations? > > >>> Do you consider a wrench to be higher level than a hammer? > >>> Your use of the terms "high-level" and "low-level" in this context > >>> is merely emotive. It doesn't reflect any meaningful concept with > >>> respect to writing quality software. > > >> Do you consider Java more high-level than C? Normally it is very > >> meaningful to use the terms high- and low-level. > > > "Normally" in what context? Java has some features such as > > garbage collection that C++ lacks, so in that sense it can be > > considered higher level, but C++ templates are far more powerful than > > Java's generics. High level and low level depend on the context. > > Higher-and-lower level doesn't (or shouldn't) depend on the feature > overload. It should depend more on abstraction or a language's ability > to get closer to the business problem and further from the computer. > Interfaces, templates, generics, iterators, scope, and other things are > all programming-specific things that aren't very close to accounting, > recordkeeping, catalog management, shopping, etc. In fact, many of the > features seem to exist only for the benefit of programmers (to protect > themselves from themselves) than to actually allow greater or innovative > expressiveness. If you read the database schema for an enterprise application, you will probably get a pretty good overview of the business problem, in just a few A4 pages. The level of abstractation is very high, and it is very close the the business problem. /Fredrik |