FYI: FW : Squeak and perl

[James Michael DuPont]

Dear Tunes Developers,
just stumbled over this thread on the squeak list about perl and mops.
You might find it interesting, if not, please ignore it, no hate mail
please.

http://www.distributedcoalition.org/mailing_lists/dist-obj/msg02709.html
---------------------------------------------------------------
    * To: distobj <dist-obj@distributedcoalition.org>
    * Subject: RE: [dist-obj] Squeak, administrivia
    * From: Kwindla Hultman Kramer <kwindla@allafrica.com>
    * Date: Sun, 4 Mar 2001 22:17:02 -0500
    * list-post: <mailto:dist-obj@distributedcoalition.org>

Like other folks who have weighed in on the 'squeak' thread, I'm a big
fan of smalltalk in particular and, more generally, of environments
that support introspection and mimesis. But if I can mixin the
previous thread on systems vs scripting languages, I'd like to also
put in a word here about my experiences over the last year doing
large-scale programming in object-oriented perl.

Last March I started re-writing from scratch a content processing,
storage and distribution system that collects news from about 80
publishers (currently averaging close to 500 articles a day), passes
each article by a human editor for variable amounts of
clean-up/ranking/categorization, stores the news permanently, and
finally distributes various slices of the feed out a half-dozen
channels, the most important being the web.

We had very little money to spend on this implementation and were
working under short, rolling deadlines. I chose to write the core
pieces of the system in perl, partly because I was confident of perl's
hack-it-together nature (there are always a number of ways to get
things done quickly), and partly because string processing is quite
important for large chunks of the news-processing functionality
(perl's pattern matching is pretty good). But the most important
benefit comes via apache and mod_perl; much of the code in the system
needs to live inside the web server as well as outside in normal
application land. Mod_perl was (and I think still is) by far the most
mature and flexible way to embed a "real programming language" inside
a web server.

I have been far more pleased with perl, in this capacity, than I
expected to be. I was strongly tempted to build the system in java,
rather than perl, because java has a lot of strengths, including the
static typing that gives you that patented systems programming feel
<laugh>. And if the apache jakarta/tomcat implementations had been
more advanced when I started, I might well have. But I'm very glad I
didn't.

We have about 6,000 lines of core code (and about that much again that
uses the core to do various kinds of processing jobs, plus about 100
web 'components' that, via HTML::Mason, embed perl in html), all of it
object-oriented perl. I have written a lot of perl over the years,
including a couple of moderate-sized things, like a compiler for
motoral assembly language. But I'd written very little oo perl. Once I
got over an initial dislike (or perhaps just incomprehension) of
perl's very idiosyncratic approach to defining classes and blessing
objects into classes, I found the minimalist framework liberating,
rather than frustrating.

Much to my surprise, oo perl came to "feel" a lot more like smalltalk
(in the great multi-dimensional space of subjective responses to
programming languages, that is) than like java, to me.

As with many other things about perl, this is at least as much the
result of decisions about style and convention on the part of the
programmer as it is of "inherent" features of the language -- we are
pretty consistent about structuring our classes and objects in
particular ways. But I think it's also because perl's minimal
framework is so clean and transparent that the mechanics of the system
never feel like they obscure the problem, or take on a life of their
own. 

I have always had the feeling, writing java code, that there is a
large and sometimes grumbling assemblage of machinery below the
surface laboring to provide the oo abstractions that a programmer
depends on. This is partly because of the labored cast-plus-invocation
syntax that common operations sometimes require. It's partly because
the (large and admirable) built-in libraries have not always been
consistent or complete. And it was exacerbated early on by disbelief
that a language built from the ground up to be oo had no reflection or
introspection capabilities exposed (since remedied) and later by a
year spent taking apart the language and vm spec and putting back
together a subset of the pieces so that we could write java code to
run on very small motorola microcontrollers. The vm design is not
terribly complicated, but neither is it clean or elegant by any
stretch of the imagination.

Perl's rules for inheritance and method invocation are extremely
simple. Object instantiation is not quite so simple, but only because
you have complete control over how data is encapsulated, and I have
come to value that trade-off. I do occasionally pine for compile-time
type checking, but other than that I have had few complaints about the
language during the course of this project. I have often heard perl
criticized as being a "messy" language that makes writing consistent,
maintainable code difficult, but this has not been the case for our
shop. We have a lot of very, very, very clean perl. Some of it is
dense (we use the map{} and grep{} constructs quite often, and a lot
of our classes are built around AUTOLOAD'ed method invocations to hide
some of the complexity or provide syntactic convenience), but the
viability of our company depends on our core system's being easy to
maintain and extend.

Given this recent experience, I am extremely reluctant to classify
perl as a "scripting" language, despite its lack of static
typing. It's certainly been put to "systems" use by us, and served
quite well. It doesn't feeling like we're pushing the language beyond
it's proper domain of use, but rather like I, as a programmer, have
only just started to take advantage of perl's full range of offerings.

Regarding the niftier meta-object features of smalltalk and clos, it
would be fun to write a mop layer for perl. The information is all
accessible in ref(), isa(), can() and the symbol table -- it just
needs some tender loving encapsulation. (There's a package on CPAN
called MRP::Introspection that does some of this, but it's intended to
be used with MRP::BaseClass, a template that makes oo class definition
easier. And anyway, it's no fun to use somebody else's!)

Kwindla
---------------------------------------------------------------


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com