Plain Functional Programming by Martin Odersky

Subscribe to Devoxx on YouTube @
Like Devoxx on Facebook @
Follow Devoxx on Twitter @

In a short time, functional programming went from an obscure academic endeavor to the technology “du jour” of the software industry. On the one side, this is great, because functional programming holds real promise to simplify the construction of highly reliable software. On the other hand, it is also frightening because the current hype might lead to over-selling and sometimes too uncritical adoption of concepts that have not yet been sufficiently validated in practice. In particular I see with worry the trend to over-abstract, which often leads to cargo-cult technology.

In this talk I give my opinion of what the core of functional programming is that we can and should use today, why that core matters, and where we currently face challenges. I argue for combining functional programming with the principle of least power, for eschewing fancy abstractions, and for being modest in what we can and should express in our programs. I also show how some of these approaches are reflected in our work on the next version of Scala.

Martin Odersky is the inventor of the Scala language, a professor at EPFL in Lausanne, Switzerland, and a founder of Lightbend. His work concentrates on the fusion of functional and object-oriented programming. He believes the two paradigms are two sides of the same coin, to be unified as much as possible. To prove this, he has worked on a number of language designs, from Pizza to GJ to Functional Nets. He has also influenced the development of Java as a co-designer of Java generics and as the original author of the current javac reference compiler.

21 thoughts on “Plain Functional Programming by Martin Odersky

  1. Did he use the grammar of Haskell 98 or of Haskell plus all GHC extensions in 2016?
    Unfortunately, many Haskell library writers seem to be happy only if they need to enable more than 20 GHC extensions.

  2. Since when grammar is an indication of complexity? Strange to hear those arguments from such a smart man.
    Does it make Haskell easier than java8?
    The term easier doesn't even make sense.

    I thought CLOS is a Common Lips Object System or is Martin referring to smth else?

    This `Possibly[Configured[T]]` is awesome though

  3. The implicit "WiFi" (as opposed to explicit "Plumbing") capability of implicit functions really shines! When implementing reader monad transormers (yes, imho they do have their usage) they "just work". I never enjoyed "deleting code and noticing that everything still works" as much!

  4. What is the appeal of the "receiver functions" DSL? (I understand how it is implemented using implicit functions, but why is it a popular feature in Kotlin/Groovy?)

  5. The greatest difficulty is dealing with the massive amounts of incompetence within this entire field. It's absolutely riddled with inexperienced programmers and managers having no clue what they're doing; the general structure of development via compartmentalization is bad, the manager needs to be the programmer, otherwise they have no perspective of how a project could feasibly be structured etc. The incompetence mostly stem from school taught programmers, who tend to suck ass because they have no personal interest in the programming itself, they're not interested in exploring it, only to learn the bare essentials and to achieve some result by any arbitrary working method, which among many other fallacies leads to the necessity of shitty OOP, since they have zero overview of what they're doing, and thus needs encapsulation to avoid the inevitable catastrophic results of their blind and spastic-like bashing of their arms onto a keyboard. I still wonder how they ever get anything to compile.

Leave a Reply

Your email address will not be published. Required fields are marked *