Plain Functional Programming by Martin Odersky

Please subscribe to our KZbin channel @ bit.ly/devoxx-youtube
Like us on Facebook @ / devoxxcom
Follow us on Twitter @ / devoxx
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.

[@StEvUgnIn]

Thank you Mr. Odersky for your introduction to Scala programming.

[@royalgoose]

This is genius. I wasn't so excited about implicit functions before seeing this talk, and Martin does an amazing job of explaining why they are useful. Don't get me wrong, this is advanced material, but if you've looked at all the alternatives he does a good job of breaking down why this approach is better. Implicits continue to be given a bad wrap because of their power, but I personally feel like they might be one of the single greatest programming language features to ever be invented. Brilliant abstraction.

[@eg4933]

this man is amazing and scala should be adapted to high-performance applications as well. Amazing language.

[@Moriadin]

software complexity arises from mortgage-driven development. True story bruh...

[@vimalneha]

To understand Functional programming I found this video to be the best one. In the Java world, it is not that well explained or assumed. One needs to understand a bit deeper and from a different angle. And I agree with Moriadin that Software complexity arises from Mortgage-Driven Development, where some individual keeps the whole company hostage, till everything crumbles under its own weight.

[@amigalemming]

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.

[@obszczymucha1337]

I came here looking for an answer to "why is scala overcomplicated"? And then it seems Odersky is asking himself that question too: 12:38

[@parakhonskiygleb8509]

@@klnlkjoinoin when you write it as a closure, you can compose them (with `compose` or `andThen`)

[@rentedunicorn]

where can I find the code shown here?

[@kevalan1042]

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?)

[@bishbashboshjt]

same reason that JSX is popular for React

[@leonk6950]

Just start using them, you'll understand.

[@RomanScherbatyuk]

scala is amazing, looking forward to create some cool project on scala and akka)

[@rxshiva]

i tried this example in 2.10.6 and 2.12 expression not supported, any idea in which Scala version this works.

[@mohance]

You should try using dotty version - dotty.epfl.ch/. Scala-2.13

[@Nicofisi]

Dotty is Scala 3.0 though

[@bjornkihlberg2103]

5:00 Lisp: "Hold my beer"

[@mrdarky3377]

Björn Kihlberg yes! hahaha

[@DenisG631]

Is grammar an indication of complexity? Does it make Haskell simpler than java8? I thought CLOS is a Common Lips Object System or is Martin referring to smth else? `Possibly[Configured[T]]` definition is awesome though

[@jaspereijkenboom4716]

Size of grammar is NOT an indication of complexity, that is precisely his point. He asks "People percieve Scala as being complex. Why do they percieve Scala this way?", he then shows the size of grammar to show that the two are not correlated. Afterwards he makes his real argument: Culture Shock.

[@DenisG631]

@@jaspereijkenboom4716 But people claim Scala being complex, not due to its grammar though. This is exactly my point. When people say language X is more complex than language Y they don't mean complexity(grammar(X)) > complexity(grammar(Y)), because that would imply that Java is more complicated than Haskell (or so it seems, again we are not talking about academic terms, but general developer perception of the langauge). Well, we can talk for hours about what exactly is - complicated. What is its definition. Is it complexity or unfamiliarity. Yet again, the point made was that Scalas' complexity is attributed not due to its simple/complicated grammar, therefore I don't buy that argument.

[@sobanya_228]

But can you do effects with continuations right now in dotty?

[@lucduponcheel]

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!

[@alex1476]

Great talk! Looking forward for Dotty compiler to be used in production.

[@TheddunTOSS]

What is the best introduction to Scala?

[@gamespazm]

It was too repetitive to write implicit config: Config, so instead let's write Possibly[Configured... everywhere!

[@yevgennerush2793]

When a function has dependency on M parameters, it is better to write ImplicitFunctionType[T] N times than writing M parameters N times, because 1*N is always less than M*N, where M > 1.

[@kevalan1042]

