Juan Manuel Gimeno jmgimeno

Effective Scala Case Class Patterns

Version: 2022.03.02

Available As

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

accountsd using 400% CPU on MacOS Catalina 10.15.7 (19H2)

TL;DR: Still open - see below.

This morning I woke up to some not-so-nice surprise - my 2018 MPB 13" would be kind of totally unusable. The accountsd process was stable at 400%, battery was going like ice-cream in the Sahara, and opening up LibreOffice was like a major achievement.

I did check the logs (that were growing at like 500 lines per second) and I saw a lot of lines at FAULT level:

fault 07:54:04.271342+0200 accountsd Unentitled access by client 'CallHistoryPlugi' (selector: accountsWithAccountType:handler:)

See this now-deleted thread (where Baez starts a long analogy with "Not just people, but also mathematical objects, can be oppressed!") and this tweet for context.

The responses quoted here have been described as "Thought Stasi" bullying (etc.), but in my reading most are respectful, very few are even confrontational, and only a couple are impolite.

This list is the result of a quick search and I may have missed relevant replies to the original thread, but if there are omiss

Some thoughts on building software

Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.

Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite

	runner.dialect = scala3
	runner.dialectOverride.allowSignificantIndentation = false
	# allows `if x then y`
	runner.dialectOverride.allowQuietSyntax = true

	import zio._

	case class Doc(
	title: String,
	description: String,
	language: String,
	format: String,
	content: Array[Byte]
	)

	package tttt

	// Awesome 😄 That looks great. It maintains all of the properties of the Frank (or, Langton style 😛) encoding—where one can recurse with different handlers and short-circuit trivially—without losing the tail-recursive stack safety. And I fully trust you when it comes to the JIT-ability of it all!
	// The only issues are minor UX ones, in that it could be confusing for the user to know whether to call

	import izumi.reflect.Tag

	type Id[T] = T
	type Const[T] = [U] =>> T
	type MX[T] = Any

	package eo

	import cats.{Applicative, Bifunctor, Functor, Traverse}
	import cats.arrow._
	import cats.implicits._

	trait Accessor[F[_, _]] {
	def get[A]: [X] => F[X, A] => A
	}

	-- Many faces of isOrderedTree
	-- Code to the talk (extended version)

	{-# LANGUAGE DeriveFoldable #-}
	module Tree where

	import Control.Monad
	import Data.Maybe
	import Data.Foldable