"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)."
A major issue here is that AOLserver works directly on Tcl internal data structures (i.e. TclString and TclObject and the like). Additional languages will suffer from the need to provide for consversion to and from the internal Tcl data structures AOLserver requires in its API. This may or may not be a significant performance barrier for those wanting to investigate such an approach.
This assumes you want the alternative language to be a first-class citizen with the kind of integration with the DB API etc that we have for Tcl.
"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."
TCL is not ideal (TM)
"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."
Yes, indeed. Tcl also has a very clean implementation that made it easy to work with, I would be surprised if Perl's as well-implemented given its history. Ruby's implementation is probably very clean, though I've never inspected the source.
"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"
People have built very large systems in languages like Ada that are very maintainable. I used to consult for the compiler company whose Ada compiler was used for the F-16 avionics systems, and in head-to-head implementation tests bug rates for those writing in Ada were about 1/2 for those writing in either C or C++ (not hard to see why).
OOPs is not a panacea. It's one technique that, properly applied, can help one write clear and maintainable code. Or, not properly applied, unclear and unmaintainable code. Take your pick.
"and without inheritance you can't make sure that logic is never duplicated."
Inheritance is no barrier towards the accidental duplication of logic. Nor is it a precondition for minimizing such logic. People oversell OOPs.
"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."
This is true of any large system. The only way it can't be true is if the demands on the system are static and unchanging ... which is pretty much the definition of a lame-duck project which has outlived its usefulness, not something dependent on programming philosophy.
Yes, language differences and programming paradigms do greatly impact maintainability ... but only the EASE of maintenance. Not the NEED for maintainence. If your project's dead, you needn't fix bugs or enhance it ... those needs are externally driven.
If people doing large-scale OOPs web development frameworks like Ruby on Rails, Websphere etc imagine they've gotten rid of (all, most of, much of) the need for maintenance, they're going to have a very unpleasant surprise down the road.
