SQL
in [OOP]
|
From: topmind on 23 Jan 2006 01:08 (Part 1 of reply) > >>>>>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. > >> > >>Exactly. Java is a specific implementation of a 3GL. 3GL is the > >>abstraction, Java is an implementation. Persistence access is the > >>abstraction, SQL is an implementation. > > > > > > > > Why do you keep saying "persistence"? I don't think you get the idea of > > RDBMS and query languages. Like I said, think of a RDBMS as an > > "attribute management system". Forget about disk drives for now. Saying > > it is only about "persistence" is simply misleading. > > Persistent data is data that is stored externally between executions of > an application. RDBs are a response to that need combined with a > requirement that access be generic (i.e., the data can be accessed by > many different applications, each with unique usage contexts). That's > what DBMSes do -- they manage persistent data storage and provide > generic, context-independent access to that data storage. I disagree. You can use them that way, but I tend to view them as an "attribute management system". They do well modelling "things" in the real world (and virtual things) by keeping track of attributes of them. They also provide important and useful services such as concurrency management, joins (cross-referencing), sorting, and aggregation (sums, counts, averages, etc.) Mere persistence does NOT have to include things such as joins and aggregation, making one do them in app code instead. Back in my desktop-DB days, I created a lot of temporary tables to do things such as joins, filtering, and aggregation for task-specific temporary uses. The results were not kept beyond the task/module. Thus, I was using DB tools *without* any sense of "lasting". What would *you* call that? "Persistence" does not apply there. > > My point in this subthread is that such responsibilities are complicated > enough in practice that one does not want the DBMS to also manage and > execute dynamic business rules and policies. IOW, the DBMS should just > mind its own store. [This thread has been a veritable hotbed of puns. > I've probably made more in this thread than I've done in the last > decade. B-)] I agree that code does some things better and DB other things, and one uses them *together* in a Yin-Yang fashion. They compliment each other. > > >>>>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. > >> > >>4GLs get around it because they are independent of /all/ computing space > >>implementations. > > > > > > I am not sure UML qualifies as 4th Gen. Just because it can be > > translated into multiple languages does not mean anything beyond Turing > > Equivalency. C can be translated into Java and visa verse. > > A UML OOA model can be implemented unambiguously and without change in a > manual system. In fact, that is a test reviewers use to detect > implementation pollution. The OOA model for, say, a catalogue-driven > order entry system will look exactly the same whether it is implemented > as a 19th century mail-in Sears catalogue or a modern broswer-based web > application. That is not true for any 3GL. One can execute Java code by hand also. If you follow the spec, it should always come out the same. (There may be minor vendor differences due to errors or fuzzy areas in the spec, but this is true of any non-trivial tech language, including UML.) > > >>However, that's not the point. SQL is a 3GL but comparing it to Java is > >>specious because Java is a general purpose 3GL. > > > > > > Again, this gets into the definiton of "general purpose". I agree that > > query languages are not meant to do the *entire* application, but that > > does not mean it is not general purpose. File systems are "general > > purpose", but that does not mean that one writes an entire application > > in *only* a file system. It is a general purpose *tool*, NOT intended > > to be the whole enchilata. > > Huh?!? If you can't write the entire application in it, then it isn't > general purpose by definition. > > > A hammer is a general purpose tool, but that does not mean one is > > supposed to ONLY use a hammer. You need to clarify your working > > definition of "general purpose", and then show it the consensus > > definition for 4GL. > > huh**2?!? A hammer is not a general purpose tool by any stretch of the > imagination. Okay, then what is a "general purpose tool"? If I was going to put together a tool box for a trip where the mission details are not given ahead of time, I would certainly pack a hammer. Only an idiot would not. No, it is not a one-size-fits-all tool, and I don't expect one. Good apps don't need a one-size-fits-all language because they can use yin-yang complimentary tools. > > >>SQL represents a > >>solution to persistence access that is designed around a particular > >>model of persistence itself. So one can't even use it for general > >>purpose access to persistence, much less general computing. > > > > > > Please clarify. Something can still be within a paradigm and be general > > purpose. Further GP does not necessarily mean "all purpose", for > > nothing is practially all purpose. > > SQL is designed around the RDB paradigm for persistence. It can't be > used for, say, accessing lines in a text flat file because the text file > is not does organize the data the way SQL expects. So SQL is not a > general purpose interface to stored data. Apropos of your point, > though, SQL is quite general purpose for accessing /any/ data in a > uniform way from a data store _organized like an RDB_. Well, I agree that SQL is probably not a very good way to reference free-form text. However, just because it is not good for everything does not mean it is not general purpose. Again, NOTHING is good at EVERYTHING. Do you claim that there is something that is good at everything? No? I didn't think so. By the way, I have created tables similar to this: table: textFile -------------- fileID ParagraphID SentenceID token (word or punctuation) tokenType (punctuation, word, non-printable, etc.) (Non-printable characters are represented in Hex notation.) It can be done. > > >>>>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. > >> > >>My 4GL definition isn't ambiguous, which is why I like it. Reviewers of > >>OOA models have no difficulty recognizing implementation pollution. > > > > > > Argument by authority. > > I prefer to think of it as argument by rational practicality. I didn't see it *here*. > > >>>>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".... > >> > >>Try using SQL vs. flat files if you think it is independent of the > >>actual storage mechanism. (Actually, you probably could if the flat > >>files happened to be normalized to the RDM, but the SQL engine would be > >>a doozy and would have to be tailored locally to the files.) SQL > >>implements the RDB view of persistence and only the RDB view. > > > > > > > > How is that different than ANY other interface? You are claiming magic > > powers of UML that it simply does not have. > > There is a distinction between describing an interface and designing its > semantics. UML is quite capable of describing the semantics of any > interface. Deciding what the semantics should be is quite another thing > that the developer owns. > > When I have a subsystem in my application to access persistent data, > that subsystem has an interface that the rest of the application talks > to. That interface is designed around the rest of the application's > data needs, not the persistence mechanisms. It is the job of the > persistence access subsystem to convert the problem solution's data > needs into the access mechanisms de jour. I could wrap SQL calls in functions, like that PinkScarf example I already gave. But unless the same kind of thing is called multiple times, it is just code bloat. Query languages can be compact in many circumstances. Putting bloated single-use wrappers around it gets you nothing except more code. Thus, I *can* play the same game via function wrappers if need be. > > If the persistence is an RDB, then the subsystem implementation will > <probably> use SQL. If the persistence is flat text files, it will use > the OS file manager and streaming facilities. If it is clay tablets, it > will use an OCR and stylus device driver API. That allows me to plug & > play the persistence mechanisms without touching the application > solution because it still talks to the same interface regardless of the > implementation of the subsystem. Flat files don't have near the power. That is a poor analogy. RDBMS are MORE than persistence. Say it over and over until it clicks in. Just because YOU use it ONLY for persistence does not make it the only way to build systems, just the bloated reinvent-the-wheel way JUST so that you can claim UML purity. > > IOW, the semantics of the interface to the subsystem is /designed/ at a > different level of abstraction than that of the subsystem > implementation. Bull. UML is often a LOWER level of abstraction because it can take much more code/language to specify the same thing. > UML doesn't care about the design process; it just > represents the results. Yeah right. Logic languages, like Prolog, once claimed the same thing (and in some senses were right, but programmer productivity or code size was not objectiviely reduced). UML is a visual language just like any other language, including the likes of Lab View. Language == Language. UML is not magic. You got nothing new. > > > And as somebody pointed out, one can use SQL on flat files too. ODBC > > drivers can be created to hook SQL to spreadsheets, flat files, etc. > > Only if the data is organized around embedded identity and normalized. > Even then such drivers carry substantial overhead and tend to be highly > tailored to specific applications. IOW, you need a different driver for > every context (e.g., a spreadsheet) and then it won't be as efficient as > an access paradigm designed specifically for the storage paradigm. So? What is the grand alternative? Of course different "devices" are going to need different drivers. That is a given. There is no one-size-fits-all driver. I have no idea what alternative you are envisioning, but it is probably in the category with unicorns and bigfoot. (end of part one)
From: topmind on 23 Jan 2006 01:15 (Part 2 of reply) > >>Compute a logarithm. You can't hedge by dismissing "scientific" > >>computations. > > > > I didn't. Nothing is ideal for everything under the sun. Nothing. See > > above about general-purpose tools. > > > > > >>Try doing forecasting in an inventory control system w/o > >>"scientific" computations. > > > > I am not sure what you are implying here. I did not claim that > > scientific computation was not necessary. > > I was just anticipating your deflection; you've been using the > give-me-an-example ploy for years. B-) When the example is provided > you deflect by attacking it on grounds unrelated to the original point. No, in this case one example is not sufficient. "Always" is not a claim I made. Thus, one exception, or even a few, does not pop my point unless they are very common. > That's usually easy to do because examples are deliberately kept > simple to focus on the point in hand. That allows you to bring in > unstated requirements, programming practices designed for other > contexts, and whatnot to attack the example on grounds unrelated to the > original point. In this case, though, you screwed up by setting up a > basis for the deflection ahead of time. > > You asked for an example outside of "timing". Actually, it depends on the type of scientific computation. If the computation involves a lot of information and a lot of cross referencing, then a DB may be the appropriate tool. (I gave a list of common exception patterns in a reply to P. May.) > The main reason SQL isn't > a general purpose 3GL is that it can't handle dynamics (algorithmic > processing) very well. So the obvious examples are going to tend to be > algorithmic, such as computing a logarithm. But your parenthetical > hedge set up a basis for dismissing any obvious example as "scientific" > when you subsequently deflect. Then later you can argue the point was > never demonstrated. I am not sure what you mean. I agree that "algorithmic" tends to be areas where DB's will often not be helpful. There are some places where hammers are useless also. However, I still consider them a general purpose tool. > > >>Or try encoding the pattern recognition that > >>the user of a CRUD/USER application applies to the presented data. The > >>reality is that IT is now solving a bunch of problems that are > >>computationally intensive. > > > > > > As usual, "it depends". Problems where there is a lot of "chomping" on > > a small set of data are probably not something DB's are good at (at > > this time). An example might be the Travaling Salesman puzzle. However, > > problems where the input is large and from multiple entities are more > > up the DB's alley. > > The Traveling Salesman problem can be arbitrarily large and the RDB > model will still probably not be useful because... > > <aside> > FYI, most of the Operations Research algorithms are actually pretty > simple when written out in equations and the core processing doesn't > require a lot of code. Typically most of the code is involved in > getting the data into the application, setting up data structures, and > reporting the results. In addition, the interesting problems are huge > and involve vast amounts of data. > > For example, the logistics for the '44 D-Day invasion of Normandy held > the record as the largest linear programming problem ever solved well > into the '70s. The equations for the Simplex solution were written in a > few lines but the pile of data processed was humongous and the actual > execution took months. (It had to be split up into many chunks because > of the MTTF of the computer hardware and a lot of preprocessing was done > by acres of clerks with hand-cranked calculators.) > </aside> That is a very specific mathematic process such that a dedicated custom-built data-structure plus algorithm will out-perform a DB. In a sense, a linear programming system is *also* perhaps a general-purpose tool because LP problems can be found in diverse industries, but so far less common than DB's. > > > (It may be possible to use a DB to solve Salesmen quickly, but few > > bother to research that area.) > > Unlikely. It's an np-Complete problem so the worst case always involves > an exhaustive search of all possible combinations (i.e., O(N*N)). The > exotic algorithms just provide /average/ performance that approaches > O(NlogN). But those algorithms require data structures that are highly > tailored to the solution. And because of the crunching one wants > identity in the form of array indices, not embedded in tables or the > problem doesn't get solved in a lifetime. Just because it hasn't been done does not mean it is not possible. Most algorithm researchers ignore DB's out of historical habit. > > >>>>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. > >> > >>Exactly. But solutions at the OOA level are 4GLs because they can be > >>unambiguously implemented without change on any platform with any > >>computing technologies. > > > > > > So can any Turing Complete language. > > And your point is...? UML is no different than any other language in terms of cross-emulation and has no extra powers. > > On separation of concerns of problem solving dynamics vs. data > persistence and access: > > >>>"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. > >> > >>You know very well what I mean by 'separation of concerns' in a software > >>context, so don't waste our time recasting it. Modularity has been a > >>Good Practice since the late '50s. > > > > > > > > If there is only one concern set where each concern is mutually > > exclusive, then we have no disagreement. In practice there are usually > > multiple "partioning" candidates, and that is where the disagreements > > usually arise. File and text systems don't make it easy to have > > partitioning in all dimensions, so compromises must be made. It is "my > > factor is more important than your factor, neener neener". If there is > > only one way to slice the pizza, then there is no problem. But if there > > are multiple ways, then a fight breaks out. > > > > This is one reason why DB's are useful: the more info you put into the > > DB instead of code, the more ad-hoc, situational partitionings you can > > view. You are not forced to pick the One Right Taxonomy of > > partitioning. Categorizational philosphers came to the consensus that > > there is no One Right Taxonomy for most real-world things. > > There are three accepted criteria for application partitioning (i.e., > separating concerns at the scale of subsystems): Subject matter, level > of abstraction, and requirements allocation via client/service > relationships. (BTW, this has nothing to do with OO; it is basic > Systems Engineering.) Even within "subject matter" there are probably multiple orthogonal partitioning candidates. So that one alone carries my point. > > Subject matter: Clearly static data storage and providing generic access > to it is a different subject matter than solving Problem X. That might be true if DB's were *only* about persistence. But, they are not. > > Level of abstraction: Outside CRUD/USER processing the detailed > manipulation of data storage (e.g. ,two-phased commit) is clearly at a > much lower level of abstraction than the algorithmic processing the > solves a particular problem. IOW, the application solution is > completely indifferent to where and how data is stored. One should be > able to solve the problem the same way regardless of what the > persistence mechanisms are. "Same way" may hard-wire the solution to a particular paradigm. How is hard-wiring the solution to a relational paradigm worse than hard-wiring it to your pet paradigm? You are in the same ball. Paradigm-neutral algorithms have not been invented yet (and UML ain't it). > That substitutability means that the > problem solution is at a higher level of abstraction than the > persistence mechanisms. IIIFFFF we were only dealing with "persistence". But, we are not. > > Requirements Allocation: Clearly the requirements for persistence > implementation and access are quite different than the requirements on > the specific solution of Problem X. You are obsessed with "persistence". Many DB features can be used even without the expectation of persistence. (See "desktop DB days" above.) > > So under all three of these criteria it makes sense to separate the > concerns of persistence from individual problem solutions. That's > exactly what DBMSes do. The problems only come into play when one > violates that separation of concerns and starts bleeding specific > problem solutions into the DBMS itself. The boundary is not really hard in practice. It *could* be, I agree, but generally makes for a bloated, beurocratic system design. UML and OO interface tend to be that way these days. > > >>The RDB paradigm > >>is not designed for context-dependent problem solving; it is designed > >>for generic static data storage and access in a context-independent manner. > > > > > > I think what you view as context-dependent is not really context > > dependent after all. It is just your pet way of viewing the world > > because of all the OOP anti-DB hype. > > My view of context-dependence is the solution to a /particular/ problem. > Each application solves a unique problem. IOW, the problem is the > context. RDBs provide persistence that allows all the applications to > access the data in a uniform way regardless of what specific problem > they are solving. > > Whether one can solve the problem in a reasonable fashion with the data > structures mapped to the RDB structure depends on the nature of the > problem. For CRUD/USER processing one can. For problems outside that > realm one can't so one needs to convert data into structures tailored to > the problem in hand. Tables are a general-purpose data structure. They can represent anything that stacks, maps, trees, sets, etc can. Plus, they flex better. For example, if you use a dedicated map, you cannot add a second value cell (3 total cells) without a lot of code rework. With tables it is a snap. I agree that a dedicated map may be faster in some cases, but usually only on the small such that performance is not an issue anyhow in the small. Dedicated structure kits rarely come with disk/ram-caching management and concurrency management, for example. Thus, if your needs grow up, you are hosed. Dedicated *anything* is usually at least slightly faster than a general-purpose tool used for that purpose. DB's just make it so you don't have to roll-your-own 95% of the time. > > [Note that this is relevant to the point above about providing SQL > drivers for different storage paradigms. That makes sense for CRUD/USER > environments because one is already employing SQL as the norm. So long > as the exceptions requiring a special driver are fairly rare, one can > justify the single access paradigm. However, it makes no sense at all > for non-CRUD/USER environments because one has to reformat the data to > the problem solution anyway. So rather than reformatting twice, one > should just reformat once from a driver that optimizes for the storage > paradigm.] Please clarify. An example may help. > > >>Before you argue that the RAM RDB saves developer effort because it is > >>largely reusable and that may be worth more than performance, I agree. > >>But IME for /large/ non-CRUD/USER problems the computer is usually too > >>small and performance is critical. > > > > > > Please clarify. Ideally the RDBMS would determine what goes into RAM > > and what to disk such that the app developer doesn't have to give a > > rat's rear. Cache management generally does this, but a both-way system > > is probably not as fast as a dedicated RAM DB. Even if the two-way > > ideal is not fully reached, one will soon have the *option* to switch > > some or all of an app to a full-RAM DB as needed without rewriting the > > app. The query language abstracts/encapsulates/hides that detail way. > > This is another non sequitur deflection. Caching and whatnot is not > relevant to the point I was making. There is business a trade-off > between run-time performance and developer development time that every > shop must make. Sometimes greater developer productivity can justify > reusing the RDB paradigm when more efficient specific solutions are > available. > > However, my point was that those situations tend to map to CRUD/USER > processing. Once problems become more complex than format conversions > in UI/DB pipeline applications, performance becomes the dominant > consideration. I spent years solving large np-Complete problems on > machines like PDP11s and there was no contest on that issue; customers > simply would not spring for Crays in their systems but they would spring > for a marginal extra developer cost prorated across all systems. See above on "linear programming". A dedicated linear programming tool will indeed outperform a DB. A hammer specially designed for a certain kind of nail will outperform an off-the-shelf hammer. No news there. > > >>>>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. > >> > >>The solution needs a different view of the data that is tailored to the > >>problem in hand. So the RDB view needs to be converted to the solution > >>view (and vice versa). IOW, one needs to reformat the RDB data > >>structures to the solution data structures. > > > > > > This is called a "result set" or "view". Most queries customize the > > data to a particular task. Thus, it *is* a solution view. > > That formatting is cosmetic. The most sophisticated reformatting is > combing data from multiple tables in a join into a single table dataset. > I am talking about data structures whose semantics are different, > whose access paradigms are different, whose relationships are different, > and/or whose structure is different. IOW, there isn't a 1:1 mapping to > the RDB. For example, if my solution requires the data to be organized > hierarchically SQL queries can't do that. Yes it can. In fact, Oracle has vendor-specific idioms in its SQL just for trees. However, trees are often the wrong data structure for non-trival things anyhow. They are popular because they are conceptually simple, but in reality they bog down from a management standpoint because the real world is better classificed with sets, not trees 90+ percent of the time. Limits, and non-tree additions to IBM's IMS already demonstrated that. We don't need to relearn the lessons of the 60's. > > >>>>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. > >> > >>That's because you are in a CRUD/USER environment where P/R works quite > >>well. Try a problem like allocating a fixed marketing budget to various > >>national, state, and local media outlets in an optimal fashion for a > >>Fortunate 500. > > > > > > Again, I never said that DB's are good for every problem. I don't know > > enough about that particular scenario to propose a DB-centric solution > > and to know whether it is an exception or not. > > > > Unless you provide some specific use-case or detailed sceneria, it is > > anecdote against anecdote here. > > > > RDBMS are a common tool. The sales of Oracle, DB2, and Sybase are > > gigantic. > > Of course they are. They provide a generic, context-independent access > to stored data that any application can use. That's why they exist. > But that is beside the point. > > The issue here is where individual business problems should get solved. > My assertion is that is an application responsibility. For CRUD/USER > processing one can use the same data structures in the solution as in > the RDB so P/R as a software development paradigm works well. > Generally, though, one can't use the same data structures once one is > out of the CRUD/USER realm so P/R doesn't work very well. Again, it is a dissagreement out the size and range of where RDBMS don't do well. The special cases are fairly rare, but you claim them common. Most software out there is business applications. It is the biggest domain, perhaps even more than 50% of all software written. > >>> [...] > >>>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.) > >> > >>Why? That has nothing to do with whether a DBMS should execute dynamic > >>business rules and policies. This isn't an OO vs. P/R discussion, much > >>as you would like to make it so. > > > > > > Are you saying it is a UML-versus-RDB debate? > > Another deflection. How do you get from how complex report generation > software is to UML vs. RDB? The topic here has nothing to do with OO, > P/R, or UML. It is about the complexity of processing for CRUD/USER > applications vs. other applications. There is another part of this topic devoted to measuring complexity. No need to reinvent that debate here. If you claim biz apps are inharently "simpler", you will need to provide some kind of objective metric, or at least something besides a personal feeling. You seem like a well-educated person; I expect more from you than feelings and argument-from-authority. > > > H. S. Lahman (Note that I had to snip some context because the usenet system was complaining about size and I am too lazy to split this yet again.) -T-
From: Christian Brunschen on 23 Jan 2006 05:37 In article <1137996532.423030.167400(a)f14g2000cwb.googlegroups.com>, topmind <topmind(a)technologist.com> wrote: >(Part 1 of reply) > >> Persistent data is data that is stored externally between executions of >> an application. RDBs are a response to that need combined with a >> requirement that access be generic (i.e., the data can be accessed by >> many different applications, each with unique usage contexts). That's >> what DBMSes do -- they manage persistent data storage and provide >> generic, context-independent access to that data storage. > > >I disagree. You can use them that way, but I tend to view them as an >"attribute management system". They do well modelling "things" in the >real world (and virtual things) by keeping track of attributes of them. >They also provide important and useful services such as concurrency >management, joins (cross-referencing), sorting, and aggregation (sums, >counts, averages, etc.) Mere persistence does NOT have to include >things such as joins and aggregation, making one do them in app code >instead. > >Back in my desktop-DB days, I created a lot of temporary tables to do >things such as joins, filtering, and aggregation for task-specific >temporary uses. The results were not kept beyond the task/module. Thus, >I was using DB tools *without* any sense of "lasting". > >What would *you* call that? "Persistence" does not apply there. You are still using a persistence mechanis; you're just choosing to not use it for persistence. A file system is a persistence mechanism; lots of applications put data into temporary files, which they delete after they're done with them, sometimes because the available storage in the filesystem is larger than in main memory (Photoshop, I believe, used to do that, and maybe still does). This non-persistent use of the filesystem doesn't make a filesystem any less of a persistence mechanism. The relational model, and SQL, were developed specifically for persistent databases. You can use them in a non-persistent manner, but that is essentially using them contrary to their original intent and purpose. By the way, how do you create and destroy these temporary tables? i.e., does the dbms manage their lifecycle for you, creating them as necessary and removing them when you no longer need them, or do you have to perform either or both of those steps yourself? >> My point in this subthread is that such responsibilities are complicated >> enough in practice that one does not want the DBMS to also manage and >> execute dynamic business rules and policies. IOW, the DBMS should just >> mind its own store. [This thread has been a veritable hotbed of puns. >> I've probably made more in this thread than I've done in the last >> decade. B-)] > >I agree that code does some things better and DB other things, and one >uses them *together* in a Yin-Yang fashion. They compliment each other. Relational Databases and SQL are tools for the specific task of storing, accessing, modifying data - they are single-purpose tools (see definitions below). They are 'general-purpose' _within their specific area_, as they are not specific to any particular data access/storage/manipulation tasks, but they are 'general-purpose' _only_ within their _specific_ domain, which is the storage of data. A 'general-purpose' programming language is one that allows one to write solutions to essentially arbitrary problems using it, possibly with some specific exceptions (such as, 'python is a general-purpose programming language, but due to its interpreted nature, it shouldn't be used for writing interrupt handlers'). One thing to remember is that a RDBMS does _not_ do _anything_ that one can't do in code on one's own - they are essentially just a pre-written library, with a little domain-specific language as part of its interface - whereas on the other hand, _most_ of the things you can fo in _code_, _cannot_ be done in an RDBMS. [ ... deletia, as I know nothing about UML ... ] >> > Again, this gets into the definiton of "general purpose". I agree that >> > query languages are not meant to do the *entire* application, but that >> > does not mean it is not general purpose. File systems are "general >> > purpose", but that does not mean that one writes an entire application >> > in *only* a file system. It is a general purpose *tool*, NOT intended >> > to be the whole enchilata. >> >> Huh?!? If you can't write the entire application in it, then it isn't >> general purpose by definition. >> >> > A hammer is a general purpose tool, but that does not mean one is >> > supposed to ONLY use a hammer. You need to clarify your working >> > definition of "general purpose", and then show it the consensus >> > definition for 4GL. >> >> huh**2?!? A hammer is not a general purpose tool by any stretch of the >> imagination. > >Okay, then what is a "general purpose tool"? If I was going to put >together a tool box for a trip where the mission details are not given >ahead of time, I would certainly pack a hammer. Yes, but you wouldn't expect to be using the hammer _unless_ you encountered a problem that _specifically_ included nails. If you encountered problems that included only screws, you'd never touch it; you'd be using your screwdriver set instead. >Only an idiot would >not. No, it is not a one-size-fits-all tool, and I don't expect one. >Good apps don't need a one-size-fits-all language because they can use >yin-yang complimentary tools. *sigh* Time for some rudimentary definitions: single-purpose useful for a single purpose, for a specific task, only multi-purpose useful for a number of specific tasks, but only a limited number still general-purpose useful for most tasks in general, though possibly with some specific exceptions all-purpose useful for absolutely everything A hammer is _not_ a 'general-purpose tool', because it isn't intended or useful for general tasks, but specifically for beating nails into stuff. If it also has a back end that lets you pry nails out, it might be considered a 'multi-purpose' tool, but even that would be a stretch, because you're still only working on the 'nails' bit. Either way, it's not a 'general-purpose' tool by any stretch of the mind. Actually, there's a saying that's apt, and which I think that 'topmind' very clearly exemplifies: "If all you have is a hammer, everything looks like a nail" The point of which, of course, is precisely that a hammer is _not_ a general-purpose tool, but that if you are accustomed to working only with a specific limited toolset (and thus the associated set of problems it is intended to solve), there is a tendency to try to see all other problems as if theyy, too, were problems of that specific type. However, that is a fallacy, as there are problems which clearly don't fit into such a narrow mold. Even topmind's own comments above show that he is fundamentally aware of this: he says that a hammer is _one of_ the tools he would pack, so he recognizes that there are many more tasks that he might encounter, but for which a hammer is not a useful tool. But he confuses 'general-purpose' with 'one-size-fits-all': Those are _not_ the same. Of course, when it comes to computers, 'general-purpose' can frequently come very _close_ to being 'all-purpose' simply because there are very few problems that fall outside the 'general-purpose' area. Java is a 'general-purpose' language, because you can write all sorts of programms in it - from math-intensive scientific number-crunching, to data storage and access, to graphical user interfaces, to distributed systems, to ... etc. SQL _isn't_, because there are _vast_ areas of problems that SQL not just osn't intended to address, but simply _cannot_ address, however much you try to make it. The need for 'yin-yang-complementary' tools arises in cases where it it difficult to create multi-purpose or general-purpose tools: construction, woodworking, metalworking etc, are all places where it is difficult to create such tools. In computing, however, such tools abound: The computer _itself_ is a gener-purpose tool. Let us not forget, in fact, that today's digital stored-program computers are actually _general-purpose_ computers, as ooposed to earlier, single-purpose computers, that were available (and some still are!), such as for solving differential equations. Procedural, funtional, object-oriented languages are all _general-purpose_ tools for programming computers, for writing essentially arbitrary programs. SQL _isn't_. If it were, then why do database vendors create languages to extend or 'hook into' the database (Oracle's PL/SQL), or allow other languages to hook into the database (PostgreSQL allows perl and python, as well as others, I believe)? There would be no need - *if* SQL were a _general-purpose_ language - which it isn't. And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true. >> > Please clarify. Something can still be within a paradigm and be general >> > purpose. Further GP does not necessarily mean "all purpose", for >> > nothing is practially all purpose. While in computing, 'general-purpose' can quite frequently get reather close to 'all-purpose' (i.e., the set of specific problems that a 'general-purpose' language cannot solve can grow very small), there is a difference, yes; however, the difference between a single- or multi-purpose tool and a general-purpose tool is _also_ still there. Certainly, tools can be within a certain paradigm, and still be general-purpose. For instance, object-oriented languages are within the object-oriented paradigm, and are still general-purpose; likewise, functional programming languages (like Haskell) are within the functional paradigm, and are still definitelly general-purpose languages. However, that is more because 'object-orientation' and 'functional programming' are both paradigms specifically for general-purpose programming. The relational data model is specifically intended for data storage and access; it isn't intended to address anything beyond that. Any language that is based on that specific model is going to be working within the limits of what that model is intended to address. So, for instance, SQL is great at modifying and accessing data in a relational database ... but is not useful for anything else, because that is outside the scope of its purpose. So, whereas SQL is a 'general-purpose' language _within the scope of database access_, it is a _single-purpose_ language if you view it from a wider scope than that. >> SQL is designed around the RDB paradigm for persistence. It can't be >> used for, say, accessing lines in a text flat file because the text file >> is not does organize the data the way SQL expects. So SQL is not a >> general purpose interface to stored data. Apropos of your point, >> though, SQL is quite general purpose for accessing /any/ data in a >> uniform way from a data store _organized like an RDB_. > >Well, I agree that SQL is probably not a very good way to reference >free-form text. However, just because it is not good for everything >does not mean it is not general purpose. Again, NOTHING is good at >EVERYTHING. Do you claim that there is something that is good at >everything? No? I didn't think so. Actually, for programming _everything_, you can always use machine code. After all, that is what everything else comes down to: Everything that you can do on a computer, you can do in machine code. In order for a programming language to be 'all-purpose', it would only have to be able to express everything you can express in machine code. There are a lot of languages that come close - those are usually 'general-purpose' languages. SQL does _not_ come close, due to inherent limitations in SQL. >By the way, I have created tables similar to this: > > table: textFile > -------------- > fileID > ParagraphID > SentenceID > token (word or punctuation) > tokenType (punctuation, word, non-printable, etc.) > >(Non-printable characters are represented in Hex notation.) > >It can be done. But then you have taken what was an arbitrary stream of characters and already broken it up into a representation that better suits your specific model. And I suspect that the code that would read an arbitrary stream of characters and puts it into your tables, was written in something _other_ than SQL - because SQL is not good at the free-text processing that is necessary to get the data into a tabular format, because SQL is not general purpose. [ ... more deletia regarding UML ... ] >> If the persistence is an RDB, then the subsystem implementation will >> <probably> use SQL. If the persistence is flat text files, it will use >> the OS file manager and streaming facilities. If it is clay tablets, it >> will use an OCR and stylus device driver API. That allows me to plug & >> play the persistence mechanisms without touching the application >> solution because it still talks to the same interface regardless of the >> implementation of the subsystem. > >Flat files don't have near the power. That is a poor analogy. RDBMS are >MORE than persistence. Say it over and over until it clicks in. Just >because YOU use it ONLY for persistence does not make it the only way >to build systems, just the bloated reinvent-the-wheel way JUST so that >you can claim UML purity. Everything that an RDBMS does, can be implemented in a 3GL using flat files for the low-level persistence layer. How do I know this? Because that is one way to implement a RDBMS. The relational model offers a useful, unified interface to data storage and retrieval, with well-defined semantics - in such a way that it is a very good solution to a specific problem; it is in fact, a 'general-purpose' solution _within its scope_ (much like a hammer is a general-purpose tool for hitting things, and isn't inherently limited to specific types of nails). But viewed from outside its scope, SQL only addresses that particular problem, and thus isn't general-purpose. The power of the combination of flat files and a 3GL, is greater than the power of SQL - because the combination can implement all that SQL can, _and much more besides_. [ ... more UML deletia ... ] >> > And as somebody pointed out, one can use SQL on flat files too. ODBC >> > drivers can be created to hook SQL to spreadsheets, flat files, etc. >> >> Only if the data is organized around embedded identity and normalized. >> Even then such drivers carry substantial overhead and tend to be highly >> tailored to specific applications. IOW, you need a different driver for >> every context (e.g., a spreadsheet) and then it won't be as efficient as >> an access paradigm designed specifically for the storage paradigm. > >So? What is the grand alternative? Of course different "devices" are >going to need different drivers. That is a given. There is no >one-size-fits-all driver. I have no idea what alternative you are >envisioning, but it is probably in the category with unicorns and >bigfoot. And these 'drivers' would be written in ... ? something like a 3GL, procedura, funtional or object-oriented, usually. You can't, for instance, write a flat-file database driver in SQL, can you? SQL, RDBMS, are all about offering a specific view of data, and a specific standard interface to that data, to accessing it and modifiing it (insertion, deletion, updates). This solves the 'data storage' problem for a large number of aplications, and is, as such, a 'general-purpose data storage' solution - but it addresses _only_ the data storage/retrieval problem, whereas most other problems also have many other aspects that need to be solved - which SQL can't do. Best wishes, // Christian Brunschen
From: H. S. Lahman on 23 Jan 2006 12:35 Responding to Jacobs... >>>Why do you keep saying "persistence"? I don't think you get the idea of >>>RDBMS and query languages. Like I said, think of a RDBMS as an >>>"attribute management system". Forget about disk drives for now. Saying >>>it is only about "persistence" is simply misleading. >> >>Persistent data is data that is stored externally between executions of >>an application. RDBs are a response to that need combined with a >>requirement that access be generic (i.e., the data can be accessed by >>many different applications, each with unique usage contexts). That's >>what DBMSes do -- they manage persistent data storage and provide >>generic, context-independent access to that data storage. > > > > I disagree. You can use them that way, but I tend to view them as an > "attribute management system". They do well modelling "things" in the > real world (and virtual things) by keeping track of attributes of them. > They also provide important and useful services such as concurrency > management, joins (cross-referencing), sorting, and aggregation (sums, > counts, averages, etc.) Mere persistence does NOT have to include > things such as joins and aggregation, making one do them in app code > instead. The things you are talking about are pure static manipulations of data within constraints defined by intrinsic, static data relationships. That's what RDBs do. That sort of thing /should/ be in the DBMS because it is part of generic (problem-independent) data storage access. The issue in this subthread is putting business logic for specific, dynamic problem solutions in the DBMS -- specifically stored procedures that the DBMS executes automatically when the data store is modified. >>>>>>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. >>>> >>>>4GLs get around it because they are independent of /all/ computing space >>>>implementations. >>> >>> >>>I am not sure UML qualifies as 4th Gen. Just because it can be >>>translated into multiple languages does not mean anything beyond Turing >>>Equivalency. C can be translated into Java and visa verse. >> >>A UML OOA model can be implemented unambiguously and without change in a >>manual system. In fact, that is a test reviewers use to detect >>implementation pollution. The OOA model for, say, a catalogue-driven >>order entry system will look exactly the same whether it is implemented >>as a 19th century mail-in Sears catalogue or a modern broswer-based web >>application. That is not true for any 3GL. > > > One can execute Java code by hand also. If you follow the spec, it > should always come out the same. (There may be minor vendor differences > due to errors or fuzzy areas in the spec, but this is true of any > non-trivial tech language, including UML.) It's not the execution model. It is what you have to specify when you write the Java code and it is the intrinsic structural decisions (e.g., scoping rules based on 3GL block structuring). >>>>However, that's not the point. SQL is a 3GL but comparing it to Java is >>>>specious because Java is a general purpose 3GL. >>> >>> >>>Again, this gets into the definiton of "general purpose". I agree that >>>query languages are not meant to do the *entire* application, but that >>>does not mean it is not general purpose. File systems are "general >>>purpose", but that does not mean that one writes an entire application >>>in *only* a file system. It is a general purpose *tool*, NOT intended >>>to be the whole enchilata. >> >>Huh?!? If you can't write the entire application in it, then it isn't >>general purpose by definition. >> >> >>>A hammer is a general purpose tool, but that does not mean one is >>>supposed to ONLY use a hammer. You need to clarify your working >>>definition of "general purpose", and then show it the consensus >>>definition for 4GL. >> >>huh**2?!? A hammer is not a general purpose tool by any stretch of the >>imagination. > > > Okay, then what is a "general purpose tool"? If I was going to put > together a tool box for a trip where the mission details are not given > ahead of time, I would certainly pack a hammer. Only an idiot would > not. No, it is not a one-size-fits-all tool, and I don't expect one. > Good apps don't need a one-size-fits-all language because they can use > yin-yang complimentary tools. You're deflecting again. Your assertion was that SQL was equivalent to Java. My response was that Java is general purpose, which it clearly is because I can solve any problem solvable on a computer with it, while SQL is not, which it isn't because certain classes of computer problems simply can't be solved with it. >>>>SQL represents a >>>>solution to persistence access that is designed around a particular >>>>model of persistence itself. So one can't even use it for general >>>>purpose access to persistence, much less general computing. >>> >>> >>>Please clarify. Something can still be within a paradigm and be general >>>purpose. Further GP does not necessarily mean "all purpose", for >>>nothing is practially all purpose. >> >>SQL is designed around the RDB paradigm for persistence. It can't be >>used for, say, accessing lines in a text flat file because the text file >>is not does organize the data the way SQL expects. So SQL is not a >>general purpose interface to stored data. Apropos of your point, >>though, SQL is quite general purpose for accessing /any/ data in a >>uniform way from a data store _organized like an RDB_. > > > Well, I agree that SQL is probably not a very good way to reference > free-form text. However, just because it is not good for everything > does not mean it is not general purpose. Again, NOTHING is good at > EVERYTHING. Do you claim that there is something that is good at > everything? No? I didn't think so. This is just an example of deflecting through deliberate obtuseness. You are trying to recast the issue in terms of relative "good". SQL simply cannot access individual lines in a flat text file. Flat text files are a valid persistence mechanism. QED. > > By the way, I have created tables similar to this: > > table: textFile > -------------- > fileID > ParagraphID > SentenceID > token (word or punctuation) > tokenType (punctuation, word, non-printable, etc.) > > (Non-printable characters are represented in Hex notation.) > > It can be done. Where to you get the ParagraphID and SentenceID? How do you maintain it when paragraphs are inserted and deleted? You can parse the file and assign your own number identities based on sequence in the file and you can manipulate those for additions and insertions. However, that requires changing the identity keys for paragraphs and sentences that are, themselves, unchanged. IOW, you are violating the RDM notion of unique /entity/ identity. Then how do you keep track of those changes between application executions? Since the identities are not stored in the file, that becomes a problem. You could create your own file to keep track, but then you are modifying the data store to solve the problem by making the flat text file look like an RDB. If there is only one application that cares, it can read the file and renumber everything at startup. But that doesn't work in multi-user contexts where things have to be coordinated (e.g., two applications need to share information about individual paragraphs and sentences). IOW, it is a one-shot solution, not a generic data model like the RDB/SQL paradigm. However, these problems just reflect the more general issue that there is no way for your software user to tell you to extract a particular paragraph or sentence without providing the entire text of the paragraph or sentence. That is, there is no way for the user or anyone outside your program to know your ParagraphIDs and SentenceIDs when there are insertions and deletions. >>>>>>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".... >>>> >>>>Try using SQL vs. flat files if you think it is independent of the >>>>actual storage mechanism. (Actually, you probably could if the flat >>>>files happened to be normalized to the RDM, but the SQL engine would be >>>>a doozy and would have to be tailored locally to the files.) SQL >>>>implements the RDB view of persistence and only the RDB view. >>> >>> >>> >>>How is that different than ANY other interface? You are claiming magic >>>powers of UML that it simply does not have. >> >>There is a distinction between describing an interface and designing its >>semantics. UML is quite capable of describing the semantics of any >>interface. Deciding what the semantics should be is quite another thing >>that the developer owns. >> >>When I have a subsystem in my application to access persistent data, >>that subsystem has an interface that the rest of the application talks >>to. That interface is designed around the rest of the application's >>data needs, not the persistence mechanisms. It is the job of the >>persistence access subsystem to convert the problem solution's data >>needs into the access mechanisms de jour. > > > I could wrap SQL calls in functions, like that PinkScarf example I > already gave. But unless the same kind of thing is called multiple > times, it is just code bloat. Query languages can be compact in many > circumstances. Putting bloated single-use wrappers around it gets you > nothing except more code. Thus, I *can* play the same game via function > wrappers if need be. That's not the point. In your example there is no semantic shift; you are just changing the syntax. >>If the persistence is an RDB, then the subsystem implementation will >><probably> use SQL. If the persistence is flat text files, it will use >>the OS file manager and streaming facilities. If it is clay tablets, it >>will use an OCR and stylus device driver API. That allows me to plug & >>play the persistence mechanisms without touching the application >>solution because it still talks to the same interface regardless of the >>implementation of the subsystem. > > > Flat files don't have near the power. That is a poor analogy. RDBMS are > MORE than persistence. Say it over and over until it clicks in. Just > because YOU use it ONLY for persistence does not make it the only way > to build systems, just the bloated reinvent-the-wheel way JUST so that > you can claim UML purity. It is not an analogy. I am describing different /concrete/ persistence mechanisms. If I need information from a Windows .ini file, I don't have a choice about the persistence mechanism. But I don't want my application problem solution to have to be concerned about that constraint; I want the problem solution to be indifferent to what persistence mechanism is used. That separation of concerns ensures better maintainability. >>IOW, the semantics of the interface to the subsystem is /designed/ at a >>different level of abstraction than that of the subsystem >>implementation. > > > > Bull. UML is often a LOWER level of abstraction because it can take > much more code/language to specify the same thing. Another example of an utterly absurd assertion whose sole purpose is to drive an opponent who knows better crazy. I know you better so I'm not going to bite by dignifying such nonsense with a response. However, it is annoying enough that you would still _try it on me_ when you know I understand your game that I'll sign off here. Ta-ta. ************* 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 23 Jan 2006 16:45
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: > > "topmind" <topmind(a)technologist.com> writes: > > > SQL is close to being Turing Complete. > > > > In other words, SQL is not Turing complete. That addresses > > your original question: > > No, because I never claimed "all". You asked "But how are tables less close to the domain than classes, methods, and attributes?" The answer is, they lack behavior. The most common language for manipulating tables is SQL and it is not as powerful as general purpose OO languages. > > > Plus, OO is usually crappy at modeling behavior, at least in the > > > biz domain. OO is only nice when things split up into nice > > > hierarchical taxonomies. Most things don't in reality, so what > > > is left is a mess. > > > > You've been challenged on this assertion in the past and > > failed to defend it. The history is available via Google for > > anyone to see. Unless you've got more to back up your nonsense > > than you did before, repeating this is intellectually dishonest. > > My crappometer crapped out. The burden is not on me to prove that OO > is better. It is on you. The default is equal or unknown. Not only are you making the same unfounded claim as you have repeatedly in the past, you are attempting to squirm in exactly the same way. You made the claim, you have the burden of proof. Put up or shut up (we should be so lucky). > > > Almost all of these have a fair amount of disagreement among OO > > > proponents. Check out c2.com. > > > > Interesting. I provide explicit examples of what are > > generally accepted as good OO principles and practices and you > > refer to a random website. If you have real documentation of > > getter/setter proliferation being an accepted OO technique, > > produce it. > > Do you have the opposite? Provided right above. Here it is again, for your convenience: Josh Bloch recommends immutability explicity in "Effective Java" and gives solid reasons for his position. Proliferation of getters and setters violates encapsulation, one of the defining characteristics of object technology. Some research will show you that OO designs focus on behavior, not state. You should also check out the Law of Demeter and similar guidelines that provide further evidence that excessive use of accessors and mutators is not good OO form. Now, where is your evidence that proliferation of accessors and mutators is considered good OO practice? > > The existence of legacy systems is just one reason why your > > suggestion of using '"big-iron" RDBMS such as Oracle or DB2' > > cannot solve the complex problems of large organizations. > > I am not following you here. If some of the processing has to be on > legacy systems then it has to be on legacy systems. The introduction > of a DB does not change that. Exactly. You stateed that: I would note that a lot of the issues you mentioned, such as performance, scalability, resiliency, and recoverability can be obtained by purchasing a "big-iron" RDBMS such as Oracle or DB2. This is simply not the case in real world systems. The existence of legacy systems is just one reason why your "just use a big database" approach won't meet NFRs such as performance, scalability, resiliency, and recoverability. > > > It depends on the kind of business. If the vast majority of > > > operations/tasks needed are per location, then regional > > > partitioning works well. If not, then a more centralized > > > approach is needed. For example, airline reservation and > > > scheduling systems would make a poor candidate to partition by > > > location because of the interconnectedness of flights. However, > > > individual stores in a big franchise can operate most > > > independently. > > > > Your lack of experience with large, complex systems is > > showing, again. > > You always claim this. Offer evidence that your alternative is > better instead of belittling people without evidence. That is rude > and bad debating. Even a chimp can claim he/she is smart and a > know-it-all. The hard part is demonstrating it. As you've shown. The point here is that statements like the one above indicate more about the limited types of systems to which you apparently have some minimal exposure than they do about good software development practice. Experience in this newsgroup has shown that attempting to educate you about software outside of your tiny box is a waste of time. Hence, I simply point out when you are saying more than you think you are, and move on. > > > > > "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. > > > > > > I see no mention of ACL's there. > > > > That's my point. > > So if Mr. Schneir does not mention it, it is no good? I'll type more slowly. There is no mention of ACLs in the references I provided. The references I provided show how some important security issues are addressed. This demonstrates that your claim that '"Security" is mostly just massive ACL tables.' is nonsense. Were any of those words too big? > > > > CRUD applications are, however, not particularly complex > > > > as software systems go. Your claims otherwise indicate a lack > > > > of experience with anything else. > > > > > > Again, please use evidence to prove me wrong instead of > > > patronizing insults. It is a bad habit of yours. > > > > How is that patronizing? It's a simple statement of fact. > > There is a reason why the CRUD work is typically given to new > > hires and junior developers. > > You have a strange sense of biz apps. You have a nasty tendency of equivocating between "CRUD applications" and "biz apps". > > If you're seriously suggesting that CRUD applications are > > equal in complexity to compilers, telco OSS/BSS, MRP/ERP, or risk > > analytics, just to pull a few examples off the top of my head, > > then that reflects more on your experience than on the veracity of > > your claim. > > Easier domain to learn, yes. Less complex, no. I stand by that > unless you can come up with a decent measurement for > complexity. Personal opinions are a dime-a-dozen. Evidence backing > such opinions is rare, and certainly in the vacinity of you. The two > candidate metrics proposed: code bulk and automatability, show biz > apps not be measurably simpler. Considered technical views of experienced software developers are valuable, especially for other developers with the experience to assimilate those views. You demonstrate your inexperience by repeatedly taking positions like the one above, which boil down to "I am unable or unwilling to understand your position, therefore mine is equally valid." Does that make you feel all warm and fuzzy inside? > > > > On the other hand, there are some delightfully complex > > > > software systems that consist of only a few hundred lines of > > > > code. Functional languages seem especially good for this. > > > > See one of Peter Norvig's books for a few examples. > > > > > > Most FP demonstrations of such are "toy" or "lab" examples. > > > > Dismissing out of hand systems of which you know nothing. That's > > a bad habit of yours. > > I gave them a chance to strut their stuff. If they can't strut > right, it ain't my fault. Yeah, I can see how systems like Macsyma, RAX (controlling Deep Space 1), Orbitz, the scheduling system for Gulf War 1, countless expert systems, electronics layout, and CAD systems, just off the top of my head, aren't too impressive. Kent Pitman put it best: "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." All toys, of course. > Hey, weren't you blown away by others on your claim that > "relational" was mostly about links? You never even admitted > defeat. Stuburn to the stub you are. No, that wasn't me. I suspect that either a) you know that or b) you have so little integrity that you are willing to make false claims to score rhetorical points in your own mind. Try showing some intellectual honesty and either provide some evidence or retract your false claim. 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) |