Ask HN: How would you evolve modern computer science curriculum?

It seems to me that you are making the same general argument that Steve McConnell (of Code Complete fame) made in his 2003 book "Professional Software Development", namely that CS programs serve a different purpose and clientele than a Software Development or Software Engineering program would serve. So, rather than evolving a CS curriculum, another option would be to introduce parallel software engineering programs. Honestly though, for a professional developer who sees this as a career, I'd argue you are better off doing CS at the undergrad level, then pursuing something like a Masters in Software Engineering. CS at the undergrad level gives everyone the foundation they need, regardless of what the pursue professionally after that.

I went through Georgia Tech, and there is never any formal introduction to version control. If you're exposed to it, it's from a job or a friend (who in turn got it from a friend or their job). If you don't know it exists, you'll never seek out and learn it.

Testing was used in some courses. We had a software development class that involved UML, TDD, and everything "proper". Testing is also provided as a way of pre-checking your homework by some TAs. They might give you a basic set of tests for your linked list homework (adding, removing, etc), but then their grading script will check off by 1s, etc. It's not necessarily taught how to write said tests in those classes.

Continuous deployment is never touched. If you co-op/intern you might be exposed to it.

No one that I knew of learned anything related to "ops", unless they happened to take an interest in it.

I absolutely beg to differ on your first point. You don't use actual performance measurements in Data Structures courses, no matter what language you use. You aren't instrumenting your code or counting bytes or anything. You measure the concepts by analyzing with Big-O notation. If you really wanted to, you could teach a Data Structures course using just paper, pencil, and pseudo-code.

Pretty much any language will work fine for teaching data structures.

If people's comments here are any indication, yes, SADLY, that is kind of the way it is.

Does it have to be? Definitely not.

There are tons of ways to inject practical skill building moments into an otherwise rigorous and principled CS degree.

For example, Professors could force students to turn in their coding assignments by Git Pushing to a repo. Since they have to do that anyway, they might as well version their assignments as they work on them. Boom! Some exposure to version control.

Or Professors could provide students with a suite of unit tests that their assignments will have to eventually pass. Now the students are coding to test cases from the very start of an assignment and probably picking up some practical knowledge about testing platforms.

Both of these tactics could be injected into just about any course, from Compilers to Data Structures.

Pretty much any language will work for teaching data structures badly.

If your instructor is showing you a cool animation of a list with less than 30 elements being sorted by X algorithm, he's doing it badly. Or at least if that's all he's doing. There are by the way many schools that do just that, under the rationalization that the point of the class is to have the student practice what he learned at Programming 101. I attended such course in the day, and then went to teach the same course some years later, but I don't think the results were any good.

IF he have you run your algorithm against input taken from /dev/random, first 100KB, then 1MB, then 10MB, then 100MB he's a little less bad. IF he makes you do the whole sequence a dozen times an plot each resulting data points in a graphic with logarithmic scale, he is not bad at all.

Then you can start to discuss Big-O notation, but for the resulting graph to make any sense you need that the program written by the student to have a relatively strong correlation with what the computer is actually doing. It will not do, by example, if the runtime environment decides to implement you list as a dictionary object instead of a raw array. Also, having a relatively precise clock like Java's currentTimeMillis will reduce the possibility that you embarrass yourself if the practice do not seem to match the theory.

If the course is being taught at graduate level, you may want to run a second experiment, this time with input sizes of 1KB, 256B, 64B, 16B. At this point you will be able to discuss stuff like the Little-O notation, the constants involved in both notations, and how those are derived from Limits of the time function.

For this you will absolutely need the best clock available in your hardware, so C because a must. It will also help if you can run cc -s on your code and see what assembly is behind your code. I know it is overly ambitions, but that's how I would like to have learn about this stuff.