13 ms·

OOP no longer mandatory in CMU Computer Science Curriculum

113 points by geophile 16y ago

toddh 16y ago
Saying OOP is anti-modular is like saying operands are anti-functional.
- loup-vaillant 16y ago
  Class based programming traditionally relies heavily on mutable state. Remove or severely limit mutable state, and most of us will stay it's not OOP any more. And pervasive mutable state is anti-modular. http://www.loup-vaillant.fr/articles/assignment http://www.loup-vaillant.fr/articles/assignment
  - TimJYoung 16y ago
    Nothing in OOP says that object state must be mutable. It's just as simple to have objects that always maintain their instance pointers and internal state separate from one another and use message passing for transforming that state. Such an architecture is completely capable of running on multiple cores without too much context switching or other synchronization overhead issues, especially if the object message queues are lock-free. However, one of the keys to such an architecture is making sure that there are no shared sub-allocators being used by the RTL for memory allocation.
  - toddh 16y ago
    Shared state is anti-concurrency, but objects don't share state, they hide state behind well defined interfaces which is inherently modular. Actors and objects work together beautifully. Objects handle the behaviour and the Actors separate out threads of control. It all goes to hell when stated is shared, but that's a completely different thing.
    - loup-vaillant 16y ago
      > they hide state behind well defined interfaces which is inherently modular They expose mutable state through a well defined interface. Unless you're talking about purely functional interfaces, of course. And purely functional interfaces are rare in typical class-based code, especially C++ or Java code. Most programmers don't understand that when when a class exposes mutable state, it automatically becomes more difficult to use because you can make fewer assumptions about it. That's why it's anti-modular. And that's even before you try concurrency.
      - toddh 16y ago
        Concurrency is dependent on how threads run your code. Accessing an object's mutable state within a defined thread context has no issues at all. Accessing shared state across thread boundaries is the problem with concurrency. My guess is people are coming from a POV where concurrency is automatically handled by the system, in which case you would want certain properties, but when coding in a typical environment where care is taken it's not an issue.
dsl 16y ago
I don'tt hire people with CS degrees unless they can demonstrate some level of technical competency before enrollment (open source commits, weekend projects, etc). Congrats new CMU grads, you get a free pass. OOP might have its place, but teaching it to first year CS students is one of the things I blame for the valley being full of mediocre programmers.
- rimantas 16y ago
  Interesting, why http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool... does not come up more often in these discussions. Seems relevant to me.
  - jchonphoenix 16y ago
    Well, here it is pretty irrelevant. CMU wasn't a java school. It was mainly a C school.
jchonphoenix 16y ago
For those of us at cmu, this is old news. The article is very misleading. The old curriculum never had a focus on OOP. However, the major difference is that the new curriculum will have a very heavy focus on the functional paradigm at the cost of teaching systems skills. For example, students will no longer learn C at CMU yet they will be expected to know it well for os. Either some higher level classes must get a lot easier or a lot more students will start failing. The general consensus among students was that this curriculum change wasn't very well thought out.
- alexgartrell 16y ago
  > For example, students will no longer learn C at CMU yet they will be expected to know it well for os. 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.
  - jwatzman 16y ago
    The problem with C0 (it's "C-naught", not "C-not") is that it is a toy language used for the compilers class which has somehow made it down into the intro curriculum. It is not useful in the real world; absolutely no one outside of CMU uses it. It is useful only as a stepping stone for C -- at which point, why not just teach C, and keep to a "safer" subset for a while? A couple weeks "transition" to get used to malloc and gdb and NULL pointers and segmentation faults etc is not nearly enough.
carterschonwald 16y ago
several remarks worth mentioning, as the infoq page seems to be editorialized link bait begging to foment a flamewar. Bob Harper and (his now graduated phd student) Dan Licata are (world class) experts in programming language semantics. What does this mean? They understand in a very very precise sense how difficult it is to correctly understand the exact semantics of various linguistic constructs. Why is this important? Because some of these freshmen will not have had a solid grounding in understanding the most basic of the tools they use, the programming language. These students should come away from their intro class not burdened by confusion over syntax and boilerplate need to use the built in language constructs, but rather a precise enough mental model of the semantics for a basic programming language that they can accurately simulate the execution of their programs with pen and paper, or just in their heads! Yes objects do provide some occasionally fantastic abstraction facilities in certain use cases in practice, but every semantic model for real OO languages is INCREDIBLY complex, let alone considering what is needed for having a correct cost model for operations in an OO language once you consider how many OO abstraction are represented by nontrivial lookup operations / data-structures. What I think is more interesting is the following 1) they've come up with low overhead ways of teaching parallelism constructs directly to intro students and 2) this course is part of a larger system of classes that include their intro imperative programming class being taught by Frank Pfenning (an expert in mechanized theorem proving such as might be used to verify program correctness)that teaches a lot of the basic algorithms / datastructures that are easiest to first see framed imperatively, and 3)they're having the intro algorithms & datastructures course be taught by Guy E. Blelloch, who's done a great amount of good research in a huge number of algorithm topics.
- zaidf 16y ago
  Agree. Running into OOP as the foundation of AP Comp Sci cirriculum in high school almost made me hate programming ... and that takes some effort because leading to the class I was programming out of joy every minute that I could. 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).
  - dustingetz 16y ago
