[sf-perl] Real perl

Dodger el.dodgero at gmail.com
Wed Apr 11 04:00:59 PDT 2012

I see moose and mouse as simplification methods. Syntactic sugar. That's all well and good but there's a reason that people go "ooh" and "ahh" when they hear about some old school hacker who would simplify a function by scoring a line into a drum. 

While those extremes are the stuff of legend, adding such a level of simplification, to me, adds a level of complexity that is not necessary. 

We hear all the time about people dissing Perl for looking like line noise and write it off as the side effect of sigils and our ubiquitous regexes but honestly most of it is because of crappy perl coders. People who just don't "get" the language as it is. People who try from a high end to code C in perl or, worse, hack out PHP in perl. And their results look like shit, are hard to follow, and do not work within the native perl paradigms. 

Perl's bad rep for unreadability comes not from perl but from people who don't really know perl. Unfortunately, that's also one big portion of what makes it unpopular. It's a stigma that doesn't go away even if you make it look like poetry. 

The other portion of the bad rap is a reputation for slowness. One which is undeserved. When this started it was being compared with compiled languages and generally in the context of CGIs. A bad place to start when in the 90s there was no existing alternative. 

But frameworks like Moose, while they may have a valid place in full-fledged app development, have very little place in the places Perl is most likely to come in handy. 

I would most certainly review someone in a most unfavourable way if I ever saw Moose show up in the two places its most useful. Namely I see the two following concepts as inherently counterproductive to the level of goto:

perl -MMoose -e ...

use Moose;

sub handler {
    my $r = shift;

Yet the two most useful places in the world for perl are, IMO, quick and dirty scripts that still have 500% the capacity of a shell script, and mod_perl web apps that blow anything else out of the water for capabilities and scalability. 

False. Laziness. 

There are places Moose makes sense. 

And then there are places Perl makes sense. 

With all due respect to Mr. Schwartz  (and having met him IMO that's not as much as his name showing up in O'Reilly books would lead one to believe) I simy do not feel the two are very often mutually compatible. 

When they are, however, I'm sure Moose is very useful.


Sent from my iPhone

On 10/04/2012, at 4:41 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Tue, Apr 10, 2012 at 2:00 PM, Randal L. Schwartz
> <merlyn at stonehenge.com> wrote:
>>>>>>> "Dodger" == Dodger  <el.dodgero at gmail.com> writes:
>> Dodger> So... How about some old school perl without mooses and meeses?
>> Dodger> Anybody out there code in... You know... Perl?
>> Seriously, if you're launching green code and not using Moose, you have
>> some weird nostalgia in you that prevents you from being a useful coder
>> for me or my clients.
> The downside with this approach is that you are choosing a solution
> without evaluating the problem.
> Moose is a tool that is right for certain needs. I always encourage
> people to think about the specific problem they are trying to solve
> before choosing the toolset for the solution. There are many tools out
> there for your specific problem needs, but you should always start off
> with the most capable one, the brain.

More information about the SanFrancisco-pm mailing list