Runar Bjarnason

It's worth noting you can implement something similar in OOP languages using Church encoding: http://blog.higher-order.com/blog/2009/08/21/structural-pattern-matchi…

From the looks of it, the author of these slides has written very little Scala. Take slide #7, for example, where he writes def bar() = { "1" } when def bar = "1" is perfectly sufficient. Ironically, I may very well be pointing out the bad parts of scala (i.e. that () is simply a convention for indicating Unit or side-effecting functions, but its just convention and not enforced by the type system in any way). Notwithstanding that, I don't think someone who has written very little Scala is in a great position to offer a reasonable critique. This is a longer discussion, but in the very first slide he points to the object-orientation as a plus. In my opinion, he's already wrong. "There is no such thing as Object-Oriented programming." See: http://blog.higher-order.com/blog/2008/12/04/no-such-thing/

"other functional style syntaxes like pattern matching are being introduced in many of them" The Interpreter and its dual the Visitor GOF pattern have made what amounts to pattern matching possible in OO languages for a few decades now [1]. The whole point of these patterns is to write recursive functions following recursive data types, which is one of the main use cases for pattern matching (ok, more generally these are used to break data structures apart). In particular, if you look at an example of the Visitor pattern, you will see that it has exactly the same structure as a recursive function that separates cases in a FP language [2] Here is a detailed explanation of how to do it [3]; it is the "little language" technique (which I suspect is the reason why it is called the Interpreter). [1] https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solu… [2] http://blog.higher-order.com/blog/2009/08/21/structural-pattern-matchi… [3] https://ocw.mit.edu/courses/electrical-engineering-and-computer-scienc…

It’s well known that there is a trade-off in language and systems design between expressiveness and analyzability. That is, the more expressive a language or system is, the less we can reason about it, and vice versa. The more capable the system, the less comprehensible it is. http://blog.higher-order.com/blog/2014/12/21/maximally-powerful/

This is an instance of the "Maximally Powerful, Minimally Useful" principle from a few days ago [0]. Because the language being described is sufficiently minimal it has multiple valid, meaningful interpretations including the direct "just execute it" interpretation, a theoretical "compile this to some kind of other language and interpret it there", and, most interestingly, interpret these relations as a linear algebra problem. It should be quite clear that a more "powerful" language would not admit this last meaning/interpretation/denotation. [0] http://blog.higher-order.com/blog/2014/12/21/maximally-powerful/