Northeastern's redesign of the CS curriculum

Dijkstra line sums it up well "Computer science is no more about computers than astronomy is about telescopes."

If a student knows how to use a computer (a prerequisite to starting software project) they will demonstrably have more opportunities for learning than one who doesn't. And it's not even close.

"He who seeks for methods without having a definite problem in mind seeks in the most part in vain."

I lol:ed.

> The “code swap” at the end of the semester, where students are required to build upon other students’ code, is one of the assignments students struggle most with

Wow, sadism may be common in academia, but that is just on a whole different level! A few hours of waterboarding would be nicer.

There is exactly zero evidence indicating that Racket would be a better introductory language than Python, so why not go with what is popular? CS students are de facto expected to already know basic programming. So with Python you can jump straight to algorithms, you don't have to waste time with a foreign syntax and an esoteric interpreter.

OO isn't debunked and its not out of fashion.

All that's happened is that it's no longer gospel that "the only way to program is OO".

I write code that has all sorts of styles and approaches that fit the task at hand and sometimes the right tool for the job is OO.

I get the sense you're saying that OO has been proven to be hokum and no one should learn it or do it anymore and all that remains OO is the smoking ruin of 20 years of Java. That's not correct at all.

There are two separate points. The first one, almost a bit hidden, seems to be a "keep the student numbers up" change: allow placing out with AP CS credit and so skipping the intro courses; making the curriculum easier; reducing the number of students who withdraw from some of the modules; removing the teamwork (code swap) exercise; rolling back on fundamentals and design principles. This is just the word of one TA, but it's big if true.

The second one is about the language change. Look - if you're as great a TA as you say, you can teach design in any language, it just works a bit differently. You can teach good design in python, though it's a lot harder than just teaching python. You can teach design in Java, at some point you'll realise that half the design patterns book is still relevant (the other half has been eaten by streams and lambdas). You can teach design in golang, the people who wrote it at google did think of this. Using a Lisp brackets-style language doesn't give you magical powers, and I doubt the full details of macros and whatever the racket equivalent of call/cc is are that accessible in a beginner course anyway. Even SICP has a JS edition these days.

Personally I think "OOP light" is where it's at: interfaces instead of subclassing, methods that can be called on objects, encapsulation and modularity, and a package-private option so you can unit test stuff but indicate to users that this is not part of the API. Immutable objects and collections are good for many things and need to be taught, but sometimes there's good reasons just to make something with internal state and a fixed set of methods to modify it, so you can reason inductively about its invariants. You can get this out of many languages and teach it properly if you really know what you're doing. And you need actual programming projects, not just exams or "write a 20 line program" midterms. You don't need racket for this.