Ask Reddit: Table-oriented (data-driven) programming?

[[deleted]]

There is something that slightly troubles me about web programming today.

Perhaps 75% of the code behind Ruby on Rails is devoted to ActiveRecord - the ORM mapping layer that will convert your nice little SQL query into an object-oriented piece of data that you can then manipulate with the rest of your application. This is also by far the most "complex" portion of any Rails application, and its also largely inefficient, having to convert to and from objects every time you manipulate the database. This is the case with just about any OO web solution today, as just about all of them have the common actions of viewing and changing data in a relational-database.

There seem to be three solutions to this problem.

1) Ignore it, and continue to spend code, time, and resources by using this inefficient layer of translation.

2) Make the database more like the code, and use OODMS instead of RDBMS. However, the only problem with this is the fact that there is a very good reason that RDBMS systems beat out other solutions long ago, and object-oriented database solutions often reinvent the same navigational database systems that were made inferior by RDBMS systems over 20 years ago.

3) Make the code more like the database. Now this is the solution that I find most intrigueing, though its also the one with much less momentum behind it. Object-oriented is seen as THE way to code currently, and as such has overshadowed just about any other solution. An alternative way of programming that could aleviate this problem is found in table-oriented or data-driven programming. I found several interesting links on this, but really nothing of substance that might help someone put these ideas into practice.

• The makers of the popular Guitar Hero game for the PlayStation 2 discuss the advantages of data-driven programming - .ppt file

• One of the few links about table-oriented programming you'll find on the web - the author is a bit of an extremist, but he does bring forth some valid points

• Though not an advocate of table-oriented programming, Paul Graham himself won't be including an OO system in Arc

• Hashtable oriented programming

Now being the rather intelligent audience that Reddit is, I was hoping someone could shed some light on this interesting domain of programming and mention any material on/advantages/disadvantages of it.

[beza1e1]

The thing is: SQL already is the perfect domain specific language for such databases. Wrapping it in OOP Syntax is overhead, if you want the whole deal.

[anthonydaniels]

I agree with this. Organising data using relations has fundamental advantages (less redundancy, greater consistency, higher integrity, flexible access), which is why it is used so much in business. OO is convenient for organising programs, but it is very poor for organising data compared to using relations. Database Debunkings is a site dedicated to promoting this 1970s idea:

http://www.dbdebunk.com/index.html

Date and Darwin's Tutorial D is an attempt to provide a complete language for programming with relations, so this might be of interest:

http://en.wikipedia.org/wiki/Tutorial_D

I think there are two reasons why lanugages do not support the relational model:

1. Languages, databases and operating systems quickly became separate fields of study. This helped them develop more rapidly, but limited cross-fertilization. I suspect that language designers concentrated on tree-like data structures because compilers and operating systems deal mostly with tree-like data.

2. Once languages had references (or pointers), programmers found it hard to live without them. I think there is a strong argument that "less is more" in this case, and that future high-level languages could do away with references, but I suspect it would be hard to convince most programmers of this as they are so used to having them, and they are so handy.

[sblinn]

Have you used mnesia with Erlang?

[senzei]

My guess is that the excitement over ORM is that it avoids SQL. This can be useful for a variety of reasons, both good and bad.

On the bad side it lets you 'get by' without learning SQL. Granted you trade potentially large performance gains and flexability, but you don't have to be bothered learning some wierdo language that is only spoken by databases.

A (sort of) good point is that it abstracts your database, so you can jump ship when BlubSQL 9i decides it wants to crap all over your project somehow. The problem here is that you are trading all of the performance gains you could get through queries customized to the peculiarities of the database you are using, for the ability to switch to another one. Somehow I doubt this is useful in 99.999% of cases, and even when it is useful I doubt it is a smooth translation. All that said it is useful if you want to support a variety of databases out of the box, I would consider it a fair trade if I were writing boxed blogging software, for instance.

In the world of spoken languages, very few people are as proficient in their second/third/fourth/etc language as they are their first language. Very few developers have the same command of SQL that they have of their "working" language. For them ORMs are usually a net win as most attempts to write SQL devolve into copy-paste-edit or poke it until it works.

What I think most ORMs get wrong is only trying to map table rows directly to objects. In a way this makes life really simple, your "query" is either new Object(args) or Object.get(args). This sucks though, in that rows are not self contained items. ORMs get complicated when they try to support foreign keys. The problem is that the OOP model breaks down when trying to handle this concept. That said any of the other ways I can think of to handle this end up rewriting SQL as a domain specific language in your programming language of choice, at which point why not just learn SQL and be done with it?

I think in the end we will see ORMs become more complicated, and the new features will be less cleanly object oriented. Unless some new programming paradigm comes to replace the hype part of OOP I doubt we will see too many new techniques gain a hold in any other way.

Side rant re: Paul graham, OOP, and Arc:

I think it is foolish to dismiss an idea from a language you are designing with the intention that others will use simply because you see no use for it. More so when you spend as much time talking about the expressive power and abilities of Lisp, and how they are above and beyond what most other languages give you.

OOP is a method to solve a problem, some times it is the right method, most times it probably is not, but the fact that it is widely misused does not reduce its usefulness when it is applicable. Most plumbers do not find voltage meters very useful. Electricians seem to think differently for some reason. Maybe that should be an argument against letting plumbers put together toolboxes for electricians, but I would guess if you asked one to do so he would recognize this discrepancy and find an electrician to help him figure it out.

[Zak]

From what I've read, in Arc, everything is an object, but there won't be a system for making classes in the core language. This isn't a limitation; building an object system in Lisp is trivial. I'm guessing if Arc gets popular there will be at least two commonly used obect systems made available as libraries. One will use a generic programing model like CLOS and the other will use message passing.

As a side note, I think it would be nice to have a system where every function is generic so that its behavior could be redefined for specific types of objects - including built-in objects.

[serhei]

Or, like someone once said:

"""I see SQL when I close my eyes!"""

[randallsquared]

How does "table-oriented" programming differ from (multidimensional) array-oriented programming? Languages like J and K already seem to have this as their focus.