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
    Ok. So I'm picking up two main ideas from this post, let me know if I'm mistaken.
    1. PHP was designed to be easier to pick up at first
    2. PHP is stuck within a certain boundary, which is nearly impossible to get out of - possibly a result of the first point?

      No, I don't think that this assessment is a fair representation of my intent. I will never desparage PHP. In fact, I will always admire it.

      Like any tool, “PHP is what it is.” And it's designed to be what it is. It can do a huge number of things and it is very popular. Lots of hosting companies support it, to the point that their tech-support zombies will look at you strangely if you refer to anything else. So it must be doing something right . . . at least today.

      Nearly everything is “impossible to get out of,” such that once a project starts in a given direction, it basically cannot switch gears later. Once you're doing PHP, that project is always going to be in PHP. The same is true of Perl, o’course, but here is where the “small core” philosophy becomes useful:   you can change virtually everything about Perl and still be in Perl. It's not, as we say, “monolithic.”

      If a great number of PHP projects had hit-the-rocks, then PHP by now would have faded away as an academic curiosity. Software folks do not continue to use tools that have substantially failed them. But... when I look, say, five years down the road when I think that most of today's “web” applications will be targeted instead at “iPhones and god-knows-what-else,” well, it's just me but... I don't really see PHP there. I do see Perl there.

      You see, he said, rambling on senselessly, there is a very fundamental difference of philosophy here, and that is:   in the world of PHP, code and HTML are designed to be inter-mixed. PHP is specifically designed that way. It's one of PHP's advantages, at least in some people's eyes (though not mine). It is a deliberate and conscious design decision for which its designers do not (and need not) apologize. But now consider, what's going to happen when (amazing as it sounds now...) HTML is no longer part of the picture? And what if we (as usual...) don't quite know what's going to replace it? I'm not saying that it will happen that way, but I think it will, and what if it does? “You can't pick your winner until after the race is run, but nevertheless you must place your bets ahead of time.” Is a language that by-design meshes code with what is no longer “the presentation of choice” going to continue to be thought of as a winning horse? Is its “advantage” still there? Only time will tell. And... I don't know either! All I'm saying is that I do wonder...

      PHP will change. Of course it will. And the legacy-systems we have created will live on. But someone created “object-oriented COBOL,” too... (Hmmm, ADD 1 TO COBOL GIVING COBOL.) ... And it didn't do any good. A big language has a much harder time surviving a sea-change.

        Awesome thanks. That's a really great explanation of the situation.