Forum OpenACS Q&A: Re: Reuse in the large is an unsolved problem !?
My take as a completely non-active developer, is many fold.
I was tempted to write a "Why I stayed with OACS and dumped my thoughts to move to ROR", I don't have time. Instead I will try to explain some of the reasons I stayed as well as some perceived problems.
1. ROR is still at pre-release, not a big deal but nonetheless, we will see how big a behmoth it becomes. I remember the old AD days when ACS was much, much smaller. I can't think of any project that doesn't bloat.
2. I don't care that TCL/AOLserver is not mainstream. I am not marketing to anyone and to be honest with you, my short look at ruby didn't impress me. Nice language, but why change, been there done that. In fact I used Perl 1.0 when it was still Practical Extraction and Reporting Languge. I used zortech C++ 1.0, MS C 3.0, Borland Prolog and Turbo Pascal, need I go on. I find the promise of yet another language that will change my life not only boring but counterproductive.
3. Contrary to the MySQL brainwashed, you can't convice me that ACID is a bad thing. http://www.loudthinking.com/arc/000516.html is a bunch of hogwash written by a good software engineer that seems to not have a grasp on writing for databases. Yes, I know that is flamebait, but that isn't how I mean it. Mainly that after 20 years of software development, I too know a thing or two about reality.
4. OACS already has many of the apps I need and is improving all the time. Are all the apps category killers... of course not. Are they good enough, certainly and I would still bet there are more ACS/OACS sites going than there are ROR.
5. AOLServer kicks ass, that is the end of the story. Screw Apache, read the history of A Patchy Server and you will gain a much better appreciation of AOLserver. Also, do a little research on security issues and you will definitly be impressed.
Now for the bad..
1. Yes it is true that the complexity of OACS is at an insane level. I can't even figure out the best practices for writing a package anymore. And for the newbie users forget it.
2. .LRN, while a great commercial vehicle, has really hijacked the project. I discussed this with CR and some others 2 years ago and while I understand the impetus for adding this complexity, putting switches in the code always struck a nerve with me.
3. The moving of logic out of the DB into TCL has left me cold. The advantages of DB enforced logic are many as CR pointed out in his reply to Lars.
Now for what I would like to see.
1. Simplify the system. I can't stand the current CSS fiasco. Why is it so hard to make a page look the way you want. Why is it so hard to figure out how to CORRECTLY use the core procs and write an app, etc, etc...
2. Make .lrn a complete layer on top of OACS, not an almost requirement to run the base system. If you have to modify the core with if blocks, something is wrong. By the same token, most likely if the .lrn app needs to modify core packages, most likely that isn't a .lrn feature, put it in the core, but make sure it is really needed.
3. There are way too many ways to do the same thing. Packages should not reinvent the wheel. One of the first things I learned when OO first came out was that if your proc was more than one screen long (and remember screens were 25 lines at the time), it was more than one proc.
4. Learn from ROR and apply it to OACS. Why is there no AJAX? I am not saying this as a critisism of OACS, I completely understand the project and the volunteer nature. Also, we have Gustaf and XOTcl, why not refactor the toolkit and use some of the excellent advantages of OO. We don't need Ruby to do OO. Again, I am fully aware of the constraints of the project, this is my ideal world.
I guess I did write a "Why I stayed with OACS and dumped my thoughts to move to ROR",