Yes, unfortunately homework and labs aren't something we can release, due to concerns over academic integrity (I'm the instructor).
I wrote the slides with the intention of them working as standalone notes, though, and as a kind of "textbook" for the course. So I think if you can follow along with the slides, you will get a fair amount of learning out of them, almost as much as attending the lectures.
Since, you are the instructor for 15-150 this semester and have graduated from CMU as per the slides. I would like to know what you think about similar intro course sequences elsewhere.
Like BrownU's CS019 course using Pyret. It also teaches a functional approach to programming.
Also Berkeley's CS61A,B,C trilogy.
Do intro level courses matter in the long run? Or is it the higher level courses that set apart universities in undergrad CS education?
I'll preface that, since I haven't actually taken any of these courses, I lack the full nuance to be able to make as faithful of a judgement as someone who actually attended these universities.
That being said, I've certainly heard of Berkeley's CS61A, and in particular, Brown's usage of the Pyret language. From what I've gleaned from Brown's curriculum, it looks extremely solid for a one-semester course! Everything from K-means to BST invariants to graphs to DP. One question I would be interested in is how "naturally" the progression arises, as the class goes from topic to topic, as I don't necessarily immediately see the thesis of the course, but that may just be a preference in how I teach. I feel like 15-150 has a very clear and obvious story to how it progresses.
Berkeley's 61A, B, C progression looks solid in terms of how it slowly unravels the state of the world to students. In terms of specifically 61A, I might hesitate a little bit at teaching higher-order functions to first-time programmers in the second week, but again, I don't really have the full context to know how successfully that usually goes. In terms of topics, it looks more object-oriented than either 150 or Brown (in that 150 is not whatsoever, and Brown does not seem to be). Personally, I fear that OOP can lead you to too much focusing on specific machinery (inheritance, `self`, method resolution) as opposed to general programming concepts, like algebraic data, recursion, or compositional thinking. It has its place, but I prefer fundamentals to specific tools.
With respect to your question about intro level courses, personally I believe they're of utmost importance. CMU SCS's success as an educational institution is in absolutely no small part due to the fact that the school's intro courses are _chiefly_ run by undergraduate TAs, and so the undergraduate course sequence is one of the strongest you can find anywhere in the world. In just the first six courses, which earns a CS minor at CMU, a student becomes most formidable. By contrast, 70% of what I learned in upper-level courses at CMU, I do not use at my day job (except for compilers).
Btw, Brandon, I hope you archive your version of the course materials somewhere as they are really as good as the notes, someplaces, even better. All previous versions of 15-150 are basically non-existent.
I'd love to post the lectures recordings online -- that remains to be seen, though, whether that's something the university might permit. Thank you for the kind words, though.
Ah! Thanks for the detailed reply. It is so good to hear from someone who have passionately benefitted from their undergraduate courses and gets to use knowledge from that in real life.
Btw with 15-150 notes and slides do you have any book suggestion in mind that self learners can read alongside?
Book suggestions are always so difficult to recommend. I've been asked this question many times, but honestly, it's hard for me, because I'm really not much of a (text)book learner. I know Structure and Interpretation of Computer Programs is supposed to be excellent, but honestly books like that just put me to sleep. It's part of the reason why I've put so much effort into my slides.
I'll say that if you want to learn functional programming in particular (in OCaml), the recently released second edition of "Real World OCaml" is an excellent reference. That one might lean more into specific OCaml language constructs than general programming know-how, though.
Otherwise, along with my notes and slides, I think the most important thing to do is just to pick a task and do it. It doesn't need to be something standalone, but I think everyone learning to program should program an expression evaluator, a priority queue, binary search, BFS, tree traversal, what-have-you. I know that the OCaml website also has a list of exercises: https://ocaml.org/problems
Robert Harper also has a book, "Programming in Standard ML", though that one doesn't have exercises, so my slides are meant to cover the same kind of material. It's here anyways, though: http://www.cs.cmu.edu/~rwh/isml/book.pdf
I hope this helps!
P.S. That Brown schedule looks absolutely intimidating. I'm not sure I could have handled Racket as a first-time programmer. I think it's so important to have a solid conceptual model of what the program is doing before you go into more advanced stuff -- our class only learned higher-order functions today, after 5 weeks of SML!
You won't learn anything if you don't practice it.
But "learning" computer related stuff without the theory behind is also kind of moot. You wouldn't get the full picture this way, and you would end up with a lot of "knowledge" that isn't more than assumptions. Likely wrong assumptions…
That’s implied by the rabbit holes. For me, following the rabbit holes meant digging deeper and deeper into the underlying theory, but at a pace mediated by my current level of understanding.
I know quite some people who do programming for living but are more or less avert to any theory behind it. You get even called names if you come along with such topics… (I think it doesn't need to be said that it's quite difficult to deal with those people at times as they're kind of ignorant.)
I learned OCaml, which made programming "click" for me, partly by doing these exercises. Compared to the root comment's "building interesting things", it's definitely more abstract than concrete.
I do see your point though. In the algebra class, I couldn't grok groups from the axioms, without first seeing some concrete examples. But the thing is, math people's "concrete" is already several layers of abstractions removed from reality.
I'm not really math inclined (for me math is a tool I can use for physics/engineering and other areas; I don't like pure math) but I find it very hard to start doing something without some reading books / docs / articles first. I need at least vague understanding of what I do otherwise it feels like a ritual which doesn't help me to learn. I can go in parallel. I'm actually self-taught and my acquired over many years knowledge is fragmented but for each specific fragment I first read then do.
Maybe it’s just me… but I never have been able to immediately fluidly intuitively grasp any understanding when someone has made “in a vacuum” statements. I just think of vacuuming carpet.
From a practical perspective, one should probably learn procedural/OOP first, it's the de-facto industry standard, and thus better for one's early career. Whether functional is "better" in the longer term, I won't get into here, only to say I have skepticism.
Imho it's exactly the other way around: Imperative programming is an implementation detail and nothing you should care at first.
If you want to learn proper abstractions you should start with something FP-ish.
This also avoids to get your head messed up with the imperative kind of "reasoning".
Besides this: FP is much simpler to learn, so much better suited for newcomers. One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math. On the other hand imperative thinking makes absolutely no sense when looked at it intuitively. It looks more like complete nonsense: `x = x + 1` isn't true for any `x`… So imperative programming is at it's core contrary to logical reasoning. I would try to avoid it as long as possible.
> FP is much simpler to learn, so much better suited for newcomers.
I can't see how this is the case. Assignment is just one tiny piece of learning how to program, and is almost never a pain point after a small amount of instruction.
Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them. FP requires much much more abstract thinking that is often difficult for newcomers to grasp.
The main exception that I see is when someone who has a very deep mathematics education. Graduate level math folks seem to more easily grasp FP concepts from my experience. Almost everyone else seems to grasp imperative programming easier.
My sense (guess) is that you, like most people, learned programming from the outset using the procedural/imperative style. After this way of thinking and approaching problems became firmly ingrained, you then experienced FP as more abstract or difficult to wrap your brain around. But I don't think this reflects on anything innate to FP. FP is, at its core, far FAR simpler than procedural/imperative/whatever-you-want-to-call-it programming. It requires high school math, if that. Equational reasoning, substitution, etc. The basic concepts get you extremely far and are, in their essence, incredibly simple and straightforward and far less foreign to a newcomer than any of the complicated stuff most people are introduced to programming with. That's one guess. The other is that you don't have a great sense of what FP actually is and most of how you think about it comes from HN conversations or blog posts about parser combinators and monads, etc. To that I would say two things: 1) those concepts AREN'T actually that complicated, they are built upon some very basic concepts, but a firm grasp of them is required. They are taking a few basic concepts and exploiting their usefulness to the nth degree and 2) some of the stuff you see or read that is, I'll admit partially, or can be quite complicated does not represent what FP is at its core and is instead a few nerds who really really enjoy pushing the limits of FP and its style of reasoning. I don't mean this derogatorily, it's great that people are doing that. But a deep knowledge of those more advanced concepts isn't essential to FP which, I argue, is incredibly simple and, indeed, far simpler than the other dominant style of programming. None of this is to say that I think a newcomer who is job-minded should start with FP. Perhaps they shouldn't. I'm only addressing what I think might be a misperception of what FP is or how complicated or abstract it is.
>My sense (guess) is that you, like most people, learned programming from the outset using the procedural/imperative style.
>FP is, at its core, far FAR simpler than procedural/imperative/whatever-you-want-to-call-it programming. It requires high school math, if that.
These two factors do not go together in my opinion. Most people who learn imperative programming have studied mathenatics for a dozen years beforehand, but somehow learning imperative programming for a year "ruins" their ability to understand FP permanently? This sounds like an excuse to explain why people have poor performance when they learn FP.
From my experience people do have poor preformance with FP. Back in uni we had a class for FP. If there's anything the majority of students took away from that class, it's that they're never going to touch Haskell again. Because the average performance was that poor.
> but somehow learning imperative programming for a year "ruins" their ability to understand FP permanently?
No, it ruins their willingness to learn FP. Novices know they're learning a new subject and set their expectations appropriately. Experienced imperative programmers think they're learning another minor variation on C and get frustrated when it turns out many of their existing mental models don't transfer.
You didn't, of course, but playing devil's advocate and abusing terminology in the usual way, you have to understand a monad a little bit to know what to make of the type signature.
In practice I expect the comment you replied to is hyperbole and/or confused.
The fact that you cannot interact with the real world without wrapping side effects is sufficient justification that OOP is easier to teach, IMO.
I'm a strong proponent of FP and agree (though I recognize I may be biased) that it's easy to learn with the right teacher, but that's a big caveat that isn't universalizable IMO
> The fact that you cannot interact with the real world without wrapping side effects
That has nothing to do with FP.
That's mostly a Haskell (and the-like) thing.
"Hello world" looks in for example in OCaml like this: `print_string "Hello world!\n"`. You can interact with the outside world just fine without any "side-effect wrapping".
You don't need to know more than high school math to learn Functional Programming. This myth really needs to stop.
All functional programing languages, have ergonomics in their syntax and semantics. around referential transparency and immutable data structures, there's nothing in there about Monads or Functors or Hindley–Milner type systems.
Languages like Haskell do benefit from having that kind of experience, however, langs like,
OCaml, Erlang, Elixir, Gleam, Racket, Clojure, Standard ML.... and the list goes on, doesn't require that kind of education.
(Antidotally, I find FP langs much easier to reason about and I have a background in the humanities. I just don't buy the advanced math argument.)
I don't know why you think I said high level mathematics knowledge is required to learn FP. I simply said that in my experience, those who found FP easier to learn than imperative programming tend to be those who have a background in high level mathematics. Not everyone follows this pattern, of course.
Remember, we're simply comparing FP to imperative programming. I'm simply not convinced that FP is easier to learn than imperative programming for the vast majority of newcomers, and that's what I'm arguing here.
Keeping track of all that state in one’s head is hard.
I think because of the limitations of FP it’s much easier for new programmers to reason about programs and honestly, learn to program.
New developers don’t have to micromanage the computer, the way that the would with an imperative lang.
For example, SQL isn’t FP, but think about the number of business analysts whose lives would be more difficult if the had to write imperative programs to fetch data from some sort of data store.
I think what in comes down to is simple vs easy. Imperative programming in the very very beginning is easy, buts not simple.
Because there’s all this implicit state in your program, as the program grows it becomes very very complex. It’s no longer simple.
There’s this really great talk about this idea by rich hickey, the creator of clojure, that dives into this in detail.
That really depends on when the person took high school mathematics, and the extent to which function abstractions were emphasized. That was not a core part of the curriculum when I was in school, but it is now.
> Assignment is just one tiny piece of learning how to program, and is almost never a pain point after a small amount of instruction.
The issue isn't assignment. You have also assignment even in the most pure FP languages.
The issue is mutation!
> Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them.
No, that's not easy given every step can change the whole world around and you need to track all the changes in your head.
That becomes very hard to follow even after only a few steps. (That's why imperative programs are always so buggy.)
FP code, which usually eschews mutation, is much simpler to follow as you can look at any "step" in isolation. No hidden "change the world" side-effects everywhere.
> FP requires much much more abstract thinking that is often difficult for newcomers to grasp.
No it doesn't. At least as long as you don't go nuts like e. g. Haskell.
At the core FP is basically the same trivial concept taught to children in elementary school: If you have some expression you can mechanically substitute following occurrences which the value assigned to that expression. That's all.
> The main exception that I see is when someone who has a very deep mathematics education.
Like every child that attended math classes for many years. In school people are trained for a very long time in exactly the way of reasoning you need to write FP code.
On the other hand you need to teach those people imperative programming form the ground up, including mayor mental shifts around all kinds of concepts they were taught previously. Only after this kind of brainwashing people start "to get" imperative programing…
> Almost everyone else seems to grasp imperative programming easier.
Just go out and talk to some programming instructors… Everybody will tell you the same.
Only people whos brains are already burned by imperative programming think it's easier. For everybody else it's the opposite. Which is perfectly logical as the FP way of thinking is what they practiced for many many years before, in math in school.
Even on the top answer on one of your own links: "In spite of what this all sounds like, I'm not suggesting that functional programming is necessarily easier"
My experience is that of a TA and a tutor. Granted, it's hard to find people who aren't tainted by imperative programming thinking these days, unless you're starting on the true ground floor, which I admittedly rarely do.
>> Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them.
> No, that's not easy given every step can change the whole world around and you need to track all the changes in your head.
Learning and using are 2 separate things.
FP is supposedly easier to use in the long run but it’s definitely harder to pick up.
Imperative is the opposite since it’s analogous to writing out a list of things you want the computer to do - a concept even the uneducated can understand.
The way I see it, I live in a world that has state. I spend all my waking hours manipulating the state around me. From this perspective, imperative programming is as natural and intuitive as anything can be. You do things, and the world changes.
Abstractions are good, but you should first understand the concrete ideas behind them. Otherwise you may end up doing pure symbolic manipulation without any intuition to guide you.
> It looks more like complete nonsense: `x = x + 1` isn't true for any `x`
It does seem you were complaining about the syntax of assignment.
In the other comments it was clearer that your main complaint is that it's hard to compose mutations to reach a desired state. I agree! You should've led with that!
The syntax is of course also confusing. If you show the above line to a 6. grade child they will tell you that that line makes no sense, obviously.
That's why this example is so good! For someone without exposition to (imperative) programming it's completely nuts. But after some "brainwashing" people don't even recognize how weird the example is actually. My hope is always this makes people think (at least after explanation) a little bit whether they maybe just internalized some actually unintuitive stuff and now think that's the "normal" way to look at things, even it's actually not if you come in just with the knowledge from school.
Not everybody remember that but most people have for example major issues in grasping a loop with a counting variable in the beginning. It's just not so easy to "do the computation" in your head and track the state of your variable. Variables as such are already confusing to most people. Beginners often use them like constants and declare new ones when they actually need to assign a new value. I've see this pattern quite often! If you ask why it was done this way the answer is often "because re-assignment is confusing"…
Your complaint is that the '=' is used in a different domain than programming with a different use. Rightly or wrongly people will adjust to different notations very easily, homonyms in natural languages rarely cause problems because of the context. Same here, this is C/C++ not formal logic.
Once somebody is told 'this is mutation' and it sinks in, it's not a problem.
You make the bigger claim that FP is easier to understand, and I don't buy it. If you want to put forward that, back it up with some evidence. Personally I believe that it depends on the person. I did a brief introduction to FP to a couple of mathematicians and they got it immediately, but then they were extremely bright and had minds naturally suited to handling abstractions. (edit: which I am not and have not, respectively)
And one of them was not allergic to learning C either, and he got a few lessons in that too.
I worked with one person who simply couldn't understand the concept of passing a function around like any other piece of data.
It frustrates me when people (like you) insist that one programming paradigms is The Truth because, the truth is, you need all of them and you need to apply them at the right time – 00, FP, logic, and yes, procedural. If you can't do that, if you're too hung up on one-way then it speaks of inexperience. As a programmer you're there to deliver a solution, not a technology, and I've been involved in the mess when someone far too inexperienced pushed for the tech rather than the saleable product.
Final note, the inventor of Scala is Martin Odersky and I was watching one of his videos on YouTube where he very much surprised me by saying something about allowing Scala to be imperative for when imperative solutions were the more concise answer. And in the end, all computers are state machines.
So please, loosen up your presumptions; the world is a messy place and you need to allow for that.
I think this reply needs a longer answer than I can give at the moment; it's morning here and I've got to work, I'll reply in a few hours hopefully with something constructive.
>One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math.
Considering how much people struggle with learning math I'm not sure that this is a good way of going about things. I don't think functional programming classes have much more success either.
>Objectively they have. I've linked already some evidence in the other reply in this thread.
I don't see it. Maybe we (our class) were taught wrong, but back in uni I would rate the usefulness of our FP class as one of the worst. I got the sense that most of the students (that passed the class) weren't able to use what they studied in the class. If they took away anything from that class, it would be that they shouldn't touch Haskell again.
FP is useful, but I would argue that imperative is easier to learn, because keeping track of state is easy when you're learning. You're dealing with small programs that you wrote yourself. Keeping their entire state in your mind is not difficult.
Also, I think there's a joke somewhere in here about learning Java ruining the 'state' of your brain for learning FP.
Creating connections in the curriculum between math and other subjects is a good way to help students better understand both math and other subjects. I don’t have literature to cite on this though.
Also a good way to turn off students who have no interest in math from subjects they have interest in. I would have never become a SWE if I actually attempted a CS degree.
> FP is much simpler to learn, so much better suited for newcomers
I'm going to have to disagree with you like most other replies.
You need basic math knowledge to do FP - at least know what a function is.
Imperative programming is just writing out a list of instructions for the computer to follow and everyone understands the concept of write out a list of instructions. No math needed.
My position is that for university students, you should start with FP. You have them for 4 years anyway, they'll have plenty of time to learn imperative programming. But FP both distills essential CS concepts, putting them front-and-center, and it puts your freshman on a more even playing field between those with existing programming experience and those who don't.
If by FP we mean Monads recurrence and no single drop of state, then yes.
If by FP we mean "Let's write our functions as pure (and leave IO as a magic box for time being)", then this is undeniably more straightforward then getting head deep into side effects that procedures can create, not to mention the entangled web of dependencies in OOP, and other messy stuff it promotes
There are jobs for pretty much all established technologies. And if there aren't currently, there could be in the future. I primarily work on procedural & OO projects, but I disagree with your position. I've seen job postings for all sorts of things; Things that interest me, things that don't, things that are hot, things that are old hat, things that have an air of prestige, things that look like a coffee stain on your resume...
Well if you're learning computer science, what does it matter what is industry standard? Computer science doesn't really have very much to do with the programming industry.
Because when we're talking about CS education, it's usually in preparation for a software engineering career. Whether that should be the case is another story, but that's the reality.
I think the reality is that computer science is only tangentially useful preparations for a career as a software engineer.
There's some courses that are inarguably fundamental, some which "separate the good from the bad," but there's also many which are simply not practical, besides the fact that they teach you how to learn.
It's a flawed analogy but I'd liken it to mechanics vs automotive/manufacturing engineers. There's a good bit of overlap, but lots that isn't shared. And software engineering as an industry doesn't always do a good job differentiating between the two
Burn computer science. Like unironically it's so grown into an awful patchwork of dogmas. It sells itself as a software engineers degree, but if it's not really then it's effectively an incidental scam.
"De-facto industry standard" is heavily a function of what slice of the industry you're looking at.
It feels like the dominant style of programming in the companies I've worked at (YC startups and FAANG) is "functionalish" procedural, with a sprinkling of objects-qua-objects to interface with libraries and frameworks (Eg, react class components or rails ActiveRecord models).
Note I'm distinguishing between objects-qua-objects (data coupled tightly to methods that operate on them) from structs-implemented-via-objects (eg, ruby's `Struct` or Java "beans") or modules-implemented-via-objects (like a class with a bunch of static methods used as a namespace). I only see the first one as "object-oriented".
This looks to me like a pretty traditional stack of Computer Science undergrad topics. A similar big list of topic/resources that's frequently linked to is: https://github.com/ossu/computer-science
Could you describe a bit more about what you're looking for when you say "traditional CompSci?"
It seems to be pretty close to my program (UCSD). Distributed systems was introduced in operating systems but you had to elect for deeper classes. System design wasn’t really taught unless you mean CPU architectures, which this covers. I’ve never heard of game theory being part of a CS program (I took it as an elective)
I guess if FP'ers didn't think it was better, we wouldn't be doing it. It's not like there are lots of people stuck in functional programming jobs wishing they could be writing Java.
"All" FP articles and "always" is probably broader a generalization than what you really mean. Can you share examples from the linked page that you see as smug?
This can also easily be a filter on the part of the reader: anything FP is always close to triggering the "smug" concept, even if they don't use words that would be read as smug if the topic was something else.
Same way some people are quick to read intelligent women as "uppity" though they say nothing that would be read as uppity if said by someone else.
I don't usually (get to) talk much in our team meetings. This one time I suggested we try FP for a new internal project - and the backlash I got was quite unexpected. Merely the mention made my teammates launch into a dozen different assumptions, before I even finished the sentence. I was shut down pretty quickly. I was surprised, because usually they are at least receptive to hearing out new ideas.
I think outside of HN, there's a large chunk of people out there who just have this prejudice about FP. I am only about 10 years into the software industry and I feel like I'm missing some history that is not recorded anywhere, but lives as a tribal memory.
I will agree it's about 30% less code on average, but whether it's "team friendly" or "debug friendly" is quite another matter. Debates over such often rage for months.
If it's truly superior, then form a company called Functional Magic or the like and out-compete OOP rivals and eat their lunch. Proof will then be in the pudding, no more talk. (Some co's have tried similar without long-term success, at least outside of niches, as it does well in finance.)
If FP is say 15% more productive, such a company would eventually just outcompete OOers by growing 15% a year. Even 5% a year would catch up in roughly a decade. If you truly believe in FP's superiority, do it! Unleash the FP Kraken! When you are golfing with Warren Buffett & Gates, you can say, "I toldja so, fore!..."
"more productive" is not a singular metric. What indefinite 15% year over year growth in mainstream tech requires is (in addition to favorable market conditions) the ability to get useful work out of huge numbers of very inexperienced people.
Clearly Scheme, for instance, cannot do this better than Java. But this tells you next to nothing about which tool is more productive in the hands of a small team of people who know what they're doing.
> But this tells you next to nothing about which tool is more productive in the hands of a small team of people who know what they're doing.
This has been tried, usually driven by academics who try to start a business by hiring "elite" coders with the belief that you need many fewer elites to do the same work as "normal" coders. Sometimes they have short-term "hits", but it's usually not a sustainable business model. For one, it takes coders with some business sense and team skills, something the academic type tend to lack: they are idealists who get snagged up on arcane design philosophies. Imagine a room of Sheldon Coopers. I'm just the messenger.
The author sets the width of the content container to 40em, for example, to make it so lines of text are wrapped appropriately (a single line doesn't contain on average more than n words). Is it worth adding some styling around typography to make it even more readable? Up to the author. Only a suggestion from a single reader, of course.
I don't have a high-res screen (just 1280x800), so to me it's one of the most readable pages I've ever seen. Although curiously, it also looks great on the iPhone by default (which is high-res). I assume you're on some sort of 4K external monitor, but I wonder why it would look small there while reacting well on the phone?
