Lambda the Ultimate

And why all software engineering/design courses should teach about profilers, and mandate their use.

Last time I worked on the nether end of a native compiler (targeting x86), when it came time to see what constants it was worth not-multiplying by (i.e., converting to shifts and adds), it turned out to be precious few (*). The amount of compute-ahead that some chips will perform (i.e., if you can avoiding doing anything data-dependent in your code) is astonishing, too.

So, just for example, you might be better off in some cases doing "complicated arithmetic" instead of "cheap table lookups".

(*) The exact multiply delay was almost certainly dependent on other factors, but it's relatively much faster than in the past.

And really, that's why a good compilers course is so important, even if the vast majority of students never write a compiler outside of class.

Or, another take we've had: teach students about compilers they would be writing. Most won't work for Sun to make the next Java. I don't think low-level optimizations are super important to most of them (though they should understand it a little). There's a myth that language design is hard: while true in the general case, as soon as you're in a specialized domain, there might be 'good enough'. Lex/Yacc-style tools were big steps here, and the community has rediscovered it a bit with Ruby DSLs. So, for example, teach students about source-to-source translators: let LLVM or JavaScript do the rest of the work.

In the beginning of our course, students wrote a quick Greasemonkey script to interpret webpages a little differently. Then, after going over parsing, they implemented one of google's little languages (unit conversion). Closer to the end (though as a worse example), they added classes, type checking, and FRP to the not-really-evolving JavaScript language through simple source-to-source translators.

Why not present compilers in a way students would more likely use them? It's less effective for students who will move on to language/compiler design, but they wouldn't be getting much out of such a class anyways.

As for the article itself -- it's interesting how it balances on the fence of architectural differences. E.g., when you tune, you tune for a particular architecture. I actually misread the article title before reading it: I've been looking for good books on modern static and dynamic language implementation.

edit: cleared up the list of examples. For this year's version (I'm not involved, but much is still in place since our changes): cs164. Unfortunately, there is no undergrad PL course, just a compilers one, which makes it a little random.

If the choice is a course on benchmarking and profiling vs a course on compilers.... teach/learn benchmarking / profiling.

And if you think there is not enough to be taught in such a course... well, you obviously need one yourself!

The author gives a non-tail-recursive version of factorial and says that msvc doesn't turn it into a loop. I've seen msvc turn tail recursive functions into loops. I use that feature pretty heavily when writing algorithmic code because the compiler is also smart enough to warn if a tail recursive call will result in an infinite loop, which you don't get if you write complex for/while iterations.


long fact(long x) {
if (x<=0) return 1;
return x*fact(x-1);
}


It is interesting that gcc turns this into a loop, although it isn't tail recursive.

I don't comment too often, but just wanted to offer kudos.

In general, I'd love more straight ahead papers/book that really explain current practice/state of the art.

-- Scott