3 ms·

When you're passing parameters to a subroutine in Perl, all you're doing is passing a list. Not an array, but a list. The foo subroutine you posted, just wouldn

When you're passing parameters to a subroutine in Perl, all you're doing is passing a list. Not an array, but a list. The foo subroutine you posted, just wouldn't be written in Perl. Besides, have you seen the syntax for passing arrays in PHP? Zend Framework is fugly: protected static function _assembleRoutes() { $routes = array(); $routes['entry'] = new Zend_Controller_Router_Route_Regex( "[0-9a-z._!;, \=\-%]+-(\d+)", array( 'module' => 'default', 'controller' => 'entry', 'action' => 'view' ), array( 'id' => 1 ) ); return $routes; } 10 lines to create an object = foo($bar);

mechanical_fish 18y ago
The foo subroutine you posted, just wouldn't be written in Perl. I think I said that, didn't I? What I wrote is wrong, absolutely. I believe the correct thing to do is to either learn all about Perl references and dereferencing syntax so that you can pass lists of references to your Perl subroutines... or to switch to a different language. The history of PHP tends to suggest that most people pick Option Two. PHP is a bad language filled with poor design choices. It is worse than Perl on every level except readability and learnability. Unfortunately, readability and learnability turn out to be very, very important. That's my only explanation for why PHP has crushed Perl in the web-language marketplace. (It's not as if Perl didn't have a big head start.) I find myself working as a professional PHP programmer. But I, too, cannot find it in myself to love the example that you have posted. To pick on just one aspect: I am sick and tired of typing array() all the time. When PHP was mining Perl for ideas, couldn't they have chosen [] or {}? And, yet, though I don't like the fact that your PHP example is 10 lines long and full of cruft, at least I can read it. I understand it. It is built out of very simple pieces, not the least of which is that damned array() syntax, which is used everywhere and which every PHP programmer learns to understand right away. Let me ramble on about array() for a bit, because I often ponder it, as one might ponder Picasso's Guernica. The designers of PHP seem to have been so dead-set on making its datatypes simple (at least until they made two separate attempts to bolt on Java's ugly-ass class system, but don't get me started on that...) that (except for classes) PHP only has one non-scalar data structure, array(), which serves as both a hash and an array. This is an astounding design decision. On the one hand, PHP arrays are the centerpiece of my dislike for the language, because their semantics are just crazy. I complain about Perl's semantics, but PHP is unreal: Calling the wrong function on an array will transform all its string keys into arbitrary integers, or renumber your integer keys without telling you. You have to learn two ways to concatenate arrays: The one that turns all your keys into integers (discarding their original contents), and the one that doesn't. Or, consider: Until you explicitly sort it, a hash has an implicit sort order that is independent of the keys or values in the hash, but depends only on the order in which the elements were originally inserted. It's very quirky. And, yet, I have to ask myself: Perhaps this only seems nuts to me because I learned Perl first. Perhaps newbies love the PHP array(), because when they see a variable they know that it is either a scalar or an array -- and, if it is an array, they know what to do with it! They don't have to worry about the distinction between an array and a hash. They don't have to worry about accidentally passing a hash to something that wants an array. The foreach() syntax is always the same. You see, the array may be a crappy data structure, but it is our crappy data structure, and OMG Alan Perlis was right even about PHP: It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis Is this insane? Yes. But there has to be some reason why PHP is such a success.
- DavidMcLaughlin 18y ago
  We're getting down to personal choices here. What you think is readable depends on how well you understand the language. Some people don't like sigils, which Perl uses in abundance. Taking a look at your PHP example, you have: function foo($bar, $baz, $quux = array('quux' => "default")) { What is $baz supposed to be here? I have no way of knowing that it's supposed to be a scalar, array or associative array. The strength of sigils for readability is revealed in the equivalent Perl code: my ($bar, @baz, %quux) = @_; Here I know instantly, without reading any further documentation, that this subroutine expects a scalar (which in OOP would be the current object instance), an array and then a hash. It took a while, but I find this readable. What PHP has over Perl, and indeed every other language right now is lowest-barrier-to-entry for web development. Out of all the other languages, it's the only one designed for the web. On top of that, developing Perl ,Python or Ruby on a Windows machine is NOT fun and it's not easy. You want to play with PHP? Wampserver or Xampp can get you up and running on XP and Vista in seconds. Even if you manage to set up a Perl environment, you've still got CGI and DBI to install before it matches what PHP does out the box. Already I've installed Strawberry Perl, Apache, mod_perl and standard CPAN modules and all I wanted to do is a simple contact me form on my website! That's why PHP is such a success.
  - mechanical_fish 18y ago
    I agree that sigils are quite nice for readability. But haven't we established that this: my ($bar, @baz, %quux) = @_; while nice and readable, also isn't valid Perl? Because you have to pass references to get both an array and a hash into a Perl subroutine. So doesn't the actual Perl code look something like this? [1] my ($bar, $baz, $quux) = @_; ...and then, in the function, you have to remember to say @$baz because $baz is an array reference and %$quux because $quux is a hash reference? And then we have much the same readability problem as PHP, don't we? Except that the PHP programmer has to make fewer guesses, because the language has one fewer fundamental datatype. ;) (I believe, in my own Perl, I used to work around this issue by using a lot of objects to encapsulate my hashes and arrays.) Correct me if I'm wrong. I was never the world's most expert Perl programmer, I haven't used the language in several years, and Perl may have improved since I left. --- [1] Not that there isn't more than one way to do it.

