azder

//--
//-- FUNCTORS in ES6
//--


//-- BOILER PLATE

let fmap = (f) => (functor) => functor.map(f);
let c2   = (f2, f1) => (x) => f2(f1(x));
let c3   = (f3, f2, f1) => (x) => f3(f2(f1(x)));

azder

{
  // http://eslint.org/docs/rules/

  "ecmaFeatures": {
    "binaryLiterals": false,                    // enable binary literals
    "blockBindings": false,                     // enable let and const (aka block bindings)
    "defaultParams": false,                     // enable default function parameters
    "forOf": false,                             // enable for-of loops
    "generators": false,                        // enable generators
    "objectLiteralComputedProperties": false,   // enable computed object literal property names

azder

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

azder

function Foo(who) {
	this.me = who;
}

Foo.prototype.identify = function() {
	return "I am " + this.me;
};

function Bar(who) {
	Foo.call(this,"Bar:" + who);

azder

#include <assert.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

enum type {
    NIL,

azder

// `unit` is `return` from Haskell
// `bind` is `>>=` from Haskell, or `flatMap` from Scala

var None = {
  bind:      function (fn)        { return this;      },
  unit:      function (v)         { return Option(v); },
  getOrElse: function (elseValue) { return elseValue; }
};

var Some = function (value) {

azder

<?php
class PartialCallable {
    function __construct($callable, $args) {
        $this->callable = $callable;
        $this->args = $args;
    }
    
    function __invoke() {
        call_user_func_array($this->callable, array_merge($this->args, func_get_args()));
    }

azder

function toArray(args) {
  return [].slice.call(args);
}

function autocurry(fn) {
  var len = fn.length;
  var args = [];
  return function next() {
    args = args.concat(toArray(arguments));
    return (args.length >= len) ? 

azder

#!/bin/bash
# Copy file or pipe to Xorg clipboard

# Required program(s)
req_progs=(xclip)
for p in ${req_progs[@]}; do
  hash "$p" 2>&- || \
  { echo >&2 " Required program \"$p\" not installed."; exit 1; }
done

azder

ganked from unreadable scribd doc here: http://cleancoder.posterous.com/what-killed-waterfall-could-kill-agile

What Killed Waterfall could Kill Agile.

Robert C. Martin
20 Nov, 2010

In 1970 a software engineer named Dr. Winston W. Royce wrote a seminal paper entitled Managing the Development of Large Software Systems. This paper described the software process that Royce felt was appropriate for large-scale systems. As a designer for the Aerospace industry, he was uniquely qualified.

He began the paper by setting up a straw-man process to knock down. He described this naïve process as “grandiose”. He depicted it with a simple diagram on an early page of his paper. Then the paper methodically tears this “grandiose” process apart. In the end, Royce proposed a far more nuanced and insightful approach, leaving the reader to giggle at the silliness of the “grandiose” model.