Why Dhall advertises the absence of Turing-completeness — Haskell for all

total2Several people have asked why I make a big deal out of the Dhall configuration language being “total” (i.e. not Turing-complete) and this post will summarize the two main reasons:If Dhall is total, that implies that the language got several other things correct“Not Turing-complete” is a signaling mechanism that appeals to Dhall’s target audience“Because of the…

via Why Dhall advertises the absence of Turing-completeness — Haskell for all

The Arrow – Advanced kanban board

The Agileist

Ever since we started to use Kanban I have been thinking about how the ”perfect” kanban board would look like. I have searched for answers in the Kanban literature, but usually the boards shown there are simple examples to get you started, rather than ”evolved” or ”advanced” variants. Shortly after I had the idea with the priority pyramid I discussed it with some other persons in the agile community. One of them gave the advice, ”Why don’t you rotate the pyramid 90 degrees and connect it to a kanban board?”. This is what I came up with.


This is some sort of advanced or “ultimate” kanban board to aim for. At least for now, our kaizen efforts will for sure evolve it in the future 🙂 The picture holds quite a lot of information, let me walk you through the arrow from left to right. Let’s get started!

Priority triangle

The priority…

View original post 1,124 more words

Data modeling with ArangoDB


Since 2009 there has been a “Cambrian Explosion” of NoSQL databases, but information on data modeling with these new data stores feels hard to come by.
My weapon of choice for over a year now has been ArangoDB. While ArangoDB is pretty conscientious about having good documentation, there has been something missing for me: criteria for making modeling decisions.

Like most (all?) graph databases, ArangoDB allows you to model your data with a property graph. The building blocks of a property graph are attributes, vertices and edges. What makes data modelling with ArangoDB (and any other graph database) difficult is deciding between them.

To start with we need a little terminology. Since a blog is a well known thing, we can use a post with some comments and some tags as our test data to illustrate the idea.

Sparse vs Compact

Modeling our blog post with as…

View original post 669 more words

vertx.io – a lightweight and high performance application platform for the JVM

Recently, I’ve been working on a project that gave me a chance to get back to JVM world and take a nice look into its current state. Having spend a lot more time in .NET world last decade, it was very refreshing to experience it again. Highlights for me are working with Groovy (very nice and easy, but powerful and fast) and vertx.io application platform.

So… I simply love and admire the design of vertx.io; although it provides powerful set of features, it uses asynchronous messaging and reactive programming principles, it makes most of required infrastructure glue code disappear, by providing right abstractions and lightweight APIs that never gets in your way.

Here is the more complete list of the features straight from the their website:

  • Polyglot. You can write your application components in JavaScript, Ruby, Groovy, Java or Python, and you can mix and match several programming languages in a single application.
  • Simple actor-like concurrency model. Vert.x allows you to write all your code as single threaded, freeing you from many of the pitfalls of multi-threaded programming. (No more synchronized, volatile or explicit locking).
  • Vert.x takes advantage of the JVM and scales seamlessly over available cores without having to manually fork multiple servers and handle inter process communication between them.
  • Vert.x includes a distributed event bus that spans the client and server side so your applications components can communicate easily. The event bus even penetrates into in-browser JavaScript allowing you to create effortless so-called real-time web applications.
  • Vert.x provides real power and simplicity, without being simplistic. Configuration and boiler-plate is kept to a minimum.
  • Vert.x includes a powerful module system and public module registry, so you can easily re-use and share Vert.x modules with others.
  • Vert.x can be embedded in your existing Java applications.

Vert.x is licensed using the Apache Software License Version 2.0, see the website for full documentation and project information. Author’s twitter handle is @timfox <- HT

Monads in C#?

VisualStudio 2015 and C# 6.0 are out available for preview!!

I decided that a good way to do that would be to try implement a couple of monads in C#. Monads offer a very nice way to separate core logic from the boilerplate code. They are used quite a lot in many programming languages, and in C# they are foundation for Linq. So, I was wondering how easy/hard it would be to implement them in pure C# (not with Linq) and would they end up being practical to use in a OOP language like C#?

Disclaimer: this really is a simplified and incomplete attempt – for a complete and more through take, you should go ahead and read more detailed blog posts here or here:

First, a basic intuition about monads:

monad = data container + some computation + public interface (‘From’ and ‘Bind’)

  • Data container – in C#, simply a class
  • Computation – repetitive logic that can be extracted from the main/core operation
  • ‘From’ – function that wraps a value inside the monad – in C#, constructor or static factory
  • ‘Bind’ – function that applies main/core operation within the context of internal computation

Lets try to implement two simple monads:  Maybe (Option) and Writer monad.

Maybe monad’s internal computation checks for ‘null’ values, making top level code path clear of null checks.

Writer monad’s internal computation allows to accumulate additional information as we progress through chain of operations, hiding away explicit logging statements from the top level code path.


