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

Posted by David Eison on
An ASJ article on the persistence system is being worked on.  This feels a little off topic because it doesn't really have anything to do with Java; one doesn't need a persistence system to use Java, and one doesn't need Java to have a persistence system, so I'll just leave it at that so we can go back to discussing OpenACS explaining its choice to stick w/ TCL.

Regarding the paper (Interesting paper with a lot of heart in it.  Specific nit-picks below):

0) Apples and oranges issue: I don't think this should become a paper about OpenACS/Java.  I'd like to see it more about TCL/Java.  See final comment.

1) The paper seems to write off "marketing" (i.e. customer desire to do projects in Java) as a worthless consideration in a platform, which I don't think is a safe conclusion.  I think everyone reading this forum agrees that projects are easier if everyone involved has a common technology base (e.g. everyone knows TCL), yet a company's desire to do their various projects in Java is brushed aside as false standardization.  This aspect of anti-Java positioning might be worth dropping as an indefensible position for any customer that is bigger than just their website.

2) The "equality of programming languages" section feels to me like it should have references to specific languages removed or relocated ("The AOLserver Tcl environment, for example, is particularly strong at linking in new libraries of functionality"; "There are 2 million Java developers worldwide...") because they interfere with the message when interspersed in the evaluation criteria.  Just a personal preference, though, no strong argument for this one.

3) Ease of hosting seems to be an important criteria that has been run up against in the past and may be worth considering when evaluating languages/platforms.

4) The AOLServer/TCL Platform and Extending AOLServer sections feel like half an argument; they qualify TCL, but they don't address/differentiate vs. Java.

5) "There is no single part of web site development that is made easier on the J2EE framework. " feels very unsupported.  Counterargument: I find testing/validation to be much easier on J2EE than Aolserver/TCL, mostly thanks to junit.  Such a thing could be done for TCL, but I haven't seen it; so this could also be chalked up as a win for availability of proven/useful packages of functionality.

6) The templating scheme feels more a function of OpenACS than of the language, and thus isn't worth arguing about.  The templating scheme in ACS/Java 4.5 is more powerful than the templating scheme in ACS 4.0, but it's not because of language choice.

7) I really don't understand what "complete, DB-backed session management" means w.r.t TCL vs. Java.  Looks similar to comment in #6.

8) After repeatedly asserting that Java is inappropraite for web development, the C#/VB.NET model is used as an example compared to ns_java w/ TCL and now Java is suddenly a good tool for creating "reusable, well-packaged functionality"?  Seems like a complete 180 or a last-ditch clause like "this is our case, but even if you don't agree, it doesn't matter because of this".  It might do better to set this off in  a "Still don't buy it?  Consider mixing the two..." section or dropping it altogether.

Most of the things mentioned as advantages of OpenACS, while being good things, have little to do with TCL or Java - they had to be built, and there's no reason that I know of why they can't be built in Java.  I would prefer to see the paper focus on how they were or weren't easier to build and/or run in TCL than in Java, or really push for the language-doesn't-matter argument (more focus on "where functionality already exists in Tcl, there is no need to clone this functionality in Java" would make for a stronger paper because it's only an assailable position if the assailant strongly believes in the common-language-across-enterprise argument or in the superiority of O-O for web development (which isn't an absurd position, but at least it's highly debatable)).