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.

Two words: port knocking.

You may laugh but it hides you from casual attackers pretty definitively. IOW, bot net brute forcers no longer clog up my auth log.

Facebook is, in the long run, far, far more destructive than 4chan.

If you're baffled I'll give you a hint: On 4chan everything posted is gone in at most hours, or it was screencapped and might exist forever... but is still anonymous. In order to fuck yourself over you have to knowingly enter personal information on a sight *everyone knows* is a seedy place.

Facebook, on the other hand, promotes a variety of character-destroying vices, such as most of the "games", encourages anti-social behavior worse than any high school I've ever heard of, and records each and every thought, picture and mistake, combined with identifying information, forever.

In 20 years the shit I do on 4chan today will be as forgotten as it will be by tomorrow, but anything I might put on Facebook today will be part of a permanent record of my character, no matter how much I might change, and will be used against me in any way it can by any enemies I might make.

Yes, 4chan is safer and better for children than Facebook! All the same, I would not let a child younger than 10 have unmonitored access to /b/, but of course I would not let a child less than 18 have unmonitored access to the hell-hole that is Facebook, either.

People *should* experience this pain. Maybe that will teach them not to **rent** software and not to trust software-as-a-service. If you let your save file and the entire game be stored on someone else's computer, especially at their expense, sooner or later you will lose access to it or have it (mis)used by another party. It's better that people wake up to this sooner rather than later, and if it takes having years of effort poured into a time-sink game to make people start thinking that maybe, just maybe, there's a reason to not give away their data, then that's *good*.

If you can't control it *you do not own it*. Learn to love Free software, learn to love the AGPL and learn to love *open* services you can, if necessary, host yourself or, at the least, pay multiple parties to host for you.

And stop using facebook! If you think *this* is bad, just wait for when that behemoth starts to fall.

If the alternative isn't GNOME or XFce but instead "just" a window manager, then KDE is indeed far more resource-intensive than the alternatives.

Compare your stripped-down KDE with fvwm2, e16 or twm. Go ahead and leave out your launcher, desktop and everything: compare *just* kwin. It's far, far heavier.

When you need "Just a WM" it's better to avoid the DE-focused WMs.