Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?
First let me state that while I know others who share my views, I also know that there are others who do not and all positions have merit!
You asked what size developments is OACS/TCL not suitable for? Well I would say that that is not quite the right question, because OACS is already much bigger than what TCL is traditionally suitable for. The fact that it is possible is due to a number of factors which I see as :
- the quality of the original ArsDigita designers and developers;
- pushing the object model onto the DB layer (which by itself turns out to be actually quite a good idea anyway);
- the richness of the AOLServer API
Point 3 is the key to why we don't suffer quite as badly as others from TCLs major weakness IMO - lack of rich data structures. Think hashes in Perl or collections in Objective C and there is no corresponding TCL concept. Everything is a list of strings. And that leads to another weakness in the scoping / substitution / execution model (or lack of). Anything quoted in curly brackets {} is (normally) untouched. So for instance when you are building a complex set of parameters (eg. an ad_form spec) with nested {} lists, you can't (easily) insert variables to be substituted. In some cases that is such a pain that our framework kludges substitution for you - but by the time it happens you are in a different scope, and so the stack level needs to be played with to get the right values to substitute. But that turns out to ber not quite always what you want (see Jade's ad_form notes for examples).
Sorry if the latter part of that paragraph is too technical, but it's a bit late for me to find a clearer way of describing it.
As I said earlier though, it should be possible for us to support two or so languages calling our core API (although that has it's own perils).
Can others maybe refine or add to this? In the end, you can do anything with anything if you put your mind to it, but in my experience of large/complex projects, dealing with TCL starts to diminish the speed benefits that the OACS base gives you.
And you are right - this problem happens everywhere. The designers of NaviServer (now AOLServer) chose TCL because they were short on time, TCL was designed for embedding inside other systems and was threadsafe. None of other alternatives were, at the time, both of those. I'm sure if Ruby was around then or Perl was less monolithic they would have chosen otherwise.
In small projects, something like Java loses hands down to TCL (or any other agile-ish language). In larger projects TCL alone would lose, but in terms of OACS versus a Java framework, it would still be hard for a Java one to beat OACS - TCL aside. Perl or Ruby would be much closer if not better.
Where the crunch comes though, is maintenance. You can't (IMO) make a very large system cheap to maintain without a really clear, simple object method reflected in both the db and code layers - and without inheritance you can't make sure that logic is never duplicated. Additionally, without objects, rich structures or a real scoping model, complex TCL code will never be able to be fully independant at the abstraction layers - there is too much interdependancy of evaluation contexts.
The interesting thing that comes from that is that a lot of OACS work is effectively maintenance - re-tooling existing code to do something slightly different.
Anyway - these issues are, i'm sure, well discussed elsewhere. With funding it would be amazing to write a new API layer on top to allow an object language to interface with the existing toolkit, but I am not sure how that would happen without a sponsor. Anyone friends with some member of a Royal family? That's how R&D was funded in the old days ;)
