Forum OpenACS Q&A: Response to A Technical Paper on Java

Collapse
Posted by Ben Adida on
Kevin, thank you for taking the time to explain your point of view. I
much prefer this level of discussion.

You are making my point for me, though. The join situation is
precisely what I was referring to. You have two tables, and
abstractions built on top of each individual table. If you want to
pull out data from both tables simultaneously, you're forced to
either issue many SQL statements to perform the join outside of
the database, or you're forced to break your abstraction with your
"DataObject." Once you've pulled out the fields using the join
SQL query, you're forced to create the individual objects (in this
case student and table) within the DataObject class by inherently
breaking the nice abstraction you created for both. You're forced
to expose the internal class structure both to Student and
StudentWithAdvisorQuery.

I've built a complete Java web application as the "Java/DB guy,"
and I was faced with this dilemma. There is no clean solution.
The OO abstraction model is inherently incompatible with the
join semantics of SQL.

So yes, Tcl has issues. It's not a language I want to build an
enormous desktop application in. That's why I rely on SQL data
types and PL/SQL where appropriate. The problem with your
analysis is that you're forgetting the thousands of VB
applications out there. Yeah, VB is a crappy language, but a lot of
the applications you use from day to day are built in VB. Why?
Because a quick and very-high-level scripting language is often
more powerful than a well thought-out Java application. It gives
computer scientists nightmares, but it works.

The other issue is that, when using a strongly typed, highly
structured language like Java, you're often forced to take
shortcuts like the DataObject approach. Suddenly, your
abstractions are broken. The reusability you expected is
seriously endangered.

So which is better? Using Java and being under the illusion that
you have structure, reusability, and generally good software
engineering practices? Or admitting that we have some serious
unsolved problems in this field we call software "engineering"
that cannot be addressed by "pure," "clean" solutions, and going
with a language where less reusability is a fact we admit from
the start, but where one can rapidly develop and deploy an
application?

I don't have the answer to all of these issues. They're not simple.
But my intuition tells me that Java is not the solution because of
the points above and in my paper. Tcl is not *the* solution either,
but it is more effective in getting people up and running quickly
with an application that ends up not being so difficult to tune.