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

[James Smith]

Not a lot of traffic here, so I figured I'd ramble a bit on Perl
Modernization and get some feedback on my evolving strategy to do
that.

Since it will be twenty years this fall that I started using Perl, and
since there is an urgent need for me to (once again) refactor my
Perl-career perspective, I have been looking back over the many large
projects that I have designed and implemented in Perl, from the early,
completely non-object oriented days of Perl 4, through the early
object oriented efforts of early Perl 5, to my current efforts to
absorb the strongly abstracted, object focused frameworks of "modern"
Perl.

Initially, I needed to better understand what had happened while I was
working in my own trench at the University over the past eight years.
With the help of comments from members of this list, and the comments
of many hiring managers, I was able to ferret out the requisite skills
and determine what resources i would need to start climbing that and
eventually convice some hiring manager that I am sufficiently
"modern".

But then I needed to better understand how my Perl Past and Perl
Experience and Perl Knowledge was going to "fit" in this "Modern Perl"
world. In previous re-tooling efforts process was more of a process of
adding on to the knowledge and experience that I had at the time, sort
of like adding rooms to the original homestead. This time, however,
this approach is not sufficient. The changes to Perl, to the web and
the world of software in general has shifted in surprising and
significant ways that diverge from the somewhat linear manner that
occurred from the time I wrote my first Fortran program in 1974 to
when I designed my Perl-Lamp MVC web framework at the University in
the 2000-2002 time frame. "Adding on" to that experience and knowledge
foundation and infrastructure would have been a disservice to the
Perl-based module libraries and programming methodologies that have
evolved, almost exponentially, since 2002. Although the "old" Perl is
still there, underneath, and one can continue to write code, even
large systems with integrated, reusable libraries, perhaps even a few
object oriented modules, the simple fact is that "Modern" Perl is
structured entirely differently, with an entirely different level of
abstraction brought into play and significantly more demanding
expectations and assumptions directed at it. Today, before the first
line of code is written, there is an urgent need to know available
frameworks and the plugins that can be called upon to "extend" the
framework. Even Perl itself has been radically "extended", to the
point where an "old school" Perlite (i.e. me) won't even recognized
many of the linguistic features, simply because they did not exist
five, ten, fifteen, twenty years before.

Once I realized that Catalyst was the mountain that I needed to climb,
and that JavaScript had become the front-end user-interface that
gleamed at the top of that mountain, I realized that I needed to start
at the bottom, in Dante's Interno, "old" Perl and work my way up to
the mountain of Purgatory that would lead to the Paradise of sparkling
(bling) of JavaScript-enable user interactions. there was no other
path.

I started off with the installation os Catalyst itself and worked
through some of the tutorials, but then I realized that, with the
advent of Moose, DBIC, Perl Template Toolkit, Test::Harness, and many
more modules and extensions to Perl, that I really didn't have a
strong, gut-level feeling for the internals of Perl, Perl Modules and
Perl Object, even though I had been using them for years. 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. 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.

So, I started over, because it was difficult to sort out when a
particular feature worked its way into the Perl world over the past
twenty years.. When you learn a language on the fly, on the job, in
the line of fire, you look until you find something useful, or you
write function, put it into a module and move on. There is little time
to put all of the available components on the table and learn how to
use it all in some systematic way. 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.

that being the case, I am building a Perl/Catalyst system from the
bottom, piece-by-piece, from the the Components of Test, DBIx::Class,
Perl::TemplateToolkit, etc, using all of the most  recent Object
Oriented methodologies. Life is hard, down here in the Inferno, but at
least the direction is "up" now, rather than "down".

Later...

The not-quite "modern" Perl geezer...

Jim
josjr69 at gmail.com

-- 
James Oliver Smith, Jr
josjr69 at gmail.com
www.cyberpoet.com