Continued from TableOrientedProgramming, which is growing TooBigToEdit.
Re: I disagree with your premises / assumptions. (1) "Navigational" is about API, not about structure. One can certainly represent, transform, and query even DirectedGraphs? - which are about as 'navigational' as a 'structure' can feasibly get - in non-navigational manners.
If a given API is the "end point", then any navigating technique involving them is going to be very limited. But I'm assuming one can look inside many of the API's when browsing code, and this "looking inside" is basically node-hopping in a graph.
What do you mean by "looking inside" an API? An API is an interface - the edge of a computational system. Unless you're talking about implementation, there is no "inside". If you are talking about implementation, then Relational is identical to Navigational; there isn't a professional implementation of Relational that doesn't use trees and node-hopping on the "inside".
I meant with regard to studying the "structure" of our software from an app developer's perspective: how information is inter-linked. For example, I might use a ControlTable where another may use VisitorPattern. There is a "structure" to each of these. As far as API's, If one cannot go "beyond" the API's interfaces, then that portion is off limits anyhow and is not a comparing factor. (Note that packages could use table-oriented interfaces in many cases, but in general don't at this time.)
ControlTable and VisitorPattern are not comparable things. The former describes a structure for organizing smallish chunks of code (scripts), and the latter describes a polymorphic traversal mechanism. It's a bit like comparing the internal structure of a beehive to the notion of 'running'. Make more consistent comparisons - you should compare things that are 'alternatives' to one another. For example, you should not compare ControlTable to AbstractSyntaxTree, since the ControlTable does not avoid need for AST to understand the scripts. If your goal is to compare UserInterfaces for IntegratedDevelopmentEnvironments, then make certain you are making fair and reasonable comparisons. The ability to perform some relational queries on code would be nice, but does that really require that code be organized into tables? I think not. But it'd probably be easier with certain language features, such as a flat global namespace. A discussion of which features would make relational code-browser/debugger features consistent and easy to implement is reasonable, but will require you be more precise / less vague about exactly what these IDE features are to be.
- I disagree, but let me select a simpler example: ControlTable versus StrategyPattern. For example, a look-up table of device drivers (oh oh!) that match a given device based on vendor and model number, perhaps with wild-cards for generic brand drivers if model number is not found. See PageAnchor "Drivers_1".
- {ControlTable and StrategyPattern are not comparable things. The former describes a structure for holding (typically) event-handling code, the latter describes programming to interfaces rather than concrete implementations, in order to permit multiple interchangeable implementations of a group of related algorithms. In particular, nothing in ControlTable defines, distinguishes, identifies, or provides for an interface, which is a key element of StrategyPattern.}
- Indeed, I was about to ask: Where does the "versus" come into play?
- Tables *are* an interface. I detect possible pro-linguistic/anti-structure bias here. One can write code for the table before it even exists; or it may come from a view, etc. -t
- {Huh? Show how the following interface is implmeneted as a table: class x {void method_a(int x, char y); int method_b(float q, double p);}}
- See below about one-to-one translations. I'd have to see the context.
- {Ah, then tables aren't an "interface" to anything except tabular collections of data. I see. *sigh*}
- Well, I hate to say it, but what's an "interface" is relative. Thus, I cannot answer that in a global fashion. Related: FuzzyDistinctionBetweenInterfaceAndImplementation. What's a "module" in TOP may also be relative, which gums up the usual black-box-with-interface analogy. One has to mentally switch their view from nested components into a world where boundaries are more relative, or at least controlled in very different ways.
- {"Interface" is only fuzzy in your own mind.}
- Maybe I'm broken in the head; for it appears relative to me. Tell me something, is an SQL query an implementation, or an interface call, like a function call is normally considered? -t A: SELECT * FROM foo WHERE x=3 AND y=7 B: Result=getFromFoo(x=3, y=7);
- {Neither is an "implementation" or an "interface call". A appears to be a SELECT query in canonical SQL syntax. B appears to be a statement in a conceptually conventional, but non-specific, imperative programming language that invokes a function and assigns the result to a variable. I don't know what you mean by "an interface call, like a function call is normally considered".}
- So SQL is never an "implementation"? Let me ask this: precisely, how does one know whether an SQL statement found embedded in an application is an "implementation" or not?
- {Your use of the term "implementation" in this context does not make sense to me, unless you mean a given SQL DBMS is an implementation of (for example) the SQL standard. In the context of this discussion, I would expect an "implementation" to refer to the concrete realisation of an interface, in which case SQL statements do not apply, except perhaps in a sense so oblique as to be meaningless.}
- I meant a specific SQL query statement.
- {Sorry, you've lost me completely. A specific SQL query is a specific SQL query. It is not an "implementation" in any sense that is relevant here. It is certainly not an implementation of an interface in any programming sense.}
- Sigh. This is degenerating into yet another definition ThreadMess. I'd like to somehow get back to solving real problems, such as creating and maintaining software, rather than trying to determine benefits by classifying things, which usually turns into a fractal definition battle. -t
- {What you'd like to do seems eminently reasonable. I think this wiki would benefit -- in the spirit of PeopleProjectsAndPatterns -- from more discussion of things we're actually working on or have implemented.}
- PayrollExample is a semi-fictitious TOP example. My version is generally more of a framework that allows sub-systems to "feed into" the central system, via a table-oriented interface (there's that word again) which "compiles" the results into paychecks and paystubs. The comparisons with other techniques generally "degerated" into a WherePsychologyMatters discussion, which is not unexpected, because that's one of the primary factors of SoftwareEngineering in my opinion. -t
- {I'd like to see PayrollExampleTwo implemented using TOP.}
- I won't do it any time soon for reasons described under PayrollExampleTwoDiscussion. And I feel I've provided enough info for one to do it themselves if they really want to.
- Re: "The ability to perform some relational queries on code would be nice, but does that really require that code be organized into tables? I think not." - Only the ability to be view-able as tables (real or virtual) is necessary. Tables can be viewed as a kind of interface. But anyhow, if the structure of your code is primarily navigational instead of relational, then the views could be too messy to use effectively. Or, at least it's not documented how to project it well. (There's existing topics around here on table-oriented code management if I remember correctly.)
- I'm assuming by "relational structure" then, that you mean cyclically "structure that allows easy and clean views by relational interface". But what does that mean? Details, please: should functions accept an arbitrary number of arguments? Should it be possible for one function to return another? Are anonymous functions allowed? How does one 'view' FirstClass functions in a relational manner? Can the code usefully include user-defined macros? How is developmental modularity achieved? Does this so-called 'relational' interface devolve into an AST that just happens to be represented inside a table?
- You seem to be thinking of terms of translating existing programming code, say a Java app, into tables in a one-to-one fashion. Generally one goes about the entire design differently if doing it in a TOP-centric way. One cannot take a statement in isolation and perform a direct mapping to TOP. How to do that as a whole, though, cannot be described in a single paragraph.
- {Your "TOP-centric way" is nothing but a subset of data-driven programming, which has been informally touted for at least four decades, typically as little more than the suggestion (which is entirely sufficient, IMO) to avoid embedding variant or possibly-variant data in static source code. TOP merely encourages that data to be stored in tabular structures inspired by the RelationalModel. Yawn.}
- This is kind of argument-by-popularity. I have seen a fair amount of TOP in ExBase shops, and MS-Access displays quite a bit of TOP, or at least "attribute-oriented-programming", although I don't like it's approach. (See Access comment near bottom of TableOrientedProgramming.) Regarding your four decade comment, editing and UI tools were insufficient to take advantage of TOP until recently. Text-oriented techniques worked better when all we had were text-oriented tools. We've had sufficient tools for only a little more than a decade, and this is only exploration tools, not production tools.
- {Huh?} [I've fixed some ambiguous pronouns, better now?] {Nope. Your point, assuming there is one, eludes me.}
Re: NavigationalDatabase fell out of favor not so much because they used graphs/trees, but rather because they didn't much support whole-graph queries, joins, updates, and views. Navigational APIs view and surgically manipulate a database through a straw.
As far as your claim that NavigationalDatabase (NavDB) slumped because they lacked built-in traversal operations, this would imply that adding those features would make them popular. I disagree, because it's hard for most people to formulate usable queries even if they have those. Nobody knows how to create sufficient consistency to make those work well. But, perhaps if they were tried more in the market-place, the situation would somehow fix itself. -t
I mentioned nothing about "traversal operations", and I certainly made no claims involving them.
Perhaps "graph query idioms" would be a better phrase.
Ah, but if "graph query idioms" is what you meant then you're wrong about inability to form usable queries. After all, relational and logic-programming queries are among "graph query idioms". "Traversal" imposes concern for permutation (traversal = visit nodes or edges in a particular order, usually with arbitrary restrictions such as only taking edges from already visited nodes or a set of start-nodes) and that extra concern can make specification in a query somewhat painful. Whole-graph queries, however, do not suggest such restrictions. Whole-graph queries allow for sub-structure pattern matching (i.e. find a subgraph that looks like... - regular expressions and such), in addition to arbitrary relational and logic-programming operations. And such a query might even ask for traversal related information (i.e. give me the shortest path between every connected pair of points), but need not specify traversals.
I don't want to get stuck in a definition tar-pit here. Your argument seems to be that if NavDB's had more built-in standard or commonly-found operations (which we'll delay listing), they would be competitive with relational. Is this an accurate re-statement of your view?
Not really; this 'restatement' is far more generic than my original statement, which makes it less useful.
Well, since it's a statement about popularity that we cannot directly test, I'll forgo any further effort to clarify, other than request an example of a specific fairly-common task that may be easier with a selected new operation or feature.
T. H. Merrett, an academic at McGill University, perhaps shares some of Top's views re encouraging increased application of the RelationalModel. See http://portal.acm.org/citation.cfm?id=1226088 From the abstract:
"Despite its immense success, the relational model of data has been underappreciated. Many wrong claims have been made to the effect that it is unable to handle complex data, to do analytical processing, or to go beyond passe, simple structured data. I have devoted most of a career in computer science to showing that relations can indeed cope with all these, without awkwardness and with minimal syntactic and conceptual extensions. Not only can relations cope; they do the job better." -- T. H. Merrett (quoted; emphasis mine)
Yay! Go Merrett! --top
PageAnchor: Drivers_1
Vender Model Driver
----------------------------
* * generic.drv
HP * HP_generic.drv
HP LJ123 HP_LJ123.drv
IBM * IBM_GENR_01.DRV
IBM SP567 IBM_SP567_R1.drv
Etc...
(A fancier version may include "device_type" and model sub-groupings.)
SeptemberZeroNine
Table Oriented Programming Discussion