Site announcements

Welcome to FunctorHub!

Picture of Anatolii Kmetiuk
Welcome to FunctorHub!
by Anatolii Kmetiuk - Sunday, 16 July 2017, 5:20 PM

Our Vision


He who has a why to live for can bear almost any how. ― Friedrich Nietzsche

There is one problem with many educational resources on sciences and math: they do a very good job explaining the "how", while completely ignoring the "why". For example, the style of teaching programming where people are made to memorize syntax and keywords of Java while not being properly told why OOP is needed. Remember the confusion between an abstract class and an interface - until you started applying them in practice?

In such books, concepts will be well defined and theorems well explained. You will however find little information on why they exist. In applied disciplines, if something sticks around, it means people find it useful for solving a particular problem. The problem that needs solution is often the primary motivation for concepts to come into life. Failure to notice this elephant in the room makes concepts "dead" for students - they simply do not realize why the solution may be useful for them.

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. ― Sun Tzu, The Art of War

Failure to understand the "why?" behind the concepts you use, the motivation for their existence, means "not knowing yourself", not knowing the tools you work with. It means you do not realize what problems they were intended to solve.

Another side of the coin is that a lot of concepts are "crutches" - ad-hoc, suboptimal solutions, begging for better ideas. We all have seen crutches everywhere in programming - go to GitHub and pick a random project. Imagine if people were taught these crutch-solutions in a university style - with the need to memorize definitions of every part of a crutch, entire textbooks written on a particular set of crutches, tests to check that knowledge, certificates to show that you know these crutches.

Arguably, examples of crutch solutions are also present in physics - for example:

Einstein included the cosmological constant as a term in his field equations for general relativity because he was dissatisfied that otherwise his equations did not allow, apparently, for a static universe: gravity would cause a universe that was initially at dynamic equilibrium to contract. To counteract this possibility, Einstein added the cosmological constant. ― Wikipedia, Cosmological Constant

The equations were not good enough, not quite in accord with observations. This motivated Einstein to add the new term. Arguably, this is not an elegant solution - in programming, this local modification would have been considered a simple hack, where no architectural redesign has taken place to account for the error. Yet imagine trying to blindly memorize the fact the constant is present. Because say you need to pass the test, without having a clue about the motivation to why it appeared. This will be hard, since an equation with the constant will not be any different from an equation without it. For you personally, this will be a "dead" concept. You will not have an intuitive understanding of it (in the form of feeling the problem Einstein tried to solve), and you will not have a feel of the hackyness of the solution. Therefore, you may be less likely to look for a more elegant one.

Disclaimer: the author of these lines is not a physics professional. I am interested in it as a hobbyist, and hence may not see all the "why" of the theory. If you are a professional with a good grasp on the matter and see an error here - please do let me know!

If you fail to see the process of people inventing crutch solutions, you will fail to see them as such - because deficiencies are a result of real-world pressures imposed on real-world people.

As a side note, a good set of resources on learning math the right way, moving from the "why" to the "how", can be found on this site of Peter Alfeld, a University of Utah professor.

While Sun Tzu did not mention what happens if you fail to know yourself (your tools) but do know your enemy (the particular problem you face) - it is safe to assume that trying to use tools you do not have complete mastery upon will be suboptimal at best. Any more-or-less experienced programmer saw evangelists in his life. People who stick to only one technique, library or concept and try to use it on every occasion. And to prove the superiority of their choice to others. You can see this when people try to pump lots of Gang of Four patterns in a Java project or to apply purely functional style to problems that don't tolerate it well.


FunctorHub was created precisely to address the problem of the "why". Of the understanding the motivation and the essence behind certain programming tools and techniques, while ignoring the noise.

Motivation is the real-world situation that led to the creation of a concept. A problem that needs solution. In purely theoretical disciplines, motivation can also be a sheer curiosity of people exploring concepts. Motivation is the driving force that gave life to the concept.

Essence is a core idea behind a concept. In Java OOP world, it is "we need objects, because we reason about the world in terms of objects". In Functional Programming, it is "no mutations, no side effects, because they are hard to keep in mind". All the rest - the syntax, the techniques - spring into existence from these core concepts when people face real-world challenges. Think axioms and theorems in mathematics: Euclidean geometry has only 5 axioms to it, all the rest can be derived from them. If you understand these axioms well enough, you can derive the rest from them. If you do not understand them, you can not hope to understand what is based upon them. Both axioms and theorems are important, and I am not trying to say that you should only know the axioms. You should know both, but learn them the right way. It just so happens that if you master the basics first and grasp the motivation - the life force - behind what is based on them, things start naturally falling into places.

Noise is unnecessary work that prevents you from attaining mastery of the tools or concepts. It is memorization of the syntax of a new language or an API of the libraries it uses. It is also the act of rushing to learn a new project you've heard of at a conference, that uses some Typelevel or other supposedly cool library. It is having your head spinning because of the perceived abundance of ideas and directions in which programming is developing. As opposed to understanding the reason these tools were invented, the problems they aim to solve and the (essential, language-independent) way they do so. Fundamental concepts and tools (like Category Theory or Cats, its embodiment in Scala) are hard to invent. But they are relatively easy to learn and use. So people use them to develop a next cool project you hear about at a meetup. Hence the asymmetry: what really matters - develops slowly, what is easily derived from it - develops fast. This is not to diminish the value of derivative projects - it is awesome if they really do the job and simplify someone's life. This is to point out that perceiving them as a serious, large target for learning is fallacy - you can start using most of them at once if you know the basics.


FunctorHub is developed by FunctorTech OÜ, a company specializing on purely functional techniques in Scala. Our company aims to stay at the leading edge of the developments in Scala. Hence, FunctorHub is highly specialized. It aims at materials about Scala's leading edge and the advanced tools Scala community works on.

I, Anatolii Kmetiuk, is currently the only one developing educational materials for the company. I've been programming in Scala for about 4 years now. The main focus of my work has been on the development of an ACP-based formalism to describe concurrent systems. I've contributed for a while to SubScript, a Scala implementation of these ideas. Recently I have implemented FreeACP, a more functional proof of concept of the same system based on free objects. You can see my recent talk about this project here. Mixing concurrency and functional programming is quite exciting, in part because the concurrency problems are one of the "bad food" for the functional programming. You can get a better idea about what I do by visiting my blog.


The main format of delivery is video courses and e-books. All of the materials are practice-oriented, aiming to explain the "why" on the real-world examples. We place intuition higher than science - because you may know all the science backing a concept, but still be unable to apply it in practice. Same is not true about the intuition - if you've got an intuitive knowledge of a concept, by definition it means you know what to do with it.

Happy Exploring!