Table Oriented Programming

[John Roth]

"Michael Hobbs" <michael at hobbshouse.org> wrote in message
news:mailman.2.1076613028.31398.python-list at python.org...
> Yeah, yeah, another X-Oriented paradigm, but please hear me out.
>
> I have recently been studying up on EJB's in order to extend my resume.
> I have looked at J2EE several times over the past years, but have never
> been impressed by it. Now that I've studied it in detail, I know why. A
> strongly typed language such as Java is poorly suited to model tables
> and relations.
>
> I got to thinking that a more dynamically typed language, such as
> Python, would be a more natural fit. I've always been fond of the
> table-oriented programming ideas described in
> http://www.geocities.com/tablizer/top.htm, so I'm thinking that if
> Python could be extended to handle table-oriented programming as
> seamlessly as it handles object-oriented programming, it could become a
> really valuable language for writing enterprise components, a la EJB.
>
> Does anyone know if anyone has already walked this path?
>
> I've given it a little thought myself, and here are some of my
> [incomplete] ideas:
>
> - Tables would be first-class values, just as classes are.
> - A table may be stored completely in memory, or it may represent a
> table stored in a database engine.
> - A table may represent the result of a query.
> - Queries are performed using a sequence of operators, rather than
> relying on SQL.
>
> Consider this example code:
>   departments = DepartmentTable
>   employees = EmployeeTable
>   johnsDepartment = (departments * employees) /
>     (employees.dept == departments.dept) /
>     (employees.name == 'John') %
>     departments.name
>   print johnsDepartment[0].name
>
> In the code above, the "*" operator performs a cartesian product, the
> "/" operator performs a selection, and the "%" operator performs a
> projection. If the DepartmentTable and the EmployeeTable are stored in a
> database engine, the expression above would generate a SQL query similar
> to "select department.name from (select * from department, employee
> where employee.dept = department.dept) where employee.name = 'John'". If
> the expression had been written "(departments * employees) /
> (employees.dept == departments.dept and employees.name == 'John') %
> departments.name", the resulting SQL would be similar to "select
> department.name from department, employee where employee.dept =
> department.dept and employee.name = 'John'", that is, without the nested
> SELECT.
>
> Of course, the entire code above could be reduced to a single line:
>   print ((DepartmentTable * EmployeeTable) / (EmployeeTable.dept ==
> DepartmentTable.dept and EmployeeTable.name == 'John') %
> DepartmentTable.name)[0].name
>
> Perhaps the list-comprehension syntax may be better suited than
> arithmetic operators. Like I said, my ideas are still a little
> incomplete.
>
> Please forgive me if this has already been discussed to death,
> - Michael Hobbs

It's an intriguing idea; I've had the occasional thought of
wanting an in-memory relational algebra implementation (which
is what he's actually specifying once you get him down off of
the hobby-horse he's riding.)

Put together a package and see whether it flies for real world
problems. That's the usual path for inclusion into Python - put a
pure Python package together, see if you can get people excited
about actually using it, and then propose it for inclusion into the
standard library.

John Roth