in reply to Re: From PHP to Perl - Should I, and how?
in thread From PHP to Perl - Should I, and how?

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?
  • Comment on Re^2: From PHP to Perl - Should I, and how?

Replies are listed 'Best First'.
Re^3: From PHP to Perl - Should I, and how?
by locked_user sundialsvc4 (Abbot) on Mar 09, 2009 at 20:56 UTC

    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.