Functional Programming Essentials by Kelley Robinson

This video was recorded at Scala Days Copenhagen 2017

Abstract:
Scala is often touted as a tool for Functional Programming, but Functional Programming (FP) itself is left to differing and opinionated definitions by many of its practitioners. FP is a well defined approach to writing programs that we will uncover in this talk. It is a style that long predates Scala and many of the modern abstractions that are often referred to as "essential" tools.

We will walk through the origins of FP, providing historical context through Lisp and the research that brought us this paradigm. We'll define what FP is and what it is not, looking at how tools like purity and immutability enable the expressions at the heart of FP.

Finally we'll talk about practical approaches to Functional Programming in Scala, how you can and why you would use this style in your everyday work. This will _not_ be a talk about monads and type systems, but give you a pragmatic look at how to separate the syntactic sugar from the underlying principles.

[WarrenLeggatt]

The thing I have found exploring FP over the years is that the abstractions are where you end up to clean code and stop writing the same code over again. It is similar to the relationship between OO and the Gang of 4 patterns. You do not need to use them or understand them to do OO but they are a set of common things you end up writing time and time again so understanding them improves your code and makes life easier.

[robinmattheussen]

While I strongly agree that we need to focus more on the problems FP abstractions (try to) solve when explaining them (as opposed to focusing on how they work, that part should come after we've established common problem patterns), I strongly disagree with the idea that we should discard established jargon. They allow us to effectively communicate about abstract concepts. We use an immense amount of jargon in the technical world, and almost all of them hold very little meaning to people outside of this world. So why is it that "Bean" is an accepted term, but "Functor" is considered scary? I can easily understand the latter, but after all these years, I still don't quite get what the former is supposed to (really) mean. While it's true that some of these concepts can be a little tricky to get the hang of because they are often very abstract, I actually think a lot of the "fear" of pure FP concepts comes from the proliferation of the idea that they are hard in online circles. And I don't think this presentation helps in that regard, even though I absolutely support the notion that we need more effective ways to teach FP.

[blockflute]

This is a great talk, and it quite agrees with some of my experiences. One point that really resonates with me is how there is a lot of exotic terminology tossed around without actually explaining why the thing is useful or what it is doing. You see talks and read blog posts about exotic category theory terms wrapped in Scala hacks wrapped in more category theory wrapped in a function. The end result is supposed to be super useful and super smart, but it's really hard to make out what's the actual crux of the solution, or sometimes even what is the problem being solved. This sometimes causes people to blindly implement the new cool thing they saw on a conference, without really understanding what it's doing, or if they really need it. Then they sometimes leave the company, and everybody "hates" them for leaving a piece of code nobody can maintain :)

The problem with _categoricaly programming_ (I like it being dubbed like that in this video) terminology is that it's like most things in maths or physics, arbitrary and non-intuitive, and requires a lot of cognitive overhead to understand what are the actual effects of the structures you are using. I don't need to spend three months of my life and watch 10 talks to understand what a Monad is, or a Free Monad, and why it's useful, because those concepts are not _that_ difficult. Yet, it's all obscured behind non-intuitive terminology. This is what's putting people off from using useful concepts in their code, and sometimes creates an atmosphere of intellectual elitism.

[antikantian]

What is up with this presenter's crusade against category theoretic concepts? The last talk I watched by Robinson was basically a rant against monads simply because they are abstract. Simply because you don't understand a concept doesn't mean it's not important or useful. In her last talk, she said that her team was afraid to refactor something because it was too functionally implemented (read: Haskell-y). I don't see how this presenter is qualified to be speaking publicly about functional programming "essentials" when she gives the impression that she couldn't lyahfgg.

[runedrolepedersen]

The effort to make functional programming more accessible and easy to learn is commendable. However I feel it is a little misguided to so harshly discredit the more abstract parts of functional programming. Furthermore i am saddened that grading concepts by difficulty alienates people. When learning to play the keyboard you don't start out with Chopin or Beethoven. You start with something simple like "Itsy bitsy spider" and work your way up. The journey might be long and no one expects you to play classical masterpieces within a month or even a year. Functional programming is the same. Simple vs complex abstractions should not be an "us" vs "them". It is simply different tools for different jobs. The complex abstractions are hard to learn. Some people can't live without them, others are less impressed. Going back to the music analogy; If you don't like Beethoven and think you can live without, play something else. But it is absolutely fair to say that if you want to play Beethoven there are other pieces you should learn first. If that somehow offends people who prefers those easier pieces I think we need to do a better job of communicating that a taste for easier to execute music does not make you a lesser person. Regardless of whether you like simple or complex abstraction I think it is more important to focus on what we have in common like our love of functions and general dislike of side effects than the places where we disagree :)

[epi]

Very disappointing that fellow woman in the industry would rather dumb down the barriers to entry than bridge the learning gap. I don't think I've ever heard people say 'you have to understand Advanced Monads etc...' (whatever advanced monads means), and only ever heard people in our FP community encouraging others to learn what things are and how they work at different levels. There are a myriad of materials out there doing just that - bridging the gap at different levels and holding people' shands. The minute you start telling people they don't have to learn any of it, you start inviting in a lower standard of programmer. You need to learn recursion. You need to learn GADTs (things that you included on your slide, that actually, are fundamental to using Scala properly), and many of the big scary words on your big scary word chart as well (another sign that you're being incredibly negative and anti-intellectual, as opposed to pragmatic). Just like they had to learn ByteBuffers, Heaps, Stacks, Lists, Trees, the DOM, etc. But you don't care about those, just the jargon that supports your argument.

Very disappointing.

[juanjosevazquezdelgado]

Very disappointing and full of clichés. It is sad to be proud of not knowing and above all not wanting to learn more to make things better. It is great that Scala provides `map` and `flatMap` but it is even better to discover a reproducible pattern, that it fulfills certain algebraic laws and that therefore allows me to reuse that knowledge in other contexts.

Why programmers are not going to take advantage of mathematics?. Physics has been doing that for centuries, using mathematics as language and support and that has taken us to space and to isolate the Higgs boson. Are we programmers less smart and capable than mathematicians and physicists?.

I agree that it is good to never forget the essentials of functional programming and its foundations, but the evolution did not stop in 1975. We have the right to continue evolving individually and as teams and organizations.

[abelgerli]

Great talk you only learn by context by putting a model in your head where specific concepts and patterns are useful. Ideally you have to be able to reason why you used it. May be with comments and hints to give others who see the code I future hints. By the way: Covfefe Monad 😂😂😂😂😆😆😆
I really like the term categorical programming by the way.