quelgar

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

sleepyfox

Why 3X is only half the story

Many people will have read one of Kent Beck's articles on 3X or eXplore-eXpand-eXtract or The Product Development Triathlon. Many people have taken to explaining Kent's work on their own sites, sometimes helping, sometimes not, sometimes even ranking higher on search engines than the original articles!

I have an unpayable debt owed to Kent, his work started me off on a journey of discovery that forever changed how I practice my craft. I count him as one of the handful of people who in this field have had the most effect on my professional career.

But even the best of us are blind to things that our position, our background, our experience and our culture either deprioritise, hide away or even make taboo. I'm going to argue that Kent isn't wrong per se, but rather his model is only half the story - perhaps

nomisRev

import arrow.core.*
import memeid.UUID

data class User(val email: String, val name: String) {
  companion object
}

data class ProcessedUser(val id: UUID, val email: String, val name: String) {
  companion object
}

raulraja

/* Coming up ~ April 2020 */

package test
import arrow.*

inline class TwitterHandle(val handle: String)  {
  companion object : Refined<String> {
    override val validate: String.() -> Map<String, Boolean> = {
      mapOf(
        "Should start with '@'" to startsWith("@"),

colomboe

// Porting of https://gist.github.com/jdegoes/dd66656382247dc5b7228fb0f2cb97c8

typealias UserID = String
data class UserProfile(val name: String)

// The database module:
interface DatabaseService {
    suspend fun dbLookup(id: UserID): UserProfile
    suspend fun dbUpdate(id: UserID, profile: UserProfile)
}

raulraja

package com.fortyseven.fptraining

import arrow.core.Either
import arrow.core.right
import arrow.effects.IO
import arrow.effects.extensions.io.fx.fx

data class Account(val balance: Int)
data class AccountEntity(val balance: Int)

cketti

If you are annoyed that "Sources for Android 26" are not yet available via SDK manager, this might be for you:

1. Collect source files

mkdir android-sdk-source-build
cd android-sdk-source-build

mkdir -p frameworks/base

gaplo917

//http://stackoverflow.com/questions/40398072/singleton-with-parameter-in-kotlin

class TasksLocalDataSource private constructor(context: Context) : TasksDataSource {

    private val mDbHelper: TasksDbHelper

    init {
        // You cannot pass null in kotlin unless you are using `context: Context?`
        // therefore, checking null is useless 
        // checkNotNull(context)

kbilsted

Moved to https://github.com/kbilsted/Functional-core-imperative-shell/blob/master/README.md

lawloretienne

Table Of Contents

• Data Structures
  • Linked Lists
  • Trees
    • Binary Trees
    • Binary Search Tree
    • Red-Black Tree
    • AVL Tree
• Tries