Saturday, February 13, 2021
The focus of the talk is to emphasize the importance of algebraic thinking when designing pure functional domain models. The talk begins with the definition of an algebra as consisting of a carrier type, a set of operations/functions and a set of laws on those operations. Using examples from the standard library, the talk shows how thinking of abstractions in terms of its algebra is more intuitive than discussing its operational semantics. The talk also discusses the virtues of parametricity and compositionality in designing proper algebras. Algebras are compositional and help build larger algebras out of smaller ones. We start with base level types available in standard libraries and compose larger programs out of them. We take a real life use case for a domain model and illustrate how we can define the entire model using the power of algebraic composition of the various types. We talk about how to model side-effects as pure abstractions using algebraic effects. At no point we will talk about implementations. At the end of the talk we will have a working model built completely out of the underlying algebra of the domain language.
Recursion schemes are a topic that often come up in conversations with experienced, knowledgeable developers. For the longest time, I’d just nod and smile and pretend I knew what was going on.
The purpose of this talk is to help people in the same situation. Recursion schemes are far less scary and confusing than the mystique that surrounds them suggests, and this talk attempts to prove it.
We’ll start from first principles and refactor our way to proper recursion schemes, discovering and explaining all the necessary concepts as we go along.
By the end of the talk, attendants should have all the tools they need to understand recursion schemes, and be able to explore the more esoteric ones on their own.
Scala 3 is just around the corner. Both EPFL and the broader community have put a lot of work into making this Scala release a success. In this talk, I will outline some of the history behind Scala 3 and what steps we took in the Typelevel ecosystem to get ready for Scala 3, and keep up with its development.
The CLI of coursier, cs, offers a convenient way to install both JVMs and Scala applications. cs itself is a native binary with no dependencies, is available on all major platforms, and can get you started with installing and running Scala tools in minutes. It can be useful to setup your local development environment, but also from scripts, or on your CI.
Until now, the first concern of cs has been ease-of-use. But what about reproducibility? cs rests on the core of coursier, and reproducibility / “purity” has always been a central concern in the core modules of coursier. Could this help recovering reproducibility in the higher level features of the coursier CLI?
In this talk, we are going to first showcase what cs, the coursier CLI, can do, and how it can be useful on your local machine, from scripts, and on your CI. Then we’ll discuss how we can make invocations of cs reproducible and what newer options are available to help for that.
Don’t ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we’re at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That’s exactly what property-based testing has to offer. I’ll show how to get started with this kind of testing in Scala, using using ScalaTest and ScalaCheck. But isn’t it all too good to be true, surely there’s some fine print? Of course there is. I’ll cover that as well.
Curious to know how good your tests are? There’s an easy way to find out: use mutation testing!
Most of us use code coverage to measure how effective our tests are. But what does code coverage really mean? How many times have you seen a test with a missing assertion or even assertions in comments? This is where mutation testing will help you. A mutation testing framework inserts small bugs into your code, hoping that your tests can spot them.
In this talk, you will learn the basics of mutation testing, and how you can use it in your Scala projects with Stryker4s, the mutation testing framework for Scala.
Scala is a hybrid OOP+FP language. If you love OOP, Scala is one of the best static OOP languages. But Scala also exposes parametric polymorphism and can encode type classes.
Thus, developers can also choose to use parametric polymorphism restricted by type classes (aka ad hoc polymorphism). As if choosing when to use immutability versus object identity wasn't bad enough, developers are also faced with a difficult choice when expressing abstractions. Such choices create tension in teams, with the code style depending on the team leader or whoever does the code reviews.
Let's go through what is OOP, what is ad hoc polymorphism via type classes, how to design type classes, go through the pros and cons, and establish guidelines for what to pick, depending on the use case.
At Inpher, we have built a domain specific language (DSL) for modelling privacy preserving computations. This DSL is targeted at cryptographers who are not necessarily familiar with Scala at all, yet it is written entirely in Scala 3! In this talk, I will present some of Scala 3's new features that were used to make the DSL powerful while keeping it very user friendly. I will share some experiences we've had as early adopters of Dotty, as well as some lessons learned while introducing the DSL to complete newcomers of the language.
With Scala 3 right around the corner, now is the perfect time to discover exciting new features, that will simplify or reinvent how we write Scala applications. In this talk I will give you a taste of the future. I will be live-coding to compare how certain problems were solved using Scala 2 and what Scala 3 brings to the table.
Scala is a cool language running on JVM and constantly changing. The same applies to JVM, which is running under the hood. What a Scala developer should know about changes in JVM? In this talk we’ll cover the major JVM changes and scratch updates to Java language.
For almost four years now I work professionally on the Android client of an end-to-end encrypted messenger, in Scala. In Android we deal a lot with events coming from many sources: the user, the backend, the Android OS itself… The code we write has to be very reactive - and it should also be concise and able to process all those events concurrently to squeeze all we can from limited resources. Scala should thrive under those conditions. And yet, it’s almost non-existent. People who still write it are forced to use old versions of libraries, on top of an old version of the language itself, to modify Gradle scripts, and basically to jump through countless loopholes which shouldn’t exist. Most of those people already either moved to other market niches… or to other programming languages.
In this talk, I want to outline how we ended up in this weird position. What attempts were made in the past to introduce Scala on Android, and how they failed. What hacks and concessions are needed in the present to still be able to write Scala on Android. But also I want to tell you about recent developments that give me a reason to believe that the future might be better. It will require a lot of effort, though, and so I want to inspire you to help me.
On the practical side, during this talk, you will learn how to build your own Android apps in Scala - in both versions: using the current (outdated) framework, and the new (experimental) one.
MUnit is a testing library for Scala built. “Another one?!”, you may say? In this talk we’ll explore together the most notable features of MUnit and see what makes this little library unique! Via a series of live code examples, we’ll answers questions like: - Why does MUnit not have a DSL? - How do we integrate MUnit with other libraries? - How can MUnit help dealing with flaky tests?
At the end the presentation, MUnit may become your new favorite testing library!
Implicits are one of Scala's most powerful features. This single mechanism can be used in various idiomatic ways to implement a number of capabilities, like implicit conversions. One of the biggest changes in Scala 3 is a reworking of implicits to introduce new constructs that make the capabilities more intuitive, with less emphasis on a single mechanism.
The new constructs include extension methods, a new way to write type classes, given instances with using clauses, given imports, and new implicit conversions. I'll discuss how to use them, how they contrast with Scala 2 idioms, and how Scala will gradually transition to them, supporting both implicits alongside the new features for a while.
Most people don't go into work excited to update their old code to slightly newer versions of APIs and figuring out what's replaced this. This is complicated in Spark where the new version of Spark will be dropping support for older language releases. This talk will explore how we can use tools to semi-automatically upgrade our Scala & Python Spark. We'll compare and contrast how the tooling & language differences between Scala and Python impact these tools.
Let’s face it: if you want to quickly hack a script for use by somebody else, Scala is rarely the first choice. Unlike Bash and Python, the essential dependencies (Java Virtual Machine, Ammonite) are usually missing on the target operating systems. This leaves you with a dilemma: should you instruct your users to install the missing bits or should you ship something, that they’ll run instantly (Bash, Python)? I think this is one of the reasons, why most of the common helper scripts is not being written in Scala. That is a shame. TSK - The Scripting Kit (https://github.com/tsk-tsk/tsk-tsk) aims to change that. With TSK you can create a Scala script that is instantly self-installable-and-executable after you save it and set the executable bit. You achieve that by prepending your Scala code with a special preamble, which consists of shell commands disguised as a Scala comment. You end up with something that works on multiple systems from the get-go and is nicely editable with IDEs at the same time. A scripting nirvana!