One important key aspect of Erlang programs is to identify where your Stable state is in the program.  Stable state is what you can trust. What you can trust is what you can build on. Joe Armstrong defines one of the key aspects of an Erlang system as Stable Storage. A place where we can push data and be sure it won't change. If we verify data before pushing, we can trust those data a great deal.

Here is a thing to ponder: Suppose you have a dynamically typed language - like Erlang. What exactly can you do with it to check stuff at compile time? This came about my mind after a twitter message by Yaron Minsky about Ocaml, where he posed the question "How people can live without types".

Programs of a certain size are complex. As long as the program is written by a single programmer and is fairly small, say under 1000 lines of code, then everything is easy. The programmer can keep the whole program in the head and it is easy to do stuff with that program. If on the other hand the program grows in size or we add more programmers, then we can't rely on the singular knowledge of a programmer.

Introduction

The unit test is the lowest common denominator. We can use them, but they are cumbersome and they only peek once into the fabric of our work. A better solution for many tasks, namely Property Based Testing exists for Erlang. This post is an example of how to use the statem type of test, mainly because there are so few of these out there. The outset is this: We will randomly generate operations on a priority queue and then validate that these operations are correct according to a simpler model.

A common problem in concurrent systems is the following: events fire from all places all the time and you have no direct control over when and why events fire. Thus, to figure out problems one can often make use of a sequence diagram like this one (thanks Wikipedia):

Now the Dart language is out at http://dartlang.org, we can begin looking at the language and see what we think of it. Everything here are musings from reading the spec of the Dart language. Note that my points here are quite subjective at times. Don't expect this to be an objective run down of the language. Rather, I wanted to write down what I thought about the language just by looking at the specification alone.

When a dog owner wants to train his dog, the procedure is well-known and quite simple. The owner runs two loops: one of positive feedback and one of negative ditto. Whenever the dog does something right, the positive feedback loop is invoked and the dog is treated with a snack. Whenever the dog does something wrong, the dog is scolded and the negative feedback loop is used.

The result is positive and negative reinforcement of the dogs behavior. The dog will over time automatically behave as the owner wants and never even think of misbehaving.

This post is all about parallel computation from a very high level view. I claim Erlang is not a parallel language in particular. It is not created with the primary goal of speeding up computation and harnessing multiple cores, your GPU and so on. If that is your goal, there are other languages which will probably fare much better for your needs (Haskell, for instance).

Google released Google+. Everyone has now blogged about whether it will "rank or tank", but nobody has really looked into the concept of circles from a more technical viewpoint to my knowledge. Let us remedy that.

When people carry out  benchmarks of web servers, their reporting of data is often inadequate. Apart from the trouble of http://www.mnot.net/blog/2011/05/18/http_benchmark_rules and getting that right, I want to focus on the reported data. The main point is this: Don't maim the raw data by taking the mean - give us a link to the raw information so we can draw our own conclusions. And don't use benchmarking tools which destroy the raw data after test.

Overload: