[Mpls-pm] Perl Gezzer Musings on "Modernization"

[Chris Prather]

While I don't quite have the same depth of experience as you I do feel
your pain.

Technically my first computer science course was a 1977 Operating
Systems Design course which I attended in-utero. I took a small break
from computers after that for about 17 years while I focused instead
on things like eating, walking, talking and dealing with general "Real
Life" issues. I came back to computers in the mid 90s because of the
Web, I knew then that this was something I would be interested in
doing with my life. I started teaching myself Perl.

This is roughly where we started diverging. I was re-introduced to
computer programming well after the explosion of Object Oriented
programming which started with Simula '67. I knew that Object Oriented
programming was going to be important and I spent a lot of effort to
learn OO design early.

Perl for the first ten years was a language that "supported" object
orientation in a very rudimentary way. You sum it up well when you
said:

> Ten years ago, Perl Objects were something one designed after there
> was some critical mass of functions that fit discernible patterns to justifying
> going the extra, somewhat exotic, step of defining and implementing a
> module that quickly squirreled away into the library used from then on
> out.

This lack of support for OO, coming from a (admittedly self-taught)
Object Oriented background, turned out to be quite a feature. I knew
more about the theoretical underpinnings of *how* my system was put
together than I could in any other language. To use the terms from the
literature, the Meta-object protocol was exceedingly explicit because
with every project you basically had to write it yourself. I went
though a couple of Perl jobs where I dealt with plain old non-OO Perl4
and other such beasts until eventually I was pointed at Moose in late
2006.

> Today, knowledge of the internal workings of objects,
> autoloading, packages, scoping, etc are no longer optional, but
> mandatory, dailing tasks that one has to think about continuously from
> the moment the first line of code is written.

I'm not sure I entirely agree with you here though. Knowledge of
Packages and Scopes are I would agree essential to "Modern Perl", but
I've managed to forget much of what I know about autoloading, and the
esoterica about Perl's object system. I still need to know about
Object Design, but now instead of needing to remember the details for
how to implement a rational object system (should I use a blessed hash
or array? do I really want to write accessors for all of these? how
much validation should I put in to this method?) I can rely upon
external tools and the knowledge I've been adding on has been more
universally applicable to languages and issues beyond Perl. I'm sure
of it's universal applicability because recently a good bit of it has
been coming from non-Perl languages that I've been applying *to*
Modern Perl projects I'm involved with. That said:

> It's kind of like tearing down the
> incrementally-evolving homestead in order reconstruct the house one
> really want's to build, rather than simply "settling" for another
> addon. I didn't want to follow recipies and construct a Perl/Catalyst
> system without understanding the components, how they worked and why
> they worked.

I fully appreciate your pain here. I went through this same process in
2006 when I had to tear down all the assumptions I had about how
Objects work and re-learn how they applied to Moose. Someone recently
accused Moose of being a totally seperate language built into Perl,
and in many ways they are right. I personally think that this is a
wonderful thing though. I can keep most of what I loved about Perl
(it's flexibility and relaxed nature, as well as the way it fits the
way I think) but expand in new directions that many languages simply
aren't capable of yet (for example outside of Moose, Scala is the only
reasonably widely adopted language I can think of that has features
similar to Roles).

Sometimes it is important to tear down the old structures and rebuild
based on the acquired knowledge of both. I've found that the process
has made me a better developer and architect. I'm currently going
through the process again while I learn this funky thing called
"Business".

-Chris