Gjorgji Kjosev spion

We have

function blah(done) {
  doSomething(function(err, data) {
    if (err) return done(err);
    var x = JSON.parse(data);
    doOtherThings();
    done(null, x);
  });
}

Real domains post mortem.

In the beginning there were callbacks.

But JS also had exceptions.

The combination of both was not working becuase catch only caught sync stuff.

try {

There are 3 levels on this abstraction ladder:

"Normal" non-generic code, the kind that a regular programmer often encounters
General code that uses typeclasses, which unlike in typical languages don't necessarily map to any single concrete functionality in non-generic code. (Will call this the Haskell cloud) *
Category theory constructs, which don't necessarily map to any concrete code or whatever (just pure objects, arrows and laws that could map to anything that fits, but aren't directly connected to anything concrete). (Will call this the category theory cloud)

(*) by unlike typical languages, I mean that those at least have abstractions that isolate a concrete thing you can do to their implementation, e.g. "iterable"

By giving me the name "monoid" and mentioning category theory, you give me a coordinate that is too high in the abstraction ladder, in the category theory cloud. This is great if you can normally comfortably climb up and down the cloud in that area, and if you've already develo

Immediately convert validation errors to Result<T>, as soon as possible. Result<T> would be the sync version of promises, with chain having a similar role to then, and .orElse having a similar role to .catch.

Assuming even crop was converted to not throw an exception but return a Result<T>:

var Transforms = {};

class ImageCropper() {
  constructor(range) {

Lets have an imaginary node core function that throws on invalid input:

function crop(image, x1, y1, x2, y2) {
  // throws if x1, y1, x2, y2 out of range for the image.
}

We wrote the following classes using this function:

Second example at

https://www.joyent.com/developers/node/design/errors

in the section "(Not) handling programmer errors"

A database (or other) connection may be leaked, reducing the number of future requests you can handle in parallel. This can get so bad that you're left with just a few connections, and you end up handling requests in series instead of concurrently.

Ok, so I have code that opens a connection, runs a query, then processes the results.

	info: >
	npm-scripts-info

	build_all: >
	npm-run-all build_es6 build_amd build_cjs build_global generate_packages

	build_amd: >
	npm-run-all clean_dist_amd copy_src_amd compile_dist_amd

	build_cjs: >

	{
	"type": "ArrowFunctionExpression",
	"id": null,
	"params": [
	{
	"type": "Identifier",
	"name": "n"
	}
	],
	"defaults": [],

	-- Given:

	append a [] = a : [] -- 1.1
	append a (x:xs) = x : append a xs -- 1.2

	last [] = Nothing -- 2.1
	last (x : []) = Just x -- 2.2
	last (x : xs) = last xs -- 2.3

	-- Prove:

	global.__$scope = new WeakMap();
	function __$withScope(f, s) {
	global.__$scope.set(f, s);
	return f;
	}