My team at Canal+ is building a new media asset management (MAM) platform. To put it simply, Mediahub, our platform, stores video files and information regarding these files: Technical information (how many audio channels does this video have? what’s the video’s resolution?) Editorial information (is it a movie? A show? A TV series episode? Who is speaking in the sequence? What about?) Legal information (when can we air this content?

The way we deal with failure in most OOP applications is itself a common source of unexpected behaviors. I believe exceptions and try/catch statements are overused. Most of the time, it isn’t obvious what a method might throw and when. Edge cases should be treated with the same amount of caution, if not more, than the rest of the code, yet they are rendered invisible by error-handling mechanisms that hide failures instead of highlighting them.

Last week I had the opportunity to attend and speak at Northeast Scala Symposium, this is the story of my experience. The symposium has been gathering Scala enthusiasts for ten years now, and while most of the attendees come from the east-coast of the U.S., it’s usual for European folks to join as well. It’s really three different conferences on three successive days. The first day of talks is the Typelevel Summit, followed by the proper NE Scala lineup, and a day of unconference.

Type classes are a very common pattern in Scala. My goal in this post is to demystify what they are, how they are useful, and how they are supposed to evolve in the next big iteration of Scala, currently known as Dotty. Why do we need type classes ? Type classes are a programming technique that allows you to define common behavior for multiple types. Type classes act as a kind of interface, providing a common way of interacting with multiple types, while each of those type have different concrete implementation for this interface.

Let me get this out of the way: side effects are evil. Our job as developers is to build abstractions that solve problems. We build independent, confined little worlds of abstractions that we can control, understand and predict. But at the end of the day, for most jobs, we need some connection to the chaos of the outside world. That’s where the trouble comes in. Side effects, being this necessary connection to the outside world, are unreliable, hard to test and sometimes hacky.

As powerful and appealing a tool is, it’s always better to know a little about the cost of using it before doing so. Recursion is no exception. Depending on the programming language you’re using and the problem you’re trying to solve, recursion might not be most efficient way to go. I’ll try to explain why in this article. We will cover tail call elimination, memoized functions, as well as an example of inefficcient recursive function.

Recursion is an essential part of the functional programming tool set. It allows breaking down complex problems into a possibly indeterminate number of subproblems. It is often used as a functional alternative to loops in the imperative world, because it allows, among many other things, to loop over elements of a data structure, while preserving the immutability of your state. This post is the first one of two posts about recursion.