Suppose you are playing Dungeons & Dragons (or Bunkers & Badasses). Suppose you throw 20 20-sided dice. What are the chances of getting a least a single dice with a 1?

Well, the easier way to formulate that question is to ask the dual question: “what is the chance that we get no 1’s at all?” This is 19/20 on the first dice, 19/20 on the second dice and so on. Since each throw is independent, we can simply multiply those events together to get a result. This number is (19/20)²⁰. …

Edit: some word choices have been altered slightly in order to make some parts more clear.

This is a short blurb about a specific optimization present in Erlang 20.0 which is scheduled for release in June 2017. The README file mentions the following:

OTP-13529    Application(s): erts

Erlang literals are no longer copied during process to process messaging.

And there have been a couple of questions as to what that is and means. Suppose we have the following little Erlang module:

-module(z).-export([f/0]).bin() ->
    <<"Some binary value">>.map() ->
    #{ a => 3,
       b => "Hello" }.f() ->…

Suppose you have a bounded queue of size 10. In a normal setting, you system may load this queue with up to 5 elements. Under load, the queue might increase to say 7 or 8 elements, but you are not going to reach the bound of the queue. Typically the queue is empty, some elements gets added to the queue and then drained again by processing.

In contrast, suppose the queue is full at 10 elements, and that the load increases on the queue. The additional load has to be dropped, and this is a nice feedback mechanism which tells…

In the recent years, I have adopted a method for system design, which I think yields good results. For a lack of better word, I overloaded “stack” yet again, and use it as a metaphor for this design.

As everything else, it isn’t a silver bullet. There are other designs, equally good, with other trade-offs. I come with an Erlang background, so of course my designs are going to be influenced by its design. I do think the methods are widely applicable however, so you could easily use them in your preferred programming language. …

Grandma and Grandpa had an election. Grandpa won. Why did grandpa win?

Whenever the election is over, pundits will find their particular horse in the race and ride it into oblivion. The seemingly deep question to answer is “why did Trump win over Clinton?”, mostly because it was seen as an upset of the established winner. One can only guess at peoples reason to vote for a given candidate. You get results such as:

• Trump voters are stupid and don’t know what are best for themselves.
• Clinton could not be trusted, so hence she ultimately lost the election.
• It’s the…

We’ve been having a slow revolution for the last 30 years. This revolution is the gradual increase of automation in our society, and now it has come to the point where it wreaks havoc in politics as well.

It started when manufacturing plants replaced their workers with robots. The robot runs 24/7, doesn’t need vacation, has no pesky union, and is generally more efficient than a skilled worker. You still need some people to maintain the robot, but this require fewer and more specialized jobs.

Next, the office culture got eroded by means of Microsoft Windows and the digital office…

While “Rees on OO” is impossible to reach, we can still try:

Functional programming is a set of different features. These features are taken, in an à la carte fashion by people in order to argue that their particular set is what constitutes FP. Thus there is no defining factor making a language functional, and thus no archetypal FP-language.

Mind you, every programming language can often be recast in a setting in which the ideas of the λ-calculus are present. This is seen in, for instance, SSA-form where a program is compiled to what is essentially a functional core, after…

Preparation

The first decision is easily the most important. It is one of ideology: the developers are in control of the software. Not the other way around. Managers are not in control of the software. Product Owners are not in control of the software. Developers are. The only people who control the software are they who write it.

The second decision is to have small units of work which you can control. It is better to solve a minuscule subset of the full problem space first and get that deployed to production than it is to have a large project die…