Absolutely, Perl has some organizational features. But many of the techniques that Perl encourages for short programs work against good organization. The longer the program the more strict you want the language to be. The reason people complain is that those features allowed Perl to handle applications style programs without all the features you would want A few bolt ons don't solve Perl's problems. Ultimately an entirely different language the right thing for large projects.

You don't use your password much your browser remembers on /. for a long time. Besides after 14 years you could just pick an easy to remember password and use that.

There never was something like a Perl kickstarter project where they put forward a "for $500k we can finish Perl 6 in one year". This is a two way street.

I think a lot of Perl 5's issues would have been fixed had the focus not shifted to Perl 6. Perl had a very active community. There is nothing about the ideas behind Ruby on Rails that couldn't have happened in Perl. Perl had a community 10x the size of Ruby and Python's combined. The Perl 6 community had a long track record of success and focused everyone's attention on Perl6. I was OK with learning Perl 5.6 features. But there has been a ton since then I didn't learn and I didn't learn them because I was waiting on the better way to do them in Perl 6.

COBOL has been passing since the 1970s. You probably want to use another analogy. Perl5 will be very lucky if it passes as slowly as COBOL.

Good comment. You should get an account.

Perl remember originated with short system automation scripts a replacement for Sed and AWK. It wasn't uncommon for a Perl script to be one line

perl -e... in a shell script.
And then of course a replacement for shell scripting. Perl handled 20 line programs wonderfully. But what works well at 20 lines doesn't work so well at 2000 lines. Perl took on new problem domains.

C written in BCPL
Later C written in B
Later C written in NB

Most popular modern C interpreter whose key components written in CIL (an artificial object oriented assembly)
2nd most popular modern C interpreter whose key components are written in llc & lli

The Perl6 interpreter has pretty good compatibility with Perl5. They are doing that so that Perl6 can use most Perl5 modules.

At this point what's the advantage in not pushing through? Perl 6 already Osborned Perl5. Perl6 is a heck of a huge upgrade. After 14 years there has been a tremendous amount of progress (about 1/5th the pace it should have had but still it has happened).

There has been at least 2 huge shifts in culture in /. since I've been around and I think I was part of the 2nd wave that replaced the original /. crowd. I suspect a lot of the guys with sigs 200k and below were enthusiasts about Perl. In 2000 I would have called Perl my favorite language. By 2005 when Pugs came out I was a Haskell fan so the idea of a dynamic language with the fluidity of Perl having many of the powerful idioms of Haskell (what Perl 6 sort of has) was tremendous. A computer project that takes 14 years is unacceptably slow. We should have had Perl6 a decade ago. People in 2000 believed that in 2004 we'd be hearing that Perl 6 was ready and Perl 5 was legacy. That not having happened changed hearts and minds.

There is nothing irrational with opinions being guided by changing facts.

Secret from the general populace: yes. Secret from large corporations and lobby groups: hell no.

I'm not sure whether you've ever tried influencing a non-binding agreement that was reached in diplomatic circles and which supposedly still needs to be ratified by politicians in public. I can tell you that by the time a completely negotiated deal ends up in a parliament, senate or council of ministers, there is an enormous amount of political pressure to approve it because of all of the efforts that went into negotiating that text. At that point, the negotiating parties have basically all said "yes, we agree with this and are willing to defend this text before our national politicians", and a very much used argument (that also carries a lot of weight) is then "we don't want to seem unreliable to our negotiation partners".

Sure, they may sometimes make a little bit of fuss about small details to "demonstrate" they're not just rubberstamping it, but actually completely changing positions on a matter of substance almost never happens (unless there is a huge public outcry, or a very big business interest). And even if that happens, it means all those negotiations were largely for nothing, which could have been solved by having more transparency in the first place.

No. CA's root certificate was never on a publicly accessible server. This was an idea thrown around at the time as an example but the example isn't true. Besides most websites have reissued certificates and most users have gotten the new ones. Most important websites also have additional checks which make man in the middle hard to do. Is somebody somewhere going to get hit? Sure. There is a big target area. But this was an easy to fix problem (though widely spread) and it was addressed quickly and effectively.

Honestly it is a plus for open source. When they did drop the ball the able to own and thus fix it very fast.

Many exploits existed for years and we don't know how long the bad guys had them. That's the nature of the thousands of exploits that come out. All the time you see new exploits dating back to Windows Server 2002. The reason you are so freaked is because you don't know about the others.

As proving stuff you haven't proven anything. You are just asserting. As for Canada it was a teenager trying it out. He didn't do anything. Nothing much happened. The fact that this was the first example that comes to mind proves my point.

The person who wrote the bug has described at length where the bug came from. The source code, and email history at the time obviously supports the very non paranoid origin that it came from a performance tweak to avoid allocating and deallocating memory. There was no NSA involvement.