Blog: "If you don't know how compilers work, then you don't know how computers work"

How much time do you really have to spend on the practical aspects of programming anyway. Once you have the basics down it's all about experience and someone with a solid theoretical CS background has a much better framework on which to hang that experience.
Depends. I know a guy (works for a recruitment firm) who keeps complaining about how a lot of candidates are 'technically' solid CS graduates but can't solve a problem worth shit. He likes guys that have a bit of structural logic, game theory, economics, linguistics, computational science, or whatnot over the ones that aced some 'hardcore' assembly course.
 
I wasn't a CS major, actually a film major, but I took Assembly because I wanted to know how the hardware actually worked. As I look back, it was probably one of the most rewarding classes I took in school.
 
Depends. I know a guy (works for a recruitment firm) who keeps complaining about how a lot of candidates are 'technically' solid CS graduates but can't solve a problem worth shit. He likes guys that have a bit of structural logic, game theory, economics, linguistics, computational science, or whatnot over the ones that aced some 'hardcore' assembly course.

Sadly, that's kind of true in all studies. The way a lot of testing is done, you can get good grades with a lot of repetition and memorization. There aren't a lot of professors that ask you to solve completely new problems, at least from my experience. Usually they'll ask something directly related to another problem from an assignment or test, or something directly from lectures to benefit those that bother attending.

It's very hard to balance it so everyone doesn't flunk the course, and it can be hard for employers to identify the real problem solvers, as they aren't necessarily the people getting the best grades.

Relating back to the topic, even if a student studies assembly and compilers, they're not necessarily going to be able to apply that knowledge to a problem they haven't looked at before. That's true of any subject. Still, I think it's better that students get some baseline experience in assembly and compilers.
 
Depends. I know a guy (works for a recruitment firm) who keeps complaining about how a lot of candidates are 'technically' solid CS graduates but can't solve a problem worth shit. He likes guys that have a bit of structural logic, game theory, economics, linguistics, computational science, or whatnot over the ones that aced some 'hardcore' assembly course.
He should hire people that are self-taught.
 
A professor of mine actually expressed the same concern, that if it was up to him that a compiler design course would be a mandatory part of the CS curriculum. However, whatever governoring body covers CS degrees focuses more of designing them as software engineering degrees and there just isn't time to add in a compiler design course.

Honestly, I don't know how it would be at more prestigious schools, but at my own there is very little interest among the student body, even among those interested in hardware, to want to take a compiler design course. I'm one of the few who would want to, but also generally have a better understanding of both hardware and software than most other students. Most students just want to be web developers, however, so I'd say they can pass on the whole compiler understanding.

That said, I can't say my programming experience in college has been vast. Most of my courses have been more theory based, with at most token projects to demonstrate the techniques. I've only had two difficult programming experiences in college (both from the professor who wants compiler design to be a required course and far beyond the coursework offered by any other professor I've had), and otherwise did more interesting and difficult projects in high school primarily for fun. Sad thing is, my programming experience isn't even all that deep, I'd say any student whose primary programming experience comes from the CS curriculum is going to be woefully underprepared for the real world. Then again, I may be biased from coming in with enough CS knowledge to breeze through or skip the first two years of classes, perhaps if I had to work through the difficulties at a university level instead of a high school level I'd have more appreciation for the programming instruction I've received.

Basic code optimization strategies and modular, easy to work with code are all most people need though. Needing to know how to optimize assembly these days is about as useful as compiling everything from source for a specific processor like some linux-junkies do. I can agree that it can be helpful for debugging, however.

I think having an assembly course is a good idea, just so you understanding of the program counter, the stack, registers, memory and how a processor performs instructions. The vast majority of people will probably never program in assembly again, but it's good to have an idea of how things work.

We've had a lot of courses that skirt around those ideas. Computer Organization and Programming Languages both did, and the digital logic lab is giving some insight onto how instructions propagate through a circuit.

Comp Org was a fun course, the small MIPS assembly programming we did was interesting. It seemed very possible to write object oriented code in it, but it was also fun exploiting boolean logic to do arithmetic and other stuff as opposed to using the built in operators. We had one task we were given that was only vaguely described in binary, but I believe it was actually an example of SIMD multiplication. (teacher didn't discuss it, but I got full credit for my explanation of what the code was doing)

I kind of appreciate the relative ease of the CS curriculum though. I'm also a physics major credit overloading every semester, and physics is...quite difficult. All the physics teachers I've had have fallen into one of two categories:
Explicitly teach you the basics, then give you incredibly difficult mathematical problems to solve that truly test your knowledge of differential equations, trig substitutions, and general knowledge of math...
Or...
Give a brief overview of the basics, then give incredibly open ended (but rather simple problems) that make you think about the reprecussions of the basic laws taught. This is fun, but in some ways even more difficult than the mathematically complex stuff due to the round about ways you may have to go to accomplish the answers.
 
Last edited by a moderator:
I think writing multi-threaded apps is very hard to do right if you don't know what it all boils down to. And I don't mean some independent Java or .NET forms.
 
I think writing multi-threaded apps is very hard to do right if you don't know what it all boils down to. And I don't mean some independent Java or .NET forms.

Maybe they'll start pushing more compiler theory into the curriculum as multi-threading seems to be picking up steam.

It's just really hard to design a program that can fit all of this information into four years. If you specialize your programs too much, you run the risk of having a lot of unemployed graduates. If you make it too broad, you have the same problem. They have to strive for that balance, which seems to be very difficult to do as the technology advances rapidly. The other part is employers that expect grads to walk out of school knowing everything, and being unwilling to train people on the job.
 
Then again, the direction seems to be towards making things "transparent" (opaque) to the "user" (programmer).

In other words: try to have the development tool and/or language/runtime make it fool-proof, so the programmer doesn't have to know.
 
I think writing multi-threaded apps is very hard to do right if you don't know what it all boils down to. And I don't mean some independent Java or .NET forms.
I doubt most compiler courses even mention stuff like memory barriers and the importance of ordering, I don't see how a compiler course will bring you all that much closer to knowing what concurrent programming boils down to ... which IMO is not a big deal, there are a couple of caveats but on the whole the issues are mostly orthogonal (ignoring parallelizing compilers, which I think is a good idea in general).
 
I think writing multi-threaded apps is very hard to do right if you don't know what it all boils down to. And I don't mean some independent Java or .NET forms.

I'm using multi-threading more and more in the fairly simple .NET tools I build ... The most complicated thing I've typically come across is when a different thread needs to access a control on a form that originated in the first thread. Even then it's not so hard - you check whether an invoke is required through a default propertly on the control, and if so, use a delegate ... And the new thread is simply created from the virtual .NET thread pool through a Thread object that refers to the address of a Sub.

I imagine all that hides quite a lot of complexity, but can anyone here explain me about how much?
 
I imagine all that hides quite a lot of complexity, but can anyone here explain me about how much?
Phew. Short answer: some timing and locking issues.

Long answer: you don't want to know unless you really need to!

I'm preparing a paper on that, I still haven't decided if I want to include all the mind-numbing low level details, or that I just keep it to what the tools offer.

I agree somewhat with MfA: it's not a biggie if you're simply using the stuff provided.

Then again, if it does go wrong "some times", you have a serious problem.


On the other hand: it isn't hard, as long as you know what you are doing. But you have to know.
 
Back
Top