Image credit lambdadays.org
"Lambda Days 2018 was the best conference I've been to so far - and I've been to many... For sure my evaluation is skewed by my interest in functional programming. If you share that interest though (at least slightly) - this is a must-attend event!
Below are some reflections it triggered and a summary of the talks I attended, that I hope will interest you in at least one or two of them :) If it will, the videos from the talks have already started appearing!
Overview and reflections
Not only the community, but its tools (both high and low level) are flourishing too!
Haskell, Scala, PureScript, Idris, Luna - all of them incorporate ideas from the academia and inspire each other, striving for principled, composable and dependable software. Haskell is pushing the frontiers of leveraging type systems in helping the developers express (and prove in compile-time!) ever more advanced properties of their programs. Scala follows closely, being inspired by Haskell, but also Idris and its unthinkable (runtime-value-) dependent types. PureScript brings row-polymorphism to the table - and Luna (made in Poland!) takes it all and uses it in a very creative manner to provide a functional language with a promising visual representation!
The talks - day 1
Here's a short summary of the talks I've been to, in order of their importance (as perceived by me :)). For now, just the talks from Day 1, stay tuned for the summary of Day 2!
Categories for the Working Hacker - Philip Wadler
The father of Haskell and Monads in FP himself has shone upon us the light of category theory and its Ways of Thought! Jokes aside, the talk offered an introduction into an unfamiliar-to-most domain of CT from which the FP community draws lots and lots of inspiration ever since Wadler's "Monads for functional programming" paper.
Both the intro and the CT itself are valuable, because they offer a *very* sharp and disciplined tool for defining lawful abstractions so refined, that they're hard to spot in the first place - despite having examples *everywhere*. The laws, in turn, are important, because they tell us what properties the abstracted-over objects have, and how the abstraction composes.
Check out the video and see for yourself how, by having such abstractions, one can derive additional laws for the abstracted-over objects and benefit from them :)
Apart from a CT intro, on its grounds, Philip also made vital points on programming in general.
[When asked about expressing OO in terms of CT]:
What is the nice categorical interpretation of object oriented programming?
No one knows...
Maybe there *isn't* one...
What is the lesson I derive from this?
Object-oriented programming is very well named. When somebody tells they want to use object-oriented programming, they're telling you what you should do: OBJECT!
Philip Wadler on object-oriented programming
These 10000 classes I never wrote - Valentin Kasas
A really painless and straightforward introduction to generalized recursion schemes as discussed in the famous "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991)" paper. The talk explains the scary "hylomorphism" word and shows how the idea behind the word is useful for elegant handling of nested (recursive) data structures. The example used is creation of a generic data pipeline spanning 10000 tables (~100 schemas * ~100 tables each). The results were impressive: converting between any two of the formats that need to be supported, validations, all expressed in a clean, composable and generic manner.
One particularly nice property of the hylomorphism is that it allows composing various transformations of recursive structures in such a way, that the intermediate trees never exist for the whole input structure at once - the only things using your program's memory are: the input tree, the output tree, and the intermediary structures for the currently processed node.
Slides are here, and the Scala library used for recursion schemes in the talk is matryoshka.
We're Building On Hollowed Foundations: Worrying Trends in Open Source and What You Can Actually Do About It - Heather Miller
Crucial points were made on the state of FOSS and on its potential collapse if the industry doesn't find good ways of contributing back to it. Long story short, the amount and use of FLOSS rose an order of magnitude in the recent years, without a noticeable change in the amount of contributors involved. This strongly suggests the current pace might be hard to maintain - unless we apply countermeasures.
Heather discussed various models companies can and should employ, like subsidies, patronage and OS-based products & services. She pointed out our role as developers, which is raising the awareness of our peers and management and pushing our companies to contribute back - be it by donations or more direct ways, like devoting developer time.
A very inspiring part was on the success story of Open Source Sprees in Scala community. Those are short hackathons helping to grow the community by guiding the participants while they're doing their first contributions. The goal is to get as many participants as possible get a small PR merged during the event.
Another promising phenomenon is the Tidelift company, trying to provide a previously unseen way of rewarding FLOSS development efforts. At least, that's what Heather could tell us before they go with a public announcement, which is to follow soon. I'm convinced that we should all keep an eye on what they come up with. Go check out their page for more info!
One thing I'd add in terms of what we - the developers - can do is: diligence in filing bug reports when we see bugs and striving to provide a reliable reproduction scenario / minimal failure example to the project's developers.
Overall, I find the talk an important point to be made for the industry and expect to see it given in other conferences.
Finite-state machines? Your compiler wants in! - Oskar Wickström
A comprehensive walkthrough of the industry's state of the art techniques for coping with state machines with aid from the compiler. Covers the ADT state encoding, MTL-style encoding with Associated Type, and the Indexed State Monad - along with their conventions and limitations. Then proceeds to a short teaser how dependent types in Idris might be useful for implementing a mission-critical state machine. The moral of the story is that state machines are hard to express in a type-safe manner, and our current type systems and compilers don't have too much to offer - unless you can use Idris in production, that is :)
Understanding Distributed Calculi in Haskell - Paweł Szulc
Paweł absolutely rocked the stage with his 300 slides in 45 mins, could-be-a-whole-day-workshop talk on the theory of distributed processes and its practical applications in real-word, opensource software. The talk was up to par with a university lecture in its detail and formality - just twice as fast and three times as entertaining while not sacrificing any understandability. We've got to know the Pi Calculus (a beautiful, yet somewhat too simple model of distributed computation) and had a glimpse of the Rho Calculus. The key takeaway for me though is that software can benefit from the latest achievements of CS academia and that making it happen is within reach of mere mortals :)
How to look like a statistician: a developer's guide to probabilistic programming - Evelina Gabasova
An interesting showcase of a novel approach to programming - probabilistic programming. On the example of a simple hypothesis about dev salary data from the recent StackOverflow survey, it shows how a statistician would approach the problem and how programming languages might someday help us programmers approach it that way too :) Definitely not a technique that all of us will get to use everyday - the more it's worth knowing, should the right problem pop up before us.
What, if anything, is a llama? - Jonas Winje
Amusing and entertaining insights on how an in-browser app for evaluating lambda calculus expressions was made using PureScript by a programmer just starting with it. Apart from slides in form of hilarious haikus on encountered compiler errors and language feautres (which TBH were in themselves a good enough reason for me to stay in the room :D) it offers a nice overview of PureScript development experience and a valuable insight on Boolean Blindness (TL;DR: say no to boolean return types, provide evidence of the boolean property instead).
The talks - day 2
Below is a summary of the talks I've been to during Day 2, in order of their importance (as perceived by me). Hope you'll find it useful and/or inspiring!
Freestyle, Free & Tagless: separation of concerns on steroids - Michał Płachta
A great, in-depth introduction to the Free Monad & Tagless approaches, given on a non-trivial example, with all boilerplate scraped using the Freestyle library! I find this talk one of the most important ones on the conference, and definitely the most important when it comes to application of the concepts (vs being aware-of and inspired-by them; with Valentin's generalised recursion schemes talk being a close second place).
*Everybody doing FP in Scala should watch this talk*. The Free/Tagless approach allows for inverting the dependencies in the program's modules in an extremely generic and powerful way - to the extent it's hard to imagine if you don't know those tricks! Because of that, it allows for better-decoupled and more focused (smaller!) modules and gives you a side-effect-decoupling strategy that scales with your program.
Not your usual dependency directions, possible thanks to Free / Tagless.
The blue rectangles are the *only ones* containing side effects! All grey are 100% unit-testable.
Source: Michał Płachta's slides for the talk
Maybe one thing I found missing from the talk is emphasising how this benefits the program's testability, maintainability, and flexibility. If you apply this approach, you have a guarantee that *EVERY* part of your program's logic is unit-testable! What about the side-effecting code, you'll ask? It's cleanly and reliably abstracted-away in your interpreters, allowing for *all* (sequential*) side-effects to be separated from program's logic and treated as infrastructure. And not just any infrastructure - it's overridable at will!
But how will you test this infrastructure? One thing is for sure: much easier than if it weren't separated from the logic ;) Sure, you need tests for that and you'll probably need to spin up a mock http server, an in-memory database instance or maybe even a docker container - but the tests won't need to fidget around additional fine-grained validations embedded in the logic of the program - it's just your test and the infrastructure.
Having the interpreters, you can be sure your program's logic doesn't depend on the concrete data store, external service, ways of accessing them - all of this is done in the interpreters! Because of this, having side-effect-free tests by exchanging the interpreters or reimplementing any of those aspects using the latest tools is just about for Free.
*parallel computations can't be expressed using just a (Free)Monad. See e.g. this talk by John De Goes
In Praise of Higher Order Functions - Mary Sheeran
As uninteresting as it may seem when judging from the title, the talk offers surprising insights into how the 'functional' way of thinking can help solving problems in domains seemingly unrelated or even distant from it - like FPGA and GPU hardware design. Full of references to CS papers from the last 60 years and rich in personal experience shared, it makes a great job in showing how FP continues to draw ideas from the academia and helps closing the gap between theory and practice. The talk is also very inspiring in its showing the views of the fathers of Computing (like John Backus and Kenneth E. Iverson - both Turing Award laureates) to be the foundations of the FP paradigm.
Idris for (im)practical Scala programmers - Marcin Rzeźnicki
A very nice introduction to type theory, focusing from midst the talk on dependent types and their applications. Provides examples in Idris and Scala (where possible), discusses what's possible in Scala, why certain things are not, and to what extent we can work around that. If you ever wondered how Shapeless works - this talk provides an intro to the techniques used in it.
How to teach programming and other things? - Felienne Hermans
My personal key takaway from this keynote is: quality can be taught - even to kids. And it *must* be, contrary to what the author seems to suggest starting from about midst of the talk. At least if the person taught is aspiring or has a chance to ever become a programming professional.
If you go to the dentist, it's not the case that they are free to choose ways of expressing themselves on your teeth, or picking whether washing hands and wearing gloves constrains their creative process. They do have a choice of methods to use in solving your health problem - but each of them is aimed at solving the problem and if they fulfill the solver's creative desires - it's only on the occasion.
Don't get me wrong! I'm totally fine with dentists doing ceramic sculptures of thought-provoking teeth - as long as it's after hours and they don't end up in someones mouth without consent or informed consciousness of consequences (which would require them to be another dentist, mind you).
Felienne gives valuable insights on how the learning process looks like and what affects it. The talk is based on a lot of her own research and cites other scientific sources on learning. In particular, it touches on 'phonics' vs 'whole language' approaches to teaching a (natural) language, how research shows the former is more effective, and how this finding appears transferable to programming language teaching.
Felliene mentions a phonics-like method for programming languages, where children would cover one programming language construct per lesson, without a context or a task to perform. Just the 'if' and everything one can do with it. Then the 'while'. And so on. Based on experiments performed in her courses, this gives better results than the "here's a loop, now go reverse a string" whole-language approach.
Another point worth remembering is that research shows no correlation between the fun children get when taught and the teaching's effectiveness. That might come in handy some time :)
Beauty and the beast Haskell on JVM - Jarek Ratajski
Jarek gave us a short introduction to Eta, and why it is (going to be) *the* Haskell for the JVM.
You might be aware of Frege (which is quite mature today) and then you might ask: in what ways will Eta be better? Well, Frege is - unfortunately - a subset of Haskell, reimplemented from scratch. Because of that, library reuse between Haskell and Frege is very limited (not to mention you're going to miss out on the latest and greatest compiler plugins, like the code inferencer mentioned below).
Eta, on the other hand, is essentially a backend for the Haskell compiler: it reuses current GHC code (forked, but still...) and transcribes Haskells intermediary language - STG - into JVM bytecode. This is a much more maintainable model, given the development pace and community size differences between Haskell and Frege/Eta. And the compiler plugins! The type system extensions!
Eta also consciously approaches the fact that Haskell code does calls to low level C libraries underneath, which might not be the most efficient way to check the time or print to console on the JVM. For that, Eta does rewrites (patches) for the Haskell libs, changing the system calls to Java library calls - a process that can very well be automated.
Unfortunately, Eta at this stage is far from production-readiness. In fact, Jarek described how he helped fix some tail-call optimisation bug resulting in a proper Fibonacci sequence code returning... the powers of two.
The bright side of the story is that Jarek got a lot of warm welcome and guidance from Eta's developers, to the point it allowed him to contribute a fix! Keep in mind he didn't even know Haskell beforehand (which is the language Eta's written in). How cool is that?
I keep my fingers crossed for the Eta project and have actually been considering helping out after Jarek's talk. Let's hope the community will continue being open and welcoming!
Visual-textual functional programming with Luna - Piotr Moczurad
If you haven't seen Luna so far - you have to catch up! Guys in Cracow are making by far the first visual language I've seen to have a potentially useful text representation - most likely because it's actually the other way around :)
Largely inspired in Haskell, Luna creatively expands on it by adding row polymorphism to the mix and simplifying the most common use cases. If you've seen Unreal Engine 4's blueprint dataflow language, you'll be excited to hear Luna provides a similar environment for a general-purpose language and use cases!
I'm not even sure which one I root for more - Eta or Luna. Both promise a new quality, albeit in different areas. Can't wait to see them grow!
Suggesting Valid Substitutions For Typed Holes - Matthías Páll Gissurarson
A great example how types can guide development and accelerate API learning, and a showcase of a useful tool amplifying that guidance. Long story short, with the compiler plugin discussed, you can put a hole (the underscore sign) into code and the compiler will answer with a list of expressions that would fit that hole given its inferred type. Think: IntelliSense on steroids, built into your Haskell compiler!
Rethinking compilers with live coding - Tomas Petricek
I wasn't able to attend the whole talk, but I've seen it's structured around the example of The Gamma, which is a tool interesting and useful enough to deserve a mention itself. It's basically a browser-embedded pivot table backed by a definition language with IntelliSense-like code completion. See for yourself!
The Gamma in action.
Lambda Days 2018 has been a great event; very inspiring and valuable to me personally. I'm definitely coming to the next editions!
I sincerely wish the event's organisers, the FP community and myself: twice as much attendees and speakers next year, with the same high ratio of somewhat hardcore topics touched by the talks and known by the attendees! :)
I hope you found at least one or two of the talks I related interesting and we'll have a chance to meet there next year!