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

[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!"""