Computer Science theory is a form of mathematics. That's how CS got started. It has evolved into something separate from mathematics - certainly related, but also clearly independent.

I've said this before on HN, but there is more to computer science than the math-heavy, CS theory that many people here seem to think is the entirety of computer science. Computer science also encompasses the study of programming language design and implementation, computer architecture, operating systems, networking, graphics and other fields. While math is a part of these fields, math is also a part of organic chemistry.

Perhaps the most fundamental nugget of computer science is that it is everything concerned with computation in both the abstract and in implementation. All of the fields I mentioned stem from that idea, including CS theory.

Too right. People who want to be coders shouldn't be CS majors (though the better coders tend to be CS majors), they should be IT majors and study programming. People who want to understand the theories of computation should take CS. It's that simple.

It's a common misconception that programming = CS. It stems from the fact that programming just so happens to be a very convenient way to compute things, so it happens to be what most people who don't understand CS see.

In most universities, the computer science program is the best way for people to learn how to program. In the future, I think CS departments will split into software engineering (which focuses on teaching students how to program and engineer software) and computer science (which prepares students for careers researching in the field of computer science). But that's not how things are in most places.

Also, "theory of computation" is an area of computer science theory. There is much more to a CS curriculum than theory of computation.

>In most universities, the computer science program is the best way for people to learn how to program. In the future, I think CS departments will split into software engineering (which focuses on teaching students how to program and engineer software) and computer science (which prepares students for careers researching in the field of computer science). But that's not how things are in most places.

Too right. I agree with this. I think that the "field" of software has generally gone in three directions.

1. How do you compute it (or Thinking about it)? That's CS 2. How do you plan to build it (or Planning it)? That's Software Engineering 3. Go build it (or Doing it)! That's IT

Sadly, at least at my alma mater, the trend of keeping these three fields separate has reversed. Instead, with budget cuts, the departments have merged under the CS umbrella. I think this continues to push forward the layman idea of these three things being equal because of how they are co-mingled -- but really they are as separate of disciplines as Physics is from Road Paving.

Ideally the number of students and practitioners in each fields should be distributed like a pyramid (a la any other engineering discipline). Most people doing, fewer people planning, and even fewer people thinking.

>Also, "theory of computation" is an area of computer science theory. There is much more to a CS curriculum than theory of computation.

I guess I also agree with this. I've always chafed at calling Computer Science the "Science of Computing" though since it's not a science in the classical sense. But everything I ever learned in my undergrad (not counting unrelated curriculum coursework) was definitely related to "computing" in even a loose sense of the term. I just don't think calling it the discipline of "computing" makes it any more clear since "computing" - the act of using a computer (like a Mac) and "computing" the act of performing computations, are easily confused. The "Theory of Computing" has always seemed to have the best balance while providing context for "computing". But I'm open to accepting other 2 word descriptions ;)

Software engineering is a young field. While I think separate SE and CS degrees is how things should be in the future, I'm not sure it's the right thing to do now. I recognize that SE programs do exist, but we (as a species) are still new at building software. We've been doing the other engineering disciplines much longer. And as you point out, we're unlikely to see programs split in a poor economy.

(I do have to disagree with your point 3: building it is very much engineering. I consider IT management and service of computing resources and information.)

All true, I think the very fact that we can have an interesting discussion about where the three major disciplines draw their respective lines is evidence of the immaturity of the respective fields.

I have a feeling that, with the way the three disciplines overlap, when everything finally shakes out we'll probably see the formation of a few more disciplines. We've been doing math, science, engineering and building things for thousands of years, but software for not even a century.

I don't have any interest in defending PHP or Java specifically, but giant projects really are interesting. They're just not Computer Science.

The interesting thing about giant projects (say, hundreds of thousands of lines of code on up) is that they're by far the most complicated systems that humans have ever created. And coping with a million lines of unstructured logic is simply impossible.

Lots of interesting ideas in software engineering -- higher-level programming languages, modularity, abstraction, tiny-programs-connected-through-stdin-and-stdout, service-oriented architectures, et multa cetera -- are direct attacks on the problem of how to design systems that predictably exhibit incredibly complex behaviors.

These systems would be literally incomprehensible, and unbuildable, without the library of intellectual tools we've accumulated over the last couple of decades. That library is still growing. Maybe you or I will get to write a chapter. This is Interesting. But it certainly has little to do with the analysis of algorithms.

Right, but there aren't a lot of industry jobs doing things which are "simple, elegant, and beautiful". In my experience, coding in industry is a great way to make very decent (6-figures in NYC) salary just a couple of years our of college while working on the "simple, elegant, and beautiful" aspects of our profession on the side.

But the OP is not a theoretician, nor does his post indicate any desire to be the next Dijkstra.

Dear [here I'll say it for you] But-I-am-not-a-geek: Obviously you are neither interested in the non-people-oriented ;) aspects of "technology" nor are you (or your university for that matter) projecting any signs of aspirations to the heights of application of "mathematics". Switch to a business degree and minor in the non-people-friendly-and-not-for-just-anyone CS.

Don't get smirky. I was exactly that guy. I was a CS major but minored in business and was the extroverted CEO of a software startup at 21. I used to think the fact that I often didn't like the "code" aspect in-and-of-itself (it just seemed hacky to me) made me think that it was my fault -- that I just didn't get it. After a lot more learning, I now know that I was right all along. It is hacky and it's horrible, and I never had to worry because that's not CS. There are cores of "Dijkstra beauty" in every project. Find that and extole that, because that's what's good in your project. It's not about being some ivory tower academic. I'm saying you can be a people person and be a CS major. You can hate "code" and be a CS major. Truth is, you'll be a better CS major.

I wasn't being "smirky" and don't appreciate your characterizing me as such.

The OP has indicated no interest in creating "technology", whether in bits or in the abstract, but has indicated his interest in both business and technology. So regardless of the validity of your general points and personal anecdote, you are not really answering his question.