Completely disagree about excluding algorithms and data structures among other things. In fact, I would say current curriculums feature much too less of design skills in these departments.
Algorithms and Data Structures needn't be about existing ones, although they are great examples. Algorithm design skills are a prerequisite for getting anything done efficiently, quickly and readably. Design patterns and software development models are secondary.
The case of data structures being available in libraries will lead to confusion as students will lack the ability to select the one with most appropriate performance characteristics. To them the only difference will be syntax. You could argue that one can look up complexity characteristics, but then how can you teach someone what is complexity without doing algorithms and data structures?
Algorithms and data structures are so prevalent, that they drive design issues that on the surface seem unrelated. Why map reduce is the query format we are using; how Clojure can have immutable, persistent yet still fast data structures; why public key cryptography is safe? And more importantly, algorithms and data structures teach us about tradeoffs.
It's not by accident that top companies test algorithm skills in interviews.
That's pretty much what my CS undergrad was about (european university).
In addition to everything mentioned by the author, we also had algorithm design, a lot of math (analysis, linear algebra, probabilities, statistics, topology, graph theory from the top of my head), economics, law fundamentals + intellectual property law, project management, communication + marketing, economics, english as a second language, and electives in our final years (computer graphics, etc.).
This seems sensible. Of course many people could quibble about things they wish were included or dropped, but almost all of this stuff I've had to learn the hard way. Having most of this information presented to someone in an organized way would go a long way towards making them a formidable hire.
What about functional programming? I quite liked my class on it.
Also, at my school, we have a course on realtime programming on embedded systems. It's a cool class, I would like to still see it around.
Also, a class on bash and unix would be good.
From my perspective, the point of a Data Structures class is not so that students can implement a red-black tree or skip-list off the top of their head- it's so that the performance characteristics of those structures and their associated algorithms will be deeply engrained. I've never needed to implement a hashmap from scratch in industrial code, but I've sure as hell needed to understand how they work beyond simply memorizing "insertions and lookups approach constant time". Algorithms is a similar story. I think leaving those courses out of a programming curriculum will result in mediocre programmers at best.
Algorithms and Data Structures needn't be about existing ones, although they are great examples. Algorithm design skills are a prerequisite for getting anything done efficiently, quickly and readably. Design patterns and software development models are secondary.
The case of data structures being available in libraries will lead to confusion as students will lack the ability to select the one with most appropriate performance characteristics. To them the only difference will be syntax. You could argue that one can look up complexity characteristics, but then how can you teach someone what is complexity without doing algorithms and data structures?
Algorithms and data structures are so prevalent, that they drive design issues that on the surface seem unrelated. Why map reduce is the query format we are using; how Clojure can have immutable, persistent yet still fast data structures; why public key cryptography is safe? And more importantly, algorithms and data structures teach us about tradeoffs.
It's not by accident that top companies test algorithm skills in interviews.