To replace the implicit config: Config, you just need to write Configured. In addition, Possibly makes the possibility of exceptions explicit in the types.

[@jakemiles999]

Strange right? That we replaced three words per method for three other words per method. But the new three words do notably more than the original three words. One is that they remove the side effect of the thrown exception, putting the possibility of failure in the type and therefore not a surprise at runtime. Another is that because the effects are now represented by a type, you can create a type alias for the composite type to make it less verbose, which you couldn't do if you needed to add other implicit parameters to handle other effects. For example, if `Possibly[Configured[Name]]` is too verbose, you can create a local alias `type PC[T] = Possibly[Configured[T]]`, and then the methods return things like `PC[Age]` and `PC[Name]` - less to type and less to read with the same benefits. And that scales to as complex a set of effects as you need: if you need to, for example, read config asynchronously from a remote service, the returned type could become something like `Possibly[Async[Config[Name]]]`. And with a type alias, `type PAC[T] = Possibly[Async[Configured[T]`, the returned types become `PAC[Age]` and `PAC[Name]`. So it scales with complexity much more efficiently in terms of the verbosity of the method signatures.

[@kevalan1042]

Which editor is he using?

[@lorenzotesta9136]

visual studio code

[@kevalan1042]

thanks!

[@TheMrTape]

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.

[@JMFAudio]

TheMrTape oh man so true. Recommend times 1000

[@timmark4190]

Agree. So how does one get the right experience or training.

[@demonkoryu]

There can be managers who aren't technical experts who still do a great job - maybe a better job than a SE type manager - because they listen to their expert; and then they have the management acumen...

[@TheMrTape]

Tim, By exploring by yourself and by learning to become your own teacher. Any programmer of just slightly versatile expertise must constantly or at least often consult manuals and documentation of languages, libraries etc. Firstly nobody can remember complex function arguments etc. when they don't regularly use them, and secondly there's constantly new challenges where you need to learn; you can only learn and completely remember a relatively tiny bit of the whole programming spectrum in a lifetime with all libraries, API's etc. considered, so can only take expertise in so much. Get the grammar (syntax) of some language right, then the rest is just looking up definitions (documentation) of the words (functions) you need, when you need them. Use Google like a maniac. Besides just looking up documentation, I can recommend this guy, great teacher and mentor, who pushes teaching yourself: TheChernoProject demon, I agree but it's the minority of cases; managers can definitely be very beneficial if everybody truly knows whats up, but it's often their lack of or understanding that makes them push decisions that aren't beneficial. With loose guidance and by giving freedom to the programmer it can work, just asking them to accomplish some task in whatever way they see best fit.

[@Gashdal]

self taught passionate programmers represent!

[@nicholasking2267]

"Here, on page 362, they finally get around to proving that 1+1=2."

[@jordanzimmerman7590]

Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.

[@matthewdedetrich6867]

How is this anymore complicated when comparative tools in Java (i.e. Spring) do all of the same work, its just at runtime where as in Scala its at compile time? What do you think stuff like @Autowired does? Its pretty much magic that is all hidden behind runtime reflection

[@jordanzimmerman7590]

If that's all it was it would be fine. With tools such as Spring/Guice, the injections are usually pretty clear (but not always). With implicits, you have to import them and the order of imports can change which implicits are used. Then, you can have chains of implicits and on and on. It's much much more complicated.

[@jordanzimmerman7590]

I can tell you it happened to me the other day. Spray JSON uses chained implicits. I put an import statement in the class that was using the JsonFormat instance and I got an unintelligible error message. I moved it to the top of the class and it compiles. Also, I'm not defending Guice/Spring. IoC frameworks in Java introduce more problems than they solve.

[@Olololsh]

I've been shot in my leg when i got a completely unreadable error when someone used implicit parameter in implicit function definition. So I'm in agree with Jordan, implicit could be good, but without a certain amount of experience and attitude to smell bullshit - they are completely complexity makers.

[@gmnboss]

Kleisli is plain??!

[@spesterwecial]

