but still along the same lines as "safer". the stresses are different, "safer" has the stress as "SAY-fer" and "secure" has the stress as "sih-KYOOR". the latter sounds more similar (and rhymes better) with "more", the originator of the phrase "less is more"
I was hoping this article would be a little more concrete, but it seems that it largely is talking about the takeaways about functional programming in a philosophical, effort-in vs value-out kind of way. This is valuable, but for people unfamiliar with functional programming I'm not sure that it gives much context for understanding.
I agree with the high-level, though. I find that people (with respect to programming languages) focus far too much on the specific, nitpicky details (whether I use the `let` keyword, whether I have explicit type annotations or type inference). I find the global, project-level benefits to be far more tangible.
Context: I posted my functional programming lectures to HackerNews some time ago (this thread: https://news.ycombinator.com/item?id=38351195) and finally got around to writing a blog post about my experience teaching functional programming. You can read about my experiences here.
There's no reason this couldn't be done. Indeed, in OCaml (which I am more familiar with), you could easily define:
```ocaml
type 'a nonempty = Single of 'a | Cons of 'a * 'a nonempty
```
This would be the type of lists that contain one or more elements of the type parameter.
I think it's just convention that typically, when we talk about lists, we are interested in the empty case as well. Finding "all X that satisfy P in Y", as a general computational problem, is _very_ common (consider: filtering a list, querying for a predicate in a collection, finding sequences of moves in a search space), and generally could result in an empty list as a possible output.
In a non-practical sense, if you want the type theory, another reason is you can think of `[a]` as the free monoid on the collection of `a`. In other words, strings of elements of `a`, joined via concatenation. This monoid requires a unit, which is the empty list.
This one makes sense to me, since lists are way more canonically used than arrays in functional languages. I rarely find myself constructing array literals -- I'm far more likely to simply convert from a list.
Though, I agree the semicolon delimiting is regrettable.
This is Haskell-specific, it sounds like. I agree, the IO monad is really quite inconvenient sometimes.
I work in OCaml, which is also a functional language, but prints can be added in single lines. I address this point in Lecture 19 (Imperative Programming), actually, but my perspective is -- we invented immutability and purity to serve us, but we need not be fanatically beholden to it. In my opinion, I think Haskell goes in that direction, when every usage of IO now needs the IO monad to get involved.
A little mutability is OK. Functional programming is about the avoidance of side effects, more than simply forbidding it.
(but I have thought of developing my own exercises independently to go with the lectures, to post on my website. This is generally a lot of work, though, so this might take some time, depending on how much people would benefit from it.)
Unfortunately, it does not. These lectures are "mine", in the sense that I developed all of them myself, but the homeworks and lab exercises are the combined efforts of generations of TAs and instructors from the past. It wouldn't be right for me to give them away. (they are also reused from time to time, so there are academic integrity concerns with that also)
There's a few things which go into this (hi, I'm the instructor!).
One such reason is historical. Standard ML is a research language, and a significant amount of work on it was done by professors at Carnegie Mellon, who developed the curriculum for this course.
Even setting that aside though, I fully agree with the choice to teach it in SML. For transparency, I work professionally in OCaml, so I am not unfamiliar with it, and I enjoy it quite a bit. That being said, I think that the approach taken by CMU is best summarized as the fact that languages are ephemeral, and the concepts are what matters. We don't teach programming languages, we teach concepts -- so even if SML is not widely used, the tradeoff for having students have a simpler, less distracting, and better learning experience is well worth it.
OCaml has its own intricacies that make things difficult. For instance, you can go down a lot of rabbit holes with `dune` and `utop` and `ocamlc` and `ocamlopt` and all of these things, versus SML/NJ's simple interactive REPL. Another thing is that the language is just generally more "bloated" -- you can teach modules, but then what if a student starts running into first-class modules, recursive modules, or even beyond that, GADTs and classes and objects?
(as an aside, this is my primary reason for why I would not want to teach an introductory course in Haskell. To do anything, you suddenly need to understand the concept of type classes and lazy evaluation, and that's simply too much. I don't know much about the other languages.)
I think teaching is as much enabling students to succeed as it is to prevent them from shooting themselves in the foot. For an anecdote, there is an `Option.valOf` function (of type `'a option -> 'a`), which essentially is just a bad function that should be avoided where possible. Every semester, without fail, even though we never tell students that function exists, students are smart enough to use Google, and will use it anyways, ultimately harming themselves.
I think that same mentality applies to programming language choice, here. Keep it simple, keep it neat, and make sure that the students see what is necessary for their education, and not have to spend mental energy thinking about much more.
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.
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!
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).
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.