Over the past two years, the PDF version of Bartosz Milewski’s Category Theory for Programmers became a highly-successful open-source book, which was adapted to other programming languages, such as Scala and OCaml. There was a high demand for a physical copy of the book, so I went exploring the vast options, which I summarize below.
Over the past two years, the PDF version of Bartosz Milewski’s Category Theory for Programmers became a highly-successful open-source book, which was adapted to other programming languages, such as Scala and OCaml. Unfortunately, building this 400+ page PDF from LaTeX sources in multiple editions took a significant amount of time, sometimes upwards of 15 minutes. One of the reasons was, all the code snippets are loaded from external code files (so that they can be easily adapted to other programming languages), and they have to be compiled each time in a format LaTeX understands.
I recently explored some possibilities to reduce the time it takes for the snippets to build, and I’m happy to report the results: a 60% improvement overall! Big thanks to muzimuzhi from the minted github, who generously helped me to arrive at the solution below.
Here’s a quick summary of my changes, that resulted in reducing my Travis CI builds from 14-16 minutes to mere 6!
This was initially a long post, detailing all the manual steps required to set up a complete Haskell development environment, however, thanks to a hint by Krzysztof Cieślak, this process is now fully automated, allowing you to get started in minutes. All thanks to a Visual Studio Code feature called devcontainers, supporting running the development environment in a Docker container.
This is the second module (out of 5) of my English summary of the Haskell MOOC on Stepik, available only in Russian. Read the first part in the Introduction module.
- Programming fundamentals (this page)
- Data types
There’s a fantastic free online course (MOOC) for the Russian-speaking developer community on Stepik for learning Haskell - a two-part course titled Functional Programming in Haskell by Denis Moskvin, (then) associate professor at the St. Petersburg Academic University. I recently re-watched the course (having completed it previously) and decided to take notes and summarize the course content in English for your enjoyment.
I would like to thank Denis Moskvin for providing this amazing resource for free, and urge you, if you speak Russian and want to learn Haskell, to work through the course material and exercises!
Below is the summary of the first module, Introduction, out of 5.
It’s amazing how sometimes just having a different framing of the problem helps with developing a much deeper understanding of the problem. I was working through the exercises of the Data61 Functional Programming course, assisted by Brian McKenna’s video streams, and I came accross a definition of a right fold that can be thought of as “constructor replacement”:
foldr f z listreplaces in
- Every occurence of the cons constructor
- Any occurrence of the nil constructor
The book The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas suggests that as developers, we should “learn at least one new language every year.” (pg. 14)
When I recently asked a roomful of developers, if there’s anyone who had learned a new language this year, only very few hands went up. A year ago today, that would have been me in the audience, keeping my hands down.
I can’t think of another 5-letter word that strikes fear in the hearts of so many developers, coming from an object-oriended/imperative language to a functional one. So much so, this, and other M-words are outright banned on some resources.
This post will not attempt to explain monads, at least, not on purpose. This fantastic post by Max Kreminski does this better than I ever could - by showing that most “monad tutorials” (or, educational blog posts in general) have problem-solution ordering issues. Please take a moment to read this wonderful post before continuing.
Layered architectures were good, until they weren’t. Someone said ORMs, and we were tearing out our SQL statements in favor of magic.
ORMs were good, until they weren’t. You couldn’t use the generated entities in your presentation layers, because they knew too much. Someone said DTOs.