The XMonad window manager is configured in Haskell. That means that when you want to apply a new configuration you actually build xmonad itself incorporating code from your configuration file. It sounds more painful than it is - when you install xmonad you get an executable called xmonad that handles the details of bootstrapping your custom build. The command xmonad --recompile builds ~/.xmonad/xmonad.hs, and subsequent invocations of xmonad run the executable that is produced.

When you configure xmonad you are actually writing your own version of the program. Because you can write arbitrary code the possibilities for customization are endless! As with any software project, you get maximum expressive power when you bring in third-party libraries. xmonad-contrib is a popular choice - but you can import any Haskell library that you want. With libraries come the problem of managing library packages. In the past I used the cabal command to globally install library packages. From time to time I would clear out my installed packages, or change something while working on another Haskell project, and then my window manager would stop working. I wanted a better option.

This is a description of my passion project. I plan to publish more detail and motivation when I get to a minimum viable product.

I want to make social collaboration software without walls. A company can have its private discussions and documents - but people in a company should be able to include clients or contractors in discussions seamlessly. It should not be necessary to require people to join a private account on service X just to have a conversation.

The idea is to make a decentralized protocol - there is no central server, and no one company that controls everything. This has been attempted before by Identi.ca, Diaspora, Google Wave, and others. I thought that a decentralized protocol could have more success if it takes a different approach: reinvent as little as possible, and build on top of an existing protocol with a large user base. I’m working on a reference client (called Poodle) that implements a new protocol that builds on email.

Email is one of the few decentralized social protocols that has broad adoption (2.6 billion users); and it has stood the test of time. Email is not perfect - but over the years email systems have evolved to address many subtle problems; and we have deployed a great deal of email infrastructure and supporting software. A protocol that builds on email instead of attempting to replace it will have a massive head start thanks to all of that work.

Last updated 2017-03-20

I have been programming primarily in Go for about six months. I find it frustrating. There are two reasons for this:

First, functional programming is particularly difficult in Go. In fact the language discourages functional programming. This frustrates me because the imperative code that I write requires a lot of boilerplate, and I think it is more error-prone than it could be if I could use functional abstractions.

Second, I see Go as a missed opportunity. There is exciting innovation in programming languages - especially in areas of type checking and type inference to make code safer, faster, and more ergonomic. I wish Google had chosen to put their weight behind some of those ideas.

I am not the first person to look at Go this way. Here are other posts that echo my feelings:

• Why Go Is Not Good
• Everyday hassles in Go
• Three Months of Go (from a Haskeller’s perspective)
• The Language I Wish Go Was

I will add to those with some of my own opinions. To highlight exactly how I think Go could be better, I want to make comparisons to Rust.

This recipe is part of the Flow Cookbook series.

Flow and React are both Facebook projects - so as you might imagine, they work quite well together. React components can take type parameters to specify types for props and state. Type-checking works well with both functional and class components.

Flow type annotations provide an alternative to propTypes runtime checks. Flow’s static checking has some advantages:

• Problems are reported immediately - it is not necessary to run tests that evaluate every component to identify props mismatches.
• Flow types can be more precise and concise than propTypes.
• Flow can also check state as well as props.
• In addition to checking that a component gets the correct props, Flow checks that props and states are used correctly within the component’s render method, and in other component methods.

This recipe is part of the Flow Cookbook series.

Hacker News provides a public API. One of the endpoints of that API accepts an ID and responds with an item:

1

fetch(`https://hacker-news.firebaseio.com/v0/item/${id}.json`)

Here is an example of a response:

1
2
3
4
5
6
7
8
9
10

{
  "by" : "todd8",
  "dead" : true,
  "id" : 13225417,
  "score" : 1,
  "time" : 1482277147,
  "title" : "U.S. Department of Energy Misconduct [pdf]",
  "type" : "story",
  "url" : "http://freebeacon.com/wp-content/uploads/2016/12/2016-12-19-Final-Staff-Report-LDRR.pdf"
}

An “item” might be a story, a comment, a question, a job posting, a poll, or a voting option in a poll. Each item type has different properties - for example stories have a title, but comments do not. If you don’t have context for the ID, the only way to know what you have fetched is to check the type property of the response at runtime. To add type safety to a call to this API, it is necessary to describe a type that encompasses all of the possible shapes that the returned data might take. That is going to be a union type, which will look something like this:

Type-checking can be a useful asset in a Javascript project. A type checker can catch problems that are introduced when adding features or refactoring, which can reduce the amount of time spent debugging and testing. Type annotations provide a form of always-up-to-date documentation that makes it easier for developers to understand an unfamiliar code base. But it is important to use type-checking effectively to get its full benefit.

The Javascript community is fortunate to have a choice of two great type checkers. These recipes focus on Flow, and introduce patterns for using Flow effectively.

This is an old post - for an up-to-date guide see Flow Cookbook: Flow & React.

Flow v0.11 was released recently. The latest set of changes really improve type checking in React apps. But there are some guidelines to follow to get the full benefits.

Flow has some very interesting features that are currently not documented. It is likely that the reason for missing documentation is that these features are still experimental. Caveat emptor.

I took a stroll through the source code for Flow v0.11. Here is what I found while reading type_inference_js.ml and react.js.

I am very excited about Flow, a new JavaScript type checker from Facebook. I have put some thought into what a type checker for JavaScript should do - and in my opinion Facebook gets it right. The designers of Flow took great effort to make it work well with JavaScript idioms, and with off-the-shelf JavaScript code. The key features that make that possible are type inference and path-sensitive analysis. I think that Flow has the potential to enable sweeping improvements to the code quality of countless web apps and Node apps.

From the announcement post:

…underlying the design of Flow is the assumption that most JavaScript code is implicitly statically typed; even though types may not appear anywhere in the code, they are in the developer’s mind as a way to reason about the correctness of the code. Flow infers those types automatically wherever possible, which means that it can find type errors without needing any changes to the code at all.

This makes Flow fundamentally different than existing JavaScript type systems (such as TypeScript), which make the weaker assumption that most JavaScript code is dynamically typed, and that it is up to the developer to express which code may be amenable to static typing.

Path-sensitive analysis means that Flow reads control flow to narrow types where appropriate.

tl;dr: ECMAScript 6 introduces a language feature called generators, which are really great for working with asynchronous code that uses promises. But they do not work well for functional reactive programming.

ES6 generators allow asynchronous code to be written in a way that looks synchronous. This example uses a hypothetical library called Do (implementation below) that makes promises work with generators:

var postWithAuthor = Do(function*(id) {
    var post   = yield getJSON('/posts/'+id)
    var author = yield getJSON('/users/'+post.authorId)
    return _.assign(post, { author: author })
})

Do(function*() {
    var post = yield postWithAuthor(3)
    console.log('Post written by', post.author.name)
})()

It is possible to use generators now in Node.js version 0.11 by using the --harmony flag. Or you can use Traceur to transpile ES6 code with generators into code that can be run in any ES5-compatible web browser.