forkandwait 16y ago
My rule of thumb with OOP (of which I am very proud): if a bunch of code needs to retain state, make it an object, but if not, make it a function. Also, in a class, you should either have glorified getter/setters (to set the state, possibly in complicated ways) or stateless functions (to execute algorithms). This approach makes it far easier to test, since you have less set up and tear down. To teach object oriented programming as if it is theoretically foundational, or should precede simpler concepts is a nice bit of foolishness that lasted from excitement over Smalltalk to, say, last week. I think the blossoming of GUI's -- which have A LOT of state -- is the historic reason for the excitement over OOP, not any theoretical advantage to OOP.
- dustingetz 16y ago
  nice note correlating GUIs with historic excitement over OOP. "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.
  - SwellJoe 16y ago
    I'm all about FP, and find it lovely, but I've never seen a coherent explanation of an FP solution to GUIs. What is the FP answer to MVC? What does a modern GUI application design look like, if not OOP?
    - wynand 16y ago
      I'll hazard a possibly bad answer. MVC is not inherently OO - it's more about sending messages which, although a feature of modern OO (Alan Kay even said that he should have called OO Message-Oriented programming), is not its defining feature (as we see it used today). Since the Model, the View and the Controller are just continually processing and sending messages, you could easily implement them as processes (say as in Erlang). A processes's state is then retained in immutable structures passed to recursive invocations of its main message loop (sorry if this sounds opaque - I'd recommend seeing how it's done in Erlang). Another GUI approach to FP that is being researched is functional reactive programming. There is a neat Javascript implementation called FlapJax. You could probably argue that FRP is a generalization of MVC (though I'll hedge my statement since I'm not 100% sure of this).
