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;
}
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.
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.
my ($bar, @baz, %quux) = @_;
my ($bar, $baz, $quux) = @_;
(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.
sub foo {
my($someflag, @subjects) = @_
sub foo {
my($self, %options) = @_
sub foo {
my($positional, %named) = @_
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);
sub foo {
my($bar, @baz, %quux) = @_
void foo(int bar, void *baz[], hash_t quux) { ...
sub foo(Ibar, Abaz, Hquux) ...
The simple syntax works in multiple Perl alternatives: PHP and Ruby are the ones I know about. Both languages have intelligent defaults to eliminate the need, in many cases, for newbs to think hard about what they're doing. (By default, PHP passes an array of arguments, by value -- with hidden optimizations to avoid the overhead of excess copying. The PHP argument array may include entire arrays as arguments. Meanwhile, in Ruby everything is an object, so Ruby passes an array of object references.) These are the languages which constitute Perl's competition, today. (Along with Python, of course, which I am unfairly leaving out of my argument because but I don't know how Python handles arguments! But I'm sure the answer is "with reasonable intelligence".)
Haskell's type system. ;-)
I also spent some time with a large Tcl project (OpenACS) and found it very painful. But, I've never learned Tcl with as much enthusiasm as I learned Perl or Python, so I might be wrong. Actually maybe it's just CMS that really suck. I hated spelunking in Zope, and I hate working with Joomla (for different, but no less strongly held, reasons).
Declaring a function in PHP which accepts a scalar, an array and a hash:
Declaring the same function in Perl: Which is already terrible. Worse, despite being relatively intuitive (I've made the mistake of writing this more than once, whenever I forget too much about Perl) it's completely broken. In the words of the Camel book:If you want to pass more than one array or hash into or out of a function and have them maintain their integrity, then you're going to want to use an explicit pass-by-reference. Before you do that, you need to understand references as detailed in Chapter 4. This section may not make much sense to you otherwise. But hey, you can always look at the pictures.
Here we see that Perl's syntax isn't just very ugly: It's hopelessly entangled with relatively-advanced concepts like references, and dereferencing, and pass-by-value vs pass-by-reference, and wacky only-in-Perl nonsense like "array context" vs "scalar context".
Even PHP can do arguments right. Meanwhile, Perl doesn't even apologize for being a language where you have to learn about pointers before you can walk.