mechanical_fish 18y ago

The foo subroutine you posted, just wouldn't be written in Perl. I think I said that, didn't I? What I wrote is wrong, absolutely. I believe the correct thing to do is to either learn all about Perl references and dereferencing syntax so that you can pass lists of references to your Perl subroutines... or to switch to a different language. The history of PHP tends to suggest that most people pick Option Two. PHP is a bad language filled with poor design choices. It is worse than Perl on every level except readability and learnability. Unfortunately, readability and learnability turn out to be very, very important. That's my only explanation for why PHP has crushed Perl in the web-language marketplace. (It's not as if Perl didn't have a big head start.) I find myself working as a professional PHP programmer. But I, too, cannot find it in myself to love the example that you have posted. To pick on just one aspect: I am sick and tired of typing array() all the time. When PHP was mining Perl for ideas, couldn't they have chosen [] or {}? And, yet, though I don't like the fact that your PHP example is 10 lines long and full of cruft, at least I can read it. I understand it. It is built out of very simple pieces, not the least of which is that damned array() syntax, which is used everywhere and which every PHP programmer learns to understand right away. Let me ramble on about array() for a bit, because I often ponder it, as one might ponder Picasso's Guernica. The designers of PHP seem to have been so dead-set on making its datatypes simple (at least until they made two separate attempts to bolt on Java's ugly-ass class system, but don't get me started on that...) that (except for classes) PHP only has one non-scalar data structure, array(), which serves as both a hash and an array. This is an astounding design decision. On the one hand, PHP arrays are the centerpiece of my dislike for the language, because their semantics are just crazy. I complain about Perl's semantics, but PHP is unreal: Calling the wrong function on an array will transform all its string keys into arbitrary integers, or renumber your integer keys without telling you. You have to learn two ways to concatenate arrays: The one that turns all your keys into integers (discarding their original contents), and the one that doesn't. Or, consider: Until you explicitly sort it, a hash has an implicit sort order that is independent of the keys or values in the hash, but depends only on the order in which the elements were originally inserted. It's very quirky. And, yet, I have to ask myself: Perhaps this only seems nuts to me because I learned Perl first. Perhaps newbies love the PHP array(), because when they see a variable they know that it is either a scalar or an array -- and, if it is an array, they know what to do with it! They don't have to worry about the distinction between an array and a hash. They don't have to worry about accidentally passing a hash to something that wants an array. The foreach() syntax is always the same. You see, the array may be a crappy data structure, but it is our crappy data structure, and OMG Alan Perlis was right even about PHP: It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis Is this insane? Yes. But there has to be some reason why PHP is such a success.

DavidMcLaughlin 18y ago
We're getting down to personal choices here. What you think is readable depends on how well you understand the language. Some people don't like sigils, which Perl uses in abundance. Taking a look at your PHP example, you have: function foo($bar, $baz, $quux = array('quux' => "default")) { What is $baz supposed to be here? I have no way of knowing that it's supposed to be a scalar, array or associative array. The strength of sigils for readability is revealed in the equivalent Perl code: my ($bar, @baz, %quux) = @_; Here I know instantly, without reading any further documentation, that this subroutine expects a scalar (which in OOP would be the current object instance), an array and then a hash. It took a while, but I find this readable. What PHP has over Perl, and indeed every other language right now is lowest-barrier-to-entry for web development. Out of all the other languages, it's the only one designed for the web. On top of that, developing Perl ,Python or Ruby on a Windows machine is NOT fun and it's not easy. You want to play with PHP? Wampserver or Xampp can get you up and running on XP and Vista in seconds. Even if you manage to set up a Perl environment, you've still got CGI and DBI to install before it matches what PHP does out the box. Already I've installed Strawberry Perl, Apache, mod_perl and standard CPAN modules and all I wanted to do is a simple contact me form on my website! That's why PHP is such a success.
- mechanical_fish 18y ago
  I agree that sigils are quite nice for readability. But haven't we established that this: my ($bar, @baz, %quux) = @_; while nice and readable, also isn't valid Perl? Because you have to pass references to get both an array and a hash into a Perl subroutine. So doesn't the actual Perl code look something like this? [1] my ($bar, $baz, $quux) = @_; ...and then, in the function, you have to remember to say @$baz because $baz is an array reference and %$quux because $quux is a hash reference? And then we have much the same readability problem as PHP, don't we? Except that the PHP programmer has to make fewer guesses, because the language has one fewer fundamental datatype. ;) (I believe, in my own Perl, I used to work around this issue by using a lot of objects to encapsulate my hashes and arrays.) Correct me if I'm wrong. I was never the world's most expert Perl programmer, I haven't used the language in several years, and Perl may have improved since I left. --- [1] Not that there isn't more than one way to do it.