Doesn't Slashdot have a big fat load balancing system in place? The speed issue was dealt with by throwing more hardware at the problem. So, like you said, it comes down to design and achitecture. I suppose somebody could code a website using Q-BASIC on several heavy duty machines behind a load balancing system, but that's probably not good design.

To me, I find Perl very fast and easy to develop with. Not only is CPAN sweet, but PerlDoc rocks as well. I use references constantly when I code, and PerlDoc is always there when I need a hint.

They describe the machines that power the site here. I wouldn't call 10 Intel boxes a big fat system. They probably cost less than one Sun box.

More importantly, if it is a problem that can be solved by throwing more computers at, then you have a linear growth scalability. If you have a bad implentation, like bad algorithims, you could end up with an exponential growth, which cannot be fixed by throwing more computers at it. Perl can obviously support good programming and linearly scalable systems.

Slashdot actually used to be fast, and back then it ran out of Malda's appartment. (I have a userid in the 2000's). It requires a big fat pipe because it uses it. It requires load balancing because it gets enough traffic to need a big fat pipe.

I'm afraid I can't agree. There are just so many cases where the sigils aren't enough to disambiguate clearly in people's brains. And references are the main cause of this. But also look at slices. Here's a hash slice:

@foo{ qw(a b c) } = qw(x y z);
[download]

Now what does the @ have to do with the variable? The correct answer is absolutely nothing. The sigils in perl are used to denote the type of the operation, NOT the type of the variable. Because the slice above operates on a list it uses the @ to denote a list. But damn, is it ever confusing.

To take it further, you say ref($var) is enough, but how do you do that while coding? You can't - you can only run ref() at runtime. So sigils aren't serving their purpose there. Also now let's suppose ref($var) returns nothing, so what does $var->(); do? It possibly executes a function! But ref() told you nothing, and the $ told you nothing. (yes, I'm aware strict will catch that, but what if the purpose is to run a function? Then you have to have strict refs off for that section of code).

Now take it a step further. What about $var->{entry}. Most people these days are doing OO (aren't they?) so what does the $ tell us this time? Nothing, because the type of $var->{entry} is totally and utterly opaque to the naked eye.

Extreme example time. How do you do a hash slice of a hashref belonging to an object implemented as a blessed hashref? (did you parse that? It's hard to read, but it's even harder to figure out without severe experimentation how to do it). The solution is the totally inelegant:

@{$var->{entry}}{qw(a b c)} = qw(x y z);
[download]

So now what part of the above defines the fact that it's a hashref? The answer is the openning curly bracket just before the first qw. Nope, sigils were pretty useless once again.

OK, rant over. Sigils really aren't all they're worked up to be. They have a purpose, which was fine for perl 4, but I think when perl 5 came along it all but made them useless.

There is a difference though between whether there is a sigil, and what it's used to denote. (In Ruby they denote scope.)

Makeshifts last the longest.