Post #70,919
12/26/02 11:43:47 AM
|
you are not weighing the whole kitten kabootal
Look your control tables are just replicating what the OO languages do for you automatically.
You mean:
eval(rs.action)
instead of
thing.action()
A very minor thing to fuss about. Viewing, typing, filtering, etc. the same info in tables is 10-times easier for me. The same thing in code is like the difference between reading a bus schedule on a browser (rendered) versus reading it as HTML code (with TABLE and TD-like tags).
If you fully normalized the actions into tables you'd have something like a class method dictionary.
What specificly is un-normalized? I know how to normalize tables. I can do it in my sleep.
only you do it in the database the hard way and OO developers have languages that take care of the grunt work automatically and leave the behavior in code libraries.
Tablizing it is actually *less* code because you don't repeat the equivalent of cell labels over and over. The "packaging" of the cell contents is not repeated over and over because the database factors that into its internal field dictionary. Plus you can get different views by issuing queries or dragging columns without upsetting any code. Your view is not limited to that envisiond by the original programmer. You can transcend them.
All it is costing me is an "Eval", and saving dozens of lines of packaging code in return. Seems like a bargain to me.
________________
oop.ismad.com
|
Post #71,052
12/27/02 2:42:14 AM
|
Kitten Kabootal?? Is that some stripper you know?
It's "kit and caboodle", Bryce.
What is your version of the lyrics to the "Flintstones" theme?
-drl
|
Post #71,058
12/27/02 3:58:27 AM
|
Don't I wish :-)
________________
oop.ismad.com
|
Post #71,072
12/27/02 10:30:01 AM
|
I know her! great smile and a grinning kabootal!
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,435
12/30/02 7:49:04 AM
|
Sure I am - but you're not
From your own site you use this example: \r\nModem \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\ndial | \r\nsend | \r\nrecv | \r\nhangup | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n14000 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nHayes 20a | \r\n1200 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| UNIX | \r\nUSR Z20 | \r\n300 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n1200 | \r\n2400 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n4800 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Mac | \r\nKLM 10 | \r\n1200 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Etc.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n \r\n \r\nYeah fine. OK, this is what we would call an instance based approach. You have polymorphism. This is really good. And it is very OO. Because you have information hiding. You have an abstract interface called modem. It responds to dial, send recv, hangup. Its exactly the same as if you had said in Java:\r\n \r\npublic interface Modem\r\n{\r\n public void dial();\r\n public void send();\r\n public void recv();\r\n public void hangup();\r\n}\r\n\r\nIOW, you can take any modem and say something like modem.dial (or eval (modem.dial) its the same right?).\r\n \r\nSo this is actually a very cool thing you've done and I see why you like it. Its analagous to what the IOCTL type stuff on Unix does - where files and sockets respond to the same interfaces via function lookup tables in C. Its still just a dispatch table. \r\n \r\nIncidentally - a row in this table isn't any different than a dictionary. And a cursor in this table isn't any different than an iterator on a list of rows (which are dictionaries key'd by column name). But I digress.\r\n \r\nIf you look at the data in this table, you begin to see that there is likely to be a bunch of duplicated code. I'll bet send and recv are the same regardless of modem speed. Furthermore, a lot of modems are Hayes compatible and use the same commands. There are definitely different commands for setting connect speed otoh, but hangup is the same pretty much for all Hayes compatibles.\r\n \r\nSo maybe its worth it to normalize this and move all the common methods to a table so you can cut down on duplicate storage. \r\n \r\nModem \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\nIsA | \r\n \r\n\r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\n\r\nA | \r\n \r\n\r\n\r\n| UNIX | \r\nHayes 20a | \r\n14000 | \r\n52000 | \r\nA | \r\n \r\n\r\n\r\n| Win-9x | \r\nHayes 20a | \r\n1200 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| UNIX | \r\nUSR Z20 | \r\n300 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n1200 | \r\n2400 | \r\n\r\nA | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n4800 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| Mac | \r\nKLM 10 | \r\n1200 | \r\n52000 | \r\n\r\nA | \r\n \r\n \r\n \r\nModem Implementation Table \r\n \r\n\r\n| type | \r\ndial | \r\nsend | \r\nrecv | \r\nhangup | \r\n \r\n \r\n\r\nYou still get some duplication here if every modem uses the same hangup - but if two modems use the same code regardless you don't duplicate the whole set of procedures. So its a little better but not great.\r\n \r\nIf instead you flip it over and create an implementation table,\r\n \r\nImplementations \r\n \r\n| id | name | implementation |
|---|
\r\n \r\n\r\nthen create a definition table for grouping the implementations\r\n \r\nThings \r\n \r\n\r\nand a join table for many to many \r\n\r\nThingImplementations \r\n \r\n| ThingId | ImplementationId |
|---|
\r\n \r\n\r\nYou can arrange things so there is exactly no duplication of implementation scripts anywhere in your database.\r\n \r\nNow you have something like this:\r\n \r\nModemData \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\nThingId | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\nA | \r\n \r\n \r\n \r\nThings \r\n \r\n| id | name |
|---|
\r\n| A | HayesUnixModem | \r\n \r\n \r\nImplementations \r\n \r\n| id | name | implementation |
|---|
\r\n| 1 | dial | [implementation] | \r\n| 2 | send | [implementation] | \r\n| 3 | recv | [implementation] | \r\n| 4 | hangup | [implementation] | \r\n \r\n \r\nThingImplementations \r\n \r\n| ThingId | ImplementationId |
|---|
\r\n| A | 1 | \r\n| A | 2 | \r\n| A | 3 | \r\n| A | 4 | \r\n \r\n\r\nAnd to get modem behavior - you join ThingId with Thing.id through ThingImplementation and get the Implementations. Full normalization with no wasted space. Of course, its expensive to go to the database this often - so you'll probably want to read the Implementation tables and Thing defininition tables into memory and just keep them there, like you do with reference tables of code values.\r\n \r\nThere's one other thing thats potentially a bit of a drag. Defining a new Thing is maybe a lot of work - so we add a ParentID to Thing and aggregate methods by dragging in the Thing and all its parent scripts as well. When two scripts have the same name, we make the child thing's win. This way, you always define a new thing in terms of an old thing. This results in the potentially expensive self-join but guarantees minimal space expense if there's any similarity at all among things.\r\n \r\nOnce you get to this point - you've completely reinvented the OO runtime system in your database. \r\n \r\nSo your system, through normalization and evolution, will likely evolve into an OO system. You've got a good start on one.\r\n\r\n I am out of the country for the duration of the Bush administration.\r\nPlease leave a message and I'll get back to you when democracy returns.
|
Post #71,478
12/30/02 10:44:45 AM
|
Wow! If this woun't get through, nothing can.
My hat is off to you, Sir. Most lucid explanation ever.
--
We have only 2 things to worry about: That
things will never get back to normal, and that they already have.
|
Post #71,547
12/30/02 4:44:33 PM
12/30/02 6:09:32 PM
|
LISP - Lists + Relational
Yeah fine. OK, this is what we would call an instance based approach. You have polymorphism. This is really good. And it is very OO.
In that case LISP invented "polymorphism" because it pioneered the idea of "code in data structures". TOP is simply an extension of the idea of LISP's list into relational tables. IOW, "relational LISP" instead of the older "list-based LISP". The data structures have simply grown up.
Full normalization with no wasted space.
Most existing relational implementations don't use fixed-cell allocations, thus there is little or no "wasted space" for empty cells. The wasted space concerns are based on outdated technology.
Of course, its expensive to go to the database this often......you'll probably want to read the Implementation tables and Thing defininition tables into memory and just keep them there
Database != Slow
I would note that most XBase implementations from about 1992 on used caching of some sort so that smaller tables *were* in RAM. (I am sure the new stuff does it also, but harder to directly varify.)
Besides, such tables may be used for code generation if including a table engine is not practical (such as embedded systems). IOW, it can potentially be used to manage the source code rather than be used "live". Plus, I don't see a need to have lots and lots of repeated lookups anyhow.
There's one other thing thats potentially a bit of a drag. Defining a new Thing is maybe a lot of work - so we add a ParentID to Thing and aggregate methods by dragging in the Thing and all its parent scripts as well. When two scripts have the same name, we make the child thing's win. This way, you always define a new thing in terms of an old thing.
What you already presented already has plenty of indirection. I don't see why we need this also. Besides non-trivial "inheritance" is best set-based instead of tree-based. The real world changes in a graph-like fashion, not trees.
To share some implementation, a simpler, but slightly less flexible approach could have a schema like:
Table: ModemDrivers
-------------------
ModemID (or perhaps DriverID)
OS
Model
SpeedLow
SpeedHigh
Dial
Send
Recv
Hangup
DefaultID
This is pretty much the original table plan with the added DefaultID and ModemID (to supply a unique reference). The Default ID could point to either another table of defaults, or point to another record within the same table. It would use the default implementation if a given implementation cell is blank. Yes, I know, it would then be "tablized inheritance", but that is the way I like my inheritance.
I am perfectly aware of the similarities between OO and Control Tables. The bottom line is that it is easier to manage such stuff in tables than in programming code. You can see patterns in tables easier than in code. Part of the reason for this is tables allow you to eye the info by both row and column at the same time. A class cannot give you this. It is like the difference between looking at an HTML table (made with "table" tag) rendered in a browser versus the raw HTML code. Classes are like the latter.
Second, one can issue queries against such table(s) to filter and project one's view to customize it for a particular need. Relational has pretty much proven superior WRT queries compared to the network-DB-like model of OO classes or a bunch of grep-like unix/perl utils. (At the very least, grep-like approaches don't easily scale up to billion+ records and multiple users, and nobody wants to learn nor switch between two query approaches depending on the size of the collections.)
Also, the "inheritence" can be set-based or made more advanced than mere OO trees. Multiple inheritance (set-like in some ways) gets really messy for such, and is still limited. For example, the "share pattern" for say the Hangup operation may not match that of the Send operation. Sure, with enough class indirection such could be obtained, but I would rather manage a bunch of cross-references using tables instead of application programming code.
Further, since my dispatching is somewhat self-implemented, I could assign priorities to default lookups so that if a given default driver is not found, then it looks for the next largest in rank. OO pretty much supplies you with "dumb" inheritance that requires a Meyerian Discontinuity Fault (big-ass overhaul) to make the transition to such "fuzzy inheritance". On that same webpage, you can see my "UI event table" that has event priorities/sequences. I invite you to show how one would manage such in OOP. Who knows, they may even name a GOF pattern after you. (Yes, I agree it is probably possible, just not disirable.)
In other words, I can get sophisticated dispatching simply by adding to what I already have.
Incidentally - a row in this table isn't any different than a dictionary.
Relational requires that the full set of (possible) columns is known for a given table. This allows sophisticated operations and optimization. (I don't know if there is an equivalent to relational theory for per-row columns. This generally seems to hark back to the fallen Network Databases of the 60's with their tangled navigation webs. Nobody found a way to "purify" them.)
Summary of advantages:
1. Row-and-column view is more concise and makes it easier to notice patterns. (At least for my eyes.)
2. Relational query ability allows me to get just about any view I want. Joins, filters, etc.
3. I can incrementally obtain sophisticated dispatching, such as set-based dispatching and priority ranking.
If it was small and unchanging, then OOP inheritance may be just fine. Then again if it is small and unchanging, then so would a case/switch statement (except for stupid languages that need a Break clause).
Thank you for your response and the effort you put into it. I appreciate it.
________________
oop.ismad.com
Edited by tablizer
Dec. 30, 2002, 06:09:32 PM EST
|
Post #71,600
12/30/02 8:15:27 PM
12/30/02 8:50:07 PM
|
Gets you Smalltalk
In that case LISP invented "polymorphism" because it pioneered the idea of "code in data structures".
Maybe, can't say. I suspect you are right. I know that LISP and Smalltalk were like Yin and Yang influencing each other - CLOS was inspired by Smalltalk who's VM, GC, and code as data were inspired by LISP and on and on...
Most existing relational implementations don't use fixed-cell allocations, thus there is little or no "wasted space" for empty cells.
I'm not talking about wasted space for empty cells - I'm talking about it for duplicate copies of implementation rather than using inheritance. If every record in your modem table uses the same hangup routine, then you have redundant data.
Database != Slow
Compared to memory - there's a factor of several orders of magnitude.
What you already presented already has plenty of indirection. I don't see why we need this also. Besides non-trivial "inheritance" is best set-based instead of tree-based. The real world changes in a graph-like fashion, not trees.
I agree it complicates the runtime model - but it simplifies the conceptual model by allowing for classification. You can say "this is the same as that except for these". Telephone switch programming is crazy with this technique for both data compression reasons and UI ease of use (you don't want to enter every single setting for every single phone number individually - you'd be at it for years). Besides, trees are graphs.
The bottom line is that it is easier to manage such stuff in tables than in programming code. You can see patterns in tables easier than in code. Part of the reason for this is tables allow you to eye the info by both row and column at the same time. A class cannot give you this. It is like the difference between looking at an HTML table (made with "table" tag) rendered in a browser versus the raw HTML code. Classes are like the latter.
No, its the other way around. You're writing the indirection on an ad hoc basis. The OO language compilers systematizes (if thats a word) the approach and hides the complexity leaving you with (hopefully) the essentials of your design minus the ugly dispatch tables that make it work. You're doing the same thing that they do, in a less efficient and manual manner. It amounts to preferring assembler over C.
C helps you write structured logic, assembler doesn't prevent it, but it doesn't help much either.
Anyhow, I'm convinced you do understand it, you just don't like it.
Whatever, mission accomplished.
Now we never have to bring this topic up again. :-)
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,601
12/30/02 8:19:39 PM
|
Thanks! 1 topic down, Googolplex-1 to go. :-)
|
Post #71,870
1/1/03 3:37:08 PM
|
For Bryce, this is pretty much the only topic he discusses
over and over and over....
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,895
1/1/03 5:44:13 PM
1/1/03 5:49:31 PM
|
That is not true
I have been known to also rant on HTML P-tags, Remote GUI's (SCGUI), SQL (The COBOL of query languages), alleged cop racial conspiracies, arbitrariness of English, and lost hamsters.
________________
oop.ismad.com
Edited by tablizer
Jan. 1, 2003, 05:47:50 PM EST
Edited by tablizer
Jan. 1, 2003, 05:49:31 PM EST
|
Post #71,937
1/1/03 10:18:51 PM
|
Not to mention sheet music conventions/annotations. :)
Alex
"No man's life, liberty, or property are safe while the legislature is in session."\t-- Mark Twain
|
Post #71,967
1/2/03 5:14:45 AM
|
Woah - sheet music - I haven't seen that stuff in years...
I used to play on the Albuquerque bar circuit.
Top 40 you have to learn off the radio. The sheet music is 1) always simplified and 2) comes out months after the tune has peaked if it comes out at all.
Standard answer to question "can you sight read" was "why - somebody write something down"?
Actually I tried to learn to read several times. But my ears are so good that as soon as I've heard it I just play it - bypassing the painful mental act of visual decoding and translation.
I don't suppose I'll ever learn...(sigh).
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #72,053
1/2/03 1:17:41 PM
|
Playing by ear
Playing by ear gives you at least one thing the sheet music cannot: The feel of the song.
While I can read sheet music (for some values of read), I do much better when I've got a copy of the song to listen to because I can get more of feel for the groove of the song than is possible using the sheet music alone.
-----
Steve
|
Post #72,098
1/2/03 6:22:04 PM
|
ObAol MeToo (tm)
I always had (and still have) trouble sight-reading because I play by ear. Back in the days when I was a kiddy and still having piano lessons, when I given a new song I go and program it into my TI 99/4a (the speed at which I could type in a CALL SOUND statement...) so I could figure out what it sounds like.
Once I started doing that it was heaps easier to learn the songs I had to play. Not at all helpful WRT my learning how to sight-read, though...
John. Busy lad.
|
Post #72,129
1/2/03 8:58:55 PM
|
Re: ObAol MeToo (tm)
Do you mean "sight read" or "read music"? I can read piano music and more or less hear it - but I can't "sight read" as I understand it for a damn.
-drl
|
Post #72,137
1/2/03 10:15:55 PM
|
I can read music, I'm just really slow at it.
John. Busy lad.
|
Post #72,170
1/3/03 4:53:00 AM
1/4/03 4:41:59 AM
|
That's really interesting.
Because I have an ear for the feel of music, but when playing, I still prefer to play from chord charts. OTOH, melody lines I can play at speed from manuscript, though hearing it first is Very Helpful. :-)
Then too, I've played from a chord chart cold (in a church band) and the song leader suspected but couldn't be sure that I hadn't played that song before.
Wade.
Microsoft are clearly boiling the frogs.
Edited by static
Jan. 4, 2003, 04:41:59 AM EST
|
Post #72,219
1/3/03 10:55:19 AM
|
Speed-reader here
Though most musicians would look at drum or percussion music and lose their minds. If you're talking percussion (not counting marimba and other keyboard-like instruments) the notes will generally be all on one line. Or rather each line is a completely different instrument. Often each instrument will have a different-shaped note head.
Then there's the stuff they give the guy playing the drum set in a pop/jazz/rock etc. band. It's frequently so over-written it's nearly unplayable. I usually just asked for the lead sheet (for standards, the kind with a melody and chord progression) or a copy of the first trumpet part. Basically give me the melody line and let me figure out what to do with it.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #72,467
1/4/03 1:13:52 PM
|
You're a drummer? Cool!
-drl
|
Post #72,624
1/5/03 2:11:58 AM
|
I use chord charts a lot
I make chord charts from sheet music all the time. I hate trying to turn pages in the midst of a song. I try to memorize as much as I can, but we do so many different songs, and a different set every week.
-----
Steve
|
Post #72,214
1/3/03 10:31:13 AM
|
Same here.
I can't play for shit from music. I end up memorizing the song more or less before I can play it well.
I can play melodies by ear after hearing them once, if I'm paying attention.
My son is learning to sight read quite well, thankfully. It's a useful skill to have in addition to playing by ear.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #72,659
1/5/03 11:47:43 AM
|
Todd, Steve, guys - just a well-meaning tip:
This kind of thing is exactly what the "As New Topic in" check-box is for.
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,661
1/5/03 11:51:53 AM
|
CRC, Just a Well Meaning Tip..
"As New Topic" is annoying as hell and more or less ruins the flow of a forum, unless (ab)used as a flame retardant. Who cares if side issues come up? When you are having a beer with your buddies, do you move to a new table when the conversation changes?
-drl
|
Post #72,662
1/5/03 11:55:45 AM
|
What's annoying as Hell is pompous know-it-alls, and...
...the fact that I apparently missed checking "As New Topic in" on my previous posting.
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,747
1/5/03 6:26:30 PM
|
Bar table load times aren't affected by size of past chat
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #72,755
1/5/03 6:44:30 PM
|
That's the legitimate use
Somehow it seemed more civilized to say "let's move to here".
-drl
|
Post #72,777
1/5/03 7:19:15 PM
|
Naah, you're missing the REAL use:
Seamlessly "moving" the discussion to "tables" where people who might be *very interested* are more likely to be "sitting": What about all the people here who might have a burning inteerest in music-sheet-reading, but never wander into the Programming forum? T'would have been nice to *them* to dump this in Open, or the Water Cooler, or something (Entertainment, perhaps?).
Especially since you *don't* have the hassle, here, of everybody having to physically get up, bring their beers (and other assorted beverages) with them, notifying the waitress of the move if they're running a tab, seeing if there's room at the other "table" to squeeze down their butts, etc, etc.
But, fuck, anyone *else's* convenience but *yours* isn't something you care all that much about, is it?
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,779
1/5/03 7:22:06 PM
|
Re: Naah, you're missing the REAL use:
Just stating an impression, CRC. No biggie. It's wonderful work.
-drl
|
Post #72,785
1/5/03 7:38:47 PM
|
OK, that last point is one we can agree on, at least! :-)
|
Post #73,023
1/6/03 5:56:25 PM
|
If I had any idea this would be so hot
I would have started a new topic.
Who knew?
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #73,119
1/7/03 2:01:02 AM
|
Well meaning tip
Don't run with scissors. ;^)
Like Todd said woulda, prolly shoulda, but dinna.
-----
Steve
|
Post #73,145
1/7/03 9:14:04 AM
|
Long as you knew you "prolly shoulda", that's all I wanted.
|
Post #71,679
12/31/02 3:53:20 AM
|
But I get juiced-up dispatching, et al.
[Database != Slow] Compared to memory - there's a factor of several orders of magnitude.
Databases don't have to run from disk. For dedicated uses, I agree that some hand-built structure is probably faster. However, when you start looking at the same data from different perspectives (different joins, different keys, etc.), then the DB approach will start to shine. DB's are decathlon athletes, not specific event athletes. (BTW, Oracle is designing a RAM-only RDBMS I hear.)
Telephone switch programming is crazy with this technique for both data compression reasons and UI ease of use (you don't want to enter every single setting for every single phone number individually - you'd be at it for years).
I did not propose duplication. We would have to study the actual patterns to see what underlying structure and repetition pattern is really there. IMO, too many developers "see" trees where there is not really clean trees. Months or years later one often has to deal with refactoring a lot of code and other shuffling to compensate. I once had to build a special "3D rollup" accounts receivable turnaround tracking and reporting system. The structure looked like a classic roll-up tree at first, but I eventually gave up on the tree idea and found sets worked much better. I admit that it takes more training to get the users (accountants in this case) to understand sets, but lucky I had a smart user for that one. She picked it up in a snap. One is not always that lucky.
I will admit that for many humans trees are easier to grok, but they just don't reflect the messiness of the real world that well.
Besides, trees are graphs.
Yes, but the reverse is *not* true, and that is the problem. Sets are more general-purpose than trees. You can build trees with sets, but it is much trickier to build non-tree sets with trees. (Did I say that right?) IOW, sets can serve as trees much easier than trees can serve as sets. I say, go with the general-purpose tool rather than marry your design to trees.
No, its the other way around. You're writing the indirection on an ad hoc basis. The OO language compilers systematizes (if thats a word) the approach and hides the complexity leaving you with (hopefully) the essentials of your design minus the ugly dispatch tables that make it work. You're doing the same thing that they do, in a less efficient and manual manner. It amounts to preferring assembler over C.
I am sorry, but I just don't see this. Again, we would probably have to look at actual patterns of repetition and relationships to see what the ideal approach would be. Besides, the "trick" is to farm off the maintenance of such relationships to an operator or intern so that a programmer does not have to deal with actual data entry of such info. Being in tables we "inherit" off-the-shelf Db features like persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc etc etc. How is that for "automatic"?
I will agree that my approach may require a little extra "manual dispatch" programming that OO would take care of IF trees were the best sharing shape, but my approach also allows one to use more "juiced-up" dispatching techniques if needed, without major code overhauls. I have seen trees run out of gas at least twice. Even in the off chance repetition patterns stayed tree-shaped, they are still easier to sift and view as tables. The dispatching code only need be written once, but the data (including code references) has to be maintained for a long time. Still a bargain in my book.
It is the classic tradeoff between a dedicated niche tool versus a general purpose tool. TOP dispatching is more general purpose, and thus will be a bit more costlier if the need tends to be just one thing. If you only use the cork-screw in your swiss army knife, then you might as well just buy a cork-screw. But the world is usually not tree-shaped in my observation.
Thus, add juiced-up dispatching ability to persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc. I am not going to give all those up to save 1 line of code per 500 lines.
________________
oop.ismad.com
|
Post #71,617
12/30/02 9:59:33 PM
|
Re: LISP - Lists + Relational
Bryce, you justify my confidence in you!
-drl
|
