Daniel Beskin's Blog

Despite rumors to the contrary, I am not actually a functional programmer.

Note: this is a "script" for a podcast that I recently recorded, as such it's more conversational and less technical than the usual content of this blog.

"What's the point of learning functional programming?"

I have a confession to make.

If you're in the rare intersection of people that use NixOS and custom keyboard layouts, this post is for you.

We seem to be living in the future.

This post is also available in video form: These are strange times we're living in.

Way back in December, in the spirit of the times (it seems that everyone was either solving Advent of Code or looking for a job), like an elephant in a china shop, I found myself solving a leetcode-style problem.

Given this class: case class User( id: UserId, email: Option[Email], address: Option[Address], posts: Option[List[Post]], lastLogin: Option[Timestamp]) What does Option on each of the fields actually means?

I've recently stumbled upon a post on Scala Contributors by Kit Langton describing how he managed to create the illusion of adding automatically derived (publicly visible) members to a companion of a class.

The Tip The Scala collections library defines an Iterator trait.

The Problem Imagine that you're building an app and somewhere in your code you write something like this: class DoFinanceStuff(cc: CreditCardService): def grabClientMoney(card: CardData) = val amount = // ... // ...

Welcome back to yet another episode of test purification.

This is not just clickbait, I really do mean that ANY form overloading in programming should be considered evil.

In the last part we saw how to make our code more declarative, and the tests more functional by introducing type parameters for the inner data flowing through our code.

In the last part we learned how to purify our tests using type parameters.

Here's a fun little trick to purify your tests.

Recently, I've been TA-ing on an introduction to functional programming course, using Haskell.