OOP no longer mandatory in CMU Computer Science Curriculum

"if a bunch of code needs to retain state, make it an object"

well, a FP wizard might argue that most problems don't need stateful code to solve -- our decision to use stateful patterns is an implementation detail.

I don't think GUI's have to have a lot of state.

I wrote a Haskell library (https://github.com/Peaker/vtywidgets) which can serve as a proof-of-concept of a "stateless GUI".

The idea is that a widget is a pure function like (in pseudo-Haskell syntax):

    input_from_program -> 
      (output_to_user, 
       Map input_from_user
           (documentation, output_to_program))

Any state (e.g: cursor) will be saved elsewhere, and I've come to the conclusion that separating "GUI state" from "model state" is not a good idea. This allows me to use the "cursor" of a box of widgets as an active selection, and not just a way to navigate, for example. It also means that I can use the same persistency model/etc for the GUI as I do for the model.

I wrote a simple (again, still at the POC stage) transactional, structural, revision-controlled editor based on vtywidgets (https://github.com/Peaker/treeedit), and it persists the model, including the GUI state, in the transactional database. This means that I get undo features for GUI state (I can store it outside the revisioned store, but it's quite nice to have), and if I kill the editor and restart it later, it is at exactly the same state it was before.

If it was that bad for me, I can only imagine what it was like for the rest of the class(granted, there were only 5 of us in total).

This just isn't true. C-not (a typesafe C variant put together by the language department) will be taught in an intro class, and the end of that class will involve a transition to C. Then, the students will take 213 Introduction to Computer Systems, which will be ALL C and Assembly (as it has been since its inception). Then, after writing malloc and a web proxy in C, they will go on to OS.

Additionally, Java will continue to be taught in 214, a class that will be mandatory for all Software Engineering minors (granted, a small number of these exist) but that will invariably be taken by many students concerned about internships and that kind of stuff.

The reality of the matter is that Language Theory is the biggest player in CMU CS right now, and so they took that as a mandate and ran with it all the way to this new curriculum, which is why it's functional-language heavy. That said, our students' brains will not rot for having learned ML more heavily than Java (I imagine it will be advantageous), and all previous options will still be available, albeit in slightly different forms (I actually imagine 214 will be much improved over previous attempts at teaching Java).

The reality is that CMU never gave a shit about students who barely make it by, and scraping off a few extra in the Systems class transition isn't really a big concern for anyone (it's a CMU cultural thing). Most of the complaints is just fear of change and "It wasn't like this when I took it!" type complaining.

That sounds like another opinion. I don't find what he said to be laughably silly. Do you have examples of such things he said?

FP is great at manipulating state. A pure Haskell function (State -> State) manipulates state.

What's being discussed is whether or not the state is manipulated destructively. And personally I don't see any real benefits to the destructive method, except performance issues in some cases, and arguably stylistic ones.

Returning new values instead of in-place updates may seem cumbersome before you get to know the abstractions that make it easy to use.

As an example, in Haskell, if you want to update a value deep inside multiple nested records, you do something like:

    movePlayer :: (Pos -> Pos) -> GameState -> GameState
    movePlayer f gs = gs { player = oldPlayer { position = f oldPos } }
      where
        oldPlayer = player gs
        oldPos = position oldPlayer

    gs.player.position = f(gs.player.position);

    movePlayer :: (Pos -> Pos) -> GameState -> GameState
    movePlayer f = (atPlayer . atPosition) f

    movePlayer = atPlayer . atPosition

    movePlayer (+delta)

Now one nice thing about the return-new-value approach is that it is more composable than the destructive update approach. When you compose state manipulation functions, you get transactional state changes.

So paradoxically, I believe functional languages to be better at manipulating state!

And pervasive mutable state is anti-modular. http://www.loup-vaillant.fr/articles/assignment

2. If you eel like functional languages are more powerful than OOP or procedural languages and you're much less comfortable in them than in C or Java, you should do a major project in one, or switch your scripting language. After all, you're still in college, you have fucking up time and capability. Haskell for the Summer of Code, or Jane Street Ocaml?

3. Never, ever pre-emptively apologise. It is a signal of weakness and lack of confidence and will cause people to give you abuse and disrespect you who would not have done so if you hadn't done it.

About the deeper problem of "thinking in OOP", I wrote a small tutorial[1] about the first step: avoiding mutable state where you can help it. The second step is to remove loops (even the recursive loops as well). Instead, use `map` and `filter` (the bulk of list comprehension) where you can. The final step is to generalize this approach by writing your own "higher order" functions to capture common patterns.

[1]: http://www.loup-vaillant.fr/tutorials/avoid-assignment

To change means painful, unproductive days. I went home sweating every day(!)

So some of the emotion regarding choise of paradigm is of course personal - we all want to stay where we are comfortable. Then we rationalize why that is best.

I believe the CMU profs have taken a different tack - how to teach folks relatively new (< 20 years?) to computers. They may choose any paradigm that works, and they seem to be perfectly trained to make that decision well.

As for job opportunities for their graduates, CMU has traditionally had zero problem there. So we shouldn't cry any alligator tears for them. They will learn 'practical' OOP etc as needed at their first job.

To go off on a tangent here, this is something that's been bothering me for a while. These one-to-ten scales are seductive, but they do a very poor job of representing people's actual skills.

The problem, for me, is the 10. Where is 10? If you're at 7/10, you're 70% of the way to whatever 10 is. But how do you know what 10 is? If you're a novice C programmer, you really have no idea. You know about some things you can't do, but you don't really know what you don't know.

Skill differences are really hard to measure. If you compare me with, I don't know, Rob Pike, Fabrice Bellard, Ian Lance Taylor, Landon Curt Noll, P.J. Plauger, Peter Deutsch, or Dan J. Bernstein, or somebody like that — well, if we're working on a project that I can reasonably do myself, they might get it done in ⅔ of the time it would take me. Or maybe ½. So maybe I'm a 7/10? Or 5/10?

But suppose the project at hand was something of the difficulty of otcc or gold or mawk? Those are probably things I could write, given enough time. But those guys could probably do it ten times as fast as I could. Does that mean I'm at 1/10? (Also, their version would work better than mine.)

The trouble with rating my skills at 1/10 is that it suggests that my C skills are close to the minimum. But I'm probably as much better than your average C-speaking CS undergrad as Peter Deutsch is better than me.

We really want some kind of exponential scale, like the Richter scale for earthquakes (or its modern replacement, the moment magnitude scale), or dBa for sound pressure levels. There's no actual ceiling on dBa or earthquake magnitude, but in practice, the numbers stay within a usable range, because of physical limits.

So maybe on this exponential scale, the CS undergrad guy is a 10, and I'm a 12, and Peter Deutsch is a 14. Or maybe a 16. And this comes to the other problem: how do you judge people above you? You can't, really. If they complain about your variable name choice when you send them a patch, and you can't tell that their suggestion is a real improvement, well, is that because something is really obvious to them that I'm missing? Or is it just an idiosyncrasy? I can't tell until I'm at their level.

To some extent, though, I can judge objective achievements. GhostScript has held its own against a much better-funded competitor, managed by adept programmers, for decades. Yahoo Groups still runs on qmail, as do thousands of other mail sites, and still nobody's found a practically exploitable bug in qmail. ffmpeg and tcc are impressive achievements. And so on.

But how can I quantify whether the skill required to create GhostScript or to create ffmpeg was greater? Both are probably beyond my own ability. So I can't even tell whether Deutsch beats Bellard or vice versa. There's no batting average to put on our Genius Hacker Trading Cards. So I can't tell whether Deutsch is at 14, or 16, or 18 — whether he's a hundred, or ten thousand, or a million times better than I am.

But if he's at 10/10, I'm sure as fuck not 70% of the way there.