When Not To Use Table Oriented Programming

According to various discussions people have had with topmind there are various situations where he's conceded that TableOrientedProgramming isn't the way to go. These are:

• GUIs. If your application uses a GUI then don't use TOP as OO works better for GUIs.

  Not so. TOP is great for generating web interfaces to data repositories. However, you need proper aggregation tools and the right template rendering solution. I know because we have created both in Deft http://defindit.com/ which I'm using to drive all my web sites. Incidentally, we also added a state machine to encapsulate the workflow (aka business logic) of the web pages. Declarative programming (with a top backend) is ideal for use with state machines.

  • Why is that? I think GUIs should be data or meta data, not code. See TooMuchGuiCode and NonOopGuiMethodologies.
    • [This is fine as long as your GUI needs are 100% addressed by whatever engine parses your GUI markup (HTML, MozillaXul, whatever). This is not the case with most applications.]

    • T.O.-gui's and markup GUI's are different animals, for the most part.

• Device drivers: If your application consists of 'device drivers' or any kind of pluggable or component based architecture then don't use TOP. "if device timing is important, then the auto-garbage-collection nature of many table engines may make performance too unpredictable for highly interactive drivers". Java suffers from similar problems, I would note.
  • Performance constraints aren't the same as pluggable/component based systems. Java makes excellent component based systems (see Eclipse).

• Unit testing frameworks

Please explain.

No need to explain. You yourself pointed out that TOP was unsuitable for building a *Unit clone.

Sorry, but the reference escapes my memory.

