Perl Moose
2008-04-25 16:29:19.294764+00 by
Dan Lyke
6 comments
I haven't been doing much Perl recently, I've been slinging C for the ATmega16 or, now, working in C#. However, I ran across Myth: Moose is an unnecessary dependency, and was reminded of how cool Perl is.
On C#, I was recently asked: "Is .Net development a hobby or a job and a hobby?", and I answered:
I'm just not goth enough to do (still) notYet as a hobby. Maybe when
cutting myself and ad-hoc tattoos and piercings wear thin I'd consider
doing Windows development for fun.
[ related topics:
Microsoft Perl Open Source Embedded Devices
]
comments in ascending chronological order (reverse):
#Comment Re: made: 2008-04-26 00:14:10.944935+00 by:
John Anderson
Moose is the full-on shizzle! Double-plus Genehack thumbs up.
#Comment Re: made: 2008-04-28 14:57:20.273727+00 by:
other_todd
Or, you could just find a place where no one ever has a compelling reason to try to write heavily-classed Perl and therefore you aren't always being asked to try to put a square peg into a round hole.
I love Perl. I write a lot of Perl. But I feel it is manifestly unsuited for the OO approach - and given my already strong feelings about use of OO coding in places where it's overkill - bah.
(DIGRESSION: Unfortunately Perl, like old-school CGI, is on its way out for the arena I work in. The writing has long since been on the wall. I'm holding off the monkeys by using Perl with the wondrous Template Toolkit, essentially using TT as the whole presentation layer and the Perl CGIs as just the core data-access functions - huge SQL query in Perl, process the results for readability in TT - or combining Perl with some of the nifty JavaScript based tools/widgets (Yahoo's widget collection, oddly, is especially good) and a strong DOM to get the display-time features the users demand. Either approach comes dangerously close to Ajax territory but without any stupid framework architecture.
What Ajax really means to me is "poor separation of core code and interface/presentation layer," a deliberate blurring of the two - and unfortunately that's what everyone wants. They want PHP, in other words, where things like your database accessors are right there in the page with your HTML. I have been asked by outside contractors, "Why isn't this in PHP?" five times so far this year. Yes, you can write an entire bug database application in a single PHP page (I've done it), but is that a good thing?
Sorry; end of digression. If I felt better, and was given to long code rants these days, this probably would turn into a journal entry.)
#Comment Re: made: 2008-04-28 20:18:35.462275+00 by:
spc476
What we really need is a good way to separate logic, layout and language.
#Comment Re: made: 2008-04-29 02:11:43.97271+00 by:
John Anderson
other_todd, I assume you're aware of Catalyst? Care to rant about why that isn't want you want?
#Comment Re: made: 2008-04-29 07:47:12.48206+00 by:
meuon
"single PHP page" - I'm good at that. :)
Although actually I've learned to use one file for "command and control" and do includes for the functions related to a thought process. It's not quite one PHP page, it just looks that way. - Odd note: On a current project I got tired of defending PHP, so I changed my extentions in apache's config, and now I can address the system main link as /index.php or /index.asp or /index.jsp or /index.cgi or index.pl index.bat.. (symlinks are very useful). Lots of fun in front of brain dead non-coder CTO's with a language/OS preference.
#Comment Re: made: 2008-04-29 13:23:41.171777+00 by:
other_todd
Never presume I'm aware of anything! I live in a cave. They hand me code assignments and every so often throw me scraps.
(Kidding, but in general reading about new technologies etc is something I never have time to do at work, and never have the interest to do in my free time, so I don't usually find out about a tool until someone tosses it at me.)
I've just gone and read up on Catalyst now, and I think I have seen this before, because the logo is vaguely familiar. It looks good, but the rant is in a wholly different place, and I apologize for being unclear: Essentially, I'm arguing that there are times when you don't NEED a framework. I'm not dissing them at all, I'm saying that for the kind of work I do - individual web middleware, a lot of different little solutions and applications - it makes more sense to me to just have a handful of old-fashioned Perl libraries in a location common to all apps, and do straight scripting.
(Mind you, some of those libraries may contain class definitions. I use a DAO class which I wrote a couple of years ago because I was disgusted with the complexity of others - it has functions like connect, disconnect, select, update, etc - and also a date-wrangling class. I'm not opposed to OO-style code, I just only want it when I need it.)
Catalyst strikes me as a good thing for larger projects, but the other thing you need to understand is that I'm the sole coder here and pretty much always will be, and I try to keep projects small and fairly-self contained for various situational reasons. I do like the fact that Catalyst seems to try to impose a framework using existing tools, rather than doing what so many grandiose framework ideas do and reinvent the world from the ground up.