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.dep t) /
(employees.name == 'John') %
departments.nam e
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 "(departmen ts * employees) /
(employees.dept == departments.dep t and employees.name == 'John') %
departments.nam e", 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 ((DepartmentTab le * EmployeeTable) / (EmployeeTable. dept ==
DepartmentTable .dept and EmployeeTable.n ame == '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
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.dep t) /
(employees.name == 'John') %
departments.nam e
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 "(departmen ts * employees) /
(employees.dept == departments.dep t and employees.name == 'John') %
departments.nam e", 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 ((DepartmentTab le * EmployeeTable) / (EmployeeTable. dept ==
DepartmentTable .dept and EmployeeTable.n ame == '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
Comment