yrral 16y ago
I'm a CMU CS minor who has gone through most of CMU's "base" CS courses (211, 212, 213, 251). The majority of these courses were taught with either C or Java, so I'd rate my abilities in C and Java as probably a 7/10. When taking 212, which is an intro to functional language course taught in SML. I had some trouble that I never encountered in other courses. I attributed this trouble with the fact that I learned programming with a Java and C mindset; such that I feel like I can only think efficiently in C or Java (or procedural and object oriented). Thus, when programming in SML, there were many times where I knew what to do in an abstract sense (and could easily code it in a functional-like manner in either C or Java), but had trouble expressing my thoughts in SML. Nevertheless, as I learned more and more SML in class, its elegance and grace drew me in. Although I feel like functional languages are more powerful than OOP or procedural languages, I am hesitant to use them on side projects because I'm not accustomed to thinking and writing code functionally. I feel like I will spend more time figuring out the syntax of the language than actually coding. Furthermore, I have no idea about how design patterns work and have never coded large projects in functional languages, so even if I knew a specific functional programming language well, I would still have trouble using it for a non-toy project. I feel like my mind thinks in OOP, and as much as I want to change that, it has already set; I still stick with OOP and procedural languages because that is what I am confortable writing in even if I know I'd be better off writing things in functional languages. From what I understand from conversations floating around campus, 150 is similar to 212, except it teaches more CS fundamentals that 1st years are less likely to know (212 is typically a 2nd year+ class). 210 will follow 150, which is a data structures course that will be taught in a functional language. By starting students out with a functional language and then continuing to teach them other aspects of CS using functional languages, these students will likely start to think functionally - even when coding in C or Java (as I kind of do the reverse when coding in functional languages). This could be a huge advantage, as I believe functional languages are more powerful and allow you to express more ideas with less thought (or "brain memory"). I think PG's essay "Beating the Averages" explains this better. Thus these students that are taking this new curriculum may be able to code or think in a order of magnitude "better" or faster than the people who learned programming using lower level languages such as Java/C. Nevertheless, I'm envious of the people who get to learn this new curriculum. I apologize if this post seems like a huge braindump. This is my first "serious" post on HN and I had a lot of difficulty expressing my thoughts clearly and organizing them in a logical manner. When I read others' posts here or PG's essays, everybody seems to be able to express themselves extremely clearly and concisely. Any advice on developing functional language or writing skills will be appreciated.
nickik 16y ago
I just watched the video by Barbara Liskov. He references this to show how even a turing award winner does not like FP. The only thing that I would directly releate to FP was that she: "I think programms are fundamentally about manipulating state". Therefore she did not like the FP back in the 70s. So I will try to show that thats a very bad reference. 1. Today FP languages are mostly about only using state if there really is state not like in OO where you just use state everywhere. 2. Try to be more clear where the sideeffects happen --> dont interleave the sideeffects with the computation. In Haskell you even have to be explicit where you use sideeffects. in imperative (in VB) for i = 1 to 100 print computeSomething(i) next while in FP you would (print (map computeSomething (range 1 101)) (I know that thats not 100% the same output but I hope you get the point) 3. She was doing Systems Programming for the last 30 years an yes at that level there is lots of state but at a high level there does not need to be that much state INSIDE the programm. More generally speaking: All the typical OO features FP languages can provied. For example Hierarchy are totally interleaved with the rest of the programm. In Clojure you can use Hierarchy if you really need a kind of animal -> dog Hierarchy-System. Even better because its not interleaved you can have two Hierarchy-System on the same "object" without them disturbing each other. The same with Polymorphism. http://clojure.org/multimethods http://clojure.org/multimethods I don't want to say OO is very bad I like just like the decision CMU takes here. Teach these concepts sepertly and not in a language like Java.
- Peaker 16y ago
  I think saying that FP is bad for "manipulating state" is misleading. 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 That looks horrible, compared to something like: gs.player.position = f(gs.player.position); But then, if you discover the Semantic Editor Combinators abstraction (http://conal.net/blog/posts/semantic-editor-combinators/ http://conal.net/blog/posts/semantic-editor-combinators/), then you can write that as: movePlayer :: (Pos -> Pos) -> GameState -> GameState movePlayer f = (atPlayer . atPosition) f or just: movePlayer = atPlayer . atPosition Then you can use: movePlayer (+delta) to add delta to the position. 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!
jwatzman 16y ago
Note that this has been coming for a while -- the "announcement" cited is from Harper's blog, as is the bit about "anti-modular and anti-parallel". The quote cited is Harper's opinion, and was not necessarily the opinion of everyone involved in the curriculum changes (though Harper himself was very instrumental in said changes). Harper is well known among his former students for being a brilliant guy who makes many interesting arguments... and who then takes those arguments so far to the extreme that it's laughably silly.
- Peaker 16y ago
  > and who then takes those arguments so far to the extreme that it's laughably silly. 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?
  - jwatzman 16y ago
    He once discussed NULL pointers. He made a well-reasoned argument about how a proper language should use some other method to properly distinguish between NULL and "I really do have a pointer here", such as ML's option types or Haskell's Maybe types or something. Basically the "million dollar mistake" argument. He then went on to say something basically like, "Thus, there is no such thing as a NULL pointer. It is a myth. It simply doesn't exist." Which is patently false, and I find rather funny. Languages do have NULL pointers whether they should or not. I can assign a value of NULL to my pointer in C -- they exist. They are not a myth. A friend of mine, who is a TA for our operating systems class, whispered to me, "Hm, NULL pointers don't exist?! I guess I'll go tell my students that."
    - Peaker 16y ago
      Can you link to the context of that statement? I think maybe he was trying to say something else, but said it in a misleading/funny way?
      - jwatzman 16y ago

113 points by geophile 16y ago

toddh 16y ago

Saying OOP is anti-modular is like saying operands are anti-functional.

loup-vaillant 16y ago
Class based programming traditionally relies heavily on mutable state. Remove or severely limit mutable state, and most of us will stay it's not OOP any more. And pervasive mutable state is anti-modular. http://www.loup-vaillant.fr/articles/assignment http://www.loup-vaillant.fr/articles/assignment
- TimJYoung 16y ago
  Nothing in OOP says that object state must be mutable. It's just as simple to have objects that always maintain their instance pointers and internal state separate from one another and use message passing for transforming that state. Such an architecture is completely capable of running on multiple cores without too much context switching or other synchronization overhead issues, especially if the object message queues are lock-free. However, one of the keys to such an architecture is making sure that there are no shared sub-allocators being used by the RTL for memory allocation.
- toddh 16y ago
  Shared state is anti-concurrency, but objects don't share state, they hide state behind well defined interfaces which is inherently modular. Actors and objects work together beautifully. Objects handle the behaviour and the Actors separate out threads of control. It all goes to hell when stated is shared, but that's a completely different thing.
  - loup-vaillant 16y ago
    > they hide state behind well defined interfaces which is inherently modular They expose mutable state through a well defined interface. Unless you're talking about purely functional interfaces, of course. And purely functional interfaces are rare in typical class-based code, especially C++ or Java code. Most programmers don't understand that when when a class exposes mutable state, it automatically becomes more difficult to use because you can make fewer assumptions about it. That's why it's anti-modular. And that's even before you try concurrency.
    - toddh 16y ago
      Concurrency is dependent on how threads run your code. Accessing an object's mutable state within a defined thread context has no issues at all. Accessing shared state across thread boundaries is the problem with concurrency. My guess is people are coming from a POV where concurrency is automatically handled by the system, in which case you would want certain properties, but when coding in a typical environment where care is taken it's not an issue.

dsl 16y ago

I don'tt hire people with CS degrees unless they can demonstrate some level of technical competency before enrollment (open source commits, weekend projects, etc). Congrats new CMU grads, you get a free pass. OOP might have its place, but teaching it to first year CS students is one of the things I blame for the valley being full of mediocre programmers.

rimantas 16y ago
Interesting, why http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool... does not come up more often in these discussions. Seems relevant to me.
- jchonphoenix 16y ago
  Well, here it is pretty irrelevant. CMU wasn't a java school. It was mainly a C school.

jchonphoenix 16y ago

For those of us at cmu, this is old news. The article is very misleading. The old curriculum never had a focus on OOP. However, the major difference is that the new curriculum will have a very heavy focus on the functional paradigm at the cost of teaching systems skills. For example, students will no longer learn C at CMU yet they will be expected to know it well for os. Either some higher level classes must get a lot easier or a lot more students will start failing. The general consensus among students was that this curriculum change wasn't very well thought out.

alexgartrell 16y ago
> For example, students will no longer learn C at CMU yet they will be expected to know it well for os. 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.
- jwatzman 16y ago
  The problem with C0 (it's "C-naught", not "C-not") is that it is a toy language used for the compilers class which has somehow made it down into the intro curriculum. It is not useful in the real world; absolutely no one outside of CMU uses it. It is useful only as a stepping stone for C -- at which point, why not just teach C, and keep to a "safer" subset for a while? A couple weeks "transition" to get used to malloc and gdb and NULL pointers and segmentation faults etc is not nearly enough.

carterschonwald 16y ago

several remarks worth mentioning, as the infoq page seems to be editorialized link bait begging to foment a flamewar. Bob Harper and (his now graduated phd student) Dan Licata are (world class) experts in programming language semantics. What does this mean? They understand in a very very precise sense how difficult it is to correctly understand the exact semantics of various linguistic constructs. Why is this important? Because some of these freshmen will not have had a solid grounding in understanding the most basic of the tools they use, the programming language. These students should come away from their intro class not burdened by confusion over syntax and boilerplate need to use the built in language constructs, but rather a precise enough mental model of the semantics for a basic programming language that they can accurately simulate the execution of their programs with pen and paper, or just in their heads! Yes objects do provide some occasionally fantastic abstraction facilities in certain use cases in practice, but every semantic model for real OO languages is INCREDIBLY complex, let alone considering what is needed for having a correct cost model for operations in an OO language once you consider how many OO abstraction are represented by nontrivial lookup operations / data-structures. What I think is more interesting is the following 1) they've come up with low overhead ways of teaching parallelism constructs directly to intro students and 2) this course is part of a larger system of classes that include their intro imperative programming class being taught by Frank Pfenning (an expert in mechanized theorem proving such as might be used to verify program correctness)that teaches a lot of the basic algorithms / datastructures that are easiest to first see framed imperatively, and 3)they're having the intro algorithms & datastructures course be taught by Guy E. Blelloch, who's done a great amount of good research in a huge number of algorithm topics.

zaidf 16y ago
Agree. Running into OOP as the foundation of AP Comp Sci cirriculum in high school almost made me hate programming ... and that takes some effort because leading to the class I was programming out of joy every minute that I could. 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).
- dustingetz 16y ago

forkandwait 16y ago

My rule of thumb with OOP (of which I am very proud): if a bunch of code needs to retain state, make it an object, but if not, make it a function. Also, in a class, you should either have glorified getter/setters (to set the state, possibly in complicated ways) or stateless functions (to execute algorithms). This approach makes it far easier to test, since you have less set up and tear down. To teach object oriented programming as if it is theoretically foundational, or should precede simpler concepts is a nice bit of foolishness that lasted from excitement over Smalltalk to, say, last week. I think the blossoming of GUI's -- which have A LOT of state -- is the historic reason for the excitement over OOP, not any theoretical advantage to OOP.

dustingetz 16y ago
nice note correlating GUIs with historic excitement over OOP. "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.
- SwellJoe 16y ago
  I'm all about FP, and find it lovely, but I've never seen a coherent explanation of an FP solution to GUIs. What is the FP answer to MVC? What does a modern GUI application design look like, if not OOP?
  - wynand 16y ago
    I'll hazard a possibly bad answer. MVC is not inherently OO - it's more about sending messages which, although a feature of modern OO (Alan Kay even said that he should have called OO Message-Oriented programming), is not its defining feature (as we see it used today). Since the Model, the View and the Controller are just continually processing and sending messages, you could easily implement them as processes (say as in Erlang). A processes's state is then retained in immutable structures passed to recursive invocations of its main message loop (sorry if this sounds opaque - I'd recommend seeing how it's done in Erlang). Another GUI approach to FP that is being researched is functional reactive programming. There is a neat Javascript implementation called FlapJax. You could probably argue that FRP is a generalization of MVC (though I'll hedge my statement since I'm not 100% sure of this).

yrral 16y ago

I'm a CMU CS minor who has gone through most of CMU's "base" CS courses (211, 212, 213, 251). The majority of these courses were taught with either C or Java, so I'd rate my abilities in C and Java as probably a 7/10. When taking 212, which is an intro to functional language course taught in SML. I had some trouble that I never encountered in other courses. I attributed this trouble with the fact that I learned programming with a Java and C mindset; such that I feel like I can only think efficiently in C or Java (or procedural and object oriented). Thus, when programming in SML, there were many times where I knew what to do in an abstract sense (and could easily code it in a functional-like manner in either C or Java), but had trouble expressing my thoughts in SML. Nevertheless, as I learned more and more SML in class, its elegance and grace drew me in. Although I feel like functional languages are more powerful than OOP or procedural languages, I am hesitant to use them on side projects because I'm not accustomed to thinking and writing code functionally. I feel like I will spend more time figuring out the syntax of the language than actually coding. Furthermore, I have no idea about how design patterns work and have never coded large projects in functional languages, so even if I knew a specific functional programming language well, I would still have trouble using it for a non-toy project. I feel like my mind thinks in OOP, and as much as I want to change that, it has already set; I still stick with OOP and procedural languages because that is what I am confortable writing in even if I know I'd be better off writing things in functional languages. From what I understand from conversations floating around campus, 150 is similar to 212, except it teaches more CS fundamentals that 1st years are less likely to know (212 is typically a 2nd year+ class). 210 will follow 150, which is a data structures course that will be taught in a functional language. By starting students out with a functional language and then continuing to teach them other aspects of CS using functional languages, these students will likely start to think functionally - even when coding in C or Java (as I kind of do the reverse when coding in functional languages). This could be a huge advantage, as I believe functional languages are more powerful and allow you to express more ideas with less thought (or "brain memory"). I think PG's essay "Beating the Averages" explains this better. Thus these students that are taking this new curriculum may be able to code or think in a order of magnitude "better" or faster than the people who learned programming using lower level languages such as Java/C. Nevertheless, I'm envious of the people who get to learn this new curriculum. I apologize if this post seems like a huge braindump. This is my first "serious" post on HN and I had a lot of difficulty expressing my thoughts clearly and organizing them in a logical manner. When I read others' posts here or PG's essays, everybody seems to be able to express themselves extremely clearly and concisely. Any advice on developing functional language or writing skills will be appreciated.

nickik 16y ago

I just watched the video by Barbara Liskov. He references this to show how even a turing award winner does not like FP. The only thing that I would directly releate to FP was that she: "I think programms are fundamentally about manipulating state". Therefore she did not like the FP back in the 70s. So I will try to show that thats a very bad reference. 1. Today FP languages are mostly about only using state if there really is state not like in OO where you just use state everywhere. 2. Try to be more clear where the sideeffects happen --> dont interleave the sideeffects with the computation. In Haskell you even have to be explicit where you use sideeffects. in imperative (in VB) for i = 1 to 100 print computeSomething(i) next while in FP you would (print (map computeSomething (range 1 101)) (I know that thats not 100% the same output but I hope you get the point) 3. She was doing Systems Programming for the last 30 years an yes at that level there is lots of state but at a high level there does not need to be that much state INSIDE the programm. More generally speaking: All the typical OO features FP languages can provied. For example Hierarchy are totally interleaved with the rest of the programm. In Clojure you can use Hierarchy if you really need a kind of animal -> dog Hierarchy-System. Even better because its not interleaved you can have two Hierarchy-System on the same "object" without them disturbing each other. The same with Polymorphism. http://clojure.org/multimethods http://clojure.org/multimethods I don't want to say OO is very bad I like just like the decision CMU takes here. Teach these concepts sepertly and not in a language like Java.

Peaker 16y ago
I think saying that FP is bad for "manipulating state" is misleading. 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 That looks horrible, compared to something like: gs.player.position = f(gs.player.position); But then, if you discover the Semantic Editor Combinators abstraction (http://conal.net/blog/posts/semantic-editor-combinators/ http://conal.net/blog/posts/semantic-editor-combinators/), then you can write that as: movePlayer :: (Pos -> Pos) -> GameState -> GameState movePlayer f = (atPlayer . atPosition) f or just: movePlayer = atPlayer . atPosition Then you can use: movePlayer (+delta) to add delta to the position. 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!

jwatzman 16y ago

Note that this has been coming for a while -- the "announcement" cited is from Harper's blog, as is the bit about "anti-modular and anti-parallel". The quote cited is Harper's opinion, and was not necessarily the opinion of everyone involved in the curriculum changes (though Harper himself was very instrumental in said changes). Harper is well known among his former students for being a brilliant guy who makes many interesting arguments... and who then takes those arguments so far to the extreme that it's laughably silly.

Peaker 16y ago
> and who then takes those arguments so far to the extreme that it's laughably silly. 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?
- jwatzman 16y ago
  He once discussed NULL pointers. He made a well-reasoned argument about how a proper language should use some other method to properly distinguish between NULL and "I really do have a pointer here", such as ML's option types or Haskell's Maybe types or something. Basically the "million dollar mistake" argument. He then went on to say something basically like, "Thus, there is no such thing as a NULL pointer. It is a myth. It simply doesn't exist." Which is patently false, and I find rather funny. Languages do have NULL pointers whether they should or not. I can assign a value of NULL to my pointer in C -- they exist. They are not a myth. A friend of mine, who is a TA for our operating systems class, whispered to me, "Hm, NULL pointers don't exist?! I guess I'll go tell my students that."
  - Peaker 16y ago
    Can you link to the context of that statement? I think maybe he was trying to say something else, but said it in a misleading/funny way?
    - jwatzman 16y ago