Skip to content

Instantly share code, notes, and snippets.


Ivan Doroshenko ploddi

View GitHub Profile
melvic-ybanez /
Last active Feb 17, 2021
What I Didn't Know about Functional Programming until 2020

What I Didn't Know about Functional Programming until 2020

  1. Programming using a series of transformations and aggregations, something I've been doing for years, is known as programming in the map/reduce style.
  2. The more abstract the type is, the greater its cardinality, and the smaller the set of operations it supports. So make use of universal quantifiers, particularly by implementing fully parametric functions. They guide you on how to implement their term-level definitions by narrowing down the number of possible implementations. In other words, the type system of Scala (or Haskell, for that matter) is not only great for capturing compile-time errors, but is also capable of leading you to the correct solution.
  3. You can encode union types by combining different Scala features such as type constructors, subtyping and implicits, and by taking advantage of the Curry-Howard Isomorphism and De Morgan's Laws for neg

Uniting the bifunctor and monofunctor hierarchies

With the rise of so-called bifunctor IO types, such as ZIO, questions have naturally arisen of how one could leverage the cats-effect type classes to make use of this new power. So far suggestions have mostly focused on duplicating the existing hierarchy into two distinct branches, one parameterized over F[_] and another parameterized over F[_, _]. To me this is not a great situation, as now library maintainers would have to write code for both of these hierarchies or choose one and leave the other one in the dust.

Instead we should find a way to unite the two shapes under a single hierarchy. This is a draft on how to enable this unification using polymorphic function types in Dotty.

fanf / TestSocket.scala
Last active Jun 19, 2019
Example of an async socket handling multiple connection in ZIO + nio
View TestSocket.scala
import scalaz.nio._
import scalaz.nio.channels.{AsynchronousServerSocketChannel, AsynchronousSocketChannel}
import scalaz.zio.console._
import scalaz.zio._
object TestSocket extends App {
override def run(args: List[String]): ZIO[Environment, Nothing, Int] = {
Odomontois / callByName.scala
Last active Oct 18, 2018
Поправь так, чтобы работало
View callByName.scala
def fix[A](f: A => A): A = f(fix(f))
val fib = fix[Int => Int]( recur => n =>
if (n <= 1) 1
else recur(n - 1) + recur(n - 2))
View gist:5ae1d6b544d65fb8190534e8c13b8de7

Provisional benchmarks of AST-free serialization puts my WIP branch of uPickle about ~40% faster than circe on my current set of ad-hoc benchmarks, if the encoders/decoders are cached (bigger numbers is better)

playJson Read 2761067
playJson Write 3412630
circe Read 6005895
circe Write 5205007
upickleDefault Read 4543628
upickleDefault Write 3814459
upickleLegacy Read 8393416

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea


Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

  1. CPU-bound
  2. Blocking IO
  3. Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.


Uninstall brew package and dependencies

Remove package's dependencies (does not remove package):

brew deps [FORMULA] | xargs brew remove --ignore-dependencies

Remove package:


Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](