• Building tools: like IDEs {I never conceded this --top}
  • [If TOP can't handle component based/pluggable systems, then it's not real useful in IDEs]
  • Does "handle" mean accept or implement? If multiple languages are allowed to implement GUI components for a given framework, then a somewhat declarative interface is warranted anyhow. OOP tends to be xenophobic.
    • Wow, way to redefine "declarative" there. Is C++ declarative because you "declare" a class "definition"? It's the implementation details that make plugin systems hard, not the definition of interfaces. This has nothing to do with OO per se and everything to do with real-world constraints.
    • I am not sure what you mean. How about an example. As far as "declaring a class definition", I don't think "declare" is used in a formal sense in that situation. It is kind of the same as "stating" or "typing".
    • [Conceptually, plugins are pretty simple (although you can end up backtracking a lot as you figure out the best interfaces to expose, etc). It's implementation details that make them hard - how to load up arbitrary code from arbitrary locations, how to associate metadata, etc, etc. The more dynamic a language, the easier it generally is.]
• Heavy text processing applications (such as wikis)

I disagree. With a reasonable set of functions (and some syntactic sugar) top is ideal for text handling. Deft builds web pages and does all the standard stuff such as sanity checking user input. I think the misunderstanding about top comes from never having seen a complete top solution. The mature solution has a number of remarkable operators without which top seems incomplete. People would object to Perl if it didn't have regexes and hashes.

• This confuses me, because I don't see much use of tables in implementing text manipulation. Are you sure you aren't doing procedural or functional programming in disguise?
• I don't see them as mutually-exclusive. It may make more sense to manage functional-like or Lex-like statements or rules in tabular form. This gives one the added ability to view, sift, sort, cross-reference (and other DatabaseVerbs) on the "rule list", or whatever you want to call it. A lot of the value of TOP is that it helps the "rule manager" or "attribute manager" (human) manage lots of parts and lots of complexity. Maybe if you have FastEyes, you can do all those in your head with textual code. The rest of us need reality-reprojection tools to help us study and see specific perspectives for specific needs. TOP is more about WetWare than hardware. -t

• Implementing an RDBMS engine
• SystemsSoftware

• There are certain classes of problems, such as GraphAlgorithmsWithTables, which existing algorithms don't support very well due to whatever historical reasons. In other words, the body of discovered algorithm knowledge may be biased toward dedicated structures (arrays, lists, etc.). This does not mean that table-friendly algorithms are not possible, just that the research has not focused on them at this stage. {TOP-oriented equivalent graph algorithms have since been supplied.) These are referred to as pointer-hopping applications in AreTablesGeneralPurposeStructures.

In other words don't use TOP to solve these problems unless you're prepared to do the primary research yourself. Unfortunately for some reason the comp-sci establishment haven't devoted a lot of effort over the last 70 years to re-implementing the last 3 thousand years of mathematics using TOP.

I think the point about algorithms and lack of research is true. We are successful with top in Deft because one of us (Noah) is a math prodigy. The fully mature top model includes recursive, multi-host (parallel execution) aggregation operators that split a table into N tables, recursively operate on each table, then join all the results back together. At the extremes this is mind-bending stuff. However, with only half a dozen functions Deft implements top and is both easy to use and easy to read. Granted that Deft includes a top oriented template rendering engine which cleans up the code considerably. Even so, small web-cgi-sql Deft is about 1/2 the size of comparable Perl code.

• Perhaps graph-centric processing is rarely needed on the batch level in practice and this is why there is little research and support for it. Generally graphs are incrementally crawled in practice and then acted upon based on digested chunks. The actions typically require complex algorithms that may be easier to describe and work with using other paradigms. It is more akin to EventDrivenProgramming. Even knowing when to stop crawling and act instead is better done with mixed paradigms. Graph-centric queries may still improve the incremental approach, but may not replace it. -t

• I will agree that TOP is under-explored for many uses. But I feel that in the longer run it is a better solution because it better fits the philosophies of SeparateMeaningFromPresentation and EverythingIsRelative. It's competitors hard-wire too many things based on archaic or rigid concepts, such as PrimaryNoun. I tend to approach these discussions from what is the ideal, not what is most tested in production or has the most vendors behind it. We would never move forward if those were our primary guides. You win on vendor votes, but not on logic. Perhaps you could argue that we must hard-wire in certain concepts in order to get satisfactory performance and that MooresLaw won't rescue us from that restriction in the future because software is increasingly called on to do more and more complex things. That would make a more interesting debate. However, the "more and more complex things" is often more ways to look at the same information, so the flexibility is an advantage, I shall argue.

Why would anyone try and invent new lesser solutions to problems that have already been solved?

"Solved" is not necessarily Boolean. It may be a case of QwertySyndrome perhaps.

GraphTheory (which originated in the works of Euler) is a branch of DiscreteMathematics?.

Does that math say that table versions of such are not possible, given more research? Relational theory was also influenced by mathematics, I would note.

Relational theory wasn't influenced by mathematics, relational theory "is" mathematics.

Table versions are perfectly possible but existing relational query languages make it very hard to express the algorithms for processing this data. Thus another more expressive language is needed.

We have more expressive language, we call them programming languages.

It is a matter of UseTheRightTool? for the job. Relational is not meant to do everything anymore than RegularExpressions are. I find them useful for doing a relatively large portion of the processing (or pre-processing). For any given task the amount they may handle varies widely, but there is still a net benefit in my experience.

If you think SQL is good for a relatively large portion of the processing, then you aren't doing anything remotely complex. Real programmers find SQL wholly inadequate to do anything but the most trivial processing. Anything even trivially difficult, requires a real programming language. At this point you should really just admit you're not a real programmer, you're just a db guy who figured out how to do basic CRUD screens. Your experience doesn't translate to the rest of the programming community, and you generally don't know what the hell you're talking about. A guy on another page showed you Python code you couldn't read, please... Python is almost pseudo code, anyone who can't figure out how to read Python can't call themselves a programmer. A real programmer who'd never seen Python could figure out how to read it in a few minutes. Watching you talk about programming is like watching a 5 year old try to explain the tax system to an IRS agent.

Let's see your magic lamp Python simplify challenge #6.

Re: Python is almost pseudo code, anyone who can't figure out how to read Python can't call themselves a programmer. Everyone thinks their favorite language is the cat's meow. This is because people tend to choose languages which fit the way they think and people tend to assume that everyone else thinks like or should think like them.

[Python does read very simply, although there can be confusing constructs, like "".join(). I've never seen Python code I couldn't understand once these were explained to me, even before I spent the time to learn Python. Intentionally obfuscated Python is a separate issue, of course]

You might be correct were I a python programmer, but I'm not. It's still quite easy to read, and I stand by my statement. Real programmers can generally read several languages, as this is something one must learn to do in order to pick up proper techniques.

Define "proper techniques".

---

See WhenAreDatabasesNotAppropriate