Kofi A No, he does not claim that. On the contrary his argument in the talk is that Kleisli (and by extrapolation monad) is a more complicated abstraction than necessary for the use case of configuration. It violated the “principle of least power”, so he proposes a “plainer” (typed) functional solution which, although it might not yet be familiar, does not require arcane knowledge of category theory.

[@ajinkyax]

@5:00 why not compare with GoLang , it has type system. Can be written in Functional fusion

[@mskiptr]

Purely functional programming removes a whole dimension of complexity. It _removes time_ (you can kinda import it back)

[@TonyBenBrahim]

I wrote a JavaScript interpreter in OCAML a few years ago, and I gave up on this video 15 minutes in. Functional programming is not hard, but I get the impression Scala is hard, if Martin had anything to do with the documentation.....

[@philippederome2434]

Possibly give it a chance later on. I think he could have spent 3-4 minutes more around 24-27", go more slowly about the details of exception handling. Ideally, this talk could last 50-100% more than it did to be approachable to a wide audience.

[@obszczymucha1337]

I agree. Scala is way overcomplicated. Even Odersky gets confused. 12:38

[@leftover7766]

@@obszczymucha1337 How are you at giving talks in your third or fourth language? Scala is complicated enough to be able to use math to the greatest extent when solving programming problems. Not using math (mostly because shortcuts taken in setting up the language/environment that the problem is solved in) is the source of all bugs in s completed, shipped program.

[@vetiarvind]

This is silly. Kleisli is part of other FP libraries like cats or scalaz. It's not part of core Scala.

[@clarkie132]

I hate to say this and I hope it isn't misconstrued but I personally think that Martin himself is one of the things that makes Scala seem hard. He is obviously brilliant but I found his functional programming course very intimidating, even though it was very rewarding.

[@BulentBasaran]

clarkie132 I think there is some truth to that. First, my experience is that Martin is an outstanding teacher. He is very demanding and explains concepts very clearly. For relative beginners (to FP let alone imperative languages) his delivery is likely to be too fast. Give yourself some time to absorb and code to get a better feel. It will pay large dividends soon enough.

[@kevalan1042]

Really? Funny how the perception of such things can be different from person to person. I personally think Martin is among the few who can make Scala feel easy! :)

[@MercedeX7]

student : i want to learn scala ☺️ Martin : to understand a program part you need no longer account for the possible histories of executions that can lead to that program part. student : 😨

[@darkesto]

@@MercedeX7 it is as simple as it is

[@tieskedh]

I think the implicit things are the things that make Scala hard

[@scarface548]

what does " transform a type name into a value" mean?

[@tieskedh]

I think that in most of the cases the things that make languages powerful are also the things that are the hardest... This doesn't mean that it should be left out! It just means that the learning curve is higher. Ps. I mean everything which is implicit, so also the implicit casting

[@leccio]

Yes, too much magic!

[@lucduponcheel]

there is this difference between "easy vs difficult" and "simple vs complex" ... computers can manage complexity ; computers have a hard time with difficulty ... human beings can (hopefully) manage difficulty ; human beings have a hard time with complexity ... as Martin pointed out, one of the main challenges of software engineering is managing complexity (some things are so complex that they *appear* to be difficult) ... well: implicits are a (at first sight, maybe) difficult feature that contributes to managing complexity ... once you understand their power you can start appreciating the simplicity that is implied by them.

[@obszczymucha1337]

@@alexelcu You sound like a fanboi. Implicits make code less readable and hard to understand and reason about. There are hidden things everywhere. That's not simplicity, that's overcomplication.

[@vladpetric7493]

Having a smaller grammar doesn't make a language readable, see LISP for instance. The biggest problem is readability, and Haskell suffers greatly from it. But yeah, one can always cherry-pick the metric that fits their ideological world view.

[@MercedeX7]

blah blah blah and nothing useful or meaningful that's the simplicity he is talking about!

[@saprahan]

Totaly agree. Too bad, now Odersky became a typical business man. Long time ago his lectures were much better