Forum OpenACS Q&A: Re: Reuse in the large is an unsolved problem !?

I find most - not all - of Lars' arguments either bogus, or minimally compelling at best. I mean really, "almost everybody uses MySQL", "many many joins", "Tcl not the sexiest" - all listed as a major flaws of OpenACS? Please, that verges on pathetic. I expected rather better analysis than that from Lars. In fact, AFAICT most of his complaints aren't actually specific to OpenACS at all.

I suspect an unstated problem here may be just that smart hackers get tired of working on the same stuff month after month. You burn out, and want to try something differnt.

Now, of Lars' bullet points (and some of the implicit ideas from his text), IMNSHO these are the only contentions that are actually important:

1. OpenACS community not growing enough.
2. OpenACS code quality uneven.
3. Ruby on Rails is a better toolkit than OpenACS.

I don't have many comments on those points, as I don't really know to what extent they're true. They're important questions to ask though, and I'd like to see others thoughts on them here.

I'm also pretty disapointed with what seems to be the, 'Ruby on Rails rocks, but I'm not going to bother to tell you exactly how or why, it's just better.' subtext of Lars' article. I'm not familiar with Rails, so I'd definitely have liked to learn something about it vis-a-vis OpenACS besides that Lars was "blown away", and that "all the problems that OpenACS had were solved."

Also, like Simon, I think Lars is completely off base with his hand-wavy "reuse in the large is an unsolved problem" argument anyway. What's critical for reuse? Clean, well factored, well maintained code. OpenACS is large, has grown organically over a long time, and has not had nearly as much dedicated house-cleaning and re-factoring as it could benefit from.

Think about it: Don has periodically complained about the ugly beast that ad_form has become (thanks in part to Lars' hacking on it...), and there are probably plenty of other similar (if less obvious) spots in the codebase. (Hell, I volunteered to refactor the acs-tcl code into Tcl packages suitable for use either within or without OpenACS, "sometime", but I've still never got around to even starting on that.)

When it comes to adapting code to new, unanticipated circumstances, simplicity and cleanliness of the codebase are key. IMNSHO OpenACS isn't all that bad in this regard, but there's definitely lots of room for improvement. For OpenACS, a useful yardstick is AOLserver: We should aspire to have OpenACS code at least as clean as that in AOLserver.

Btw, my uses for and interest in both OpenACS and AOLserver are similar to (if a bit less broad than) Simon's. They are both toolkits, and rather full-featured, ready to go ones. Kind of like an industrial sized Dremel tool that comes with 67 bits - but keeping the bits organized and sharpened and replacing the ones lost or broken over time takes real work.

And yes I know, the sticking factor is always time, especially time of the most expert developers. I don't have any answers there, but certainly welcome suggestions from others...