Re^4: Another prediction of Perl's demise

For example, try comparing the process of getting the contents of a text file into a variable in Perl vs. PHP. Hint: In PHP, you only need one function in a short line of code.

This really has nothing to do with the point I was making, but I'll bite. I'll agree that many things are easier in PHP. This flows from PHP's philosophy of shoving everything in as individual built-in functions. I have many problems with this philosophy, but it's pretty clear that it makes many things easier.

The example you chose, though, isn't quite as dramatic as you make it to be. As others mentioned, the best answer (in terms of effort) is probably to use File::Slurp, but it's not very difficult to do in core Perl, either:

  my $foo = do { local (@ARGV, $/) = "bar.txt"; <> };
[download]

Now, the PHP code is simpler and more obvious, but the Perl is no great feat. It's common enough that most good Perl programmers should recognize it immediately. Again, I'm not trying to say your main point about PHP being easier is wrong, but I don't think this is the best example of it.

Comment on Re^4: Another prediction of Perl's demise Download Code

Replies are listed 'Best First'.
Re^5: Another prediction of Perl's demise by apotheon (Deacon) on Nov 28, 2004 at 03:03 UTC
Granted, there are surely better examples. I'm not precisely what you'd call a "good Perl programmer", though. At this point, only the obvious is likely to occur to me, because I just don't have the depth of knowledge necessary to conceive of the unobvious in Perl (usually). C'est la vie. In any case, even if it's not the "best" example, it is still an example that is somewhat effective. By recognizing that there are other, better, examples, you only make my point more concrete. In any case, my point is mostly predicated upon the notion that often the programmer's time is more valuable than whatever benefits you may gain through more time-intensive code implementations. The fact that PHP can often save hours of programmer time is its most compelling point of value. I, too, find the PHP philosophy of "too damned many tools" to be troublesome, but that doesn't change the fact that sometimes its benefits outweigh its detriments. There are also times that Perl is easier, of course. In those situations, there's not much to be said for using PHP instead. It doesn't seem that we disagree, in the final analysis. My only reason for bringing it up was as a reminder that sometimes the "overall better language" isn't the better language in a given instance, and if you have the resources and capability to choose either of them for a given job, you should just use the right tool for that job. Don't limit the tools you will use if you don't have a compelling reason to do so. - apotheon CopyWrite Chad Perrin	[reply]

Replies are listed 'Best First'.

Re^5: Another prediction of Perl's demise
by apotheon (Deacon) on Nov 28, 2004 at 03:03 UTC

Granted, there are surely better examples. I'm not precisely what you'd call a "good Perl programmer", though. At this point, only the obvious is likely to occur to me, because I just don't have the depth of knowledge necessary to conceive of the unobvious in Perl (usually). C'est la vie.

In any case, even if it's not the "best" example, it is still an example that is somewhat effective. By recognizing that there are other, better, examples, you only make my point more concrete.

In any case, my point is mostly predicated upon the notion that often the programmer's time is more valuable than whatever benefits you may gain through more time-intensive code implementations. The fact that PHP can often save hours of programmer time is its most compelling point of value. I, too, find the PHP philosophy of "too damned many tools" to be troublesome, but that doesn't change the fact that sometimes its benefits outweigh its detriments.

There are also times that Perl is easier, of course. In those situations, there's not much to be said for using PHP instead.

It doesn't seem that we disagree, in the final analysis. My only reason for bringing it up was as a reminder that sometimes the "overall better language" isn't the better language in a given instance, and if you have the resources and capability to choose either of them for a given job, you should just use the right tool for that job. Don't limit the tools you will use if you don't have a compelling reason to do so.

- apotheon
CopyWrite Chad Perrin

[reply]