The obsession with connecting teaching with particular languages is totally bizarre. This quote, in particular, is somewhat mind-boggling:
If it taught you to be a better programmer, then you absolutely applied it. That’s the whole point. People should be taught how to program, not how to use particular languages (you can learn the basics of a language by reading a book, and the rest you’ll learn by using it).
Now there are plenty of things wrong with SICP, but to say that since it is teaching functional programming, it is totally useless if you aren’t writing Scheme/Clojure/Haskell/OCaml is nuts. It teaches abstraction, problem solving, how to break problems into smaller ones, etc. It’s a particularly spare presentation (as it starts with such small building blocks), which makes it a bit extreme, but the process of building data structures and algorithms out of smaller pieces is an absolutely fundamental part of computer science, and the rush to replace these curricula with “more realistic languages” seems to lose some of this (e.g., everyone wants intro classes in Python, a supposedly “simple” language, but one where it’s impossible to define data structures in a straightforward way without bringing in half of the class system).
If I recall correctly, they mention right in the beginning that what they’re after is figuring out the nature of computation. In that sense, it’s a much more fundamental (dare I say philosophical?) book than most, which may turn some people off or leave them with the idea that they didn’t learn any directly “practical” skill. However, it will shape your thinking about problems in such a way that indeed, you will be a better programmer. It transcends language and even programming paradigm. Of course, you will have a more FP-oriented mindset after you’ve finished it, but that can be applied in almost every language.
I didn’t find this blog post very insightful, and I reject the notion that “FP is hard”. Yes, it’s a different way of thinking, but it’s only difficult if you try to go too fast while teaching it to programmers who are firmly stuck in a different paradigm and expect them to just grok it immediately. Teaching is hard, and teaching FP just seems harder if you are leaning too hard on students already knowing how to program and expect them to just pick it up like the syntax of a new language. It’s actually quite similar to try to teach object-oriented programming properly to people who have very little experience with programming. That’s actually much harder than you think! The whole idea of “objects” sending “messages” to each other is really very abstract.
I think teaching functional programming to people who have never programmed is much easier as you can rely on some of the math knowledge they already have. Teaching old-school imperative programming (think BASIC, Pascal, Logo) is much easier too, but in some circles there’s something of a taboo against teaching that kind of programming as it supposedly teaches people “bad habits”.
Some blog posts should be considered harmful. This is one of them. Functional programming is in no way like the Matrix or simulation theory or any of the author’s other tortured metaphors. Maybe functional programming is hard for some people to understand but the author’s approach is not a way forward. These attempts to make functional programming easier by drawing analogies to every other corner of the universe are well meant but I am scared for the beginner who finds them. They generate the same confusion generated by the old language like “monoid in the category of endofunctors”. But unlike that language, these metaphors are also just wrong.
When you learn hardware, you learn there’s stateless and stateful circuits. Almost everything in a CPU manipulates state even though some of its primitives are stateless. They only use stateless up to a certain point before switching away from it for practical reasons. It’s more like a concurrent, imperative thing built out of FSM’s with some functional pieces. Author shouldn’t have included hardware for arguing functional programming if most is interacting FSM’s.
The author’s hardware vs software duality is also wrong even though they’re definitely on opposite extremes in ideal cases. In reality, many large pieces of software can be as expensive to change as some hardware. Microcode has been used for fixing certain kinds of hardware mistakes for a long time. Gate arrays got ASIC costs down quite a bit for prototyping by sacrificing some speed. FPGA’s made hardware reprogrammable with them getting faster and larger to be used in more applications. Author is right that FP algorithms will synthesize easier in theory but the best tools I found in practice were for C-like languages.
I think the author would also like dataflow or flow-based programming paradigms given their points support it more.
What did I just read? No offense @Yogthos I’ve liked a lot of the articles you’ve shared. This one was a lot of words and I personally didn’t even pick up a cohesive message. Frequently I’ve found that newer programmers have an easier time in FP because they have less to unlearn. Sure there’s a :O moment when you pass a function into a function, but that passes pretty quickly.
That matches my experience teaching FP as well. The only people who have trouble with it are those who already have a lot of experience with the imperative style. The problem isn’t with learning FP, it’s with the fact that it requires a different way of solving problems than the one people already learned. People typically don’t like feeling stupid, and if they know how to solve a problem using familiar tools, they get flustered having to feel like a beginner while figuring out a new technique.
The article appears to be written by somebody who’s an experienced OO programmer learning FP though, so I thought the perspective was interesting. If the analogies the author uses helped him, it might be a helpful way to look at it for others as well.
Functional programming isn’t hard… That’s the point right? Oo is hard, and fp really is just different
I’ll have to agree that this post is rather rambling and confusing. The comparison of functional programming to hardware is 1) not very helpful to those trying to familiarize themselves with FP paradigms, and 2) in my experience, more relevant in comparing circuits to FP (instead of the other way around). For example, Clash, Bluespec, and Chisel all leverage the properties of functional languages to better support HDL abstractions. Part 2 seemed to be a convoluted way to say FP-oriented languages attempt to apply more mathematical rigor to programming.
EDIT: I do agree that it is worth introducing early-on. There’s value in helping students think computationally.