cb372

TL;DR

We should use a type parameter with a context bound (e.g. F[_]: Sync) in library code so users can choose their IO monad, but we should use a concrete IO monad in application code.

Abstracting over IO

If you're writing a library that makes use of effects, it makes sense to use the cats-effect type classes so users can choose their IO monad (IO, ZIO, Monix Task, etc).

So instead of

vil1

This is a witch hunt.

When you exclude a relentless innovator from a conference, when this exclusion results in excluding the young woman from North-Africa who was supposed to share the stage with him, it has nothing to do with promoting innovation and inclusivity. It is a witch hunt.

When you bar someone from contributing to a FLOSS project based on alleged aggressive communication without providing any concrete example of the said behavior nor explaining what you did to make this behavior stop before taking such extreme decision, it has nothing to do with making your community a better place. It is a witch hunt.

Witch hunts are bad. Not because they burn people with no fair trial and that some of the burnt people may not have been witches in the first place.

Witch hunts are bad because they burn people. Period.

nrinaudo

Introduction

I was recently asked to explain why I felt disappointed by Haskell, as a language. And, well. Crucified for crucified, I might as well criticise Haskell publicly.

First though, I need to make it explicit that I claim no particular skill with the language - I will in fact vehemently (and convincingly!) argue that I'm a terrible Haskell programmer. And what I'm about to explain is not meant as The Truth, but my current understanding, potentially flawed, incomplete, or flat out incorrect. I welcome any attempt at proving me wrong, because when I dislike something that so many clever people worship, it's usually because I missed an important detail.

Another important point is that this is not meant to convey the idea that Haskell is a bad language. I do feel, however, that the vocal, and sometimes aggressive, reverence in which it's held might lead people to have unreasonable expectations. It certainly was my case, and the reason I'm writing this.

Type classes

I love the concept of type class

vegard

# -*- coding: utf-8 -*-
#
# Author: Vegard Nossum <vegard.nossum@gmail.com>

import math
import os
import sys

import cairo

johnhw

### JHW 2018
import numpy as np
import umap



# This code from the excellent module at:
# https://stackoverflow.com/questions/4643647/fast-prime-factorization-module
    
import random

HeartSaVioR

/////////////////////////////////////////////////////////////////////////////////////////////
// 1. select with swapping columns, and apply where
/////////////////////////////////////////////////////////////////////////////////////////////
import spark.implicits._

import org.apache.spark.sql.{DataFrame, Dataset}

case class Hello(id: Int, name1: String, name2: String)

val ds = List(Hello(1, "Alice", "Bob"), Hello(2, "Bob", "Alice")).toDS

benjamineskola

-- run first thing in the morning, e.g., from cron

tell application "Things3"
  set theToken to "your-auth-token"
  
  set theTodos to to dos of list "Today"
  repeat with aTodo in theTodos
    set tagList to tags of aTodo
    repeat with aTag in tagList
      if (name of aTag as text) is "Evening"

djspiewak

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

yukoff

Project documentation

The project documentation (stored in the docs directory) is a git subtree of the project wiki. This allows for the documentation to be referenced and edited from within the main project.

Initial local setup

When cloning the main project repository for the first time, the wiki repository must be added as a remote.

git remote add wiki https://github.com//.wiki.git

olafurpg

import sbt._, Keys._
import scala.xml.{Node => XmlNode, NodeSeq => XmlNodeSeq, _}
import scala.xml.transform.{RewriteRule, RuleTransformer}
import sbt.plugins.JvmPlugin

object PPrintPlugin extends AutoPlugin {
  override def requires = JvmPlugin
  override def trigger: PluginTrigger = AllRequirements
  override def projectSettings: Seq[Def.Setting[_]] = List(
    libraryDependencies ++= {