I went to Caltech when they were contemplating similar things in the CS curriculum, although the normal curriculum was less radical than Northeastern's seems to be.
There is a tension here that is being understated which is that people of every major now take the intro-level CS class because programming is integral to everything. Teaching algorithm design in that class is not particularly useful to a biologist who just wants to be able to cobble something together to analyze some data (usually in Python). As a result, the non-computer-scientists and non-software-engineers at the school would rather have a curriculum that is more "practical" and directly applies to research (or later class projects) the students might be doing.
Some time not far in the future, we are going to accept that this is not the same thing at all as computer science and give the computer scientists a curriculum that is a lot heavier on math and theory while adding elective or core courses for non-major students on programming. That will end the compromised state that intro CS courses currently sit in. Right now, there isn't enough teaching talent to run those non-core courses (because that talent is earning the big bucks doing something else).
> There is a tension here that is being understated which is that people of every major now take the intro-level CS class because programming is integral to everything.
Why doesn’t the CS department have a different intro class for CS majors and non-CS majors.
That’s a common practice in the mathematics, physics, etc. departments.
(To have harder intro classes for the students majoring in your department vs those who don’t.)
At least when I went to school, intro CS was a weed out course for getting into the CS department in the first place, along with calculus based physics that potential engineer and physic majors also had to take.
I think these days it’s a bit different in that many schools allow high schoolers to apply directly to the CS department? But then it would be a matter of scale I guess, they usually have clinical professors run these classes because they demand full time attention.
Weed out courses do have various problems. Some of it is regulatory - certain public or public funded universities don't let you eliminate large portions of your cohort. Graduation rate is a part of many college rankings, so there's also an incentive to not fail.
I don't think it's completely wrong. Failing a student after he or she sunk a ton of money into it is really not ideal. IMO it seems really easy to pass prospective students the first few chapters of your CS textbook/lectures then test them as a prerequisite for enrollment, before they enrol. This would be close to free, filter out a lot of would be dropouts and just save money and effort all around.
Doing weed out courses on purpose I think is elitist and unnecessary, but computer science does require understanding of some hard topics. Linear algebra, theoretical computer science and the like may have very high failure rates, but are a necessary pre-requisite to become a computer scientist.
I wouldn’t say linear algebra is a necessity to being a computer scientist. At least, not the full linear algebra content. Knowing matrix math is enough.
It's not completely necessary. But I will say, as someone who began their career as an 18 year old "self-taught developer" then completed a CS degree at 30, I found linear algebra to be the most useful bit of knowledge that was missing from my kit.
1. Back when I was in CS, the department was much smaller than it was today. This was after the 80s programmer crash, and so they just didn't have enough professors or resources to teach as many students as were interested in being CS majors.
2. You are able to teach to a higher standard if you've filtered the students that enter your department. You can have one or two people fail OS rather than half the class. At some point, it is reasonable to see if the students are committed, and they get to prove themselves a couple of years after high schools, which worked better for people like me who weren't very accomplished until they get to college.
They need to get rid of the concept of weed out courses. It's bad for learning. If you are paying 30-50K a year for an education, course availability should be a given. Don't use the bell curve as an excuse to deny students an education, or if you are going to use a threshold, use a fixed one, not one that limits by percentage of students. The fat cat admins and professors need to be fired. Too many schools take the students' money and plow it into research and other areas, with zero regard for undergraduate education. "You are in university now, it's sink or swim. Can't make it? Too bad." This attitude is especially prevalent in the state/public unis, especially places like Berkeley where demands exceeds supply. Your traditional private colleges like Dartmouth and Harvard don't have this problem.
Ideally people who can't handle the course should get filtered out before being accepted to the college, so they don't waste any money. But since it's impossible to filter reliable at that stage, surely it makes sense to also filter early on in the course. (from the perspective of the student. If the college wants to take more of their money they could still direct them to a different, easier/more suitable subject).
A lot of schools these days weed out at the application level: if you have a great portfolio from middle school through high school, great! You have it made.
I sort of like the change to redeem yourself during the first two years of your university if you didn't have the ideal secondary school experience to get into a hot department of a hot university. CC can do that as well, I guess, but it is a much harder hill to climb.
My university had a proof based, let's construct the natural numbers from axioms and prove that a+b == b+a type course as the first class for aspiring math majors. It was a "weed out" course, not in the sense that it was particularly hard, but more in the sense of introducing students to this is what 'real' math is actually about, and not so much the stuff you were doing in high school. Some students decided each year that they didn't want to do 'real' math and went on to focus on other things.
At my university, after the usual calculus/diff eq/lin alg sequence everyone in STEM takes, we had “intro to advanced mathematics” that was proof based, taught in the spring, and a pre-req for everything higher level (abstract algebra, real analysis, etc). Most math programs have a similar “first proofs” class as their “weed out” class.
Math isn't popular enough to have weed out courses, and math professors of higher division classes don't mind failing half the class. There isn't much of a drawback to letting as many people who want to major in math.
But intro STEM math is used as a weed out for other majors. You aren't going to get far in CS if you aren't able to ace your basic calculus classes.
This is how physics is now. You teach an intro physics class and you have a billion engineering students all telling you what they actually need to know to be an engineer. But the truth is, it is often impossible to anticipate what a person needs to know for their future. The future is not an easy thing to predict despite recent innovations in AI and machine learning. And a student's current motivation is not necessarily the most important thing to consider when thinking about what they should be currently learning. People often change majors, career paths, etc. This is why I would rather people learn about topics that are fundamental to various fields, such as algorithms or conservation of energy or whatever, than some topical thing.
This exists already at Northeastern. They have a data science major and minor with a much more 'practical' intro sequence that teaches in Python. I actually TA'd for it, and many of the students were business or life sciences majors going for a data science minor. It even came with a 1-credit practicum geared towards specific domains, which students could choose from.
I live in California and I recently read an article from the perspective of Berkeley's CS department explaining why they don't take transfer credits from high schoolers who took AP CS or AP Stats -- they're just not "real" Computer Science, but rather applied programming.
Even when I was an undergrad (1995-1999) and a grad student (2008-2011) everyone knew that CS was a research science [that happened to turn out people who lucratively employable skills], and not a software engineering program, which existed separately at both schools.
That uses to be called CIS. When I was at Harvard they still took the algorithms class. Yeah, it was the ezmode version, but it still covered stuff like how to build a hash table and a trie.
I went to UNC Chapel Hill, and this was already done back in 2005 there. CS major intro classes were numbered in the 400s (401, 402, etc) with a focus on data structures, basics of big-O (later refined in algorithms), etc.
CS 101, 102, etc. were the “non-major” intro CS classes and exactly what you describe here. They didn’t count towards a CS major at all. Neither would non-calculus-based physics classes.
Note that, at least at UNC, in every other department I know of, 400-series classes were generally graduate level. But UNC CS operated a bit differently.
I loved the challenge and the knowledge I gained, but it’s worth noting that CS at UNC was much, much harder than nearly any other major there (Chemistry may be the one exception).
Why can't they just take a class on shell scripting? The whole point of computer science is to automate things, because that's what gives you leverage. If you don't care about understanding computer science, at least skip to the point and enjoy the fruits. We've been using the UNIX shell for 50 years. It's not going anywhere.
I majored in biology. A shell script would be a much more cumbersome tool for making a scatterplot, running a linear regression on a csv, etc.
The things that people are using Python for are significantly easier with Python. There are libraries designed to make these tasks super simple, and with the right IDE you wouldn't ever have to touch the shell.
I'm someone that uses shell scripts in my day to day work (I don't work in biology any more, but did for a while).
I'm saying that for the average scientist using these tools, a shell script is not an easier or more useful tool than Python plus libraries. Can you honestly say that shell scripts are more intuitive and easy to understand than Jupyter notebooks? Are they going to be more easy to transfer to other stakeholders?
This is one of those solutions that seems better in theory, but likely isn't in practice.
I can't think of a faster easier tool for composing and controlling a bunch of heterogeneous things. Even if you write a Python script that does it, you're still using shell to run it. Notebooks are good for experimenting and explaining, not for automating.
"Practical python" is undoubtedly useful to a biologist, but I wouldnt understate the utility of an intro to algorithms for technical but non CS majors.
'Algorithmic thinking' more or less doesn't exist in a lot of the classical disciplines with any degree of rigor, so a CS class is the only place a biologist is going to be exposed.
Specifically for utility, there is a very tight mapping between 'how do I search these strings' and 'how do I [most efficiently] design a set of experiments [searching for a a result]'. Both in the literal algorithms as well as the logical framework necessary to extend past trivial examples.
Dating myself, my college had Pascal for CS majors, and FORTRAN for physicists. The FORTRAN class was math heavy, and we had a higher level course in process control as well, plus we all took the math class in numerical analysis.
When my daughter was in college, it was Java and Python. She took Java. I had suggested to her that she could easily keep up with the CS students, which she did.
I very much favor better training in programming for scientists. Taught by a scientist. The "intro to Matlab" that many students take is really too lightweight. Also, as for languages becoming obsolete, the disciplines that I learned in the 1980s are still of value today even if the languages have changed.
A more pragmatic answer is who’s going to teach it? Someone with weak skills in the discipline? Or someone with weak skills in computing? (This is a glib answer)
Finding people at the true intersection is surprisingly hard, and those people tend to be busy.
In grad school I took and advanced statistics course in the psych department. The concepts were new to me but not to the folks in the discipline. However the math (matrix multiplication) and basic coding were easy for me and very hard for them.
There was only one person in the department who could teach it, other faculty did that type of work entirely as “clients” which just ran tools and code from others.
Who teaches the "<math specialty> for business" courses? IME, it was math professors.
It's not unreasonable for the biology department to come up with the common programming use-cases for their students, then have the CS department build a course around those skills.
My minor was Bioinformatics. The biology department taught foundational course like biology and genetics and the CS department taught the courses on processing data.
> Who teaches the "<math specialty> for business" courses? IME, it was math professors.
IME its the same...I've also found that approach works less well at generating good learning. It (seemingly inherently) results in decontextualized knowledge and does not get students over the application gap, which is the exact problem that such things are trying to solve.
When I was at UCLA in the mid-‘90s there were computer science courses taught through the school of engineering, mostly limited to SEAS students. So computer science, computer engineering, ee, me, and the like. I think the intro classes were taught in scheme.
And then for everyone else the Math department of the school of Letters and Science had their PIC (program in computing I think?) series which had two or three courses in C++ and another course in Lisp. As a physics major I took the latter.
> Some time not far in the future, we are going to accept that this is not the same thing at all as computer science and give the computer scientists a curriculum that is a lot heavier on math and theory while adding elective or core courses for non-major students on programming.
I graduated from an Engineering focused college in the late 1990's, and many departments offered exactly these types of courses in addition to the standard intro courses. They were typically named something [domain] [course #] for non-majors.
The end of an era. This is nothing less than a travesty honestly. The current (now former) curriculum at NEU was uniquely exceptional, and now it will be conformingly adequate. Anyone who complained about the difficulty or lack of "job-market applicability" of the Fundies classes entirely missed the forest for the trees. The point is the design _process_, and using Racket forced this. It also demonstrated the magic that is possible with computer science. The Dr. Racket editor has features that do not exist in any other editor (e.g. visually tracing references, and so much more). The teaching language just got out of the way and let professors teach the essentials of program design, without the burden of language idiosyncrasies. My mind was honestly blown when Olin Shivers coded the Y combinator directly and showed us how to add recursion to a language. It felt like having occult knowledge, and it made me an acolyte to computer science. I mourn the loss of this curriculum for future students, especially considering the premium price tag they now pay.
Taking Shivers' Fundies I class was mind blowing, even as a student that had been programming for several years already. They should have put him and Barzilay (who I had for PL and then later TAed under) in charge of the curriculum update.
I always enjoy seeing Olin Shivers name come up in threads about Northeastern. I had him for Fundies and have many fond memories of his lectures, I was truly inspired. It's no exaggeration to say that class and those lectures helped me find a passion and a career I enjoy. It's a shame they're phasing out Fundies, hopefully whatever they come up with will still be able to have that same impact on young students.
I spoke briefly with Felleisen at the end of this year, and sadly it seems the zoom recordings from the pandemic are lost to time. The course sites will likely stay up but the lectures were where it mattered
I'm going to provide a controversial take here as CS grad from a similarly-tiered program: there is a huge chasm between top-4 cs programs and everyone else. The top 4 are obvious: Stanford, MIT, CMU, Berkeley.
Then there are the cs programs of the ivy leagues, not as strong, but usually you have a rich parent or uncle who has already speed-tracked you into a hedge fund, so lets put those aside.
I didnt go to a top-4 cs program and the reality is -- there is no longer a real job market for any cs grad outside the top-4. If it were not for ZIRP it could be there never was! There is definitely not a job market for the sheer masses graduating with cs degrees, and it will take a decade to absorb the fresh graduates.
The curriculum does not matter here, so I think all this discussion is beside the point. No curriculum stasis or change will magically lead to jobs for fresh graduates.
I say this from three perspectives
1. Reality - just ask people if they found a job (ignore nepo-hires, also ignore startup founders with nepo-vc investments)
3. How people act. Foreign workers want the jobs more and are willing to do anything and learn anything to get it. My office is 95% non-us workers. They work hard.
Retired CS prof here (from a below (ok way-below) top-4 program). There is no longer a job market for CS grads outside of top-4? Is this true? I had no idea, as I understood it, CS major numbers are still rising.
GP is just making stuff up. There are plenty of jobs for CS grads still outside the top-4. Will there be some constriction in the market? Probably, code generating LLMs are getting more popular. But there are plenty of systems that are a bit too important to leave to random code generators.
Firstly, there are not "plenty of jobs for CS grads" -- if there were, you would have supply (us cs grads) matching up with demand (us tech jobs). Yet you see tons of unemployed CS grads. FAANG mostly has hiring freezes, and you have to be part of the inside club to be let in. Many cs grads go into bs jobs way under their potential (random government agencies, contractors.)
Walk into any US tech area and you wont see any Northeastern CS grads, or many non-Top-4 grads. You will either see Top-4 CS grads in leadership positions or at their own startups -- or you will see foreign grads. In some offices, 90% or more of the workers are foreign grads, not US school system grads.
Tons of job postings are fake. There was an entire HN post on this last week, companies posting fake jobs. Sometimes it is just to show a best effort before an insider is hired.
I think LLM copilots are a factor, but they are just a convenient distraction from the real problem -- a supply-demand-price mismatch. ZIRP conveniently hid the problem, but now it is out and visible.
>>> Many cs grads go into bs jobs way under their potential (random government agencies, contractors.)
> Why are those jobs deemed bs?
Because many of us went into the field bright-eyed, thinking about working on cool products, designing the latest algorithms, or being part of world-renowned teams. NOT to run the nightly batch job for the Massachusetts Depart of Family Services wage garnishment system. NOT to fix bug tickets at the local tax office's COTS implementation, while all the actual software is built elsewhere. NOT to work as a contractor without benefits.
Just look on Linked In, filter by Northeastern CS, see how many people have green semi-circles. Look at where people are landing jobs. Filter out nepo-hires, which are easily visible (e.g., jumping into leadership role straight out of school)
Sorry - little sympathy here. I acknowledge the market is much worse this year and last year.
But I started at a lame crappy job 10 years ago after college. It’s not a big deal, it gets your foot in the door and then in 2-3 years you can move up to a better company. I did this a couple times and after 10 years i’m now working at a faang adjacent company (household name but not part of faang).
That’s what normal life looks like for a typical CS grad. The fact you think getting a job at faang is expected or normal right out of the gate shows you’re in a bubble. It happens, and i’ve worked with colleagues who did it, but it’s not the norm.
and nobody is changing the world with their code, unless you’re linus torvalds or similar. best to squash that naivety earlier than later lol. It’s a job, and a passion for some (like myself). that’s it. It’s also healthy to find additional hobbies outside of the computer - something i learned the hard way.
Guess the smarties should have measured the patterns physical social reality rather than get sucked in by propaganda.
What physics demands society align with the spoken philosophy of a people? It’s kind of on the people to demand politics align with the philosophy. But go on, people; scream at your screen like gramps did at Dan Rather.
Distribution of education does not guarantee distribution of intelligence.
bad faith doomer. One thing you also forget to mention is that non-us workers are just that, not in the US, and that matters now that more places are putting an emphasis on in-person work.
The University that hosted "The Little Schemer" and all its derivatives. Those books were a delight and taught me to think about programming in a way that other languages had not. (Even if I didn't go to that University).
https://prl.khoury.northeastern.edu/teaching.html
I had been to a Scheme conference in Washington, adjunct to the Clojure Conference one year, and it was attended by many undergraduates from Northeastern, (and the authors of those books that I got a photo with.)
I have to feel sympathy for those undergraduates I spoke to. They gave a strong feeling, even then (8 years ago), that it was time for the University to move on in language choice.
I had a similar experience in the late 90s when the world was picking up Java, and our University insisted on teaching in Eiffel.
Teaching object-oriented design as fundamental computer science seems like it would have been an odd decision for 2025. I looked up the class syllabus, and it seems to have been taught in Java (fine) and makes extensive reference to design patterns (not fine).
I once asked a professor about this and the answer I got was interesting.
Basically Java and OO and Design Patterns are taught upfront because it turned out this was a huge stumbling block for a lot of people. Bigger than for instance C and pointers. Like it just doesn't click for a lot of people and they end up struggling a lot the rest of the major
So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year
This makes sense. You might not immediately need to design a complex hierarchy, but you'll encounter them pretty early in a lot of languages standard libraries.
The first time I tried to learn how to program, I was 12-13 years old and found some video from a university that started by covering Classes, Methods, and Objects.
I watched one or two lectures and it made no sense to me, so I gave up. I had no idea WTF "objects are like nouns and methods are like verbs" was trying to teach me. I just wanted to make my computer do things.
Around 14-15 I started playing around with my TI-84 calculator writing simple programs. The TI-84 used a form of BASIC where I could write a program that took INPUT and plugged it into an equation and print it to OUTPUT, and it felt so much more approachable than the neo-neo-platonist OO lectures I'd watched. From there I gradually started writing more complicated code until I eventually started to get why programmers would define functions to stop repeating themselves, or why they might implement custom types.
> So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year
I'd instead posit that so many people "fail fast" with OO because they go into their class being interested in programming, but have no idea wtf is even going on with programming and drop it, because they're forced to learn all this inane trivia [0] and write all this boilerplate (define a class, methods, observability, return by value vs ref) they don't understand before they can even run a program. They think maybe they're stupid or not a good fit for programming and drop it.
IMO a better teaching language would be one that lets you opt-in to OO and functional features but also lets you write really simple programs like "take a number, multiply it, and print it". I think that's why Python is so popular these days. It helps that the lack of semicolons/curlies, optional typing, and modifiers [1] removes so many distractions and gotchas that stymie absolute novices.
I also think most CS educators do a very poor job explaining CS concepts to beginners without realizing it. "Methods are like verbs" is absolute nonsense without a moderate to large amount of computer science knowledge to contextualize it. Some of my teachers were actually pretty good, and I also don't remember much acknowledgement that programming didn't have to be this way but that the language/tool was designed that way because that abstraction comes in handy. That'd probably help a lot in retaining students who successfully suffered through their first semester of CS 101 in Java but hated it so much they decided to swear off programming.
[0] Always start your program with "public static void main(string[] args)" ! Don't worry, that'll make sense in a year, or in six years when one day on the toilet at your software engineering job you realize that it really was a static function returning void that took string[] args
[1] Static and Foo& are justifiable, although static should arguably be implicit for a beginner language. Forcing students to learn about final, const, val/var, public/private, etc. early on is just stupid. I never understood why these were actually useful, or had a good reason to use them, until I'd already graduated.
Brilliant. And correct.
The people who created this concepts landed there after going through similar paths like you did (i.e. they started somewhere straightforward but eventually invented these complexities out of necessity.) They understand they "why" behind it.
But somehow, in the curriculum, we expect complete noobs to just get this abstract, non-relatable concepts without any contexts.
There's some irony here. These courses exist because years ago, CS departments made a shift towards "marketability" in their courses at the expense of "fundamentals". So they introduced Java to replace C++ because that's the language companies hiring new grads were looking for. And now OOP and Java are not skills that companies are looking for in new grads. But instead of acknowledging the facts, the departments are lumping Java+OOP in with "fundamentals" and getting rid of it.
I'm sure if we look back further, C++ displaced some other language (pascal?) for exactly the same reason. And likely the same for the language the proceed C++. I'm just not old enough to have personal experience here.
OOP is one of the major schools of programming, significantly more widespread than functional languages. The only thing arguably used more is "simple" procedural, but even that is doubtful. Sure, in the 90s people thought OOP was the be-all-end-all, and we've moved away from that, but it still makes complete sense to teach the main different styles of programming. C and assembly are basically covered by a course on computer architecture and OSs, then teaching an intro course on both FP and OOP gives students a broader understanding on how the vast majority of program design works. Follow up courses on algorithms can then have synergy by showing how much easier/safer/faster they are to implement depending on the style.
I reject the idea that OO is a "major school of programming"; or, if it is, that school has been largely discredited. I think you're on firmer ground if you claim that ideas from OO still inform modern programming (traits and interfaces being a good example).
I think a lot of 2025 developers would be alarmed to think that a project had started from an object-oriented design perspective.
That's a bubble thing. The vast majority of serious software engineering is done in OOP. Java, C# and C++ alone are more than half the market, and then you have Python, Ruby, Kotlin and many more. Even JS has moved largely to (bastard) classes.
Then you have data (growing above average), scripting and partially frontend that are done differently, but they are still a minority of the job market.
If it was 2005 I would take this argument pretty seriously, but it's 2025 and I find it less plausible. Python has (somewhat dumbed down) OOP features, but modern idiomatic Python tends not to be domain-modeled intricately-encapsulated OOP; in fact, it's increasingly functional. You bring up Javascript, and my retort is React: the most popular UI framework in Javascript --- UI frameworks being the archetypical case of a problem domain well-suited for OOP --- is largely a rejection of OOP principles and a marked shift towards functional programming.
(I'm not a Lisp or functional partisan; like I said downthread, it's Go and Rust for me these days mostly).
Keep my original point in mind here, which is simply that OOP principles are not a fundament of software development in the same way algorithms, data structures, memory models, and concurrency are. We're discussing curricula that have students learning class-based object-oriented programming as expressed in Java as a requirement, and basic systems programming as an elective. That's backwards.
I don't care if you still use OOP. I'm not advocating for its removal from production codebases. There are plenty of things that earn their keep in modern product stacks that aren't fundamentals of computer science!
It's still useful sometimes. Right now I have a functional-style program I think would be easier to write if was redesigned in Mixin-style OOP. Usually happens the other way, but not always.
I don't think it's useless so much as that it's not on the same tier of fundamental importance as structured programming, the memory hierarchy, concurrency, functional decomposition, recursion, trees, tables, and graphs.
And when you look at what the actual classes teach: it's usually patterns-y Java. GoF patterns are effectively obsolete. You might still need to grok them, but that's trade knowledge, not fundamental computer science. You don't come out of a CS degree knowing Hibernate or SAP, either, but people figure it out on the job.
What's the problem with design patterns? At its core, a design pattern is just a name applied to a frequently used code pattern. It gives us a common language. I can tell you we are using a publisher-subscriber model and you know what that is without me having to be super specific.
The concept of a design pattern is ~fine, and people have done good work applying the concept to specific programming domains (concurrency being the best example I can come up with), but "Gang-of-Four"-style design patterns are just workarounds to the limitations of the languages those authors were grappling with at the time, and are deeply silly in modern code, mostly living on today as an AbstractFactoryFactory joke.
I disagree? The point of a CS degree isn't to prepare you for the 20 years of stale J2EE code your first job is going to throw at you, and object-oriented design is pretty out of fashion.
What programming job are you getting in the next few years that understanding oo isn’t important?
Inheritance, polymorphism and encapsulation inform every major professional programming language and framework (except c). Even go which in many ways is active response to oo uses most of those concepts extensively. One major challenge of people programming in go is how to adapt the familiar patterns to it.
Now I’d probably not teach the whole GoF as an exercise in cataloging patterns but teaching a few of the most common while showing the concept of patterns (probably the least well understood concept in development) seems sensible.
My argument accepts the idea that you're likely to come across object-oriented code in your first jobs in the field, the same way you're going to come across complicated SQL joins, which is also something a CS curricula is unlikely to prepare you for. I would advocate for delegating OO concepts to that kind of level of "trade knowledge" rather than elevating it to a "fundamental" of computer science.
Rust and Go have concepts that approximate class-based object-oriented programming (and: if you look at NEU's OO syllabus, that's what they're doing), but only barely. You could teach someone how to use an interface without teaching "polymorphism" as a concept. Encapsulation as a language feature is an example of an OO-ism that I think is done and dusted. We hid implementation details in C, too! The notion of an abstract data type is fine to hold on to. The idea of "friend classes" and "protected" fields and other ACLs for variables, though, I don't think we're going to see come back.
OO elevated encapsulation, inheritance and polymorphism to fundamental language features. Polymorphism especially has become ubiquitous in modern languages in the same way types have.
And perhaps we’ve moved past inheritance hierarchies (though multi/parent inheritance has been interestingly used recently) but even then, knowing about it and its negatives seems as fundamental as understanding goto.
Are they on the programming side of the computer science curriculum rather than computational math? Yes! But much of the normal curriculum is. Similar to how I’d expect the relational calculus to be taught as well as how sql relates to it.
I think you’re pretty far out on a limb here and I’d be very skeptical of a curriculum that didn’t have a segment on oo early on.
I'm comfortable being out on this limb! I think there were OO-skeptics even at the height of OO (call it the Ruby/Java crossover period; or, maybe, the point at which Norvig gave his patterns presentation, 5 years earlier) and I think the skeptical take looks pretty strong in retrospect.
Whatever you want to say about the OO inspiration of how Rust and Go are structured, they are both clear and deliberate rejections of the OO orthodoxy from that period. They both deliberately don't have classes. They both deliberately eschew inheritance. They both deliberately have less-granular, less-configurable "encapsulation" rules.
And: "encapsulation" is a term we only have because of class-based object-oriented programming. As a professional C programmer in the 1990s, I'd have gotten dinged on a message board by a C++ person if I claimed that I was "encapsulating" when I hid the structs for my timer library or my trie library behind a void pointer. We had abstract data types long before mainstream class-based OO, and then class-based OO claimed credit for the idea.
I also think, as you've alluded to here, mainstream OO has a lot of bad ideas that get people in trouble. The obvious one is animal->mammal->cat->tabby, but there's also the debacles that happen when people try to unify storage with the same inheritance ideas used by compute.
More than anything else though, I think these are the kinds of details you can just learn on the job. What's fundamental to programming? Ironically, it's a lot more of the stuff you get in a Scheme-based class --- and I'm saying this as someone who does not like Lisp. I think Python is a step in the right direction here.
Go absolutely has classes, polymorphism and encapsulation (I don’t know Rust) and many, many packages in go follow extremely common OO patterns.
The 2 differences in go are composition being the mechanism for inheritance and structural typing in an otherwise strongly typed language. Both of those were available in other languages that strongly identify as oo.
My first cs class was taught in scheme. I think that’s the _right_ way to begin to learn. But very quickly after that oo and imperative ought to be introduced.
I would sum my career up as C -> C++ -> Python/Ruby/Python -> Go -> Go/Rust, and would say my experience of Go (reinforced in Rust) was sharp pushback on class-based OO idioms, especially inheritance.
People are still writing OO code today, they way the industry stands it looks like people will still be writing OO code for at least the next decade. Maybe the next 20 years, even.
I understand that not every developer is a big fan of OO but that doesn't mean we can ignore it.
OO is one of many paradigms to take while programming. Between functional programming, C-style subroutine programming, and OO, or the more recent amalgamations of those, you pick whatever suits your problem best. It's perfectly useful to teach, even if you dislike OO programming. I don't like writing for outdated programming designs like Scheme or LISP either, but that doesn't mean they don't have anything useful to teach.
OO is out of fashion just like blockchains and NFTs are out of fashion, and the same way AI will fall out of fashion in the future. The huge hype around it will die and what's left covers the few useful scenarios.
>> and object-oriented design is pretty out of fashion
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.
You’re assuming an exaggeration of their point. The question at hand is whether OO is so fundamental as the backbone of a computer science 101 course. This doesn’t preclude much of what you said.
how did it ever become gospel. given the diversity of human experiences, and the the diversity of problems we have to tackle, it is near impossible for there to be one and only way to solve a problem.
Matthias Felleisen, architect (I think) of the current curriculum, explains to a hypothetical skeptical university administrator the virtues of it: https://felleisen.org/matthias/Thoughts/py.html
The new curriculum might be worse but I'm not sure how a 4th year undergraduate should be too sure of themselves when second guessing the department.
My undergraduate degree is from RPI, I have worked with many NU grads, they are often very good, but there have been many eye opening moments for me with them in terms of how different the material they learned was and what was left for graduate school when it comes other the core mathematical fundamentals of computer science. To be fair I've run into engineers from other schools that leave all of this to graduate school too. My first internship I shared a cubicle with a graduate student at Boston University. She was taking a graduate course on algorithm proofs and the course used the same book that we had used in the major weed out class that we had in the spring of Freshman year.
"Program Design" has changed almost as often as popular programming languages during my career. Almost none of those core mathematical fundamentals have changed at all.
Algorithm proofs around complexity, efficiency, etc..
At least an introduction to the design of languages, parsers, and grammars
Algorithms and concepts in the design of different database designs (not how to use specific databases)
Fundamentals of operating systems and systems programming
Some crossover with computer systems engineering courses. You must know at a basic level how logic gates are implemented, how an ALU is built, and how these blocks are built up to construct a CPU
These are the actual fundamentals of CS and they change at glacial pace compared to languages and design patterns.
I can't speak to your experiences with others from my alma mater but pretty much all of these things are covered in the core CS curriculum at NU (at least the pre-redesigned one). Systems, PL, Algorithms, Algorithmic proofs, automata, ALU design were all part of required courses, and that's before I include the elective CS courses I took.
One area where NU does fall down IMO is that they offer "combined majors" with CS and other subjects that eschew some of these courses to make room for the other half of the major, which will be an unrelated subject. This offering is a mistake because you do miss out on some key concepts. If you're working with a pure CS major, however, they were required to learn all these concepts.
It's funny, my friends and I all entered CS around the same time (2010-2013) and I remember thinking it was weird for NEU to be using Racket. Clearly it's successful, and has proven itself to be a great place to start a CS career.
I always advocated a C based language, like C or C++. That's where my program (not NEU) began and I hated it but am grateful. We eventually moved onto Java. Later courses through my 3rd year allowed me briefly work with functional programming. We never touched Python or web frameworks until our Junior and Senior year projects, and even then it was generally voluntary and depended on the project we had proposed for our databases or algorithms classes.
What I do think CS programs should be evolving for are LLMs. Python + ChatGPT are powerful without the user knowing too much of the logic off-hand. That's a problem for new CS students who need to learn the fundamentals of logic, reasoning and programming. I don't know what languages work "less-better" with modern LLMs, all I know is that ChatGPT and Claude work exceptionally well with Python.
I suppose, as long as we keep paper exams, all hope is not lost. Maybe just a little, in my opinion.
Agreed, LLMs mean that it's MORE useful and important to learn Racket and C, the LLM will help you much more with knowing the specifics of python/js/go/java or whatever human-focused language you end up working with for your job. If you want to be a stellar developer in 2025 you want to learn the things the LLM ISN'T good at, understanding the fundamentals of computer science is way more useful now than it was 5 years ago because the baseline for being good at a language is so much lower with an LLM aiding you.
I watched the video first lecture in the MIT course on which Structure and Interpretation of Computer Programs is based and it explains "computer science is not a science and is only incidentally to do with computers" and goes on to compare the relationship between CS and programming to that between geometry (which means "earth measurement") and surveying.
I'm seeing many undergrads write LLM code that they don't even understand. It's a travesty. Can't remember the exact saying, but it went like: "AI creates short development times and super long debugging"
I fourth-year undergraduate argues against the change like a professor. Honestly, this shows the strength of NEU's current (former) curriculum.
Without knowing the new curriculum, I guarantee you that one of the biggest daily complaints about the old curriculum was the requirements that they write unit tests ("check-expects"). Do you think that's going away? Hahahaha. The laugh will be on students who think they're getting something different because the label on the can changed.
If this strategy infects CS degree curriculums widely, employers looking for more than mere coders will overlook CS majors and instead look to engineers, which is where most computing professionals came from academically before about 1980.
Engineering continues to demand that students learn principles grounded in theory (calculus and statistics and discrete math), rigorous analysis (pattern recognition and learning), and system compositionality (design using reliable components as building blocks). CS curricula largely jettisoned this approach after higher-level languages like FORTRAN and C caught on, and has retained only vestiges of old-school mathematical rigor (basic inductive proofs and algorithmic analysis (albeit dumbed down to O(n) only). In the past 20 years, CS has even given up teaching software engineering (compositionality and reliablility) as a requisite skill area. That speaks volumes about the difference that already exists between CS and engineering.
With the enormous growth in college-preparation for software careers in the past decade, it's little wonder that most students prefer a less rigorous, less formal curriculum, and that colleges will choose to meet demand where it lives. Thereafter, if employers want to hires grads with math or engineering skills, they will turn back to engineering as they did long ago. I expect programs in EE and Computer Engineering will adjust their curricula (or add minors) to fill the intellectual void that 'CS For Poets' will leave.
I find myself agreeing. As a person with an engineering background that's part of an ownership team, I often find myself longing for software developers with an engineering mindset i.e think of how the components will fit, without breaking user experience.
My son went to Northeastern ('19) and now designs programming languages and can program skillfully in ANY language. I'm glad he went to Northeastern before this announced change. I feel my money spent at Northeastern was well worth it, not because it made him employable (it did), but because it gave him critical thinking and research skills. It would be sad if too many future Northeastern grads were limited to programming in Python or whatever the mainstream language of the decade is. "Batteries included" Python is great for the workforce but it may weaken basic development skills of undergrads. I'm glad I grew up in an era (1970-80s) when what mattered was sitting down with a manual or book and picking up a language in a weekend and, working with your friends, mastering it in a few weeks or months. A favorite memory that still astonishes me: in 1983 Andy Sudduth, one of my roommates and soon Olympic rowing medalist, built his own computer (a Heathkit), and with a paper due the next day, I offered to lend him my Kaypro-II so he could use WordStar. He said, "Thanks, but I'm going to put my own operating system on it [which he developed in his OS course], then I'm going to use my own full-screen editor I wrote, and then I'm going to write my paper using that editor." "You're going to do all that by tomorrow?", I asked. "Yes." And HE DID IT.
Hey! Guessing by your handle, your son is Alex, yes? He's done some really cool work. I particularly love his paper "Type Systems as Macros" that he wrote with Stephen Chang and Ben Greenman (my advisor now). Super cool stuff.
I attended Northeastern from 2010-2013. Fundies (the freshman-level functional programming courses) was fundamental (ha) to my growth as a software developer. It taught me how to reason about data and how to design programs (the literal name of the textbook).
I know a lot of students hated it—frankly those were mostly the students that it seemed were only doing computer science programs because they’d heard they could make a lot of money in the field. The “real nerds” all seemed to love it, and now nearly 15 years later those are the engineers in my network who have built the most impressive systems and products.
I guess I’ll have to update my default instructions for recruiters from “automatically interview anyone with a degree from Northeastern” to add “if they graduated before 2025”
I can't find a person who didn't initially make the fun-dies joke, then later come around to it, myself included. Sometimes you don't realize someone helped you until years later.
That's a good thing. I don't know whether your assertion about the breakdown between "real nerds" and the other camp is accurate or not, but I think this point stands on its own regardless--learning is hard. It's uncomfortable. It's unpleasant. If it isn't, you're not being pushed hard enough. So what's the point of asking students how they feel about it? Why make strategic decisions based on those data?
I'm genuinely curious, not trolling or anything. It seems completely baffling to me that educators behave this way, and I'd really love to understand why.
My take: if a given task is not fun, then it is work. People on average do not enjoy work. They do not like doing work, let alone doing it well. Training kids to do work well, without any pleasure, necessitates heavy accountability enforced by management, which brings a slew of its own requirements and complexities.
Schools already handle many cross-competing concerns across stakeholders (PTA, Taxpayers, Town Government, State Government), so I suspect they would want to reduce their enforcement & oversight load. They'll choose a teaching style that makes everyone happy or at least complacent, even if they know "fun is not learning".
Exciting to see this on HN! As a ‘15 NU alum that took the CS program & third time founder, I support the change.
Fundies 1 and 2 were great, but I have always felt that the amount of delayed gratification in NU’s CS program was much too long and incongruent with the university’s focus on experiential learning. I wanted to get my hands dirty and build something and the whole curriculum felt too academic.
Northeastern CS is world class at compilers and programming language research, so I always understood that the undergrad program would tend to be academic as a trickle down effect.
It’s a spectrum with tradeoffs, so I think balance is key. But happy to see the pendulum swing a bit and think it will be good for new grads, especially as more coding work becomes automated.
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.
"Everything will be OK" - people will succeed in any system. Nobody will ever compare the outputs of the two systems, so nobody will ever know.
Let me instead suggest that one question we should ask is: What kind of students will be successful in the new system? What kinds of students will not?
One interesting thing aspect of the former curriculum is that (IMO) it provides an entry for students who are not entering with a lot of pre-existing knowledge. One of the criticisms of "old school" computer science teaching is that it privileges students who already have exposure to the material... The former curriculum is not the only way to level the playing field, but it certainly does provide a more level playing field for students who might not even be sure about the major.
I will stop with the suggestion that (IMO) pre-existing experience is definitely not the best indicator of future developer quality, so I value a curriculum that does not select for this.
(Caveats: never saw the new curriculum, it could be just fine, there are lots of other ways to accomplish this goal, but still... I am concerned.)
I don't know how much I buy the "leveling the playing field" argument. In my computer architecture class, we learned Sparc assembly. Very few people had encountered much assembly, and definitely not Sparc. At first, it was level, but people with more programming experience quickly adapted since it wasn't actually that different.
I believe this is a fundamental misjudgement of the CS curriculums at MIT and NEU and, apologies for being blunt, probably the worst take on this thread.
The student populations at MIT and NEU, particularly in CS, are fundamentally different. The majority of undergraduates at CS MIT participate in academic research while the vast majority of CS undergraduates at NEU do not (do not let NEU's exceptionally high computer science research output [1] confuse you - the undergraduate and graduate schools are very separate). MIT educates significantly less students than NEU. MIT's algorithms class (6.046) is significantly more rigorous than NEU's equivalent (CS3000) - just compare the publicly available curriculum and problem sets [2,3]. In general, MIT's CS curriculum caters towards the third of the student body that go on to do PhDs, while NEU's CS curriculum caters towards the vast majority of students that beeline towards industry [4,5]. The institutional goals and educational values between MIT and NEU could not be more different. I know all of this to be true because I've spent a significant amount of time at both institutions.
I don't know if NEU will butcher its CS curriculum. I hope not. I guess we'll just have to see.
P.S. it's worth checking out Pyret [4], essentially a functional teaching programming language. The language is mostly written by NEU staff, so I wager NEU's future CS curriculum plans to phase out Racket in favor of Pyret.
Before the current curriculum was implemented, a good portion of students were having difficulty finding jobs and co-ops. After the switch, employers were very eager to hire these students.
The change is not a mere "switch to Python" (which itself is not nothing). It is the replacement of a good curriculum with something mediocre.
Also, I don't know how MIT is doing after the switch.
Skimmed it quickly and saw it taught Racket to teach programming design.
I've worked at a coding bootcamp in 2017. And I have to say, I was a bit jealous. Where I was learning through methods at university that were a bit quaint, my students learned JS with the latest frameworks. And sure, you can argue whether the length of 3 months is enough, but they were surely getting a better education. What they learned in 3 months, took me at least 6 months to a year in terms of how useful it is.
The thing is, especially as a beginner, learning any programming language will give you similar difficulties (glossing over some nuances). So why not just learn a practical one?
I think once a student has had a practical programming course under their belt, only after that should more esoteric languages come to showcase certain concepts. I believe that they'd be more motivated to learn them as they're more into the groove of programming.
And this is coming from someone that has programmed 2 years in Pharo.
Also expressing concerns about the selection of suitable languages for novice programming is King's College CS Prof Michael Kölling, who explains, "One of the drivers is the perceived usefulness of the language in a real-world context. Students (and their parents) often have opinions which language is 'better' to learn. In forming these opinions, the definition of 'better' can often be vague and driven by limited insight. One strong aspect commonly cited is the perceived usefulness of a language in the 'real world.' If a language is widely used in industry, it is more likely to be seen as a useful language to learn." Kölling's recommendation? "We need a new language for teaching novices at secondary school and introductory university level," Kölling concludes. "This language should be designed explicitly for teaching [...] Maintenance and adaptation of this language should be driven by pedagogical considerations, not by industry needs."
While noble in intent, one suspects Kaplan and Kölling may be on a quixotic quest in a money wins world, outgunned by the demands, resources, and influence of tech giants like Amazon — the top employer of Northeastern MSCS program grads — who pushed back against NSF advice to deemphasize Java in high school CS and dropped $15 million to have tech-backed nonprofit Code.org develop and push a new Java-based, powered-by-AWS CS curriculum into high schools with the support of a consortium of politicians, educators, and tech companies. Echoing Northeastern, an Amazon press release argued the new Java-based curriculum "best prepares students for the next step in their education and careers."
> The program design skills that our current curriculum emphasizes are “what distinguishes a garage programmer from a serious software developer,” in the words of the Fundies 1 textbook.
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.
This is a really frustrating development, and I'm not sure I have the energy to explain why because it should be obvious and because the negative emotions of years of dealing with stuff like this.
My main complaints border around: there's no art in anything anymore in that unless you're doing the lowest common denominator you are doing it wrong, companies show more and more success in influencing others (namely universities) to be their training centers for them, and that universities should be about learning and exploration and not subservience to culture.
I haven't seen many CS curricula start bottom-up with things like digital logic, yet the best programmers I've worked with all started around there and then went upwards --- many of them were self-taught, and although I realise that introduces some selection bias, I have also worked with others who were self-taught but started with some HLL instead, but they didn't have quite the same performance.
That's not "bottom-up". That's a concern for EE/CE or something in that general scope.
As the old Dijkstra quote correctly states, physical computing devices have as much to do with CS as telescopes have with astronomy. They're eating utensils, not the main course. Computer science (the name in English is misleading and horrible) is not about physical computing devices. Devices are merely an instrument. Knowing how to use this instrument well is very useful for people in the field, but it is incidental to the field itself.
Even the distinction between "high-level" and "low-level" languages is meaningless from a CS perspective, as it essentially presumes a target language on a target architecture (with the target "low-level" language) that is treated as normative and "real", but again, that is an implementation concern wrt the instrument. From the CS perspective, compilation is just translation from one language to another.
So I dare say that a CS curriculum that starts with digital logic is not really a CS curriculum, but an electronics engineering curriculum. This is the lesson here.
What kind of argument is this? Do you also think it's fine for an astronomy course to not teach their students how to use telescopes? Or a creative writing class how to perform the physical act of writing?
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."
> Or a creative writing class how to perform the physical act of writing?
A computer science class teaching how transistors work is more like a creative writing class teaching how pencils are made, and focusing on the quirks a particular language is like the creative writing class teaching a specific style of cursive.
There are degrees which blend the EE and CS worlds, commonly referred to as computer engineering. That would be more along the lines of mixing the hardware/boolean logic idea with then software development. But that's definitely a different perspective compared to what computer science historically meant.
> I haven't seen many CS curricula start bottom-up with things like digital logic
That's how we did it in Slovenia (Uni of Ljubljana). You start with discrete math and bool algebra, and you learn how transistors work in physics, then you learn about digital circuits and write some assembly, after that it kinda feels like two parallel branches. One set of professors teaches you the math of it all, the other set teaches you how all that math works in practice.
It's a really good curriculum.
Yes yes you also have programming classes in parallel with the digital logic and the math and the assembly. Gotta make sure folks can get those all important part-time jobs and feel like they're learning something useful. It's common, or at least was back then, for students to have jobs in industry while they are studying CS. I honestly think having a job and getting to apply what you're learning makes it stick more ... even if it leads to abysmal completion rates (average 7.5 years to graduate when I was there).
My university's CS program was taught in Ancient C++. This was fine for the Comp Sci majors, but the intro-level class was required for all science majors. I fielded many pleas for help on homework assignments and saw that many struggled so much with the (let's be honest, incredibly unintuitive) syntax and inscrutable compiler errors, that they couldn't internalize the more fundamental concepts that the course was trying to teach.
Later on, I joined the curriculum committee and argued for it to be taught in Python. The faculty weren't convinced at the time but I see now that eventually they moved the intro course to Python and kept the later courses in C++, which seems like a wise decision. Python is far more approachable and will serve science students well if they ever need to use Pandas etc. (The second-semester C++ course has you implement the STL container types, which is an extremely valuable exercise.)
Pyret, the pedagogical language for the next intro course seems like a massive improvement over Racket. I have faith in the PL team at Northeastern, especially BLerner to not skip problem-solving fundamentals in an introductory course. Having been a TA for Fundies I and seeing what these professors value, I feel confident it’s in capable hands and that it may ultimately be an improvement.
I read the article and got curious about Pyret. It turns out to be a very nice language, especially for teaching! Very clear and easy to read syntax, no weird bracket mania :D, it even forces programmers to write good formatted code (space surrounding operator!) and encourages the use of best practices (test first!).
I also like the fact that it is functional, invariant by default, and they are working on type checking.
Seeing this, I can't wait to hear about the students' experiences with the new curriculum.
i'm a dropout just do horrible coding for fun can anyone explain why CS programs are adamant about not teaching on the job skills? like databases, web, embedded, security plus theory
The ideas behind a database is more important than the the concrete database used. If the ideas are taught, then the students can adapt when the fashion changes.
So instead of teaching something that you can use on your first job, they teach principles you can use your entire career. And times does change.
Remember the good old languages Fortran, Algol 60 etc. That's where the jobs were...
I graduated with a degree in CS. Checking back with my university they'd added a degree in Software Engineering.
CS (traditionally) is more about algorithms, limits, growth. There's a bunch of complexity in even just understanding and calculating what a computer can do.
The Software Engineering degree makes so much sense if you're studying about how libraries can be tied together, upgraded, unit/integration testing, container and source code management, etc.
They are truly different disciplines at this point.
sorry if this sounds dumb I don't have any formal education why is there a distinction?
when i hear computer science i hear the study of computers that in my head means software, hardware, and theory it's like having doctors that study humans theoretically and others that do surgery
Computer science is step one towards getting a phd and doing research and design of actual tools like compilers, understanding how the CPU sees and asks for data stored in memory, efficient algorithms to do XYZ, it's highly relevant for stuff like embedded computing where you're often working with severe hardware constraints and possibly with a real-time os.
Software Engineering is the study of how to efficiently build software, typically on a medium to large team.
Analysis is the key. You write a program to multiply matrices. That is software engineering. You analyze the program to figure out how much slower it becomes as the matrices becomes larger, how many times it must access ddr, how well-utilized the caches are, etc. That is computer science.
Computer science is designing a new video compression algorithm to be more efficient. Software engineering is taking that video compression algorithm and putting into an application users actually use.
That heavily depends on the school. But I’ll add many years later, I appreciate the theoretical classes much more because the knowledge I gained there has aged much better.
In our pretty dynamic fast moving industry, it is more important to learn how to learn technologies, rather than learn the technologies directly. No one wants to be a specialist in 20 year old outdated tech late in their career. Having a strong foundation in how CS tech generally works allows you to move between different tech stacks fairly quickly.
Pretty much every class that focused on "on the job skills" when I went to university (2008-2014) either at my university or from looking at coursework available elsewhere (I might have considered jumping universities for non-educational reasons) was either outdated or useless within few years. If I were to redo it I'd prefer to have even more "esoteric" tech involved and more theory and fundamentals.
And not because they were outdated and useless when the course started, though some did have issues. I think the least outdated "on the job applicable" material is Java fundamentals, and that's because you can still write Java 6 basic stuff in current JDK - a lot of the interesting and powerful stuff we learnt is no longer available in JDK though.
OTOH, fundamental principles - algorithms, including set logic in RDBMSes, low-level programming (which to annoyance of some was done in SPARC assembly or random assembly designed just for given assignment), robotics using programming stack and parts that were never seen outside university, various in-depth studies on different theoretical or scientific areas - all of that is material I use to this day in many different jobs when it allows me to understand and reason in ways I couldn't before I joined university - and I already "knew" how to program then.
BTW, within the 5 years I spent at university, "javascript on the server" turned from niche use cases within some stacks, usually running Mozilla Rhino, into complete new ecosystem that was surviving its first big fork and was becoming used in big projects, Android went from one phone "who knows" to pretty mature platform holding half the world with 64bit CPUs, tablets and first wearables, similar evolution for iOS, in fact arguably over my entire university time we had explosion of "you can now make mobile apps easier" to "mobile app developer is lucrative" all the way to "you're probably not going to make much money as solo developer anymore".
It's stunning to work with fresh out of college cs grads and... having to take 10 minutes to explain how git works, why we use source control, and then every day fielding questions about git, merges, and fixing merge conflicts etc as the get up to speed. I realize there is a learning curve as someone fresh out of school but also there should be some basic job training using free versions of tools like git and sql. The average student is only going to get a shadow of the relevance if they're learning pure theory with no context.
These are tools! You don't go to university to learn how to use git. Besides, tools that come and go. You can pick these up along the way. You can make their use a part of coursework, but this is not what you go to university to study!
That's the point. CS curricula are supposed to teach you deep skills and principles, not how to fiddle around with git.
If your CS degree never requires you to write a program complex enough to warrant version control you should get your money back. I agree that the theory is more important and tools should not be focused on, but exercising the theory you have learnt is extremely rewarding.
I am a graduate of Khoury and find this very disappointing. I wasn’t a huge fan of learning Scheme/Racket but after looking back during my career I’m grateful for the education I got there.
I’m wondering if neighboring competitor schools who offer python classes are the reason for the change since more students would actually consider attending a different school due to having a stronger post experience and skills gained.
I don't think Northeastern is worried about attracting applicants, they were the 8th most applied-to school in the US last year, with nearly 100K applicants. And CS is one of their most popular programs.
I think the more likely cause is pressure from their co-op program's partner employers to make the intro curriculum more 'practical' (i.e. outsourcing training from the employer to school). It's beneficial in the short-term but IMO a loss in the long-term, Northeastern is a university not a bootcamp.
My biggest worry is that maybe the co-op program for CS became a "low interest rate" phenomenon over the years from ~2009-2020 and now they don't want to take gambles on students that likely need to grow into the role. It's not enough, and they treat it like a regular internship program.
This op-ed was written by an undergrad and complains that Northeastern's switch to Python (from Racket) for its introductory classes will prevent students from learning fundamentals of computer science.
But that complaint can be made about any language! "This dynamically typed language won't allow students to understand type safety." "This high-level language won't allow students to learn pointers and systems programming." Etc.
I believe that an intro course should get students coding since the first major hurdle is learning how to construct any kind of program at all. The switch to a more "employable" language isn't going to make education worse.
Tell me you haven't read the article (or used racket) without telling me.
> I believe that an intro course should get students coding since the first major hurdle is learning how to construct any kind of program at all. The switch to a more "employable" language isn't going to make education worse.
None of this is the issue at hand. The switch to python is because industry uses it. The article correctly makes the point that racket was intentionally designed to get students coding as easily and quickly as possible. It has multiple steps of teaching languages for exactly that purpose, introducing concepts in ways that let students grapple with them one at a time in an interactive environment.
Meanwhile in python complex topics like duck typing, object oriented methods, exceptions, the distinction between iterables and lists, how to use a command line/terminal or how to configure an IDE, and so on must be covered before people can start writing code for the exercises. Racket is streamlined for beginners.
> Meanwhile in python complex topics like duck typing, object oriented methods, exceptions, the distinction between iterables and lists, how to use a command line/terminal or how to configure an IDE, and so on must be covered before people can start writing code for the exercises.
No, they dont have to be at all. You might as well suggest you need to learn the JVM before writing a line of Java.
Python supports imperative, OO and functional programming paradigms. And to start you can use any text editor, an IDE is not required. In fact you can start working in the REPL right away, in which case you need a terminal and the command “Python”.
To quote the above person: "tell me you haven't read the article without telling me".
You thought that supporting multiple "programming paradigms" is a nice thing, but it's the opposite for teaching beginning student. Experienced programmers want expressivity/customization/choices to do whatever they want. That's not what newbies need when they get stuck on an assignment.
In this case, you can find the same criticisms in published articles and books. I expect this student heard them straight from the source (author of the articles or books). That does not lessen their impact or correctness in my opinion.
>we should not teach something just because it's a useful skill, we should teach our favorite dogma that we believe is totally more useful than a system built up through decades of practical experience, guys really.
I went to Caltech when they were contemplating similar things in the CS curriculum, although the normal curriculum was less radical than Northeastern's seems to be.
There is a tension here that is being understated which is that people of every major now take the intro-level CS class because programming is integral to everything. Teaching algorithm design in that class is not particularly useful to a biologist who just wants to be able to cobble something together to analyze some data (usually in Python). As a result, the non-computer-scientists and non-software-engineers at the school would rather have a curriculum that is more "practical" and directly applies to research (or later class projects) the students might be doing.
Some time not far in the future, we are going to accept that this is not the same thing at all as computer science and give the computer scientists a curriculum that is a lot heavier on math and theory while adding elective or core courses for non-major students on programming. That will end the compromised state that intro CS courses currently sit in. Right now, there isn't enough teaching talent to run those non-core courses (because that talent is earning the big bucks doing something else).
> There is a tension here that is being understated which is that people of every major now take the intro-level CS class because programming is integral to everything.
Why doesn’t the CS department have a different intro class for CS majors and non-CS majors.
That’s a common practice in the mathematics, physics, etc. departments.
(To have harder intro classes for the students majoring in your department vs those who don’t.)
At least when I went to school, intro CS was a weed out course for getting into the CS department in the first place, along with calculus based physics that potential engineer and physic majors also had to take.
I think these days it’s a bit different in that many schools allow high schoolers to apply directly to the CS department? But then it would be a matter of scale I guess, they usually have clinical professors run these classes because they demand full time attention.
Weed out courses do have various problems. Some of it is regulatory - certain public or public funded universities don't let you eliminate large portions of your cohort. Graduation rate is a part of many college rankings, so there's also an incentive to not fail.
I don't think it's completely wrong. Failing a student after he or she sunk a ton of money into it is really not ideal. IMO it seems really easy to pass prospective students the first few chapters of your CS textbook/lectures then test them as a prerequisite for enrollment, before they enrol. This would be close to free, filter out a lot of would be dropouts and just save money and effort all around.
Doing weed out courses on purpose I think is elitist and unnecessary, but computer science does require understanding of some hard topics. Linear algebra, theoretical computer science and the like may have very high failure rates, but are a necessary pre-requisite to become a computer scientist.
I wouldn’t say linear algebra is a necessity to being a computer scientist. At least, not the full linear algebra content. Knowing matrix math is enough.
It's not completely necessary. But I will say, as someone who began their career as an 18 year old "self-taught developer" then completed a CS degree at 30, I found linear algebra to be the most useful bit of knowledge that was missing from my kit.
Two reasons:
1. Back when I was in CS, the department was much smaller than it was today. This was after the 80s programmer crash, and so they just didn't have enough professors or resources to teach as many students as were interested in being CS majors.
2. You are able to teach to a higher standard if you've filtered the students that enter your department. You can have one or two people fail OS rather than half the class. At some point, it is reasonable to see if the students are committed, and they get to prove themselves a couple of years after high schools, which worked better for people like me who weren't very accomplished until they get to college.
They need to get rid of the concept of weed out courses. It's bad for learning. If you are paying 30-50K a year for an education, course availability should be a given. Don't use the bell curve as an excuse to deny students an education, or if you are going to use a threshold, use a fixed one, not one that limits by percentage of students. The fat cat admins and professors need to be fired. Too many schools take the students' money and plow it into research and other areas, with zero regard for undergraduate education. "You are in university now, it's sink or swim. Can't make it? Too bad." This attitude is especially prevalent in the state/public unis, especially places like Berkeley where demands exceeds supply. Your traditional private colleges like Dartmouth and Harvard don't have this problem.
Ideally people who can't handle the course should get filtered out before being accepted to the college, so they don't waste any money. But since it's impossible to filter reliable at that stage, surely it makes sense to also filter early on in the course. (from the perspective of the student. If the college wants to take more of their money they could still direct them to a different, easier/more suitable subject).
A lot of schools these days weed out at the application level: if you have a great portfolio from middle school through high school, great! You have it made.
I sort of like the change to redeem yourself during the first two years of your university if you didn't have the ideal secondary school experience to get into a hot department of a hot university. CC can do that as well, I guess, but it is a much harder hill to climb.
Are there "math weed out courses"?
My university had a proof based, let's construct the natural numbers from axioms and prove that a+b == b+a type course as the first class for aspiring math majors. It was a "weed out" course, not in the sense that it was particularly hard, but more in the sense of introducing students to this is what 'real' math is actually about, and not so much the stuff you were doing in high school. Some students decided each year that they didn't want to do 'real' math and went on to focus on other things.
Yep.
At my university, after the usual calculus/diff eq/lin alg sequence everyone in STEM takes, we had “intro to advanced mathematics” that was proof based, taught in the spring, and a pre-req for everything higher level (abstract algebra, real analysis, etc). Most math programs have a similar “first proofs” class as their “weed out” class.
In that case the weed-out course is _after_ the calculus/diff eq/lin alg sequence then, not the intro math course.
Math isn't popular enough to have weed out courses, and math professors of higher division classes don't mind failing half the class. There isn't much of a drawback to letting as many people who want to major in math.
But intro STEM math is used as a weed out for other majors. You aren't going to get far in CS if you aren't able to ace your basic calculus classes.
Real analysis or other similar "proofs of basic things" classes usually fill this role.
At my university, they did, I don't think it's that uncommon.
Same here. The CS curriculum was theory-heavy (as it should be), and there were purely practical programming courses for the other faculties.
Right, there’s the longstanding joke about whether you’re taking real geology vs “rocks for jocks”.
Costs. They don't want to have two courses teaching largely the same concepts when one will do. Short sighted, but that's how they roll.
This is how physics is now. You teach an intro physics class and you have a billion engineering students all telling you what they actually need to know to be an engineer. But the truth is, it is often impossible to anticipate what a person needs to know for their future. The future is not an easy thing to predict despite recent innovations in AI and machine learning. And a student's current motivation is not necessarily the most important thing to consider when thinking about what they should be currently learning. People often change majors, career paths, etc. This is why I would rather people learn about topics that are fundamental to various fields, such as algorithms or conservation of energy or whatever, than some topical thing.
This exists already at Northeastern. They have a data science major and minor with a much more 'practical' intro sequence that teaches in Python. I actually TA'd for it, and many of the students were business or life sciences majors going for a data science minor. It even came with a 1-credit practicum geared towards specific domains, which students could choose from.
I live in California and I recently read an article from the perspective of Berkeley's CS department explaining why they don't take transfer credits from high schoolers who took AP CS or AP Stats -- they're just not "real" Computer Science, but rather applied programming.
Even when I was an undergrad (1995-1999) and a grad student (2008-2011) everyone knew that CS was a research science [that happened to turn out people who lucratively employable skills], and not a software engineering program, which existed separately at both schools.
That uses to be called CIS. When I was at Harvard they still took the algorithms class. Yeah, it was the ezmode version, but it still covered stuff like how to build a hash table and a trie.
I went to UNC Chapel Hill, and this was already done back in 2005 there. CS major intro classes were numbered in the 400s (401, 402, etc) with a focus on data structures, basics of big-O (later refined in algorithms), etc.
CS 101, 102, etc. were the “non-major” intro CS classes and exactly what you describe here. They didn’t count towards a CS major at all. Neither would non-calculus-based physics classes.
Note that, at least at UNC, in every other department I know of, 400-series classes were generally graduate level. But UNC CS operated a bit differently.
I loved the challenge and the knowledge I gained, but it’s worth noting that CS at UNC was much, much harder than nearly any other major there (Chemistry may be the one exception).
Why can't they just take a class on shell scripting? The whole point of computer science is to automate things, because that's what gives you leverage. If you don't care about understanding computer science, at least skip to the point and enjoy the fruits. We've been using the UNIX shell for 50 years. It's not going anywhere.
I majored in biology. A shell script would be a much more cumbersome tool for making a scatterplot, running a linear regression on a csv, etc.
The things that people are using Python for are significantly easier with Python. There are libraries designed to make these tasks super simple, and with the right IDE you wouldn't ever have to touch the shell.
I put gnuplot code and python code in my shell scripts all the time.
Someone like you should think of it as a jupyter notebook that doesn't need a web browser.
I'm someone that uses shell scripts in my day to day work (I don't work in biology any more, but did for a while).
I'm saying that for the average scientist using these tools, a shell script is not an easier or more useful tool than Python plus libraries. Can you honestly say that shell scripts are more intuitive and easy to understand than Jupyter notebooks? Are they going to be more easy to transfer to other stakeholders?
This is one of those solutions that seems better in theory, but likely isn't in practice.
I can't think of a faster easier tool for composing and controlling a bunch of heterogeneous things. Even if you write a Python script that does it, you're still using shell to run it. Notebooks are good for experimenting and explaining, not for automating.
Relational databases are going to be around for the next thousand years if you want something useful outside of tech.
This is how bad ideas keep propagating.
In the 90's at MIT they solved the problem by having the civil engineering department teach a C coding class to the non-CS engineers.
There was no pretense that it was even remotely appropriate as a CS class.
"Practical python" is undoubtedly useful to a biologist, but I wouldnt understate the utility of an intro to algorithms for technical but non CS majors.
'Algorithmic thinking' more or less doesn't exist in a lot of the classical disciplines with any degree of rigor, so a CS class is the only place a biologist is going to be exposed.
Specifically for utility, there is a very tight mapping between 'how do I search these strings' and 'how do I [most efficiently] design a set of experiments [searching for a a result]'. Both in the literal algorithms as well as the logical framework necessary to extend past trivial examples.
<specialty> for non-majors isn't radical.
"Stats for business"
"PE for physicists"
Why isn't "programming for sciences" not a thing?
"PE for physicists." Touche. ;-)
Dating myself, my college had Pascal for CS majors, and FORTRAN for physicists. The FORTRAN class was math heavy, and we had a higher level course in process control as well, plus we all took the math class in numerical analysis.
When my daughter was in college, it was Java and Python. She took Java. I had suggested to her that she could easily keep up with the CS students, which she did.
I very much favor better training in programming for scientists. Taught by a scientist. The "intro to Matlab" that many students take is really too lightweight. Also, as for languages becoming obsolete, the disciplines that I learned in the 1980s are still of value today even if the languages have changed.
>PE for physicists
You meant juggling and fencing?
A more pragmatic answer is who’s going to teach it? Someone with weak skills in the discipline? Or someone with weak skills in computing? (This is a glib answer)
Finding people at the true intersection is surprisingly hard, and those people tend to be busy.
In grad school I took and advanced statistics course in the psych department. The concepts were new to me but not to the folks in the discipline. However the math (matrix multiplication) and basic coding were easy for me and very hard for them.
There was only one person in the department who could teach it, other faculty did that type of work entirely as “clients” which just ran tools and code from others.
Who teaches the "<math specialty> for business" courses? IME, it was math professors.
It's not unreasonable for the biology department to come up with the common programming use-cases for their students, then have the CS department build a course around those skills.
My minor was Bioinformatics. The biology department taught foundational course like biology and genetics and the CS department taught the courses on processing data.
> Who teaches the "<math specialty> for business" courses? IME, it was math professors.
IME its the same...I've also found that approach works less well at generating good learning. It (seemingly inherently) results in decontextualized knowledge and does not get students over the application gap, which is the exact problem that such things are trying to solve.
It is. When I was in school we had a matlab class for grad students in other departments.
I don’t know why you’d try to throw CS majors and Biology majors looking to cobble together scripts into the same class.
When I was at UCLA in the mid-‘90s there were computer science courses taught through the school of engineering, mostly limited to SEAS students. So computer science, computer engineering, ee, me, and the like. I think the intro classes were taught in scheme.
And then for everyone else the Math department of the school of Letters and Science had their PIC (program in computing I think?) series which had two or three courses in C++ and another course in Lisp. As a physics major I took the latter.
> Some time not far in the future, we are going to accept that this is not the same thing at all as computer science and give the computer scientists a curriculum that is a lot heavier on math and theory while adding elective or core courses for non-major students on programming.
I graduated from an Engineering focused college in the late 1990's, and many departments offered exactly these types of courses in addition to the standard intro courses. They were typically named something [domain] [course #] for non-majors.
See also Applied Mathematics vs Pure Mathematics.
The end of an era. This is nothing less than a travesty honestly. The current (now former) curriculum at NEU was uniquely exceptional, and now it will be conformingly adequate. Anyone who complained about the difficulty or lack of "job-market applicability" of the Fundies classes entirely missed the forest for the trees. The point is the design _process_, and using Racket forced this. It also demonstrated the magic that is possible with computer science. The Dr. Racket editor has features that do not exist in any other editor (e.g. visually tracing references, and so much more). The teaching language just got out of the way and let professors teach the essentials of program design, without the burden of language idiosyncrasies. My mind was honestly blown when Olin Shivers coded the Y combinator directly and showed us how to add recursion to a language. It felt like having occult knowledge, and it made me an acolyte to computer science. I mourn the loss of this curriculum for future students, especially considering the premium price tag they now pay.
Taking Shivers' Fundies I class was mind blowing, even as a student that had been programming for several years already. They should have put him and Barzilay (who I had for PL and then later TAed under) in charge of the curriculum update.
I always enjoy seeing Olin Shivers name come up in threads about Northeastern. I had him for Fundies and have many fond memories of his lectures, I was truly inspired. It's no exaggeration to say that class and those lectures helped me find a passion and a career I enjoy. It's a shame they're phasing out Fundies, hopefully whatever they come up with will still be able to have that same impact on young students.
He also wrote the best Acknowledgments section to a manual ever: https://scsh.net/docu/html/man.html
Too bad there isn't an online version that anyone can take.
I spoke briefly with Felleisen at the end of this year, and sadly it seems the zoom recordings from the pandemic are lost to time. The course sites will likely stay up but the lectures were where it mattered
I'm going to provide a controversial take here as CS grad from a similarly-tiered program: there is a huge chasm between top-4 cs programs and everyone else. The top 4 are obvious: Stanford, MIT, CMU, Berkeley.
Then there are the cs programs of the ivy leagues, not as strong, but usually you have a rich parent or uncle who has already speed-tracked you into a hedge fund, so lets put those aside.
I didnt go to a top-4 cs program and the reality is -- there is no longer a real job market for any cs grad outside the top-4. If it were not for ZIRP it could be there never was! There is definitely not a job market for the sheer masses graduating with cs degrees, and it will take a decade to absorb the fresh graduates.
The curriculum does not matter here, so I think all this discussion is beside the point. No curriculum stasis or change will magically lead to jobs for fresh graduates.
I say this from three perspectives
1. Reality - just ask people if they found a job (ignore nepo-hires, also ignore startup founders with nepo-vc investments)
2. What politicians say. Both Dems and Reps have tacitly (or loudly) noted that local graduates do not cut it. It used to be subtle (https://www.fisherphillips.com/en/news-insights/biden-admini...), but it isnt any longer https://www.bbc.com/news/articles/clyv7gxp02yo
3. How people act. Foreign workers want the jobs more and are willing to do anything and learn anything to get it. My office is 95% non-us workers. They work hard.
Retired CS prof here (from a below (ok way-below) top-4 program). There is no longer a job market for CS grads outside of top-4? Is this true? I had no idea, as I understood it, CS major numbers are still rising.
GP is just making stuff up. There are plenty of jobs for CS grads still outside the top-4. Will there be some constriction in the market? Probably, code generating LLMs are getting more popular. But there are plenty of systems that are a bit too important to leave to random code generators.
I respectfully disagree Jtsummers.
Firstly, there are not "plenty of jobs for CS grads" -- if there were, you would have supply (us cs grads) matching up with demand (us tech jobs). Yet you see tons of unemployed CS grads. FAANG mostly has hiring freezes, and you have to be part of the inside club to be let in. Many cs grads go into bs jobs way under their potential (random government agencies, contractors.)
Walk into any US tech area and you wont see any Northeastern CS grads, or many non-Top-4 grads. You will either see Top-4 CS grads in leadership positions or at their own startups -- or you will see foreign grads. In some offices, 90% or more of the workers are foreign grads, not US school system grads.
Tons of job postings are fake. There was an entire HN post on this last week, companies posting fake jobs. Sometimes it is just to show a best effort before an insider is hired.
I think LLM copilots are a factor, but they are just a convenient distraction from the real problem -- a supply-demand-price mismatch. ZIRP conveniently hid the problem, but now it is out and visible.
> Many cs grads go into bs jobs way under their potential (random government agencies, contractors.)
Why are those jobs deemed bs?
>>> Many cs grads go into bs jobs way under their potential (random government agencies, contractors.)
> Why are those jobs deemed bs?
Because many of us went into the field bright-eyed, thinking about working on cool products, designing the latest algorithms, or being part of world-renowned teams. NOT to run the nightly batch job for the Massachusetts Depart of Family Services wage garnishment system. NOT to fix bug tickets at the local tax office's COTS implementation, while all the actual software is built elsewhere. NOT to work as a contractor without benefits.
Just look on Linked In, filter by Northeastern CS, see how many people have green semi-circles. Look at where people are landing jobs. Filter out nepo-hires, which are easily visible (e.g., jumping into leadership role straight out of school)
Sorry - little sympathy here. I acknowledge the market is much worse this year and last year.
But I started at a lame crappy job 10 years ago after college. It’s not a big deal, it gets your foot in the door and then in 2-3 years you can move up to a better company. I did this a couple times and after 10 years i’m now working at a faang adjacent company (household name but not part of faang).
That’s what normal life looks like for a typical CS grad. The fact you think getting a job at faang is expected or normal right out of the gate shows you’re in a bubble. It happens, and i’ve worked with colleagues who did it, but it’s not the norm.
and nobody is changing the world with their code, unless you’re linus torvalds or similar. best to squash that naivety earlier than later lol. It’s a job, and a passion for some (like myself). that’s it. It’s also healthy to find additional hobbies outside of the computer - something i learned the hard way.
First world problems.
Guess the smarties should have measured the patterns physical social reality rather than get sucked in by propaganda.
What physics demands society align with the spoken philosophy of a people? It’s kind of on the people to demand politics align with the philosophy. But go on, people; scream at your screen like gramps did at Dan Rather.
Distribution of education does not guarantee distribution of intelligence.
You understood correctly, CS major numbers are still rising.
CS major numbers == supply
I'm speaking about jobs == demand
bad faith doomer. One thing you also forget to mention is that non-us workers are just that, not in the US, and that matters now that more places are putting an emphasis on in-person work.
Your head is stuck in FAANG land.
At the end of all of this I wonder what will become of such great professors like Felleisen, Hescott and Lerner. A real shame
The University that hosted "The Little Schemer" and all its derivatives. Those books were a delight and taught me to think about programming in a way that other languages had not. (Even if I didn't go to that University). https://prl.khoury.northeastern.edu/teaching.html
I had been to a Scheme conference in Washington, adjunct to the Clojure Conference one year, and it was attended by many undergraduates from Northeastern, (and the authors of those books that I got a photo with.)
I have to feel sympathy for those undergraduates I spoke to. They gave a strong feeling, even then (8 years ago), that it was time for the University to move on in language choice.
I had a similar experience in the late 90s when the world was picking up Java, and our University insisted on teaching in Eiffel.
Teaching object-oriented design as fundamental computer science seems like it would have been an odd decision for 2025. I looked up the class syllabus, and it seems to have been taught in Java (fine) and makes extensive reference to design patterns (not fine).
I once asked a professor about this and the answer I got was interesting.
Basically Java and OO and Design Patterns are taught upfront because it turned out this was a huge stumbling block for a lot of people. Bigger than for instance C and pointers. Like it just doesn't click for a lot of people and they end up struggling a lot the rest of the major
So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year
Right, so... just don't teach Java and OO at all? They're not fundamental. Some of the ideas in that course are something closer to discredited.
Later
I edited "a lot of" to "some of"; I was coming on too strong.
If by discredited you mean incorporated into many of the most used languages as well as several of the hot new ones then yes.
Furthermore part of PLT is learning the past and what worked and what didn't.
I don't think that literally means learning how to write AbstractFactories in Java.
This makes sense. You might not immediately need to design a complex hierarchy, but you'll encounter them pretty early in a lot of languages standard libraries.
The first time I tried to learn how to program, I was 12-13 years old and found some video from a university that started by covering Classes, Methods, and Objects.
I watched one or two lectures and it made no sense to me, so I gave up. I had no idea WTF "objects are like nouns and methods are like verbs" was trying to teach me. I just wanted to make my computer do things.
Around 14-15 I started playing around with my TI-84 calculator writing simple programs. The TI-84 used a form of BASIC where I could write a program that took INPUT and plugged it into an equation and print it to OUTPUT, and it felt so much more approachable than the neo-neo-platonist OO lectures I'd watched. From there I gradually started writing more complicated code until I eventually started to get why programmers would define functions to stop repeating themselves, or why they might implement custom types.
> So it's not that these are the most crucial concepts, but you want people to "fail fast" and have a sense if they'll succeed in the major within the first year
I'd instead posit that so many people "fail fast" with OO because they go into their class being interested in programming, but have no idea wtf is even going on with programming and drop it, because they're forced to learn all this inane trivia [0] and write all this boilerplate (define a class, methods, observability, return by value vs ref) they don't understand before they can even run a program. They think maybe they're stupid or not a good fit for programming and drop it.
IMO a better teaching language would be one that lets you opt-in to OO and functional features but also lets you write really simple programs like "take a number, multiply it, and print it". I think that's why Python is so popular these days. It helps that the lack of semicolons/curlies, optional typing, and modifiers [1] removes so many distractions and gotchas that stymie absolute novices.
I also think most CS educators do a very poor job explaining CS concepts to beginners without realizing it. "Methods are like verbs" is absolute nonsense without a moderate to large amount of computer science knowledge to contextualize it. Some of my teachers were actually pretty good, and I also don't remember much acknowledgement that programming didn't have to be this way but that the language/tool was designed that way because that abstraction comes in handy. That'd probably help a lot in retaining students who successfully suffered through their first semester of CS 101 in Java but hated it so much they decided to swear off programming.
[0] Always start your program with "public static void main(string[] args)" ! Don't worry, that'll make sense in a year, or in six years when one day on the toilet at your software engineering job you realize that it really was a static function returning void that took string[] args
[1] Static and Foo& are justifiable, although static should arguably be implicit for a beginner language. Forcing students to learn about final, const, val/var, public/private, etc. early on is just stupid. I never understood why these were actually useful, or had a good reason to use them, until I'd already graduated.
Brilliant. And correct. The people who created this concepts landed there after going through similar paths like you did (i.e. they started somewhere straightforward but eventually invented these complexities out of necessity.) They understand they "why" behind it.
But somehow, in the curriculum, we expect complete noobs to just get this abstract, non-relatable concepts without any contexts.
There's some irony here. These courses exist because years ago, CS departments made a shift towards "marketability" in their courses at the expense of "fundamentals". So they introduced Java to replace C++ because that's the language companies hiring new grads were looking for. And now OOP and Java are not skills that companies are looking for in new grads. But instead of acknowledging the facts, the departments are lumping Java+OOP in with "fundamentals" and getting rid of it.
I'm sure if we look back further, C++ displaced some other language (pascal?) for exactly the same reason. And likely the same for the language the proceed C++. I'm just not old enough to have personal experience here.
OOP is one of the major schools of programming, significantly more widespread than functional languages. The only thing arguably used more is "simple" procedural, but even that is doubtful. Sure, in the 90s people thought OOP was the be-all-end-all, and we've moved away from that, but it still makes complete sense to teach the main different styles of programming. C and assembly are basically covered by a course on computer architecture and OSs, then teaching an intro course on both FP and OOP gives students a broader understanding on how the vast majority of program design works. Follow up courses on algorithms can then have synergy by showing how much easier/safer/faster they are to implement depending on the style.
I reject the idea that OO is a "major school of programming"; or, if it is, that school has been largely discredited. I think you're on firmer ground if you claim that ideas from OO still inform modern programming (traits and interfaces being a good example).
I think a lot of 2025 developers would be alarmed to think that a project had started from an object-oriented design perspective.
That's a bubble thing. The vast majority of serious software engineering is done in OOP. Java, C# and C++ alone are more than half the market, and then you have Python, Ruby, Kotlin and many more. Even JS has moved largely to (bastard) classes.
Then you have data (growing above average), scripting and partially frontend that are done differently, but they are still a minority of the job market.
If it was 2005 I would take this argument pretty seriously, but it's 2025 and I find it less plausible. Python has (somewhat dumbed down) OOP features, but modern idiomatic Python tends not to be domain-modeled intricately-encapsulated OOP; in fact, it's increasingly functional. You bring up Javascript, and my retort is React: the most popular UI framework in Javascript --- UI frameworks being the archetypical case of a problem domain well-suited for OOP --- is largely a rejection of OOP principles and a marked shift towards functional programming.
(I'm not a Lisp or functional partisan; like I said downthread, it's Go and Rust for me these days mostly).
Keep my original point in mind here, which is simply that OOP principles are not a fundament of software development in the same way algorithms, data structures, memory models, and concurrency are. We're discussing curricula that have students learning class-based object-oriented programming as expressed in Java as a requirement, and basic systems programming as an elective. That's backwards.
I don't care if you still use OOP. I'm not advocating for its removal from production codebases. There are plenty of things that earn their keep in modern product stacks that aren't fundamentals of computer science!
It's still useful sometimes. Right now I have a functional-style program I think would be easier to write if was redesigned in Mixin-style OOP. Usually happens the other way, but not always.
I don't think it's useless so much as that it's not on the same tier of fundamental importance as structured programming, the memory hierarchy, concurrency, functional decomposition, recursion, trees, tables, and graphs.
And when you look at what the actual classes teach: it's usually patterns-y Java. GoF patterns are effectively obsolete. You might still need to grok them, but that's trade knowledge, not fundamental computer science. You don't come out of a CS degree knowing Hibernate or SAP, either, but people figure it out on the job.
What's the problem with design patterns? At its core, a design pattern is just a name applied to a frequently used code pattern. It gives us a common language. I can tell you we are using a publisher-subscriber model and you know what that is without me having to be super specific.
The concept of a design pattern is ~fine, and people have done good work applying the concept to specific programming domains (concurrency being the best example I can come up with), but "Gang-of-Four"-style design patterns are just workarounds to the limitations of the languages those authors were grappling with at the time, and are deeply silly in modern code, mostly living on today as an AbstractFactoryFactory joke.
If you are going to teach OO in Java, I fail to see why teaching design patterns is so awful.
I mostly point it out as a reason why teaching OO as a fundamental is a bad idea in the first place.
But OO is a fundamental, even if it isn’t longer gospel.
OO is important and if I’m three years of computer science there’s no time to teach it then you have to ask what you’d heck they are doing.
OO is everywhere and it’s an important software concept and is the right solution for certain classes of problem.
I disagree? The point of a CS degree isn't to prepare you for the 20 years of stale J2EE code your first job is going to throw at you, and object-oriented design is pretty out of fashion.
What programming job are you getting in the next few years that understanding oo isn’t important?
Inheritance, polymorphism and encapsulation inform every major professional programming language and framework (except c). Even go which in many ways is active response to oo uses most of those concepts extensively. One major challenge of people programming in go is how to adapt the familiar patterns to it.
Now I’d probably not teach the whole GoF as an exercise in cataloging patterns but teaching a few of the most common while showing the concept of patterns (probably the least well understood concept in development) seems sensible.
My argument accepts the idea that you're likely to come across object-oriented code in your first jobs in the field, the same way you're going to come across complicated SQL joins, which is also something a CS curricula is unlikely to prepare you for. I would advocate for delegating OO concepts to that kind of level of "trade knowledge" rather than elevating it to a "fundamental" of computer science.
Rust and Go have concepts that approximate class-based object-oriented programming (and: if you look at NEU's OO syllabus, that's what they're doing), but only barely. You could teach someone how to use an interface without teaching "polymorphism" as a concept. Encapsulation as a language feature is an example of an OO-ism that I think is done and dusted. We hid implementation details in C, too! The notion of an abstract data type is fine to hold on to. The idea of "friend classes" and "protected" fields and other ACLs for variables, though, I don't think we're going to see come back.
OO elevated encapsulation, inheritance and polymorphism to fundamental language features. Polymorphism especially has become ubiquitous in modern languages in the same way types have.
And perhaps we’ve moved past inheritance hierarchies (though multi/parent inheritance has been interestingly used recently) but even then, knowing about it and its negatives seems as fundamental as understanding goto.
Are they on the programming side of the computer science curriculum rather than computational math? Yes! But much of the normal curriculum is. Similar to how I’d expect the relational calculus to be taught as well as how sql relates to it.
I think you’re pretty far out on a limb here and I’d be very skeptical of a curriculum that didn’t have a segment on oo early on.
I'm comfortable being out on this limb! I think there were OO-skeptics even at the height of OO (call it the Ruby/Java crossover period; or, maybe, the point at which Norvig gave his patterns presentation, 5 years earlier) and I think the skeptical take looks pretty strong in retrospect.
Whatever you want to say about the OO inspiration of how Rust and Go are structured, they are both clear and deliberate rejections of the OO orthodoxy from that period. They both deliberately don't have classes. They both deliberately eschew inheritance. They both deliberately have less-granular, less-configurable "encapsulation" rules.
And: "encapsulation" is a term we only have because of class-based object-oriented programming. As a professional C programmer in the 1990s, I'd have gotten dinged on a message board by a C++ person if I claimed that I was "encapsulating" when I hid the structs for my timer library or my trie library behind a void pointer. We had abstract data types long before mainstream class-based OO, and then class-based OO claimed credit for the idea.
I also think, as you've alluded to here, mainstream OO has a lot of bad ideas that get people in trouble. The obvious one is animal->mammal->cat->tabby, but there's also the debacles that happen when people try to unify storage with the same inheritance ideas used by compute.
More than anything else though, I think these are the kinds of details you can just learn on the job. What's fundamental to programming? Ironically, it's a lot more of the stuff you get in a Scheme-based class --- and I'm saying this as someone who does not like Lisp. I think Python is a step in the right direction here.
Go absolutely has classes, polymorphism and encapsulation (I don’t know Rust) and many, many packages in go follow extremely common OO patterns.
The 2 differences in go are composition being the mechanism for inheritance and structural typing in an otherwise strongly typed language. Both of those were available in other languages that strongly identify as oo.
My first cs class was taught in scheme. I think that’s the _right_ way to begin to learn. But very quickly after that oo and imperative ought to be introduced.
I would sum my career up as C -> C++ -> Python/Ruby/Python -> Go -> Go/Rust, and would say my experience of Go (reinforced in Rust) was sharp pushback on class-based OO idioms, especially inheritance.
People are still writing OO code today, they way the industry stands it looks like people will still be writing OO code for at least the next decade. Maybe the next 20 years, even.
I understand that not every developer is a big fan of OO but that doesn't mean we can ignore it.
OO is one of many paradigms to take while programming. Between functional programming, C-style subroutine programming, and OO, or the more recent amalgamations of those, you pick whatever suits your problem best. It's perfectly useful to teach, even if you dislike OO programming. I don't like writing for outdated programming designs like Scheme or LISP either, but that doesn't mean they don't have anything useful to teach.
OO is out of fashion just like blockchains and NFTs are out of fashion, and the same way AI will fall out of fashion in the future. The huge hype around it will die and what's left covers the few useful scenarios.
>> and object-oriented design is pretty out of fashion
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.
You’re assuming an exaggeration of their point. The question at hand is whether OO is so fundamental as the backbone of a computer science 101 course. This doesn’t preclude much of what you said.
how did it ever become gospel. given the diversity of human experiences, and the the diversity of problems we have to tackle, it is near impossible for there to be one and only way to solve a problem.
Matthias Felleisen, architect (I think) of the current curriculum, explains to a hypothetical skeptical university administrator the virtues of it: https://felleisen.org/matthias/Thoughts/py.html
Here is Felleisen's (who I should note is retiring) views on teaching programming at NEU, which is worth a read:
https://felleisen.org/matthias/Thoughts/Developing_Developer...
(... in the style of his The Little Schemer et al. books)
This is so sad.
The new curriculum might be worse but I'm not sure how a 4th year undergraduate should be too sure of themselves when second guessing the department.
My undergraduate degree is from RPI, I have worked with many NU grads, they are often very good, but there have been many eye opening moments for me with them in terms of how different the material they learned was and what was left for graduate school when it comes other the core mathematical fundamentals of computer science. To be fair I've run into engineers from other schools that leave all of this to graduate school too. My first internship I shared a cubicle with a graduate student at Boston University. She was taking a graduate course on algorithm proofs and the course used the same book that we had used in the major weed out class that we had in the spring of Freshman year.
"Program Design" has changed almost as often as popular programming languages during my career. Almost none of those core mathematical fundamentals have changed at all.
Would be interested on hearing more if you expanded on that point about differences in material.
Types of automata and computability
Algorithm proofs around complexity, efficiency, etc..
At least an introduction to the design of languages, parsers, and grammars
Algorithms and concepts in the design of different database designs (not how to use specific databases)
Fundamentals of operating systems and systems programming
Some crossover with computer systems engineering courses. You must know at a basic level how logic gates are implemented, how an ALU is built, and how these blocks are built up to construct a CPU
These are the actual fundamentals of CS and they change at glacial pace compared to languages and design patterns.
I can't speak to your experiences with others from my alma mater but pretty much all of these things are covered in the core CS curriculum at NU (at least the pre-redesigned one). Systems, PL, Algorithms, Algorithmic proofs, automata, ALU design were all part of required courses, and that's before I include the elective CS courses I took.
One area where NU does fall down IMO is that they offer "combined majors" with CS and other subjects that eschew some of these courses to make room for the other half of the major, which will be an unrelated subject. This offering is a mistake because you do miss out on some key concepts. If you're working with a pure CS major, however, they were required to learn all these concepts.
It's funny, my friends and I all entered CS around the same time (2010-2013) and I remember thinking it was weird for NEU to be using Racket. Clearly it's successful, and has proven itself to be a great place to start a CS career.
I always advocated a C based language, like C or C++. That's where my program (not NEU) began and I hated it but am grateful. We eventually moved onto Java. Later courses through my 3rd year allowed me briefly work with functional programming. We never touched Python or web frameworks until our Junior and Senior year projects, and even then it was generally voluntary and depended on the project we had proposed for our databases or algorithms classes.
What I do think CS programs should be evolving for are LLMs. Python + ChatGPT are powerful without the user knowing too much of the logic off-hand. That's a problem for new CS students who need to learn the fundamentals of logic, reasoning and programming. I don't know what languages work "less-better" with modern LLMs, all I know is that ChatGPT and Claude work exceptionally well with Python.
I suppose, as long as we keep paper exams, all hope is not lost. Maybe just a little, in my opinion.
Agreed, LLMs mean that it's MORE useful and important to learn Racket and C, the LLM will help you much more with knowing the specifics of python/js/go/java or whatever human-focused language you end up working with for your job. If you want to be a stellar developer in 2025 you want to learn the things the LLM ISN'T good at, understanding the fundamentals of computer science is way more useful now than it was 5 years ago because the baseline for being good at a language is so much lower with an LLM aiding you.
None of what you talk about is computer science, it's applied programming.
Computer science is to programming in the same way that astronomy is to navigation.
How can a student "understand" LLMs without the background knowledge of computer science?
Programming courses can teach how to use LLMs, in the same way it can teach how to use Python, Java, language-de-jour.
I watched the video first lecture in the MIT course on which Structure and Interpretation of Computer Programs is based and it explains "computer science is not a science and is only incidentally to do with computers" and goes on to compare the relationship between CS and programming to that between geometry (which means "earth measurement") and surveying.
I'm seeing many undergrads write LLM code that they don't even understand. It's a travesty. Can't remember the exact saying, but it went like: "AI creates short development times and super long debugging"
I fourth-year undergraduate argues against the change like a professor. Honestly, this shows the strength of NEU's current (former) curriculum.
Without knowing the new curriculum, I guarantee you that one of the biggest daily complaints about the old curriculum was the requirements that they write unit tests ("check-expects"). Do you think that's going away? Hahahaha. The laugh will be on students who think they're getting something different because the label on the can changed.
If this strategy infects CS degree curriculums widely, employers looking for more than mere coders will overlook CS majors and instead look to engineers, which is where most computing professionals came from academically before about 1980.
Engineering continues to demand that students learn principles grounded in theory (calculus and statistics and discrete math), rigorous analysis (pattern recognition and learning), and system compositionality (design using reliable components as building blocks). CS curricula largely jettisoned this approach after higher-level languages like FORTRAN and C caught on, and has retained only vestiges of old-school mathematical rigor (basic inductive proofs and algorithmic analysis (albeit dumbed down to O(n) only). In the past 20 years, CS has even given up teaching software engineering (compositionality and reliablility) as a requisite skill area. That speaks volumes about the difference that already exists between CS and engineering.
With the enormous growth in college-preparation for software careers in the past decade, it's little wonder that most students prefer a less rigorous, less formal curriculum, and that colleges will choose to meet demand where it lives. Thereafter, if employers want to hires grads with math or engineering skills, they will turn back to engineering as they did long ago. I expect programs in EE and Computer Engineering will adjust their curricula (or add minors) to fill the intellectual void that 'CS For Poets' will leave.
I find myself agreeing. As a person with an engineering background that's part of an ownership team, I often find myself longing for software developers with an engineering mindset i.e think of how the components will fit, without breaking user experience.
My son went to Northeastern ('19) and now designs programming languages and can program skillfully in ANY language. I'm glad he went to Northeastern before this announced change. I feel my money spent at Northeastern was well worth it, not because it made him employable (it did), but because it gave him critical thinking and research skills. It would be sad if too many future Northeastern grads were limited to programming in Python or whatever the mainstream language of the decade is. "Batteries included" Python is great for the workforce but it may weaken basic development skills of undergrads. I'm glad I grew up in an era (1970-80s) when what mattered was sitting down with a manual or book and picking up a language in a weekend and, working with your friends, mastering it in a few weeks or months. A favorite memory that still astonishes me: in 1983 Andy Sudduth, one of my roommates and soon Olympic rowing medalist, built his own computer (a Heathkit), and with a paper due the next day, I offered to lend him my Kaypro-II so he could use WordStar. He said, "Thanks, but I'm going to put my own operating system on it [which he developed in his OS course], then I'm going to use my own full-screen editor I wrote, and then I'm going to write my paper using that editor." "You're going to do all that by tomorrow?", I asked. "Yes." And HE DID IT.
Hey! Guessing by your handle, your son is Alex, yes? He's done some really cool work. I particularly love his paper "Type Systems as Macros" that he wrote with Stephen Chang and Ben Greenman (my advisor now). Super cool stuff.
I attended Northeastern from 2010-2013. Fundies (the freshman-level functional programming courses) was fundamental (ha) to my growth as a software developer. It taught me how to reason about data and how to design programs (the literal name of the textbook).
I know a lot of students hated it—frankly those were mostly the students that it seemed were only doing computer science programs because they’d heard they could make a lot of money in the field. The “real nerds” all seemed to love it, and now nearly 15 years later those are the engineers in my network who have built the most impressive systems and products.
I guess I’ll have to update my default instructions for recruiters from “automatically interview anyone with a degree from Northeastern” to add “if they graduated before 2025”
I can't find a person who didn't initially make the fun-dies joke, then later come around to it, myself included. Sometimes you don't realize someone helped you until years later.
> I know a lot of students hated it
That's a good thing. I don't know whether your assertion about the breakdown between "real nerds" and the other camp is accurate or not, but I think this point stands on its own regardless--learning is hard. It's uncomfortable. It's unpleasant. If it isn't, you're not being pushed hard enough. So what's the point of asking students how they feel about it? Why make strategic decisions based on those data?
I'm genuinely curious, not trolling or anything. It seems completely baffling to me that educators behave this way, and I'd really love to understand why.
My take: if a given task is not fun, then it is work. People on average do not enjoy work. They do not like doing work, let alone doing it well. Training kids to do work well, without any pleasure, necessitates heavy accountability enforced by management, which brings a slew of its own requirements and complexities.
Schools already handle many cross-competing concerns across stakeholders (PTA, Taxpayers, Town Government, State Government), so I suspect they would want to reduce their enforcement & oversight load. They'll choose a teaching style that makes everyone happy or at least complacent, even if they know "fun is not learning".
My best learning was difficult, whole mind encompassing, and incredibly fun.
If you can get college students idle brains curiously contemplating the how and why of the subject, that's when the tuition is really worth it.
I completely agree. The only things I consider fun are also "hard", "uncomfortable", and "unpleasant". Otherwise it's just boring.
Another way to say it is "rewarding".
Exciting to see this on HN! As a ‘15 NU alum that took the CS program & third time founder, I support the change.
Fundies 1 and 2 were great, but I have always felt that the amount of delayed gratification in NU’s CS program was much too long and incongruent with the university’s focus on experiential learning. I wanted to get my hands dirty and build something and the whole curriculum felt too academic.
Northeastern CS is world class at compilers and programming language research, so I always understood that the undergrad program would tend to be academic as a trickle down effect.
It’s a spectrum with tradeoffs, so I think balance is key. But happy to see the pendulum swing a bit and think it will be good for new grads, especially as more coding work becomes automated.
Mixed feelings here.
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.
15 years after MIT made the same switch from Scheme to Python. Since CS at MIT seems to be fine, so will CS at NEU.
"Everything will be OK" - people will succeed in any system. Nobody will ever compare the outputs of the two systems, so nobody will ever know.
Let me instead suggest that one question we should ask is: What kind of students will be successful in the new system? What kinds of students will not?
One interesting thing aspect of the former curriculum is that (IMO) it provides an entry for students who are not entering with a lot of pre-existing knowledge. One of the criticisms of "old school" computer science teaching is that it privileges students who already have exposure to the material... The former curriculum is not the only way to level the playing field, but it certainly does provide a more level playing field for students who might not even be sure about the major.
I will stop with the suggestion that (IMO) pre-existing experience is definitely not the best indicator of future developer quality, so I value a curriculum that does not select for this.
(Caveats: never saw the new curriculum, it could be just fine, there are lots of other ways to accomplish this goal, but still... I am concerned.)
I don't know how much I buy the "leveling the playing field" argument. In my computer architecture class, we learned Sparc assembly. Very few people had encountered much assembly, and definitely not Sparc. At first, it was level, but people with more programming experience quickly adapted since it wasn't actually that different.
I believe this is a fundamental misjudgement of the CS curriculums at MIT and NEU and, apologies for being blunt, probably the worst take on this thread.
The student populations at MIT and NEU, particularly in CS, are fundamentally different. The majority of undergraduates at CS MIT participate in academic research while the vast majority of CS undergraduates at NEU do not (do not let NEU's exceptionally high computer science research output [1] confuse you - the undergraduate and graduate schools are very separate). MIT educates significantly less students than NEU. MIT's algorithms class (6.046) is significantly more rigorous than NEU's equivalent (CS3000) - just compare the publicly available curriculum and problem sets [2,3]. In general, MIT's CS curriculum caters towards the third of the student body that go on to do PhDs, while NEU's CS curriculum caters towards the vast majority of students that beeline towards industry [4,5]. The institutional goals and educational values between MIT and NEU could not be more different. I know all of this to be true because I've spent a significant amount of time at both institutions.
I don't know if NEU will butcher its CS curriculum. I hope not. I guess we'll just have to see.
P.S. it's worth checking out Pyret [4], essentially a functional teaching programming language. The language is mostly written by NEU staff, so I wager NEU's future CS curriculum plans to phase out Racket in favor of Pyret.
[1] https://csrankings.org/#/fromyear/2014/toyear/2024/index?all... [2] https://courses.csail.mit.edu/6.046/ [3] https://tlarock.github.io/teaching/cs3000/syllabus.html [4] https://facts.mit.edu/alumni/ [5] https://www.northeastern.edu/experiential-learning/co-op/ [6] https://pyret.org
MIT, despite it thinking otherwise, is a slave to industry, funding, and trends.
This adds nothing other than “MIT did it so it’s OK.”
History says otherwise.
Before the current curriculum was implemented, a good portion of students were having difficulty finding jobs and co-ops. After the switch, employers were very eager to hire these students.
The change is not a mere "switch to Python" (which itself is not nothing). It is the replacement of a good curriculum with something mediocre.
Also, I don't know how MIT is doing after the switch.
Is it fine? How would we determine that? What's the metric?
Skimmed it quickly and saw it taught Racket to teach programming design.
I've worked at a coding bootcamp in 2017. And I have to say, I was a bit jealous. Where I was learning through methods at university that were a bit quaint, my students learned JS with the latest frameworks. And sure, you can argue whether the length of 3 months is enough, but they were surely getting a better education. What they learned in 3 months, took me at least 6 months to a year in terms of how useful it is.
The thing is, especially as a beginner, learning any programming language will give you similar difficulties (glossing over some nuances). So why not just learn a practical one?
I think once a student has had a practical programming course under their belt, only after that should more esoteric languages come to showcase certain concepts. I believe that they'd be more motivated to learn them as they're more into the groove of programming.
And this is coming from someone that has programmed 2 years in Pharo.
Are you sure you meant to post in the thread about NEU's intro CS curriculum?
I've moved the comment there now. It was originally posted as a top-level comment to https://news.ycombinator.com/item?id=42676928; hence the 'wtf' replies. Thanks!
@dang Is this another instance of that concurrency bug in the comments?
I hope not! because I thought I'd fixed that bug.
What?
Also expressing concerns about the selection of suitable languages for novice programming is King's College CS Prof Michael Kölling, who explains, "One of the drivers is the perceived usefulness of the language in a real-world context. Students (and their parents) often have opinions which language is 'better' to learn. In forming these opinions, the definition of 'better' can often be vague and driven by limited insight. One strong aspect commonly cited is the perceived usefulness of a language in the 'real world.' If a language is widely used in industry, it is more likely to be seen as a useful language to learn." Kölling's recommendation? "We need a new language for teaching novices at secondary school and introductory university level," Kölling concludes. "This language should be designed explicitly for teaching [...] Maintenance and adaptation of this language should be driven by pedagogical considerations, not by industry needs."
While noble in intent, one suspects Kaplan and Kölling may be on a quixotic quest in a money wins world, outgunned by the demands, resources, and influence of tech giants like Amazon — the top employer of Northeastern MSCS program grads — who pushed back against NSF advice to deemphasize Java in high school CS and dropped $15 million to have tech-backed nonprofit Code.org develop and push a new Java-based, powered-by-AWS CS curriculum into high schools with the support of a consortium of politicians, educators, and tech companies. Echoing Northeastern, an Amazon press release argued the new Java-based curriculum "best prepares students for the next step in their education and careers."
Links at: Should First-Year Programming Students Be Taught With Python and Java? https://developers.slashdot.org/story/25/01/05/1853210/shoul...
> The program design skills that our current curriculum emphasizes are “what distinguishes a garage programmer from a serious software developer,” in the words of the Fundies 1 textbook.
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.
A discussion about this from faculty: https://bsky.app/profile/samth.bsky.social/post/3lf22654bks2...
This is a really frustrating development, and I'm not sure I have the energy to explain why because it should be obvious and because the negative emotions of years of dealing with stuff like this.
My main complaints border around: there's no art in anything anymore in that unless you're doing the lowest common denominator you are doing it wrong, companies show more and more success in influencing others (namely universities) to be their training centers for them, and that universities should be about learning and exploration and not subservience to culture.
I haven't seen many CS curricula start bottom-up with things like digital logic, yet the best programmers I've worked with all started around there and then went upwards --- many of them were self-taught, and although I realise that introduces some selection bias, I have also worked with others who were self-taught but started with some HLL instead, but they didn't have quite the same performance.
That's not "bottom-up". That's a concern for EE/CE or something in that general scope.
As the old Dijkstra quote correctly states, physical computing devices have as much to do with CS as telescopes have with astronomy. They're eating utensils, not the main course. Computer science (the name in English is misleading and horrible) is not about physical computing devices. Devices are merely an instrument. Knowing how to use this instrument well is very useful for people in the field, but it is incidental to the field itself.
Even the distinction between "high-level" and "low-level" languages is meaningless from a CS perspective, as it essentially presumes a target language on a target architecture (with the target "low-level" language) that is treated as normative and "real", but again, that is an implementation concern wrt the instrument. From the CS perspective, compilation is just translation from one language to another.
So I dare say that a CS curriculum that starts with digital logic is not really a CS curriculum, but an electronics engineering curriculum. This is the lesson here.
What kind of argument is this? Do you also think it's fine for an astronomy course to not teach their students how to use telescopes? Or a creative writing class how to perform the physical act of writing?
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."
> Or a creative writing class how to perform the physical act of writing?
A computer science class teaching how transistors work is more like a creative writing class teaching how pencils are made, and focusing on the quirks a particular language is like the creative writing class teaching a specific style of cursive.
There are degrees which blend the EE and CS worlds, commonly referred to as computer engineering. That would be more along the lines of mixing the hardware/boolean logic idea with then software development. But that's definitely a different perspective compared to what computer science historically meant.
> I haven't seen many CS curricula start bottom-up with things like digital logic
That's how we did it in Slovenia (Uni of Ljubljana). You start with discrete math and bool algebra, and you learn how transistors work in physics, then you learn about digital circuits and write some assembly, after that it kinda feels like two parallel branches. One set of professors teaches you the math of it all, the other set teaches you how all that math works in practice.
It's a really good curriculum.
Yes yes you also have programming classes in parallel with the digital logic and the math and the assembly. Gotta make sure folks can get those all important part-time jobs and feel like they're learning something useful. It's common, or at least was back then, for students to have jobs in industry while they are studying CS. I honestly think having a job and getting to apply what you're learning makes it stick more ... even if it leads to abysmal completion rates (average 7.5 years to graduate when I was there).
My university's CS program was taught in Ancient C++. This was fine for the Comp Sci majors, but the intro-level class was required for all science majors. I fielded many pleas for help on homework assignments and saw that many struggled so much with the (let's be honest, incredibly unintuitive) syntax and inscrutable compiler errors, that they couldn't internalize the more fundamental concepts that the course was trying to teach.
Later on, I joined the curriculum committee and argued for it to be taught in Python. The faculty weren't convinced at the time but I see now that eventually they moved the intro course to Python and kept the later courses in C++, which seems like a wise decision. Python is far more approachable and will serve science students well if they ever need to use Pandas etc. (The second-semester C++ course has you implement the STL container types, which is an extremely valuable exercise.)
Pyret, the pedagogical language for the next intro course seems like a massive improvement over Racket. I have faith in the PL team at Northeastern, especially BLerner to not skip problem-solving fundamentals in an introductory course. Having been a TA for Fundies I and seeing what these professors value, I feel confident it’s in capable hands and that it may ultimately be an improvement.
I read the article and got curious about Pyret. It turns out to be a very nice language, especially for teaching! Very clear and easy to read syntax, no weird bracket mania :D, it even forces programmers to write good formatted code (space surrounding operator!) and encourages the use of best practices (test first!).
I also like the fact that it is functional, invariant by default, and they are working on type checking.
Seeing this, I can't wait to hear about the students' experiences with the new curriculum.
i'm a dropout just do horrible coding for fun can anyone explain why CS programs are adamant about not teaching on the job skills? like databases, web, embedded, security plus theory
Most Computer Science programs teach principles.
The ideas behind a database is more important than the the concrete database used. If the ideas are taught, then the students can adapt when the fashion changes.
So instead of teaching something that you can use on your first job, they teach principles you can use your entire career. And times does change.
Remember the good old languages Fortran, Algol 60 etc. That's where the jobs were...
I graduated with a degree in CS. Checking back with my university they'd added a degree in Software Engineering.
CS (traditionally) is more about algorithms, limits, growth. There's a bunch of complexity in even just understanding and calculating what a computer can do.
The Software Engineering degree makes so much sense if you're studying about how libraries can be tied together, upgraded, unit/integration testing, container and source code management, etc.
They are truly different disciplines at this point.
sorry if this sounds dumb I don't have any formal education why is there a distinction?
when i hear computer science i hear the study of computers that in my head means software, hardware, and theory it's like having doctors that study humans theoretically and others that do surgery
Computer science is step one towards getting a phd and doing research and design of actual tools like compilers, understanding how the CPU sees and asks for data stored in memory, efficient algorithms to do XYZ, it's highly relevant for stuff like embedded computing where you're often working with severe hardware constraints and possibly with a real-time os.
Software Engineering is the study of how to efficiently build software, typically on a medium to large team.
Computer Science as a field predates computers. Computer Science is the subsection of maths that answers "what is computable".
Dijkstra line sums it up well "Computer science is no more about computers than astronomy is about telescopes."
Analysis is the key. You write a program to multiply matrices. That is software engineering. You analyze the program to figure out how much slower it becomes as the matrices becomes larger, how many times it must access ddr, how well-utilized the caches are, etc. That is computer science.
Computer science is designing a new video compression algorithm to be more efficient. Software engineering is taking that video compression algorithm and putting into an application users actually use.
I think the analogy
Software Engineers : Doctors :: Computer Scientists : Biologists/Biomedical Scientists
is perhaps reasonable.
That heavily depends on the school. But I’ll add many years later, I appreciate the theoretical classes much more because the knowledge I gained there has aged much better.
In our pretty dynamic fast moving industry, it is more important to learn how to learn technologies, rather than learn the technologies directly. No one wants to be a specialist in 20 year old outdated tech late in their career. Having a strong foundation in how CS tech generally works allows you to move between different tech stacks fairly quickly.
Pretty much every class that focused on "on the job skills" when I went to university (2008-2014) either at my university or from looking at coursework available elsewhere (I might have considered jumping universities for non-educational reasons) was either outdated or useless within few years. If I were to redo it I'd prefer to have even more "esoteric" tech involved and more theory and fundamentals.
And not because they were outdated and useless when the course started, though some did have issues. I think the least outdated "on the job applicable" material is Java fundamentals, and that's because you can still write Java 6 basic stuff in current JDK - a lot of the interesting and powerful stuff we learnt is no longer available in JDK though.
OTOH, fundamental principles - algorithms, including set logic in RDBMSes, low-level programming (which to annoyance of some was done in SPARC assembly or random assembly designed just for given assignment), robotics using programming stack and parts that were never seen outside university, various in-depth studies on different theoretical or scientific areas - all of that is material I use to this day in many different jobs when it allows me to understand and reason in ways I couldn't before I joined university - and I already "knew" how to program then.
BTW, within the 5 years I spent at university, "javascript on the server" turned from niche use cases within some stacks, usually running Mozilla Rhino, into complete new ecosystem that was surviving its first big fork and was becoming used in big projects, Android went from one phone "who knows" to pretty mature platform holding half the world with 64bit CPUs, tablets and first wearables, similar evolution for iOS, in fact arguably over my entire university time we had explosion of "you can now make mobile apps easier" to "mobile app developer is lucrative" all the way to "you're probably not going to make much money as solo developer anymore".
It's stunning to work with fresh out of college cs grads and... having to take 10 minutes to explain how git works, why we use source control, and then every day fielding questions about git, merges, and fixing merge conflicts etc as the get up to speed. I realize there is a learning curve as someone fresh out of school but also there should be some basic job training using free versions of tools like git and sql. The average student is only going to get a shadow of the relevance if they're learning pure theory with no context.
These are tools! You don't go to university to learn how to use git. Besides, tools that come and go. You can pick these up along the way. You can make their use a part of coursework, but this is not what you go to university to study!
That's the point. CS curricula are supposed to teach you deep skills and principles, not how to fiddle around with git.
If your CS degree never requires you to write a program complex enough to warrant version control you should get your money back. I agree that the theory is more important and tools should not be focused on, but exercising the theory you have learnt is extremely rewarding.
Possibly because that isn’t computer science.
I am a graduate of Khoury and find this very disappointing. I wasn’t a huge fan of learning Scheme/Racket but after looking back during my career I’m grateful for the education I got there.
This feels like a step backwards.
Northeastern is a major part of PLT right? What does this mean for the future of sch^H^H^Hracket?
I’m wondering if neighboring competitor schools who offer python classes are the reason for the change since more students would actually consider attending a different school due to having a stronger post experience and skills gained.
I don't think Northeastern is worried about attracting applicants, they were the 8th most applied-to school in the US last year, with nearly 100K applicants. And CS is one of their most popular programs.
I think the more likely cause is pressure from their co-op program's partner employers to make the intro curriculum more 'practical' (i.e. outsourcing training from the employer to school). It's beneficial in the short-term but IMO a loss in the long-term, Northeastern is a university not a bootcamp.
My biggest worry is that maybe the co-op program for CS became a "low interest rate" phenomenon over the years from ~2009-2020 and now they don't want to take gambles on students that likely need to grow into the role. It's not enough, and they treat it like a regular internship program.
The best thing for a student is to abandon dogma. The easiest thing for a teacher is to embrace it.
Meh. Don’t agree.
It’s entirely reasonable to ask why students valuable learning budget is being wasted on Racket.
If you go to university you have a reasonable expectation to learn relevant things.
The disease must have jumped the river from M.I.T.
i think it is coming from industry
It was apparently industry who told Australian Universities that relational algebra was not needed in databases.
My geography of that region is dated, but when I worked in industry there I was north if M.I.T., so it's plausible industry could be patient zero.
This op-ed was written by an undergrad and complains that Northeastern's switch to Python (from Racket) for its introductory classes will prevent students from learning fundamentals of computer science.
But that complaint can be made about any language! "This dynamically typed language won't allow students to understand type safety." "This high-level language won't allow students to learn pointers and systems programming." Etc.
I believe that an intro course should get students coding since the first major hurdle is learning how to construct any kind of program at all. The switch to a more "employable" language isn't going to make education worse.
How about you focus on the argument instead of making ad hominem attacks?
>Racket was chosen because it has “teaching languages” that can gradually introduce features as students are taught the relevant design principles.
So no, that complaint can't be made about any language.
Tell me you haven't read the article (or used racket) without telling me.
> I believe that an intro course should get students coding since the first major hurdle is learning how to construct any kind of program at all. The switch to a more "employable" language isn't going to make education worse.
None of this is the issue at hand. The switch to python is because industry uses it. The article correctly makes the point that racket was intentionally designed to get students coding as easily and quickly as possible. It has multiple steps of teaching languages for exactly that purpose, introducing concepts in ways that let students grapple with them one at a time in an interactive environment.
Meanwhile in python complex topics like duck typing, object oriented methods, exceptions, the distinction between iterables and lists, how to use a command line/terminal or how to configure an IDE, and so on must be covered before people can start writing code for the exercises. Racket is streamlined for beginners.
> Meanwhile in python complex topics like duck typing, object oriented methods, exceptions, the distinction between iterables and lists, how to use a command line/terminal or how to configure an IDE, and so on must be covered before people can start writing code for the exercises.
No, they dont have to be at all. You might as well suggest you need to learn the JVM before writing a line of Java.
Python supports imperative, OO and functional programming paradigms. And to start you can use any text editor, an IDE is not required. In fact you can start working in the REPL right away, in which case you need a terminal and the command “Python”.
All of that except for working in the terminal, could probably be considered higher level
To quote the above person: "tell me you haven't read the article without telling me".
You thought that supporting multiple "programming paradigms" is a nice thing, but it's the opposite for teaching beginning student. Experienced programmers want expressivity/customization/choices to do whatever they want. That's not what newbies need when they get stuck on an assignment.
Does anyone else question whether an undergrad is best able to evaluate the strengths and weaknesses of the curriculum?
In this case, you can find the same criticisms in published articles and books. I expect this student heard them straight from the source (author of the articles or books). That does not lessen their impact or correctness in my opinion.
Also, see SolarNet's comment. https://news.ycombinator.com/item?id=42677918
Yeah.. Undergads leave school and are barely trusted to write CRUD apps.
>we should not teach something just because it's a useful skill, we should teach our favorite dogma that we believe is totally more useful than a system built up through decades of practical experience, guys really.
At least "Racket" is aptly named.