//-- monad interface
public interface IMonad<T> {
//IMonad<T> From(T @value);//note: implemented as constructor
IMonad<T2> Bind<T2>(Func<T, T2> f) where T2 : class;
// simple access the wrapped value(s), optional but helpfull 🙂
string Show();
//-- Maybe monad
class MaybeM<T> : IMonad<T> {
internal T _value;
public MaybeM(T value) {
_value = value;
public IMonad<T2> Bind<T2>(Func<T, T2> f) where T2 : class {
if (_value != null) {
return new MaybeM<T2>(f(_value));
return new MaybeM<T2>(null);
public string Show() {
return _value == null ? "null" : _value.ToString();
//-- Writer monad
class WriterM<T> : IMonad<T> {
internal T _value;
List<string> _info;
public WriterM(T @value) {
_value = value;
_info = new List<string>();
WriterM(T @value, List<string> info) {
_value = @value;
_info = info;
public IMonad<T2> Bind<T2>(Func<T, T2> f) where T2 : class {
try {
var result = (f(_value));
_info.Add("\{(f.Method).Name}()-> \{result}");
return new WriterM<T2>(f(_value), _info);
catch (Exception ex) {
_info.Add("Exception: \{ex.Message} thrown for \{(f.Method).Name}()");
return new WriterM<T2>(default(T2), _info);
public string Show() {
var valStr = _value.ToString();
_info.ForEach(s => valStr += "\r\n\t" + s);
return valStr;
view raw maybeM.cs hosted with ❤ by GitHub

and here is how it is used:

static void Main(string[] args) {
//-1) Maybe monad usage: input regular string, intermediate result int...
var maybeM = new MaybeM<string>("I'm a string, wrapped up in the Maybe Monad!");
var result1 = maybeM.Bind(ExtractVowels)
WriteLine("Result is: \{result1.Show()}");
//-2) Maybe monad usage: null string
maybeM = new MaybeM<string>(null);
var result2 = maybeM.Bind(ExtractVowels)
WriteLine("Result is: \{result2.Show()}");
//-3) Writer monad usage
var writerM = new WriterM<string>("I'm a string, wrapped up in the Maybe Monad!");
var result3 = writerM.Bind(ExtractVowels)
WriteLine("Result is: \{result3.Show()}");
view raw MainMaybeM.cs hosted with ❤ by GitHub

You can get full source code by going to this GitHub page. I may continue to play around with this, potentially add other monads and more complex examples of use…

resto: a little api playground that just might work…


var service = require('resto.service');
var pipeline = require('resto.pipeline');
var http = require('resto.httpserver');
var authenticator = require('resto.middleware.authn');
var authorizer = require('resto.middleware.authr');
var resolver = require('resto.middleware.resolver');
var invoker = require('resto.middleware.invoker');
var converter = require('resto.middleware.hal');
//- dsl
var withMany = require('resto.realtionships').hasMany;
var ownedBy = require('resto.realtionships').hasOne;
var whoHas = require('resto.realtionships').hasOne;
//- resources
var farm = require('./resources/farm');
var farmer = require('./resources/farmer');
var appleOrchard = require('./resources/appleOrchard');
var apples = require('./resources/apple');
var appleFarm = service.compose(farm)
// .use(liveupdate)

Distributed Systems and the End of the API

The Quilt Project

This is a written (expanded) narrative of the content from a talk I first gave at PhillyETE on April 23rd, 2014. It mostly follows the flow of the presentation given then, but with a level of detail that I hope enhances clarity of the ideas therein. The talk’s original slides are available, though the key illustrations and bullet points contained therein are replicated (and somewhat enhanced) below. When audio/video of the talk is published, I will update this page to link to it. Discussion about this piece has taken place on Hacker News, reddit, and Lobsters.

I have two claims of which I would like to convince you today:

  1. The notion of the networked application API is an unsalvageable anachronism that fails to account for the necessary complexities of distributed systems.
  2. There exist a set of formalisms that do account for these complexities, but which are…

View original post 7,460 more words

Either monad to the rescue…

Lots of programming problems can be modeled by pipe-lining data through series of sequential or parallel processing steps. This data flow allows us to separate computational tasks into meaningful modules and
get more focused code base that is easier to debug and reason about. For example, a pipeline with three steps that takes input ‘req’ and successfully process it, would look like this:


And if at any stage there is error during the processing, we would skip the rest and return error…


Now, there are many ways to implement error handling, but this can easily end up in a messy combination of conditional statements and/or throwing and catching exceptions to stop processing. This adds noise to the real code logic and makes composing tasks harder… I’ve recently started to use Either monad to help with this this problem and am very happy about the results:

var Either = require('data.either');
var log = console.log;
var handlers = [];
function use(f, p, t) {
handlers.push({ func: f, pred: p || false, trace: t || false});
// f, ep, m(a) -> m(b)
function run(f, ep, m) {
return m.chain(function(d) {
var r = f(d);
return ep(r) ? Either.Left(r) : Either.Right(r);
// hs, ep, a -> b | err
function runAll(hs, ep, d) {
var m = Either.of(d);
hs.forEach(function(h) { m = run(h.func, ep, m); });
return m.merge();
var expect = require('expect.js');
log('testing: monad-pipeline-spike.js');
function f1(ctx) {
log('f1, counter before: ' + ctx.counter);
if(ctx.counter > 1) {
ctx.statusCode = 500;
return ctx;
ctx.counter += 1;
return ctx;
function f2(ctx) {
log('f2, counter before: ' + ctx.counter);
if(ctx.counter > 1) {
ctx.statusCode = 500;
return ctx;
ctx.counter += 1;
return ctx;
function f3(ctx) {
log('f3, counter before: ' + ctx.counter);
if(ctx.counter > 1) {
ctx.statusCode = 500;
return ctx;
ctx.counter += 1;
return ctx;
// setup
// run until failure
var result = runAll(handlers, function(d) {return d.statusCode !== 200;}, {counter: 1, statusCode: 200});
//>f1, counter before: 1
//>f2, counter before: 2
//>{ counter: 2, statusCode: 500 }
view raw monadic-pipeline.js hosted with ❤ by GitHub

Here, I’m using Either implementation from the nice functional library Falktale

Till next time…