I'm enrolled in this class now--pretty funny to see it on the front page of HN.
For anyone who's interested, the lectures generally consist of very high-level views of various elements of programming; anything from version-control to a C++.
IMO the best parts of the lectures are Kernighan's anecdotes: he constantly drops in stories from his time at Bell Labs, and even includes some correspondences and comments from the very programmers who created the technologies on which he lectures.
I do! Although not totally sure if Professor Kernighan intended for them to leave the classroom. Occasionally he'll throw an email from a former associate into the lecture slides (e.g., James Gosling), but I've noticed that he's removed them from the public-facing slides on the site, which makes me think I should be somewhat cautious. Maybe eventually, with his permission, I'll write some up and post them on HN.
I took Brian Kernighan's class when I studied at Princeton. As part of the class I developed www.itrans.info which set me on my way to being an independent app developer. I'm enormously grateful for his class, his involvement with students at Princeton, and just how genuine he really is as a person on campus.
Any of those topics could be taught at an arbitrarily advanced level. You could, for example, demand that each one be studied and a non-backwards-compatible alternative be designed with the wisdom of hindsight and, of course, implemented in C.
If I were considering that class for a grade, I would hope that those topics would be mostly introduced rather than dealt with in that kind of depth. (Now, if it were a non-graded, non-time-limited, free Udacity or Coursera online course that I could work my through as time allowed, I would rather have the depth. Just don't make me master one new decades-old technological toolbox per week and grade me on it.)
I wasn't a CS major while there, but I did take a few CS classes. Those classes, in particular, are top notch, and a lot of time was clearly spent on at least the intro classes (the first 3-4 classes you may take). The classes are very well polished, the support staff is welcoming and teaches well, assignments are always really fascinating, and the courses as a whole are very put together. It's part of the reason that the CS department size more than doubled in the last few years!
I'm currently at Berkeley EECS. It's certainly a very good program, and they put a ton of effort into undergraduate education. For example, I was recently talking to people at the ParLab about how they developed a rather popular class about parallel programming, so undergraduate education is certainly something of a priority.
Ultimately, it really depends on what you're interested in. From my perspective, Berkeley seems very good for systems stuff: parallelism, distributed systems, databases or even computer architecture. The undergraduate CS classes are all rather good and mostly interesting. (Except for the stupid Java/OOP/data structures course--that was a big waste of time, but you can probably just skip it.)
However, the classes really aren't the most important thing. I think there are two things that trump this. One is simply location: Berkeley is very close to a ton of startups. I've met some incredibly smart people running exceptional companies, and even worked at a couple during the year. It's a great resource that would be hard to duplicate anywhere outside of the Bay Area. Even if you don't plan to spend much time working at startups, it's still really cool to occasionally pop down to SF and hang out with hackers; the community around here is really great.
The other aspect that's more important than classes is research. Berkeley has a very project-driven approach to research where people decide on applications first and tailor their research to that. Some projects are really full-stack: for example, at the ParLab (where I'm doing some undergraduate research), there was a demo where everything including the hardware, the OS and the high-level algorithm design all stemmed from active ParLab research, all integrated together at the very end. If you like that sort of thing, it's very neat. The other big lab I know about--the Amp lab--operates similarly.
It's also going to depend on what particular subjects you like. From my perspective, Berkeley is great for all sorts of systems stuff: architecture, distributed systems, parallelism and so on. It's really a great atmosphere for that sort of work, with a ton of cool people to talk to.
Of course, this does mean that most of the stuff that's going on is annoyingly practical. Relatively few people seem to be working on neat theory, and most of that is in complexity. So if you want to study cool theory just because it's pretty, Berkeley might not be ideal.
I've found myself inexorably drawn to PL theory--types, categories, algebras and so on--and Berkeley is really no place for that :(. It's driving me to distraction. So if you're interested in something along those lines, I'm willing to bet that Princeton is quite a bit better. And I really do think PL theory is the coolest field, partly because of how general it--it's applicable literally everywhere in CS and then spills over into math or even physics--but mostly because of how pretty it is.
Also, if you like functional programming--another thing I'm very interested in, unsurprisingly--then Berkeley is also the wrong place. Most people seem to know literally nothing about it beyond its being somehow related to functions and a bit wonky, and I've only met a few people who know much beyond that.
Anyhow, I hope that helps you get a good idea of how Berkeley is like. I'm very biased, but I think my biases cancel out: on the one hand, I go here and it's great; on the other, the things I actually like are sorely under-represented and that really annoys me.
I just want to back this up by saying that I've been exposed a little to some AMP lab projects (Spark, Shark), and they're pretty cutting-edge for the industry. That lab seems to be focused on tackling the same problems industry is actively working on, which is rare at my university. If you're interested in distributed, parallel computing in the vein of MapReduce, I would second Berkeley.
No lecture videos as of yet, but perhaps eventually. Princeton began a partnership with Coursera last year and the CS department has been relatively active, e.g., our algorithms course is now on the site [1], and I believe that they actually 'flipped' the course over the past semesters, i.e., students were expected to watch the lectures online and typical lecture hours were replaced with professors fielding questions / working through examples.
I'm not quite sure what the resource here is? Lecture notes and syllabus overview? No lecture videos? so how is this useful for the rest of us who are not in Princeton. what am i missing here.
I would have loved to have a class like this in my program. It's basically a summary of all the things I've learned in my side projects and first year of my career. I hope this is mandatory for all of their students.
Thanks, I hadn't heard of Ousterhout's dichotomy. It sounds unhelpful, and like an excuse for users of compiled languages to be supercilious about interpreted languages.
A "scripting language" should, if it means anything, mean a language used for writing "scripts". So it hinges on the definition of "script". IMO, a reasonable definition of script might be something like "A computer program comprising a sequence of commands executed for their side effects, whose primary purpose is neither reusability as a software library nor to act as a robust component of a long-running or frequent process, and therefore may not be thoroughly organized into functions, classes, methods etc."
node.js can be used as a scripting language, but the primary role of javascript is to run in a web browser and implement a GUI with an event loop, which is very different from "scripting", if you accept a definition similar to mine.
For anyone who's interested, the lectures generally consist of very high-level views of various elements of programming; anything from version-control to a C++.
IMO the best parts of the lectures are Kernighan's anecdotes: he constantly drops in stories from his time at Bell Labs, and even includes some correspondences and comments from the very programmers who created the technologies on which he lectures.