His Category Theory for Programmers book is an excellent introduction to the CT world if you come from a Computer Science background (well ... duh it says it right there in the title) and know very little math.
Highly recommended to give it a try, even if the topic doesn't seem to fit you. This is one of those books that will make you a better programmer regardless of what you do.
Writing interpreters in Haskell (which is what some of the lessons seem to be about) is a great way to learn the language. It naturally motivates recursion, algebraic data types, strong types, higher-order functions and later, when effects such as state and errors are needed, monads arise naturally.
The best part? It takes a ridiculously small amount of code to do all that, maybe around a hundred or less. Languages without ADTs and higher-order functions bend over backwards to recover them[0] via design patterns.
It also introduces you to the expression problem pretty quickly and organically :)
I agree with the comment though. I learned Haskell and how to write an interpreter at the same time by working through the book Crafting Interpreters. It was a great match.
Back when I did my degree, Haskell still wasn't a thing, like it was giving its first steps.
So the choice would be Lisp, Prolog, Caml Light, or the recently released Objective Caml.
The year before I took compilers design project, the TA responsible for it used to disallow them from the implementation language option list, as it would make the assignment too easy.
Agreed! I've been trying to learn haskell for a long time, and this guy writes a json parser live, giving his intuition along the way. It's helped me immensely.
https://www.youtube.com/watch?v=N9RUqGYuGfw
compiler, evaluator constructs should be the bottom of the next set of mainstream languages (possibly being born today by former haskell programmers?) imagine free monad lisp
Also I personally recommend to take a look to this series before diving into his great introductory book about category theory [1]. Seeing the application of the theoretical concepts and deriving the code yourself makes it more approachable for completly begginers from my experience.
The only introductory treatment of Category Theory for non-specialists that I’ve encountered that even competes with it is Spivak’s “Category Theory for the Sciences.” For the curious, Eugenia Cheng’s books for lay audiences are excellent for getting a feel of the power and value of the Category Theoretical approach.
Category Theory is somewhat unique in being a recently developed area of advanced maths that is nevertheless approachable with only modest formal training. Because it maps so well to much of the theory and practice of functional programming, most programmers with even a little interest and familiarity with that will be able to engage with the fundamentals, and Milewski does a masterful job of introducing it to that audience.
My university teaches the intro CS course in Racket (lisp), and I know another that teaches in Haskell. If decades of priority exposure to young programmers is not enough to spur widespread adoption, then I'm not hopeful.
I think intro CS courses in Lisp and Haskell (or other less-than-mainstream languages) hurts the uptake of those languages. The students will confuse the difficulty of the material with the language itself. And there's less material out there to support them, compared to the multitude of Q&As for C or Java or C++. And when later courses move them to other languages (C, Java, C++, etc.) things seem easier so the students reject those earlier languages. In some ways those languages may be easier, but the student is also more experienced.
I doubt I would've taken as well to Lisp if it was my first course, versus used in a couple graduate courses.
When I did my degree, we had ISO Pascal and C++ (proper C++ not C with classes) on the 2nd year (1st was a common year to all engineering degrees),
Followed by abstract logic, Prolog, Caml Light and Smalltalk on the 3rd.
By the 4 year, you would have used Prolog in a couple of parallel assignments that also required it, Lisp via ELisp, as Emacs was the "IDE" for the Prolog and Caml Light assignments and some TAs liked to spend an hour introduction to not using Emacs like Notepad.
UNIX systems programming, distributed computing, data structures and algorithms would make use of C, that by virtue of having already learned C++, no teacher would spend a second with an introduction to C lectures.
Those of us that took language design and compilers, would still delve into proper Lisp, Cobol, Fortran, Algol, Oberon, and a couple of others even less known. The teacher driving this lectures would switch back to Caml Light for several exercises.
Since I ended up graduating as Java came into the scene, the very last year I ended up doing several projects in Java as well, while taking place in the national championship of logic programming.
If anything what frustrated me was coming into the market place and having to deal with C, while having been exposed how much better the things could be. Thankfully using it alongside Tcl made it not so bad, given Tcl's lispy background.
The problem is not the intro courses, the problem are the teachers and the material been given to the students. It isn't a big deal if there aren't many books available, when there are teaching notes (of book like quality) given by the responsible professor, which one can question at any time unlike most book authors.
For me what made the difference weren't the books, rather the teachers I had the luck to meet during my university travel.
I don't think that's the point of having the intro CS course in a functional language. The concepts that you get taught there can also be applied outside of pure functional languages and they teach you a different way to think about programming.
I did my interpreter class in Scheme in university. The main thing it taught me was I never wanted to use scheme (or lisp) and put me off of functional programming for many years.
I re-did the interpreter from that class in C++ and it made insanely more sense to me than the scheme version. I could see where scheme was going and why it was a good fit but just hated it.
That same professor taught our C++ class (while learning it, they had someone quit) the next semester and they had to actually do a do-over he was so bad at C++. To his credit he knew as much half way through the semester (he had students getting ahead of him). He basically nop'd out of C++ like I did out of Scheme. It just didn't fit his brain.
I did my interpreter/PLT class in OCaml and absolutely loved it. I yearn for things like ADTs and pattern matching in other languages I use now :'(
Another benefit (I guess the primary benefit) was that my interpreter programs written in OCaml ended up looking nearly identical to my proofs/definitions. Doing it imperatively would add a nasty layer of indirection.
If you already knew C++, that's not a particularly useful comparison. Of course you were more comfortable reading and writing code in a language you already knew, than one you were learning.
An equivalent would be a class teaching c++ and writing and interpreter at the same time. And my gut says that would be more complex for unnecessary reasons than the class you took.
I did not already know C++. I did already know Java since we did java for our intro class (101/102) and then the next year we did Compiler theory (240). But the professors who know more than me an entry level student designed this structure.
And I did write that same compiler in c++ and sure it was more lines of code but I understood it better.
I've also worked on a scheme interpreter in C++ that someone wrote in a game engine and it wasn't all that complicated.
There are plenty of programmers who learned languages like Haskell, Scheme, Eiffel etc. as their first languages who are now programming in Java, JavaScript, C# etc.
There are just way more courses/universities that teach or taught Java/Python.
Businesses settle on the lowest common denominator it seems.
Would it not be great if instead of a programming language being handed down to us as if made of stone, it was seen as a particular expression of a set of ideas (some good, some bad), much as music is, that we could relate and respond to in the same spirit?
i think a better analogy would be [programming techniques as "musical ideas", programming languages as instruments]. you can pick an instrument that fits what want to do, or build a new one if you know how :)
This is just my heuristic but Haskell has just 25 keywords. For comparison: C 32, Java 53, C++ 83 and C# 102. What makes Haskell confusing are the 115 GHC language extensions. Each is basically a new concept to learn. Every time i join a new and sufficiently large project, I stumble across an extension that I am not familiar with.
Often extensions make the language easier to understand, by removing arbitrary restrictions that you wouldn't have expected to be there in the first place.
I think that a lot of people find that LYAH makes you feel like you're learning, but have difficulty actually applying/using the concepts. This is compounded by the lack of exercises.
> The material often bores learners and leaves them feeling like they're not "getting" it. This is because they're being "talked at" and demo'd to. They're not engaging with and solving problems.
His Category Theory for Programmers book is an excellent introduction to the CT world if you come from a Computer Science background (well ... duh it says it right there in the title) and know very little math.
Highly recommended to give it a try, even if the topic doesn't seem to fit you. This is one of those books that will make you a better programmer regardless of what you do.