That's cool, and I could see how you might get something out of it if it actually digs in on some of the tougher topics. Pipelining doesn't really affect your code until you start doing things that expose the pipe's depth, such as branches, load instructions, multiply/divide and floating point. It can be a good lesson on why instruction scheduling matters, whether it's handled by software or hardware.

In my comment above, I mentioned a class that I wasn't sure students were getting much out of, the bar of accomplishment seemed pretty low, and the things focused on seemed esoteric as compared to what actually matters. For example, the professor had the class design a machine to implement quicksort on bytes, with a memory that was only word addressable. That just seems like a pointless brain teaser.

I think it'd be far more relevant to model a simple RISC pipeline and look at the impact of, say, a branch predictor in the context of some common algorithms. Or maybe the impact of memory latency on various data structures. "Hey kids, this is why linked lists suck." "Let's see the horror show behind switch-case statements and VTables!" :-)

In other words, I was picking on that particular professor and course, not the idea of such a class.

I have worked with compilers that auto-vectorize, unroll and jam loops, collapse/coalesce loop nests, interchange loops, software pipeline instructions, and so forth. (The compiler we ship for our DSPs at work does all of these things.) And there are some compilers that will tile loop nests into chunks that fit in L1 and L2 caches, although I don't know that I've used one, unless GCC's picked up some new tricks.

But yeah, rewriting data structures, such as undoing XORed-pointer lists? I agree with you: BS! Heck, in C / C++, such as transformation is actually illegal.

I wonder if this is a case of confusing the compiler with the standard library? Most people I know who aren't compiler geeks don't really distinguish between the compiler and the standard libraries. "I don't know; it comes with the compiler!"

For example, I know if I use std::map in C++, that I'll get certain big-O guarantees. But, I don't know how it's implemented underneath. Is it an RB tree? An AVL tree? A B* tree? Some other structure? I don't actually care, but I do expect whoever's writing the standard library to pick an appropriate representation for current hardware. And I know if I upgrade my compiler (which upgrades the standard library), I may get an improved implementation of the standard algorithms.

I've met CS grad students (grad students!) that have never programmed assembly language, or really anything lower than Java. I've worked with other freshly minted CS majors that have barely gotten a taste of machine organization, computer architecture, or any of these lower level concepts. Or, they were exposed to it, they did the bare minimum to survive the architecture class with no intention of retaining the material. And, I've worked with others that were stellar and knew their stuff inside-out.

Sure, the better schools do a better job of covering computer architecture basics. But it seems a fair number cover this material rather perfunctorily.

In any case, this is a bit off the topic. I expect CS folks to know their job and their curriculum, and complaining about schools with shoddy CS curricula vs. schools that do CS right is missing the point.

Bill Nye's complaint is that most software writes (and he included that in a rather generic list of occupations, as opposed to singling them out specifically) aren't terribly scientifically literate. That has almost nothing to do with Computer Science, and more to do with how many folks fall for pseudoscientific claims and hokum.

Silicon Valley has a unusually high concentration of anti-vaxxers. Explain that. No amount of compiler theory, digital logic, virtual memory, pipelining, algorithm analysis, or big-O notation can fix the scientific literacy gap that anti-vaxxers fall into. And it's that sort of scientific literacy Bill Nye was going on about.

I have it here on my desk. IEEE 754-2008 defines a binary representation for decimal floating point, so that people can move away from BCD (Binary Coded Decimal). Your observation doesn't invalidate Lumpy's point that the computations and electrical representation are all in binary.

I'd argue that that's not so computer science as it is computer engineering. Computer Architecture courses tend to be more the domain of EE departments than CS departments, in my experience. I'll grant you that enlightened schools do a better job of combining them. The school I went to, which has an excellent EE department, didn't combine them. (Our CS department at the time was made up primarily of math professors that couldn't hack teaching math.)

I find it hard to imagine a pure CS undergrad program going to the extreme of designing and building a pipelined processor. I have seen some CS architecture classes that try to have students architect and simulate simple machines. The bar was pretty low, and it wasn't clear to me what the students were getting out of that particular class.

Granted, I'm saying all of this from the jaded perspective of someone who's been in the chip industry 18 years, and has had the pleasure of working with a wide range of skill sets. I've also seen how much there is to learn after college. I do think EEs could stand to learn more CS, and CS folks could stand to learn more EE, but I don't know what you'd displace in the existing curriculum to fit it all in. Some of this you just have to learn on the job if you don't want to be stuck in college for 6 to 8 years.

I have tons of programming books, engineering books, algorithms books, data manuals, etc., all of which I read for enjoyment and to better myself as an engineer. I have read some fiction, but it's been a long while since I spent much time reading fiction. And then there's puzzle books which don't really fall into either category.

When I want fictional entertainment, I'll turn on the TV or go watch a movie.

*chuckle* It's a power so great, it can only be used for good or evil!

Actually, it's useful for compile-time optimization of performance critical code. For example, I have a CRC calculation template class that generates its lookup tables at compile time based on the specified polynomial, shift, direction and field size. Need a new CRC in a different wacked out field? One line of code and it's there.

Previously, in C (or C++ w/out template metaprogramming), I'd need to either write a separate program to generate the lookup table for me offline and manually graft that into the code, or generate the lookup table at startup.

The consuming code is fairly clear, so in principle it makes other code easier to write. Of course, if there were something wrong with my implementation, debugging it is potentially more challenging.

Public Service Announcement comes on the television. Pages of code scroll by on a computer screen in the background. A strung out looking programmer stares into space, bleary eyed, obviously stressed, pulling his hair out. A voiceover begins...

Using recursion as a simple looping construct in an imperative programming language isn't normal. But, in C++ template metaprogramming, it is.

Template metaprogramming, not even once.

;-)

(Actually, I do a fair bit of template metaprogramming in C++. It can be handy for a certain class of problem.)

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?