You must not live in the USA. I recommend you reserve judgement.

Standardized tests just cause schools to focus on scoring well and ignore actually educating students. If your school does not do well on standardized tests they take money away from you, period. If your school does well you can employ more teachers at better salaries, build more schools, have more programs like music and sports, etc.. The frenzy to "win" at tests is incredible. I've seen teachers all but GIVE students the answers ahead of time in a so-called "prep" test in the hopes that woefully undereducated students will pass muster on test day. Nothing else in a public school is more critical than getting a good score (which means good percentages and good averages across the student body) on test day. NOTHING. Not student welfare, not knowledge, nothing.

The answer to this is a philosophical one. We can say pretty definitively that rote memorization is a very poor method, but there is no generally accepted "best" method.

You don't. Progress is life; are they still alive? You can only encourage and hope, measurement is pointless.

Easy. I understand lots of things that I can't remember if asked. Memorization is a very different thing than understanding.

I'll try to contrive an example: I understand English, for example, and can use it with precise correctness (and with a vast vocabulary) upon request, but if you ask me to define parts of speech or diagram a sentence I'll fail 99% of the time. I tend to score quite poorly on English exams that are not purely prose. A lot of things are like that, although less so in the discrete sciences. Do you understand recursion? Good. Can you tell me what year it was invented and by whom? You fail the programming exam! This is the way testing fails.

80% of the spec perhaps, now we're closer to 90% of the implementation. You can use almost all of it right now.

I do not disagree that for this example there are superior name choices that could have been used. I preferred not to dig through real code to find an example of a case where there was no better choice than to use the same basic name with different sigils; it does happen and it's not unclear.

And my point is sigils are part of the name, which makes each name distinct.

You could say the same thing about case-sensitive variables. The fact that you can use COLUMNS and columns in C and they mean different things is confusing, especially for neophytes! The VB solution of case insensitive names is obviously less confusing and thus superior, right? Why should anyone have to master this syntax quirk?

The sigil is part of the variable name and makes the names different (and this is very clear). Most of the time you will also alter the variable names in other ways, because it's usually a good idea, but there is no problem with leaving the non-sigil part the same from a confusion point of view *when the code is clearer as a result*. Just as COLUMNS in C is *obviously* a constant to anyone familiar with C, and just as having a COLUMNS constant should not preclude me from having a local int columns; variable.

It's not as if there's been no progress. It's much more around the corner now than it was 10 years ago, it's quite close to done now.

Yes, also thanks to you for missing the point. I was not demonstrating best Perl practices, either in naming or code style or efficiency. Yes, all of the cool things you mentioned about Python work in Perl, too! I am not doing a feature comparison chart. Congratulations, you can write a better function to read a file! You know what? So can I. Now we're *all* special, together.

Yes, thanks for missing the point. I *deliberately* chose an example where the with-sigil variables *allow* you to name different things the same way without it being confusing. Of course you *can* choose names, as I said in my post, which are not the same. Would you care to choose another example of *using variables with different sigils but otherwise the same names*? Because, you know, *that was the whole point of the example*.

It rather depends on what you call a "big feature" - syntactically not much is likely to change, that's true. On the other hand if you look at the list of changes from the latest stable release it's clear that many things continue to be improved, even more so if you look at the sum of all changes from 5.12 forward (aka the modern perl5 era).

PHP may be more actively hacked on than perl5, though I doubt it, but it cannot be called better. All the flaws of perl5, and many flaws from perl4, are present in PHP, along with a bunch of other problems.

Perl5 OO is not so much "bolted on" as "Nonexistent"--instead it has a mechanism for designing your own OO system, which is great except that most people just want to get things done and don't care about being an architect at that level. These days it's a bit better in that you can tell any new person "Don't read perltoot, just use Moose" and they'll be a lot less frustrated and get more things done.

I find this funny, because after stagnating for a few years waiting on perl6 the development of perl5 did pick back up (not a fork, but a renewal) a few years ago and is going strong. Useful things are being added, the code is being improved, and so on.

Confusing is in the eye of the beholder. Consider

sub read_file{
    my $file = shift;
    open(FILE, $file) or die "$!";
    chomp(my @file = <FILE>);
    close(FILE) or die "$!";
 
    my %file;
    while my $line (@file){
        my($key, $value) = split /=/, $line;
        $file{$key} = $value;
    }
    return %file;
}

To a Perl programmer this is all very clear despite having multiple things called 'file' in the same scope. What would you prefer? "$file, $file_handle, $file_array, $file_hash"? There are a lot of things you could do instead but they're not much clearer or easier to read, and this is more than sufficiently clear.

And before you say anything, yeah this is not the best way to write such a function. If you're thinking "WTF?" the answer is "For illustration I went with something that should be fairly clear to non-Perl people" and "I'm trying to use as many different types of variable as possible."

Most modern languages have caught up to Perl5 in terms of basic regex power, so using Perl5 for its regex is no longer quite so essential in that you can probably get as powerful a system as you probably need in any language. That said, Perl5 *still* has regex features no one else has (or perhaps that no one else is crazy enough to implement.) For better or for worse, it's still the best... ...until you look at Perl6. Okay, so Perl6 is not done yet, but when it is the bar for regular expressions will instantly go up again. There's absolutely no competition for what it does, no other language has first class Perl6-style regex.

Smart cards neat kill the stickynote-on-monitor and password-too-weak problems dead. The main problem is inevitably some things don't support SSO.

For inside a big (or small!) company smartcards will eliminate a huge weakness. Requiring remote employees to log in via cert is even better, if you can afford it, because after that phishing loses some effectiveness ("Oh great, an attacker got the boss to send his PIN again. Too bad it's useless without the private key on his card.")

It's not a silver bullet but it does help for a certain class of problem. For the web... now there's another story, we don't have anything close to the right infrastructure to support generic smart card SSO. I had been hoping that OpenID would solve this: get all sites to adopt it, let most keep using passwords and let ME set up a provider that will auth me via smart card.

It's worse than that.

It only takes one site you use being compromised and having its hashed password list stolen, then all passwords brute-forced by rainbowtable, then the table distributed. An attacker targeting you simply gets your decrypted site password from the table by grepping your email address, sees the obvious pattern and now you're busted. If you think this is far-fetched "And no one is targeting me anyway," think again. Are you sure no one will for the lifetime of any of these sites? Are you sure no bad actor will *automate* this process at any time between now and when you no longer have any accounts protected by passwords?

Entirely random garbage of > 21 characters is required for security. It's not "How valuable is the data on site $foo?" or "How much do I trust site $bar?" that should worry you, instead it's "In the event that this password plaintext becomes known, how screwed would I be?" -- if compromising one password *could lead* to another of your passwords being compromised then you must increment your screwed level based on the damage from both the original compromised password and all other potentially compromised passwords. You *must* assume that the plaintext for any given site *WILL* become known sooner or later, that is simply the reality of web-based password authentication today.

If you insist on sticking with alpha-based word-based passwords with obvious changing bits then I recommend that the passphrase you choose have a minimum of 40 characters.