I wonder whether theoretical computer science courses are really necessary within this major. Curriculum of computer science differs from university to university, country to country. But I often see that strong emphasis is put on topics and subjects like computational logic, computability and complexity (not complexity of algorithms), formal languages, automata. Also numerical methods and stochastic method are also thought. Especially when these courses are taught by professors who are not good teachers (I am not talk about their knowledge and personality), they are rather torture and these courses prevent students from further enhancing their skills by making them lose time on these rather graduate/PhD courses.
These courses are, sometimes, somehow, nice. They improve intellectual skills. But I don’t understand how they relate to the job and work of the computer science graduates. I am not criticizing courses like linear algebra or discrete mathematics. They can somehow be connected to the job.
The courses that will enhance their skill sets such technical computer science courses (computer architecture, operating systems, computer networks) or programming languages, in my humble opinion, seem to deserve much more emphasis than the courses I named above.
I remember seeing times came across something like the following on professors’ course notes: “theoretical CS topics are not sufficient yet to describe the concepts and problems”
What percent of rerquired CS courses are theoretical? Undergrad CS classes are not exclusively practical. I’ve actually used formal languages, and my stuff has always been very practical.
How is someone going to want to work in theory if they haven’t been exposed to it?
The thing is, a CS degree is not just a degree in hands-on coding. It’s essentially a branch of applied mathematics, and a proper understanding of theory gives you a good foundation for writing efficient and effective code anyway.
Theoretical CS is misnamed. It should be named “The Most Important Courses in Computer Science!” (Complete with the “!”.)
The material in these courses are incredibly fundamental to understanding everything about the field.
One key problem all too many students have is they don’t have a handle on the idea of “abstraction”. To solve problems you have to get down the the abstract ideas embedded within them and work on how to solve those. Then and only then can you properly solve the whole problem.
If you can’t understand abstraction or do abstraction well, then you are going to be a very, very, very bad problem solver. (Trust me, I’ve seen all too many of these types.)
Of course the people who are bad at something, such as abstraction, criticize the need for learning about that something. Ignore them, they just plain don’t have a clue.
The OP’s point that today CS degrees are pretty woolly is IMO mostly correct.
If we substituted mechanical stuff for computer stuff it’s be like calling an undergraduate degree in physics emphasizing dynamics, an undergraduate degree in mechanical engineering, and a vocational certificate in current-tech factory machinery installation and servicing to all be the same thing. Clearly they’re not.
IMO the best direction from here is to get some standardization on the labeling. Once we can tell which of the three degree tracks is involved then we can decide the right course mix for that track.
ISTM the OP wants to follow track 3 but has been exposed to the current mishmash that’s all three at once. With too much emphasis on track 1 content, at least for the OP’s taste.
Ref ftg above I’m not discounting the theoretical stuff. It’s essential for people going into the deeper end of the pool. But not everybody spends much or, or indeed any of, their career there.
Ideally we’d also have industry certification requirements to prevent a track 3 graduate from being put into a track 1 or track 2 situation. Architects, structural engineers, and steelworkers aren’t interchangeable either. And have separate licensing requirements to reflect that reality.
This is basically it. It’s like people getting mechanical engineering degrees, hoping to become plumbers, and complaining that you have to take a lot of non-plumming-related courses, and when you’re done, you don’t even know how to install a toilet.
This “it’s only needed for deeper stuff” is completely and utterly wrong! It is needed for everyday programming! The huge problem, like with a lot of academic areas, is that people blank out on the practical uses of what they are learning. So they never use it. So they think it was a waste of time.
Well, they did indeed waste their time and money. But that’s their loss.
E.g., I had two ex-students come and see me about some problem they were working on. (One their first job, the other an internship.)
The latter was working at a chemical refinery and the big issue was routing materials thru pipes at different times to get to the stacks that did the processing efficiently. So I said, so you have a graph with weighted edge. He said “No, I have a refinery.” No matter what I said, he couldn’t abstract out the problem.
The other was working for a major teleco. Again, routing traffic based on capacities and costs. I brought up some keywords: network flow, etc. Where to start reading. It just clicked for him. Clearly it’s a graph with various kinds of weights, etc.
Guess which one is likely to have had a more successful career?
I am always greatly disappointed when people mention “What good was X? I’ve never used it.” Which proves nothing. All too often they could have benefited from using it and just didn’t realize it.
If you doing any sort of programming or some such at all, you are in the abstraction business. That is the core, the basis, the beginning of it all. If you don’t get abstraction, you will be very bad at it.
I’ll second what ftg is saying… a lot of the theory has come in more handy in my career than the practical stuff.
I learned C/C++ as the primary language in my CS degree track, with some FORTRAN, some COBOL and some PASCAL. That stuff is not terribly useful these days.
But the stuff like analysis of algorithms, the set math/set theory, and data structure stuff like trees, lists, etc… remain extremely useful, as they’re not linked to a particular language, or even programming paradigms.
I found myself thinking back to courses I took in 1994 (analysis of algorithms and database theory) about a year ago, when I was trying to figure out just how to speed up a really clunky SQL query that I’d made in a hair-on-fire hurry to answer a one-time, ad-hoc request, and whose data was needed for a vital workflow step. Turned out that by restructuring the query, I made the whole thing run in O(n) time, rather than the O(n^2) that it was originally running in.
But I had to be able to figure out the sets of data, how they intersected, and how I could restructure the query to run faster, and why. That was all theoretical work; stringing the keywords together was the easy part.
QFT. It’s computer SCIENCE. If you want to learn to program, go buy a book.
Regardless, quite a few of the upper division courses I had to take had more to do with the business of managing a software project rather than the code that goes into one.