in reply to From PHP to Perl - Should I, and how?
All I can say is, I know dozens of programming languages but I have never been “a convert.”
It is definitely worth your time to learn Perl and to seek to do it well. Proudly put on your neophyte's robes and feel welcomed among the Esteemed Monks who regularly visit here. Never feel that you must in any way “discount” your growing professional experience with PHP, and never expect anyone around here to think negatively of it. “Most of us use PHP too.” You have nothing to prove, nor to defend, here.
Perl is very different from PHP, in the sense that “all of what PHP can do” is only a portion of what Perl can do. Furthermore, whereas PHP by-design incorporates much of its functionality directly into the PHP executable itself, Perl by-design does not. Both of these approaches are “very defensible software design decisions,” just different ones.
There really isn't a conflict here... you're not changing religions. Many of the designers of the PHP language system are “regulars” here. If you study the list of people who have contributed meaningfully to both systems, you find a lot of the same names. The ongoing commercial success of what they've done cannot be denied. Happily, you generally do not find anyone here trying to “preach the gospel” in either direction. (I find that very refreshing.)
Fair warning: the more you learn about Perl, the more you'll use it. You'll find yourself consciously steering the “big” projects away from PHP and towards Perl. This will especially start happening when you've run into your first project that unexpectedly ran into the rocks of PHP's inherent (and, yes, deliberate, legitimate) design boundaries.
One of those boundaries is “big-core vs. little-core.” (That's just my term.) PHP has a big set of core-features that are all hard-coded into the language. Fortunately, the “one way to do it” that they've chosen to integrate into the PHP language is a pretty-good selection. But hang around Perl for any length of time and you'll see continuous reference to this mantra: TMTOWTDI = There's More Than One Way To Do It. At first, it sounds like heresy... at best, a calling-card to bad design. But it doesn't work out that way. The core of Perl is relatively small, and upon that small framework is built a fairly-endless cascade of CPAN modules. Some of them, like DBIx::Class and Template::Toolkit, represent an abstraction of the functions that are elsewhere available. For these you will find not just this one but half-a-dozen or more alternate implementations. Meanwhile, you will also find packages like Moose that very fundamentally change the language itself. (And, in the spirit of TMTOWTDI, it's being chased right along by a little Mouse.)
“You won't find that in PHP,” and really, you can't find that in PHP. The flip-side, of course, is that for whatever you are doing now, you might well say that, “but I have utterly no use for that in PHP!” And you are absolutely right ... live long and prosper ... until. One day, you hit the wall of PHP, and you can't readily go beyond it, and when you try to do so ... (hell, you have to get this thing to work somehow!) ... you know in your gut that you are now generating horrible cruft that you (or your successor) will have to maintain. You can't go back and change the tens of thousands of lines that you already did. You can't even argue in any way that the implementation and design of PHP is in any way “wrong.” But you “suddenly ran out of tool,” and you do remember that experience.
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: From PHP to Perl - Should I, and how?
by salazar (Scribe) on Mar 09, 2009 at 17:12 UTC | |
by locked_user sundialsvc4 (Abbot) on Mar 09, 2009 at 20:56 UTC | |
by salazar (Scribe) on Mar 09, 2009 at 22:44 UTC |