Subj : Re: Change Patterns (was: Polymorphism sucks) To : comp.programming,comp.object From : rem642b Date : Wed Aug 10 2005 12:26 am > From: "topmind" > the closest approach to the Ultimate Business Rule Machine that I > have seen is a RDBMS. About ten or so years ago I read a book about SQL and thereby got a general idea of it, basically COBOL-style fixed-length fixed-format records stored in huge arrays on disk. I decided it was too limiting for my uses which typically had hugely variable length data fields. My only exposure to a real live RDBMS was within the past year, when our Java classes had us play with one, MicroSoft ACCESS on the campus machine and CloudScape/Derby on my Linux laptop that one of my Java instructors gave to me in lieu of posting it for free on eBay. Do you know of any really good text/html document online which would give me a more complete idea of what such a thingy might be used for beyond storing the fixed-length fixed-format records that I've seen it used with? I need to get a better "feel" for what good it is. For all of my applications to-date, s-expressions seem better, since they can handle arbitrary-length fields within arbitrary-organzed records, and can easily nest records via pointers of various kinds (direct nesting of lists within single s-expression, cross-references to named globals, cross-references to named tags within single structure, external references by filename or URL, etc. Or have you written anything like that yourself? > I wish they would release dynamic RDBMS. The static Oracle model is a > bit limiting. Would I be correct to guess that both MicroSoft ACCESS and CloudScape/Derby are Oracle model, and that I've never seen any dynamic RDBMS? Do you know of any online document (usascii/html) that tells the difference, or if not then could you summarize the difference? > only once out of several dozens, perhaps hundreds, of projects I > worked on did we have to go back to flat files. Would hierarchial lists as in s-expressions (on disk) and nested linked lists (in main memory) count as "flat files" per your usage of the terms? In all my experience I never felt the need to use RDBMS instead of just sticking with either s-expressions or HTML whenever I needed something logically non-flat. Of course I don't have access to any RDBMS on my Unix shell account nor on my Macintosh, only on my Linux laptop and the whole machine runs a lot slower when the CloudScape server is running, so I am disinclined to make any serious use of it. So I take it you've always had RDBMS available whereever you worked in all your years, unlike me where I never had any RDBMS available where I ever worked. Actually the main usage I can see for RDBMS is data synchronization between processes that are running in different virtual machines but all talking to the same RDBMS/SQL/ODBC server with access to shared databases. I wanted to make sure two different programs didn't try to increment the master sequence number at the same time, so I set up a "Lock" database whereby any process can ask the RDBMS to add a Lock record with a certain value as the unique key, and if successful then the process knows that no other process can have that same key at the same time, hence that one process has unique access to whatever activity is associated with that unique key, in this case right to compute the maximum plus one of sequence numbers within another table and generate a new record with that guaranteed new sequence number. Since I was on Linux, I might have used standard Unix lock files instead, but using a lock record in a database was easier to program without making any mistake, and also since I was developing on Linux but then porting to Windows, and I had no idea how to do lock files on Windows, it made sense to do it once with the database lock table instead of trying to do it separately in system dependent manner for each of Linux and Windows. > I have never seen a software engineering book that looks carefully at > change patterns and their probabilities before offering solutions. > They skip a big step and start with a lot of bad or unproven givens. It sounds like *you* should write that book. Perhaps start with an informal "book" as a Web site to get feedback from people like myself who might appreciate it and people like the unknown person you were responding to (you didn't attribute the text you quoted, and the new Google Groups doesn't provide any way to see where in the thread tree your article is located in order to back up in the tree to find what article you were replying to) who really seems to need your advice. Why you? Because you really deeply understand and appreciate the need for such a book and the comparitive shoddyness of all currently existing books you've seen before. Only somebody who really understands the need for something new can invent it. (As I invented linked frames of information online in 1970-71 after having seen harccopy "programmed texts" and the AutoTutor machine a few years previously, and Richard Stallman got the same idea about the same time, by coincidence both of us implementing our ideas within the framework of an existing text editor, me using SOS (Son Of Stopgap), RMS using EMACS/TECO.) Finally more than ten years later Apple converted our ideas into HyperCard, and then about ten years after that somebody invented HTML and the Web using those same ideas. So anyway, why don't you start a hyper-book tutorial for what you consider better than state-of-art software engineering, and send me the URL as soon as you have even one page of introduction written so that I can make sure your HTML stuff is lynx-compatible before you invest too much work in it? > We need to go back to square one to find, document, and clarify the > nature of change first, and THEN worry about writing change-friendly > software. Do you have any actual case histories of change that aren't confidential at the places you've worked, so that you could detail them as examples in your book? I like tutorials that give a brief conceptual idea of what will be presented, then give some examples to illustrate the idea, ... Hmm, I think it must be bedtime because I'm getting into silly mode. The title of your book should be "Refactoring Made Simple" if you can get permission from the copyright owner on that original series of books. But not "Refactoring for Dummies"!! That book series always pissed me off. The reason why I suggest "Refactoring Made Simple" is because refactoring is what you must do when there is too much change to be accomodated by exactly the program structure you already had, but your idea seems to be to write your program in such a flexible non-hierarchial way that it's relatively easy to refactor to accomodate any new change, even major changes. So your software-engineering meta-methodology really does set up circumstances such that refactoring is "simple" or "easy". .