Forum OpenACS Development: Re: The future of OpenACS

9: Re: The future of OpenACS (response to 1)

Posted by Gustaf Neumann on 08/07/07 02:12 PM

There are a couple of statements concerning XoTcl, that i have to address here. i had yesterday an operation, so i can address these points only shortly.

Tom:

If the original code works, why would it need refactoring to xoTcl, why not refactor to Java or LAMP?

Why not refactoring in Java or LAMP? Wasn't there a project trying to refactor ACS in Java, which failed badly? XoTcl is a Tcl extension which integrates therefore nicely with pre-existing code, which is not the case for LAMP alternatives.

There are a couple of reasons for refactoring "working" code in xotcl

Make applications reusable through subclassing
Improve flexibility and maintainability
Improve orthogonality (why is argument passing and checking in ad-procs, page contracts, widgets and for adp includes different?)
Reduce the need for the notorious upvar/uplevel necessity by using objects.
Last but not least: improve speed (invocation overhead of an XoTcl method is significantly less than the invocation overhead of an ad_proc) and reduce memory consumption (for every ad-proc two tcl procs are added to the blueprint; that is not the case for xotcl based ad-procs and ad-instprocs)

Furthermore, through higher reusability, xotcl code is typically much shorter than tcl-only code. For example xotcl-core and xowiki are together significantly smaller than e.g. assessment, just by counting the number of lines:

assessment: 49.000 lines
xotcl-core: 6.900 lines
xowiki: 29.000 lines (4 of the 5 largest files are javascript libraries used by xowiki)

I doubt very much that a change in the OACS core or changing to xoTcl would somehow help write the eventual killer app

The only openacs application currently available with some killer-app potential is xowiki, which can be easily configured as a collaborative wiki, a blog, an announcement system, an faq module, a collaborative networking tool, a slide presenter, a podcaster, etc.

14: Re: The future of OpenACS (response to 9)

Posted by Don Baccus on 08/07/07 07:27 PM

Wasn't there a project trying to refactor ACS in Java, which failed badly?

No, not really. It was overdesigned and overly complex attempt at a redesign of ACS 4 (which has some overdesigned and overly complex elements already :)

For instance, you didn't write HTML-based template files ala ACS 4. You wrote XML which got fed through XSLT to create HTML which then got streamed to the user, and whatever the abstract attractiveness of this approach might be, the particular implementation was obtruse and difficult to use by experienced programmers. Designers? Forget it.

That's just one example.

A straightforward rewrite might've been interested, in the sense at least of giving some empirical evidence that a Java-based framework's always going to be a PITA to work with.

One might say it had a similar relationship to ACS 4 as ACS 4 did to ACS 3, with a language change thrown in for fun.

My comment about xotcl simply reflects a belief that AOLServer+tcl+xotcl will be no more popular than AOLserver+tcl.

Well, there's still a pro-Mysql bias in the web world, too. Mysql's gotten better, at least, though the idea of giving up PG would make me sick :)

17: Re: The future of OpenACS (response to 9)

Posted by Tom Jackson on 08/08/07 06:27 AM

Why not refactoring in Java or LAMP?

If you delete the first part of the sentence, you can make any conclusion you want. The first part was "If the original code works, why would it need refactoring to xoTcl". Working code doesn't need to be refactored to make that working code nicer to look at. Refactoring must be directed at reuse by higher level APIs. Obviously there could be internal refactoring which has no external impact: who cares about this?

Unfortunately I sense that refactoring into xoTcl will have a vast impact on other code. xoTcl is not an extension of Tcl. It is a new language. If it were an extension, then the authors would not complain about uplevel and upvar. These are not evil commands. This single complaint informs us that the authors see a deficit in Tcl. Believe me, it doesn't exist. The only deficit is in the understanding of how to use Tcl. Why is it that ignorance makes people think they are smart? This whole discussion could be reformulated as: is Tcl Java? Thank whoever, the answer is no. Am I, again, overreacting? Then explain how Tk extended Tcl without complaint.

Anyway, there is a huge difference in saying xoTcl is not good and saying that it doesn't offer much benefit, if any, to an existing code base written in Tcl. I perceive them as distinct programming models. They are presented as distinct, so there doesn't seem to be much argument over this fact. Why is this new language being introduced, and why is it being accepted? Tcl does not have the deficiencies which concern a few here. Tcl is easily adapted to any object model, I would argue that Tcl is very object oriented, maybe exclusively object oriented. Tcl acts on objects. Even commands are objects, so the Tcl model is objects acting upon other objects. Maybe the difference with Tcl is that the same object can be both the actor and that which is acted upon. Some people are offended by this. Screw 'em.