I think you are arguing against a claim I didn't make. Your first half of the post about compiler classes and other tougher courses are giving me the perception that I somewhere claimed CS education isn't useful. I didn't make that claim. I was responding to the claim about CS and non-CS people taking different approaches to problem solving.
> But back to your comment: It's not that all code needs to be "clever."
By clever, I meant code that isn't routine. My definition of clever will include dynamic programming, reducing NP complete problems to known algorithms, writing a parser which takes xml as input and produces python dicts("writing a parser is simple" you say. But compared to the rest of the code in a typical project, it does count as clever)
> But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer.
It's not me who was making general claims. In my post, I did point out that about 20% of the time, CS background is very useful. The OP made the claim that CS and non-CS approach differs in general, which I don't think holds true.
> Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development.
CS researchers have a lot of commendable qualities, but that requires a different set of qualities than a regular software development project, and CS research doesn't hone their skills as far as regular software dev is concerned.
Look at the code from the academia. More often than not, either there is no code(hence the comment "doesn't exist") or it's spaghetti. I don't see how that helps you write code for the regular projects where you work with teams, code isn't thrown away and you are expected to maintain it. Now, I am not saying CS researchers can't work that way - I am saying what they do for research doesn't help.
> But back to your comment: It's not that all code needs to be "clever."
By clever, I meant code that isn't routine. My definition of clever will include dynamic programming, reducing NP complete problems to known algorithms, writing a parser which takes xml as input and produces python dicts("writing a parser is simple" you say. But compared to the rest of the code in a typical project, it does count as clever)
> But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer.
It's not me who was making general claims. In my post, I did point out that about 20% of the time, CS background is very useful. The OP made the claim that CS and non-CS approach differs in general, which I don't think holds true.
> Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development.
"Real higher level CS" -> http://en.wikipedia.org/wiki/No_true_Scotsman
You don't get to choose what real CS research is.
CS researchers have a lot of commendable qualities, but that requires a different set of qualities than a regular software development project, and CS research doesn't hone their skills as far as regular software dev is concerned.
Look at the code from the academia. More often than not, either there is no code(hence the comment "doesn't exist") or it's spaghetti. I don't see how that helps you write code for the regular projects where you work with teams, code isn't thrown away and you are expected to maintain it. Now, I am not saying CS researchers can't work that way - I am saying what they do for research doesn't help.