SQL
in [OOP]
|
From: H. S. Lahman on 16 Jan 2006 12:55 Responding to Jacobs... topmind wrote: >>The point is that there are alternative /implementations/ for >>persistence to RDBs in the computing space. SQL has already made that >>implementation choice. > > > > SQL is not an implementation. What is the difference between locking > yourself to SQL instead of locking yourself to Java? If you want > open-source, then go with PostgreSQL. What is the diff? Java ain't no > universal language either. Of course it's an implementation! It implements access to physical storage. More important to the context here, that implementation is quite specific to one single paradigm for stored data. Requirements -> 4GL -> 3GL -> Assembly -> machine code executable Everything on the left is a specification for what is immediately to its right. Similarly, everything to the right is a solution implementation for the specification on its immediate left. Go look at an SA/D Data Flow Diagram or a UML Activity Diagram. They express data store access at a high level of abstraction that is independent of the actual storage mechanism. SQL, ISAM, CODASYL, gets, or any other access mechanism, is then an implementation of that generic access specification. Java is certainly a general purpose 3GL. Like most 3GLs there are situations where there are better choices (e.g., lack of BCD arithmetic support makes it a poor choice for a General Ledger), but one could still use it in those situations. SQL, in contrast, is a niche language that just doesn't work for many situations outside its niche. BTW, remember that I am a translationist. When I do a UML model, I don't care what language the transformation engine targets in the model implementation. (In fact, transformation engines for R-T/E typically target straight C from the OOA models for performance reasons.) Thus every 3GL (or Assembly) represents a viable alternative implementation of the notion of '3GL'. >>>>UML with a compliant AAL is an example of a 4GL. If I build an OOA >>>>model for, say, a POS Order Entry System, that model can be >>>>unambiguously implemented without change either manually as a print mail >>>>order catalogue or as software for a browser-based 'net application. >>>>The fundamental processing logic of catalogue organization and order >>>>entry is expressed the same way regardless of the implementation context. >>> >>> >>>And if other people/vendors made their own flavor of this tool with >>>differences between the implimentation, then it would be in the same >>>boat. Why should implementation A1 and A2 demote the "generation" >>>ranking of A? >> >>It is not the same thing at all. The 4GL solution does not care if >>persistence is /implemented/ with RDBs, OODBs, flat files, paper files, >>or clay tablets. > > > For the zillionth time, RDBMS are far more than just "persistence". It is only if one refuses to manage complexity by separating logical concerns. Render unto the Disk generic static storage and render unto the Application context-dependent dynamics. * 1 [Context] ----------------- [Data] 1 * [Problem Solution] -------- [Data] The first view if the basis of the RDB paradigm -- generic storage of the same data for access by many different contexts. The second view is the one that is relevant for solving large problems -- access of data that is carefully tailored to the problem in hand. Storing and accessing data for many different contexts is a quite different problem than formatting and manipulating data to solve a specific problem. For a non-CRUD/USER application, SQL and the DBMS provide the first relationship while a persistence access subsystem provides the reformatting for the second relationship. >>>>SQL does support abstraction in the sense that it abstracts the RDB >>>>implementation. However, here I was referring to problem space abstraction. >>> >>> >>>This depends on how one defines "problem space abstraction". The OO >>>view of PSA is kinda lame if you ask me. It does not factor out common >>>"database verbs" into a single tool or convention, but reinvents it >>>over and over for many classes. Repetative SET/GET syndrome is an >>>example of this poor pattern factoring. OO'ers often don't see this >>>ugly ugly duplication of concept. >> >>I am talking about the abstracting the domain where the original problem >>exists rather than the computing domain where a software solution will >>be executed. SQL only abstracts a very narrow part of the computing domain. > > > I disagree. A large part of *most* apps I have seen involves > database-oriented stuff. P. May mentioned security. Security can be > viewed as a dealing with large ACL tables. Most algorithms can be > reduced to mostly DB-oriented operations. I had to build a 3D graphics > system in college, and most of it could be reduced to DB-operations: > having "parts" reference each other in many-to-many tables, > transformation steps tracking, looking up polygons, cross-referencing > those polygons with their "parent part", storing scan-lines for later > inspection, etc. I will agree that DB's are not (currently) fast at > such, but still from a logical perspective the operations were > essentially DB-oriented. (Because I couldn't use a DB, I ended up > reinventing a lot of DB idioms and it was not very fun.) When the only tool you have is a Hammer, then everything looks like a Nail. The FP people will be happy to tell you that they can solve those problems quite elegantly without any state variables, much less tables of data. Similarly, the OO paradigm allows one to solve those problems with quite different abstractions. [FYI, the most comprehensive book on building UML Class Diagrams is Leon Starr's "Executable UML: How to Build Class Models". In that book Leon repeatedly uses tables as analogues for validating class instances. In effect he is using them as a tool for normalization. But the identification of classes and properties is all done in a OO fashion via abstraction for the problem space. More important, the management of relationships and collaborations is very different than the RDB paradigm (e.g., one almost never selects from a collection of all instances and the notion of a multi-table join is virtually nonexistent in an OO application). IOW, there is a mapping to tables but the construction paradigm is not at all driven by a table view.] > > A compiler/interpreter is the same way: a DB would make it simpler to > implement, especially fancy interactive debuggers, but performance/RAM > issues make it not practical. Thus, one spends a lot of time coding > array and pointer hopping to look stuff up, count things, etc. Most of > it is just tracking and associating "stuff". I don't think that is a very good analogy. A compiler/interpreter applies exactly the same set of rules to transforming the input model to machine language on the platform de jour. IOW, the same compiler/interpreter will do exactly the same thing in any shop having the same hardware for any customers. The issue here is letting the DBMS apply business rules and policies that are specific to a particular customer or, worse, that are specific to a particular problem. Then one is not separating concerns and one is bleeding cohesion; the penalty is a high cost in maintenance. >><moved>What I implied was that CRUD/USER applications tend to be not very >>complex. Report generation was never very taxing even back in the COBOL >>days, long before SQL, RDBs, or even the RDM. Substituting a GUI or >>browser UI for a printed report doesn't change the fundamental nature of >>the processing. > > > Please clarify. If a process was "not taxing", then you are simply > given more duties and projects to work on. Management loads you up > based on your productivity and work-load. Back in the '60s and early '70s writing COBOL code to extract data and format reports was a task given to the entry level programmers. That's where the USER acronym (Update, Sort, Extract, Report) came from. The stars went on to coding Payroll and Inventory Control where one had to encode business rules and policies to solve specific problems. In CRUD/USER processing the customer is the one actually solving problems by interpreting the data. The developer is just formatting the data to support the customer. Replace printouts with GUIs or browsers and the customer is still solving the real problem. It is only when the problem solution gets drawn into the software that one leaves the realm of CRUD/USER processing and thing start to get tricky. >>Unfortunately, I agree with May that the rest of the paragraph makes no >>sense; it just seems to be your personal jargon and mantras. > > > If May said anything else, we should check his tempurature. He has > never been friendly to me or my ideas. A polite person would simply ask > for clarification rather than label it "jargon or mantras". You > wouldn't do that to your boss, would you? We've been here before. It's part of your shtick. You define your own terms, like 'noun-based' and 'verb-based', and then throw them out on the table so that your opponent sees them as non sequitors. You also keep throwing out the same slogans as your web site. They are part of the predictable collection of forensic ploys you use when debating OO people. It's all designed to have an emotional effect to put the opponent on tilt. You seem to get your amusement out of having OO people go bonkers. Seeing how far down the rabbit hole you can drag them is a sport to you. You even keep trying to get me involved in such debates, even though I insist on not biting. Do you think that I haven't noticed that this subthread started off as a discussion about DBMS vs. application responsibilities but you keep trying to push it into an OO debate? The entire paragraph in question was a blatant attempt to deflect from the DBMS issues to OO issues. BTW, I would and have said similar things to various bosses. >>>>Note that UML static diagrams also implement the RDM >>>>but they do so in a very different way than the RDBs do. >>> >>> >>>UML takes us back to the navigational/CODYSAL pointer/path hell that >>>proved a mess in the 60's and 70's. UML and OO is the structural GO TO >>>of the modern age. >> >>You keep trying but I'm still not biting. This is just another of your >>stock ploys to pull people's chains. You throw out a deliberately >>baseless and nonsensical assertion just to create emotional controversy >>to drag people down your anti-OO rabbit hole. > > > > You are so cute when you paint me as bad, manipulative, and evil. Not bad or evil, but definitely manipulative. You just find it amusing to pull people's chains and the OO community is providing plenty of soft targets. As I've said before, I think you are actually know a lot more about OO development than you let on and you are pretty clever about the way you tweak the OO people who engage with you. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
From: Patrick May on 16 Jan 2006 15:27 "topmind" <topmind(a)technologist.com> writes: > > > > SQL does support abstraction in the sense that it abstracts > > > > the RDB implementation. However, here I was referring to > > > > problem space abstraction. > > > > > > This depends on how one defines "problem space abstraction". > > > > "Problem space abstraction" typically refers to a concept > > from the domain for which the software system is being developed, > > e.g. Customer, Sales Order, Network Element, Product, etc. This > > is distinguished from "solution space abstractions" such as > > tables, rows, columns, keys, pointers, functions, and so on. This > > isn't a point of contention among experienced software developers. > > But how are tables less close to the domain than classes, methods, > and attributes? The ability to model behavior as well as data makes general purpose languages better able to model the problem domain than is SQL. > (I agree that some of the behavior side is not something to be done > on the DB, but that is simply a partitioning of specialties issue.) No, it's a qualitative difference. > > > Repetative SET/GET syndrome is an example of this poor pattern > > > factoring. > > > > 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. > 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. 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. Even if it were possible to go down the mainframe route, in many cases it would not make business sense. Big iron is expensive to buy, maintain, and upgrade. Distributed systems running on relatively inexpensive hardware can provide a more cost-effective solution. > "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. > > > You are participating in Domain Bigotry here. > > > > No, he is simply stating the obvious: CRUD/USER applications > > are not particularly complex, especially when compared with other > > software systems. > > Again, I have yet to see an objective or even semi-objective way to > measure "complexity". I suggest you Google for "software complexity" and you'll find several million links. Starting from a page like http://yunus.hun.edu.tr/~sencer/complexity.html will give you pointers to other research if you are genuinely interested in learning. > Again, the basic concepts of CRUD are easier to learn than most > other domains or problems, but that does not mean that the > implementation and maintainence of related apps is simple. CRUD applications are, however, not particularly complex as software systems go. Your claims otherwise indicate a lack of experience with anything else. > For lack of a better metric, I propose lines of code (LOC) for now > as our metric for complexity. This is yet another suggestion that shows you don't know much about the topic you're discussing. Lines of code is not a good measurement of anything. Do some research. > Can you make an argument for something being lots of LOC without > being "complex" (beyond learning the domain)? If not, then you are > probably stuck using LOC here. Some of the largest programs I've seen, in terms of lines of code, are for generating reports. Getting just the right information from a large data set and laying it out precisely as requested can be time consuming, but it's not particularly challenging. Object technology is not immune. J2EE in general, and EJBs in particular, require a great deal of code to provide functionality that could be provided far more efficiently. 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. Lines of code is a useless metric. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: topmind on 16 Jan 2006 16:29 H. S. Lahman wrote: > Responding to Jacobs... > > topmind wrote: > > >>The point is that there are alternative /implementations/ for > >>persistence to RDBs in the computing space. SQL has already made that > >>implementation choice. > > > > > > SQL is not an implementation. What is the difference between locking > > yourself to SQL instead of locking yourself to Java? If you want > > open-source, then go with PostgreSQL. What is the diff? Java ain't no > > universal language either. > > Of course it's an implementation! It implements access to physical > storage. Just as Java implements access to physical RAM etc. > More important to the context here, that implementation is > quite specific to one single paradigm for stored data. Any language or API is pretty much going to target a specific paradigm or two. I don't see any magic way around this, at least not that you offer. UML is no different. > > Requirements -> 4GL -> 3GL -> Assembly -> machine code executable > > Everything on the left is a specification for what is immediately to its > right. Similarly, everything to the right is a solution implementation > for the specification on its immediate left. Well that is a bit outdated. For one, the distinction between 4GL and 3GL is fuzzy, and many compilers/interpreters don't use assembler. > > Go look at an SA/D Data Flow Diagram or a UML Activity Diagram. They > express data store access at a high level of abstraction that is > independent of the actual storage mechanism. SQL, ISAM, CODASYL, gets, > or any other access mechanism, is then an implementation of that generic > access specification. SQL is independent of the "actual storage mechanism". It is an interface. You may not like the interface, but that is another matter. Repeat after me: "SQL is an interface, SQL is an interface, SQL is an interface".... Plus, what such UML models often do is something like: method getGreenScarvesCostingLessThan100dollars(...) { sql = "select * from products where prod='scarves' and color='green' and price < 100" return(foo.execute(sql)) } You simply wrap everything with long method names and call it "abstraction" and pat yourselves on the back. However, it is not really abstraction because often they are called from only ONE place. That just contributes to code bloat and red-tape-code. Plus one could do the same with functions if you really want such red tape. It is simply giving a specific unit of behavior a name. Some people want to name every nut and bolt. > > Java is certainly a general purpose 3GL. Like most 3GLs there are > situations where there are better choices (e.g., lack of BCD arithmetic > support makes it a poor choice for a General Ledger), but one could > still use it in those situations. SQL, in contrast, is a niche language > that just doesn't work for many situations outside its niche. You could be right, but I have yet to see a good case outside of split-second timing issues where there is a limit to the max allowed response time. (This does not mean that rdbms are "slow", just less predictable WRT response time.) If you can give an example outside of timing, please do. (I don't doubt they exist, but I bet they are rarer than you imply. Some scientic applications that use imaginary numbers and lots of calculus may also fall outside.) > > BTW, remember that I am a translationist. When I do a UML model, I > don't care what language the transformation engine targets in the model > implementation. (In fact, transformation engines for R-T/E typically > target straight C from the OOA models for performance reasons.) Thus > every 3GL (or Assembly) represents a viable alternative implementation > of the notion of '3GL'. Well, UML *is* language. It is a visual language just like LabView is. > > >>>>UML with a compliant AAL is an example of a 4GL. If I build an OOA > >>>>model for, say, a POS Order Entry System, that model can be > >>>>unambiguously implemented without change either manually as a print mail > >>>>order catalogue or as software for a browser-based 'net application. > >>>>The fundamental processing logic of catalogue organization and order > >>>>entry is expressed the same way regardless of the implementation context. > >>> > >>> > >>>And if other people/vendors made their own flavor of this tool with > >>>differences between the implimentation, then it would be in the same > >>>boat. Why should implementation A1 and A2 demote the "generation" > >>>ranking of A? > >> > >>It is not the same thing at all. The 4GL solution does not care if > >>persistence is /implemented/ with RDBs, OODBs, flat files, paper files, > >>or clay tablets. > > > > > > For the zillionth time, RDBMS are far more than just "persistence". > > It is only if one refuses to manage complexity by separating logical > concerns. "Separation" is generally irrelavent in cyber-land. It is a phsycial concept, not a logical one. Perhaps you mean "isolatable", which can be made to be dynamic, based on needs. "Isolatable" means that there is enough info to produce a seperated *view* if and when needed. This is the nice thing about DB's: you don't have to have One-and-only-one separation/taxonomy up front. OO tends to want one-taxonomy-fits-all and tries to find the One True Taxonomy, which is the fast train the Messland. Use the virtual power of computers to compute as-need groupings based on metadata. This is also why UML sucks: Either you have a jillion diagrams of the same thing in order to provide all the potential viewpoints that different users and developers will need, or you have to force a limited taxonomy on developers. UML does not provide this virtualization capability. > Render unto the Disk generic static storage and render unto > the Application context-dependent dynamics. > > * 1 > [Context] ----------------- [Data] > > > 1 * > [Problem Solution] -------- [Data] > > The first view if the basis of the RDB paradigm -- generic storage of > the same data for access by many different contexts. The second view is > the one that is relevant for solving large problems -- access of data > that is carefully tailored to the problem in hand. Storing and > accessing data for many different contexts is a quite different problem > than formatting and manipulating data to solve a specific problem. Again, DB's are not JUST for "storage". There are RAM-only RDBMS's. They provide services for "attribute modeling" for lack of a better term. They are essentially attribute modeling tools, not disk managers. OO'ers would rather reinvent their own attribute managers with different charracteristics for each implementation. RDBMS simply "encapsulate" commonly-used attribute management idioms into a standard (or at least semi-standard). > > For a non-CRUD/USER application, SQL and the DBMS provide the first > relationship while a persistence access subsystem provides the > reformatting for the second relationship. Reformatting? Please clarify. > > >>>>SQL does support abstraction in the sense that it abstracts the RDB > >>>>implementation. However, here I was referring to problem space abstraction. > >>> > >>> > >>>This depends on how one defines "problem space abstraction". The OO > >>>view of PSA is kinda lame if you ask me. It does not factor out common > >>>"database verbs" into a single tool or convention, but reinvents it > >>>over and over for many classes. Repetative SET/GET syndrome is an > >>>example of this poor pattern factoring. OO'ers often don't see this > >>>ugly ugly duplication of concept. > >> > >>I am talking about the abstracting the domain where the original problem > >>exists rather than the computing domain where a software solution will > >>be executed. SQL only abstracts a very narrow part of the computing domain. > > > > > > I disagree. A large part of *most* apps I have seen involves > > database-oriented stuff. P. May mentioned security. Security can be > > viewed as a dealing with large ACL tables. Most algorithms can be > > reduced to mostly DB-oriented operations. I had to build a 3D graphics > > system in college, and most of it could be reduced to DB-operations: > > having "parts" reference each other in many-to-many tables, > > transformation steps tracking, looking up polygons, cross-referencing > > those polygons with their "parent part", storing scan-lines for later > > inspection, etc. I will agree that DB's are not (currently) fast at > > such, but still from a logical perspective the operations were > > essentially DB-oriented. (Because I couldn't use a DB, I ended up > > reinventing a lot of DB idioms and it was not very fun.) > > When the only tool you have is a Hammer, then everything looks like a > Nail. No, out of necessity I started my career without DB usage, and I never want to return there. > The FP people will be happy to tell you that they can solve those > problems quite elegantly without any state variables, much less tables > of data. Well, I have asked for a practical demonstration in the past, and they couldn't provide one that showed more than about a 5% difference, making up pretty lame excuses in the process. I won't claim that my favorite approaches are objectively better. However, they have not been shown objectively worse. > Similarly, the OO paradigm allows one to solve those problems > with quite different abstractions. > > [FYI, the most comprehensive book on building UML Class Diagrams is Leon > Starr's "Executable UML: How to Build Class Models". In that book Leon > repeatedly uses tables as analogues for validating class instances. In > effect he is using them as a tool for normalization. But the > identification of classes and properties is all done in a OO fashion via > abstraction for the problem space. More important, the management of > relationships and collaborations is very different than the RDB paradigm > (e.g., one almost never selects from a collection of all instances and > the notion of a multi-table join is virtually nonexistent in an OO > application). IOW, there is a mapping to tables but the construction > paradigm is not at all driven by a table view.] How is replacing a table view with a class view better? Sure, schema's are messy at many shops, but given time the OO'ers will probably have messy classes also. The same motiviation (or lack of) for slop is part of human or management nature, not part of the paradigm. No paradigm has been shown to FORCE good practices. At least relational provides tools to keep schemas fairly clean (normalization rules). OO has no decent normalization model, tacking on more and more classes and methods like a shanty town living for the moment (out of necessity perhaps). Regarding joins, some dialects of SQL allow tables to be optionally joined without explicitly mentioning the relationships. I agree that SQL has many flaws. But it still beats the existing alternatives. > > > > > A compiler/interpreter is the same way: a DB would make it simpler to > > implement, especially fancy interactive debuggers, but performance/RAM > > issues make it not practical. Thus, one spends a lot of time coding > > array and pointer hopping to look stuff up, count things, etc. Most of > > it is just tracking and associating "stuff". > > I don't think that is a very good analogy. A compiler/interpreter > applies exactly the same set of rules to transforming the input model to > machine language on the platform de jour. IOW, the same > compiler/interpreter will do exactly the same thing in any shop having > the same hardware for any customers. > > The issue here is letting the DBMS apply business rules and policies > that are specific to a particular customer or, worse, that are specific > to a particular problem. Then one is not separating concerns and one is > bleeding cohesion; the penalty is a high cost in maintenance. I would like to see an example. "Separation of concerns" is why data issues are managed differently than behavior issues, by the way. You are narrowing your usage of "separation" to your pet approaches. You see, data is more "mathable" than behavior at this point in history. Behavior has resisted attempts to have useful and consistent idioms applied to it. Relational reigns in the pointer-like spehggetti of OO and UML but putting at least the data side into a standard attribute processing and management system. OO/UML drag both data and behavior back to the navigational spehgetti dark ages of the 1960's. It drags software down to the yet-to-be-mathed behavior realm. > > >><moved>What I implied was that CRUD/USER applications tend to be not very > >>complex. Report generation was never very taxing even back in the COBOL > >>days, long before SQL, RDBs, or even the RDM. Substituting a GUI or > >>browser UI for a printed report doesn't change the fundamental nature of > >>the processing. > > > > > > Please clarify. If a process was "not taxing", then you are simply > > given more duties and projects to work on. Management loads you up > > based on your productivity and work-load. > > Back in the '60s and early '70s writing COBOL code to extract data and > format reports was a task given to the entry level programmers. That's > where the USER acronym (Update, Sort, Extract, Report) came from. The > stars went on to coding Payroll and Inventory Control where one had to > encode business rules and policies to solve specific problems. Fine, show how OO better solves business rule management. (Many if not most biz rules can be encoded as data, BTW, if you know how.) Also, part of the reason for starting out with reports etc. is that it takes a while to learn the domain. Interface-level stuff (screens and reports) can be learned from semi-generic courses and books. The specific business rarely has good documentation and must be learned by *exposure*. Starting out with UI allows one time to get such exposure. There is no "domain school", or "Learn Bob's Kite Business in 21 Days" books. It is largely a matter of where training comes easiest from. > > In CRUD/USER processing the customer is the one actually solving > problems by interpreting the data. The developer is just formatting the > data to support the customer. Replace printouts with GUIs or browsers > and the customer is still solving the real problem. To some extent, yes, but users are usually crappy at factoring such that if you take everything they say litterally you will end up with duplication of concepts and info up the wazooo. Part of an analyst's job is to clearify the biz rules and then educate the customer about the benefits, changes, options, and corrections that normalization will require. > It is only when the > problem solution gets drawn into the software that one leaves the realm > of CRUD/USER processing and thing start to get tricky. > > >>Unfortunately, I agree with May that the rest of the paragraph makes no > >>sense; it just seems to be your personal jargon and mantras. > > > > > > If May said anything else, we should check his tempurature. He has > > never been friendly to me or my ideas. A polite person would simply ask > > for clarification rather than label it "jargon or mantras". You > > wouldn't do that to your boss, would you? > > We've been here before. It's part of your shtick. You define your own > terms, like 'noun-based' and 'verb-based', and then throw them out on > the table so that your opponent sees them as non sequitors. You also > keep throwing out the same slogans as your web site. That is called "reuse". > They are part of > the predictable collection of forensic ploys you use when debating OO > people. It's all designed to have an emotional effect to put the > opponent on tilt. > > You seem to get your amusement out of having OO people go bonkers. I will admit there is a certain satisfaction of using other people's own logic against themselves, especially if they have insulted me prior. > Seeing how far down the rabbit hole you can drag them is a sport to you. > You even keep trying to get me involved in such debates, even though I > insist on not biting. Do you think that I haven't noticed that this > subthread started off as a discussion about DBMS vs. application > responsibilities but you keep trying to push it into an OO debate? The > entire paragraph in question was a blatant attempt to deflect from the > DBMS issues to OO issues. OO'ers in generally do not like RDBMS and would rather wrap them with OO wrappers so that they don't have to deal with them directly. But this is not abstraction, it is translating horizontally from what you hate to what you like. In their head RDBMS are (incorrectly) viewed as low-level assembler-like tools. I am simply correcting this myth. They are a very powerful abstraction and modeling tool IF you know how to use them right. OO is in many ways lower level because it does not include many DB idioms and reinvents them the hard way from scratch each time they are needed. Putting long-named methods around everything does not improve abstraction, only creates beurocracy. > > BTW, I would and have said similar things to various bosses. > I don't know whether to label that as brave or foolish. > >>>>Note that UML static diagrams also implement the RDM > >>>>but they do so in a very different way than the RDBs do. > >>> > >>> > >>>UML takes us back to the navigational/CODYSAL pointer/path hell that > >>>proved a mess in the 60's and 70's. UML and OO is the structural GO TO > >>>of the modern age. > >> > >>You keep trying but I'm still not biting. This is just another of your > >>stock ploys to pull people's chains. You throw out a deliberately > >>baseless and nonsensical assertion just to create emotional controversy > >>to drag people down your anti-OO rabbit hole. > > > > > > > > You are so cute when you paint me as bad, manipulative, and evil. > > Not bad or evil, but definitely manipulative. You just find it amusing > to pull people's chains and the OO community is providing plenty of soft > targets. As I've said before, I think you are actually know a lot more > about OO development than you let on and you are pretty clever about the > way you tweak the OO people who engage with you. You are spreading falsehoods about RDBMS. They are NOT low-level. You only treat them as low level. Otherwise, show me with code examples that they are inharently low-level. Why should anybody take your word for it? Show me the code! (or UML) Enough of this brochure-talk. Show me UML/OO being better. Show me how wrapping everything under the sun with long-named methods/functions, even if referenced only once, makes for a better system. Your bashing of relational is evidence-free so far. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman -T-
From: Mikito Harakiri on 16 Jan 2006 16:43 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Again, I have yet to see an objective or even semi-objective way to > > measure "complexity". > > I suggest you Google for "software complexity" and you'll find > several million links. Starting from a page like > http://yunus.hun.edu.tr/~sencer/complexity.html will give you pointers to > other research if you are genuinely interested in learning. Hmm. I tried to find "software complexity" in wikipedia and failed. Apparently this topic (and the link you supplied) is a typical example of junk science. In general, I agree with Bruce -- there is no objective measure for program complexity. What is the complexity measure of 100000110000000000 for example? Speaking of *finite* objects, it is a basic fact that on TM can model another, therefore, you have to [arbitrarily] choose some reference TM. It is interesting [and nontrivial] fact that there is a way to establish complexity metrics for infinite objects, though.
From: Hasta <hasta on 16 Jan 2006 17:13
In article <1137447794.122780.151500(a)f14g2000cwb.googlegroups.com>, mikharakiri_nospaum(a)yahoo.com says... > In general, I agree with Bruce -- there is no objective measure for > program complexity. What is the complexity measure of > 100000110000000000 > Well, there is an objective measure of the complexity of 100000110000000000. It's the length of the smallest program able to generate that string. Browse for chaitin-kolmogorov complexity/randomness. A fascinating subject :-) |