Forum OpenACS Q&A: Why perl, you ask?

Collapse
7: Why perl, you ask? (response to 1)
Posted by Jim Lynch on
Adam,

I'll start with my own reasons...

I've been playing with/learning about the ACS for perhaps 2 1/2 months, starting with a friend's suggestion that I install the pieces of the ACS for a project he is working on. He has since moved it to a different platform, but I'm still here, mostly due to Phil's excellent pedogogical coverage of it. I don't think the other toolkits of this kind have that kind of coverage and I share Phil's belief that kids are the future and should be encouraged, allowed and shown how to create stuff.

I've been doing some volunteer work at a nearby community college, keeping their connection up and creating student accounts. Over a period of maybe 9-10 semesters, I created and maintained the Roster Project, a collection of perl scripts that processes a file downloaded from the school records computer and produces scripts that run on the servers, to assign login/password accounts on those servers. The Roster Project is available under the GPL.

Presently, an admin person needs to know perl in most or all aspects of running the Roster Project, including setup, beginning-of-semester preparation and actually running the student database updates. This is primarily because admins can then look at the data and create scripts to solve problems that come up and partially because the admin has to write some scripts and alter others to customize for his/her site.

I looked into ways to present and allow editing in other ways, but never got around to implementing them, when the ACS came along. I thought, "great, and I can learn it for free if I put the effort in".

So, I dug into Phil's problem set 1, learned TCL, improved on my SQL and got through some of it.

Working through some of the problems, I think I forgot maybe 9 times during a two-week period, that you need

      ... [expr a + b * c] ...
if you want to evaluate any kind of arithmetic expressions. Each time meant 2-3 hours hunting for the problem. When I became aware of this, I realized I didn't like TCL much. The source to some of this was that when you begin a TCL statement, you don't need [ ... ], so TCL compares unfavorably to lisp or scheme, which is at least consistant in this regard.

They say "Strings are TCL's only data structure", but they forgot arrays and lists. They also forgot to make them first-class structures, and that often frustrated me. I was often in the position of returning a set of key/value pairs, especially in books.tcl/books2.tcl.

My summary of this part, is after about 2 weeks of working through problem set 1 and not even getting through (I have more than 20 years of programming experience. I was implementing the FORTH programming language 20 years ago), I find TCL to be typing-intensive, clunky and incomplete, especially in its choice to not make its aggregate types first-class objects. In short: personally, I can code faster in perl, and make deeper things in it. I'm not saying anything about anyone else here, just me. I also want to incorporate the code I already wrote in perl; I can't do that efficiently using CGI for reasons known here. So, I wanted to make perl as close as TCL was to aolserver.

At the point I switched from doing the problem sets to working on the perl interface, I had no clue of perl internals or aolserver internals. With a bit of help and a lot of reading, I was able to take an exposed aolserver data structure, an Ns_DString, and present it to perl as an object-oriented class, with the operations directly mapped to the Ns_DString operations. Once I saw this was possible and played a bit more, I went over to the aolserver side and wrote a way for it to invoke the perl scripts in response to a web browser inquiry.

That brings us to the present, as far as my projects are concerned: aolserver can invoke a perl script (to which it hands off a Ns_Conn object) and the perl script can send stuff (like an HTML page) to the browser.

I think this project can help OpenACS and ACS itself by providing a better scripting language. (And if that doesn't do it, I think scheme should be next :)

The perl people will stop screaming. (well, they will scream less loudly: the API planned now is -very- C-like, very efficient, very close to aolserver and not something a perl coder would be used to. Compare the TCL commands for aolserver with the C api to see the analogy.) Another more perl-friendly API is planned, but its development can't be started (imo) until this "low-level" API is fully functional and available. Given the low-level API as a platform, prototyping such an "outer layer" of the API would be made much easier to accomplish, think about, form new concepts and try them.

Because there is now movement in this direction, the ACS community will get larger. More will be able to participate immediately. I plan for this functionality to be cooperative with aolserver's TCL and to be complete in its implementation of the aolserver API.