3 ms·

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 Pe

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.
- thwarted 18y ago
  This is somewhat of a contrived example. I can't think of any subroutine in perl that I've written, or interfaced with, or seen in production code, that takes multiple types beyond the first argument. If any function is doing that, the function is too complex and should be refactored. What you do see a lot of is stuff of the forms: sub foo { my($someflag, @subjects) = @_ sub foo { my($self, %options) = @_ sub foo { my($positional, %named) = @_ etc. And in fact, when the way you call these is the 90% case for functions, at least in perl. sub dosomething_with_data(@) { ... } @data = (1, 2, 3); @moredata = (4, 5, 6); dosomething_with_data(@data, @moredata); sub invoke(%) { ... } %common_opts = (a=>1, b=>2); invoke(%common_opts, c=>3); invoke(%common_opts, c=>6, d=>5); %overrides = (b=>3); invoke(%common_opts, %overrides, c=>6); (I included the subroutine prototypes for clarity). In this case, perl is exactly DYIM without the programmer having to think about list folding, array splicing, or hash merging. It just works. This would appear to be true dynamic typing, rather than dynamic typing where I still need to be strict about how I handle the values.

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.

thwarted 18y ago
This is somewhat of a contrived example. I can't think of any subroutine in perl that I've written, or interfaced with, or seen in production code, that takes multiple types beyond the first argument. If any function is doing that, the function is too complex and should be refactored. What you do see a lot of is stuff of the forms: sub foo { my($someflag, @subjects) = @_ sub foo { my($self, %options) = @_ sub foo { my($positional, %named) = @_ etc. And in fact, when the way you call these is the 90% case for functions, at least in perl. sub dosomething_with_data(@) { ... } @data = (1, 2, 3); @moredata = (4, 5, 6); dosomething_with_data(@data, @moredata); sub invoke(%) { ... } %common_opts = (a=>1, b=>2); invoke(%common_opts, c=>3); invoke(%common_opts, c=>6, d=>5); %overrides = (b=>3); invoke(%common_opts, %overrides, c=>6); (I included the subroutine prototypes for clarity). In this case, perl is exactly DYIM without the programmer having to think about list folding, array splicing, or hash merging. It just works. This would appear to be true dynamic typing, rather than dynamic typing where I still need to be strict about how I handle the values.