
Table-oriented programming (2002) - open-source-ux
http://www.oocities.org/tablizer/top.htm
======
jloughry
I can't believe nobody has invoked Fred Brooks yet, so I'll do it:

"Show me your flowcharts and conceal your tables, and I shall continue to be
mystified. Show me your tables, and I won't usually need your flowcharts;
they'll be obvious."

 _The Mythical Man-Month_ (1975)

------
zwieback
Voted this up out of pure nostalgia. I remember the "spirited" usenet
discussions we had with topmind/tablizer on comp.object. He was a one-man army
fighting proponents of OO. There were actually some decent ideas buried in his
ramblings about table-oriented programming but he was so abrasive nobody could
deal with him. I'd be curious what became of him...

~~~
jvoorhis
When I saw the headline I immediately thought of
[http://c2.com/cgi/wiki?TopMind](http://c2.com/cgi/wiki?TopMind)

~~~
dri_ft
Me too. I binged a lot of the C2 wiki last year and waded through a lot of his
spew.

------
barrkel
Tables are a fine way to explore the testable state space of moderately
complex functions where there's natural or explicit discrete points in each
dimension / argument. It's easy to see which combination is or isn't tested
when it's in a tabular form, vs almost any other approach.

For actually driving logic, it tends to be somewhat user unfriendly unless
there's something intrinsically table-oriented in the domain. The best table-
oriented program I ever worked with was a disassembler; naturally, machine
code (particularly the x86 series) lends itself to tables since unused /
reserved opcodes in one generation turn into prefixes in the next.

Tables do make explicit the entire state space, though, and if followed to the
logical cross-product extreme, are agnostic to the hierarchy imposed by OOP.
But the geometric space explosion of cross-products makes you want to create
new abstractions to cover more ground, and you start to lose what tables gave
you to begin with.

~~~
vmorgulis
> But the geometric space explosion of cross-products makes you want to create
> new abstractions to cover more ground, and you start to lose what tables
> gave you to begin with.

What kind of abstractions are you thinking of? ORM?

There is an interesting comparison between tables and s-expression on c2.com
that might interest you:

"The average for TOP is higher than es-exp's in my opinion, so they are the
better general-purpose tool, especially if complexity of a project grows over
time. I rarely see project complexity shrink over time, thus it seems more
logical to emphasize the higher end when making a judgment rather than the
lower end. If you see dark clouds on the horizon, you should pick the bigger
umbrella even though the current rain may be light. -- top "

[http://c2.com/cgi/wiki?AreTablesGeneralPurposeStructures](http://c2.com/cgi/wiki?AreTablesGeneralPurposeStructures)

~~~
barrkel
I'm thinking of functions with many arguments: every argument adds an extra
dimension to the table. Even if you unwrap the dimensions (e.g. instead of a
cube made of 1/2, a/b and x/y, you have a table of a1/b1/a2/b2 vs x/y) you
still multiply the state space.

S-exprs are simply a representation for trees, and you can use trees for
anything - not necessarily the most efficient way, but trees are very
flexible. But trees encode policy: the choice of root and branch determines
what's cheap and what's expensive. Tables are agnostic, but they pay for their
agnosticism with their dimensionality.

------
pedasmith
The RS/1 statistical system used a table-based approach; it was wonderful! If
I ever spend time to design a language, it's going to have "table" as the main
non-primitive type, with some "hints" to sallow super speed.

Cool features: tables could be much larger than memory; they were swapped out
as needed. Temporary tables would just stay in memory until memory pressure
grew too high; then they were automatically spilled to disk.

What in unix are weird-looking files (termcap, I'm looking at you!) were just
tables of data.

Unlike SQL table, RS/1 simply let you change tables using a nice editor (or
via SQL-like commands).

Also unlike SQL tables, RS/1 tables should be grouped into objects; an XY
graph was simply a collection of tables (a data table, a table for options
like line color, some ticks tables, and more). Normally you edit a graph using
a nice editor, but you could also edit the (documented) underlying tables.

Overall, it was the single most productive programming and data manipulation
environment (for it's time) that I've used.

------
dahart
One of the rogue work projects I took on once that I'm still proud of was
baking Excel tables into a memory-mapped block in a game engine, and having a
very lightweight API for reading the table.

That makes it _super_ easy to author state machines using Excel with arbitrary
data per state. Super useful and provided a great way for designers to do the
game logic in Excel while I focused on the physics or whatever else.

It was also orders of magnitude faster than any other format the studio was
using for data - XML was truly disasterously awful, but even decent formats
would be doing parsing, translating, copying and memory allocation per node
from whatever file format they were using. Compare that to a table that is
ready to go in memory after a single fread().

I still wouldn't call it Table Oriented Programming, nor suggested that it is
somehow opposed to Object Oriented Programming, but I do have experience to
back up how some of the ideas in this article are good.

~~~
co_dh
Can you provide more details on how do you baking Excel tables into a memory-
mapped block? did you used memory mapped file as in linux? or you manually
synchronize between excel and a memory block in game engine?

------
radarsat1
Is there a modern language built on these (or similar) principles? Just
curious. I imagine a DSL would be adequate, but it seems we still use SQL and
OOP most often, with the exception of array languages. (These days even my
array programming is in an OOP language, Python)

Not to say that this is necessarily a better idea, but I find it interesting
enough to wonder what analogous things are out there right now.

Aside: I find this a neat example of some hidden knowledge buried in the
historical web that could easily have been lost if it weren't for brave
internet archivists. Kudos to the internet archive et al!

~~~
Zuider
The article claims that the following languages are table oriented in some
respect:

"TOP languages do exist in various levels or incarnations of Table-
orientedness. These include Xbase derivatives (dBASE, FoxPro, Clipper), PAL
(Paradox), Power-Builder, Perl (for certain list types), Progress, Oracle's
PL/SQL, and Clarion Developer."

A quick web search shows that all of these are apparently still actively
developed and used. I don't think any one is modern in the particular sense I
understand your question since, apart from Perl, they were all attempts to
create the fourth generation languages that were supposed to take over from
structured programming.

------
jfoutz
The one place this style has been handy (for me) was managing gui actions.
Imagine some code to save a file. That code should be activated on a few
different events, CTRL-S, File -> Save, perhaps a save icon on a toolbar. You
want a 4 way associative set. A key event comes in, lookup the action for that
event in the table, SELECT action FROM bindings WHERE key=CTRL_S; (or
whatever). I didn't really use a database, but it gets the concept across.

This style makes it really easy to dynamically add buttons for actions, verify
you've got shortcut keys for different actions, things are hooked up in menus,
things like that.

IMHO, it's of limited value. On the other hand, any time you've got several
maps that all need to stay in sync something more table like is really nice. A
map and it's inverse, several maps all pointing at the same values, things
like that.

------
fsloth
Efficient syntax for set operations and enabling and exposing relational
algebra as simple constructs usually simplifies code (I do lot of data
transforms at work). It does not require fancy constructs, just starting from
the fact that a large category of programs can be expressed succintly with
relational algebra and then implementing the clearest and most succint code to
implement it.

------
stcredzero
Couldn't you just call Lua "Table Oriented Programming?" Everything is a
table, from which you can construct things like an object system.

~~~
lokedhs
Or even APL, where everything is an array (with an arbitrary number of
dimensions). For example, adding two arrays together will add the
corresponding elements.

------
Animats
Table-oriented programming needs more tables and less code. Think
spreadsheets, and systems with functional boxes interconnected by lines.
Examples are LabView and Blender game programming.

Incidentally, the box with all the knobs is an art piece by Miller Levy, not a
functional device. Here's the original.[1]

[1] [http://www.millerlevy.com/](http://www.millerlevy.com/)

~~~
wvenable
We need spreadsheet oriented programming. A _lot_ of people use Excel for all
kinds of programming but it gets pretty complicated. Even something as simple
as being able to name a column or a cell could go a long way towards improving
these Excel programs.

~~~
siddboots
Many people, including Microsoft, have tried and failed extrapolate on
spreadsheeting towards a more general purpose programming environment, and it
turns out to be very hard. A 2D grid of editable cells without a type system
makes for a great scratchpad environment, but those features are also a
barrier for abstraction.

~~~
Swizec
> A 2D grid of editable cells without a type system

That sounds like a big improvement on the model we all use every day: a 1D
grid of editable memory locations without a[n inherent] type system.

~~~
bbcbasic
Who uses such a model? Unless you write assembly language?

------
gwbas1c
One of the projects that I worked on failed miserably because the leads drank
so much OOP kool-aide that they just couldn't conceive of table-oriented
techniques when needed.

Updated Requirements dictate that we need to add a field? Just spend a few
days adding the same field to 20 different classes and converters!

UI team asks that our REST APIs allow them to filter fields? One of the lead's
head exploded because he couldn't conceive how to do that without strongly-
typed objects.

------
dang
There was one previous discussion in 2009:
[https://news.ycombinator.com/item?id=892163](https://news.ycombinator.com/item?id=892163).

------
JoeAltmaier
I'm wondering why there's no table-based computer language, is there? We have
string-based, functional, list-based, object-based. Why not one where
conditionals, even arithmetic is a table lookup? Could execute terrifically
fast if tables were small enough to fit into memory.

~~~
dboshardy
It's not quite table-based, but APL [0] uses multidimensional arrays as it's
main datatype.

[0]:
[https://en.wikipedia.org/wiki/APL_(programming_language)](https://en.wikipedia.org/wiki/APL_\(programming_language\))

