We actually use Perl quite heavily where I work, and its use is only growing. We've built rather significant pieces of our infrastructure around it, including a rather impressive internal project that uses Perl as a metaprogramming language. You'll get yelled at if you deviate from the standard perl-based development flows we've put in place.

So, "isn't used all that much anymore" may be more anecdotal than not? I guess it really depends on the shop whether perl use is increasing or decreasing.

There's that typo and the fact that the < got eaten.

Personally, I don't see the point in a pissing match between Perl 5 and C++14. I use both. Perl's great for rapid prototyping and programs that need a certain flexibility. C++14 is great for rapid execution.

The perl code is fairly idiomatic, and a perl programmer would type it without thinking. It'll likely compile into an optimized sort, since this type of sort is common in perl.

The C++14 version is also idiomatic to C++14 (although I think non-member begin/end would be preferred there), and has the advantage that it'll compile an optimized sort for whatever type you're sorting.

In C++14, I can use std::vector, std::map, std::unordered_map, std::regex, std::shared_ptr, std::unique_ptr, gobs of standard algorithms, range-based for() and lambdas. These give me very similar containers and tools to what I have access to in Perl 5. That makes the conceptual leap between the two shorter. I quit worrying about syntax ages ago. Know the syntax for the language you're programming, and spend your energy on the semantics of the program and problem you're trying to solve. This is work, not a beauty contest.

I've been waiting patiently for a usable Perl 6. I did install a version of Rakudo Star a couple years ago to compete in a Perl 6 coding contest (over Christmas, it so happened). It was fun picking up the language, and I was able to implement some interesting stuff quickly, including an A* search. But, it was definitely not ready for prime time. I ran into several rough edges, and execution time was uninspiring. I've gotten accustomed to how fast Perl 5 is.

Now I'm hoping for a nice Perl 6 Christmas present this year, although I won't get my hopes up too high. :-)

Did you read the part in the article where they're actually doing the matching based on the ASTs (abstract syntax trees), and so are able to identify authors even after the code goes through an obfuscator? Relevant quotes:

Their real innovation, though, was in developing what they call “abstract syntax trees” which are similar to parse tree for sentences, and are derived from language-specific syntax and keywords. These trees capture a syntactic feature set which, the authors wrote, “was created to capture properties of coding style that are completely independent from writing style.” The upshot is that even if variable names, comments or spacing are changed, say in an effort to obfuscate, but the functionality is unaltered, the syntactic feature set won’t change.

Accuracy rates weren’t statistically different when using an off-the-shelf C++ code obfuscators. Since these tools generally work by refactoring names and removing spaces and comments, the syntactic feature set wasn’t changed so author identification at similar rates was still possible.

Regarding the first quote: The author of the article probably didn't realize that ASTs aren't a new thing; it's just this application of ASTs that's new. ASTs are as old as the hills. I learned about them from the Dragon Book, and by the time that was written they were old hat.

You mean that the cost savings of rolling out internal websites didn't drive the cost to zero, and there is a small, periodic maintenance cost to this otherwise scalable communication medium? *shock* *horror*

Maybe we should go back to mimeographed inter-office memos. Quick, someone take dictation and get this to the typing pool stat!

Why do you use IE 8? You should be using IE 6, according to your own sig. IE6 won't be wasting your time with modern YouTube videos, I bet. If that wasn't true, it probably will be true soon...

So where's youtube.com? It's not a web page on the web is it? Oh, wait...

I think we can agree that the original article has some supremely sloppy writing. What they meant to say, if I interpreted everything correctly, is this:

* Modern browsers visiting YouTube directly will get HTML5.

* Folks embedding YouTube videos into other websites will be nudged toward HTML5 by encouraging folks to use the the embedded frame API, as opposed to embedding a flash app.

Does that decompress the situation properly?

Yeah, I was sorta wondering this too. Do people browse YouTube in Chrome/IE/Safari/etc. on DVD or something?

Or is there a direct web interface that allows directly watching HTML5 videos, but doesn't involve a browser? And, presumably, doesn't involve spiders.... I'm interested in the World Wide Web, not a spiderweb.

Note that I don't really count wget / curl, since they just transfer files from the web server. There's no good reason to get web assets with wget / curl, and then browse them (sans web) with Chrome / IE / Safari / etc. on the local disk. It's a victory for pedantic semantics but also spectacularly missing the point.

I only hope that formats like these drive production of more UHD displays, bringing their price down. I don't want to watch UHD movies. I want cheap, high-res monitors for my computers.