[dfranke]

Can you do any of the following?

* Write a compiler of any kind (native code, bytecode, HLL-to-HLL, whatever).

* Write an ACID storage engine.

* Write a trivial OS, including the bootloader.

* Write any non-trivial component of a real OS kernel.

* Design a CPU or a microcontroller.

* Write a rendering loop for a 3D game.

* Design a secure cryptosystem out of existing cryptographic primitives.

I give you an A- if you can do one of these, and an A+ if you can do two or more.

[flashgordon]

Isnt this what you do in your undergrad CS courses? With pretty standard algorithms?

[dfranke]

See my response to ken.

[ken]

I had to do half of these to get a CS degree 10 years ago, and I can assure you that the vast majority of my class was not what I would call an A-list hacker.

[dfranke]

It doesn't count if you have a professor holding your hand every step of the way and giving you a framework suited to exactly the project you're working on and no other.

Nonetheless, which half do you mean? In my OS class we just worked with a toy MINIX derivative and never got down to anything nearly as nitty-gritty as a bootloader, and the people who didn't drop my compilers class were A-list hackers. I never did any of the others as an undergrad, though I could have and didn't take the class where you build a CPU.

[ken]

What I did in college:

I wrote a compiler (for a Java-like language) that compiled to x86 instructions. The last week, we were writing nontrivial programs in this language, compiling them, linking the result with a GUI library the instructor wrote, and seeing it put graphics on the screen. It was not a required class, but one of a fairly small set of which a certain number (3 of 5?) were required. It was easily both the best and hardest class I took.

I wrote the guts of an ACID database (basically every part of a simple RDBMS except the query language). Again, this particular course was optional, but among the small set which were required.

The OS course, by the time I took it (1999?), was no longer having students write an entire OS, sadly. But we did have to implement several major components. I'm not sure I'd call any component of a real kernel "non-trivial" -- there's no black magic here -- but I did have to deal with many real issues. Required course.

I had to design and implement a CPU (at the gate level) for a pipelined MIPS-like instruction set. This was a required course, and in fact the big weed-out course for the computer science department. The last week, we got to actually put it on an FPGA and let it run real code, which probably would have seemed pretty cool if I had gotten more than 15 hours of sleep that week.

The ones I didn't do:

I took the first half of a graphics course (which involved writing things like rendering loops), but dropped it because it was just too boring. The graphics geeks I lived with ate that stuff up, and they did some amazing things, but I just couldn't get excited about it.

I never did anything with crypto in school. I don't even know if it was offered, but it doesn't really interest me, on a technical level, so I wouldn't have taken it, anyway.

I don't think any of these could be described as "a professor holding your hand". The professors at my school were, overall, notoriously bad. In some classes, there was no point in going to lectures. Even when the lectures were good, they were just about the theory; you still how to derive how to build the sucker yourself. Think "an hour discussing the differences in power between LR/LL/LALR/...; OK, now here's the BNF for a language, write a parser for it by Thursday, bye".

I guess some will take this to mean that it's not worth going to school for computer science. For me, at that age, though, the learning experience was (a) having hard deadlines, and (b) being surrounded by other young people interested in learning the same thing. I might never have written a compiler on my own, though it helped me as a programmer immeasurably.

[sanj]

I'd add:

* build a non-trivial and well-performing interpreter

[dfranke]

Depending on how loosely you define well-performing, that probably entails my definition of a compiler.

[sanj]

Agreed. But I was thinking more of dealing with the interesting runtime and caching issues that interpreters run into.

You hit neat stuff like call overhead of the base language.