Table Mantra Taken To Extreme
Table Mantra Taken To ExtremeFrom DynamicStringsVsFunctional: ...Please explain what you mean by blurring the distinction between an interpreter and a database, and explain why this would be desirable. Or point me somewhere else where you discuss it. Do you mean the distinction between the interpreter and the database system? As in, the database system includes the interpreter? I don't see what bearing this would have on how code is represented.
It is a little hard to explain because it is a new concept without a lot to compare it to. Think about how an interpreter works. It builds up a compound internal data structure as it runs. If one had direct access to this in a program, one could do their own "meta-programming" of sorts. Related is FileTreesToManageCodeDiscussion. If the code repository was a DB, then the interpreter would get code information the DB instead of files. Further, add to this the event and GUI control mechanisms that modern programs need. All these use roll-your-own kind of databases (or file systems), AKA, "custom-built NavigationalDatabase." The system would be simpler if all these were consolidated in a RDBMS. In summary, take these:
Plus, the integration would make referencing between them simpler. Right now each tends to make "RAM copies" of stuff in other parts of the above list in order to reference it. This results in some OnceAndOnlyOnce sins. However, I suspect that the way we currently program would have to change somewhat to fully take advantage of such integration. How exactly it would do this, I can't quite put my finger on it yet. It may take actual hands-on experiments with such technology to "see" how to more effectively use it. I suspect code would be less hierarchical and more event-driven.
But even without the "new coding", it would still be "better" in my opinion. What we are currently doing is creating more and more complex navigational structures in our tools to manage all these. This creates a few problems. First off, as you know, I think relational is superior to navigational. Second, the existing navigational structures are not integrated. They generally don't directly "talk" to each other, and this creates complex and inconsistent interface barriers. Third, I think meta ability can come from directly talking to the database rather than having languages and/or each part invent their own "accessors" and access syntax (DatabaseVerbs) for meta abilities. A "namespace", such as what one may find on a call stack, for example, is just a set of database records. Closures and up-stack-evals are more or less just syntactic ways to manage which "scope group" is used. HigherOrderFunctions are just ID's to functions, i.e. "function definition records". Everything just becomes simpler and more consistent when you view it as a RDBMS instead of weird code syntax, at least to me. Maybe I suffer CodeAvoidance syndrome, or else most of you guys suffer "database avoidance" because other toppies would be scared out of the current code-centric system (although I get emails from some) and thus the personnel is filtered by current IT fashions. -- top
Well, in general I'm sympathetic to the ideas of Table Oriented Programming, and I'm by no means database-phobic. (I've spent the last six years working on almost nothing but database technology!) But my initial reaction is that call stacks in a database is taking things much too far. Stack frames almost never need to be manipulated by anything but the interpreter or run-time of a language, and a debugger. Even the "up-stack-level" eval mechanism of Tcl (which really is much less elegant than closures) only references other stack frames by a number indicating relative position, which is interpreted by the interpreter. Even debuggers don't generally need to do anything resembling a query on a call stack; in fact, in compiled languages there's typically not much there to search for. If it really seemed advantageous to a debugger author to look at call stacks this way, I suppose an interface could be devised that made them look that way.
Sure, but it would be a heck of a lot easier to make one if that stuff was in a DB. It would not take a special commercial product; one could roll their own with a RAD table-browser tool, and customize it to be how you want it. I personally would like to be able to query the call stack during some of the trickier bugs. I could write scripts or database triggers to store stack snapshots when and how I want. I would not need a dedicated fancy tool for such because it would be just "regular ol' database stuff" that table heads are used to and proficient at. Same thing applies to all four items on that list. Why make a special tool for each one when they can be built and customized with regular database tools and tricks? Unixphiles are used to doing similar things with text and files. They don't need expensive or rare tools because there are plenty of text and file tools already in Unix. I am only moving that concept to the DB realm. One good thing about everything-is-an-X is that everything responds to X tools.
But the internal structure of call stacks really doesn't matter to much code, and should be optimized for its primary purpose -- efficient execution.
Representing code in a database has certain advantages, and it has been done, but it's not an easy task, and also has some disadvantages. Simply storing modules as unstructured source code text in a database is possible, but not very interesting; it's just a variation on a file system. {FileSystemAlternatives} But the code can also be stored as structured data in a database. Code by nature has hierarchies in modern programming languages -- every conditional, every loop is a hierarchical structure. Relational databases can deal with this, but it's somewhat awkward.
Some people other than me already lobby to "flatten" the code tree quite a bit by using ShortMethods (related to: LongFunctions). For example, rather than make a case statement, one just creates records in a kind of ControlTable for each option. A lot of code is wasted, in my observation, on things that would be simpler or different under a data-centric design.
Better relational languages could mitigate the awkwardness, but the elements of the hierarchy tend to be of pretty diverse types -- which again presents some difficulties for a database schema. You really wouldn't want to regress to languages that lack these hierarchies though. Take a look at some very old FORTRAN, or Basic, or SNOBOL for examples of languages that implemented conditionals via gotos. Personally, I prefer the PowerOfPlainText, augmented sometimes by databases of information generated by code analysis tools.
As an aside: Even granting these things, I see no blurring of the distinction between database and interpreter. Something still needs to interpret the data and act on it, and that's the interpreter.
Event-driven GUI systems are more or less a specific kind of interpreter. One fills in event code snippets (routine-like or module-like), and the event manager decides what gets executed next and in what order. The distinction between event triggers and subroutine calls is perhaps not different enough to make them be different things. If that is the case, then there is a blurring.
I also still don't really see what this has to do with strings. Storing code in a database does not necessarily imply storing it as source code text.
-- DanMuller
As far as execution speed, I agree that the hardware is not ready to do this in larger production systems yet. I am thinking ten or twenty years out into the future. We are at the stage of database usage that the "Southerland drawing tool project" (link?) was in the early 60's when it was experimenting with WIMP-like interface concepts: a good idea but ahead of the hardware curve (At least that is how I hope it is.)
Perhaps this page should be merged into AdvantagesOfExposingRunTimeEngine.
EditText of this page
(last edited June 17, 2006)
or FindPage with title or text search