This is a brief technical explanation of MVVM, with enough detail (borrowed from its WPF implementation) and examples to allow the reader to grasp how it actually works.

Abstract

Garbage collectors have given us a false sense of security with respect to what happens to an object once we stop thinking about it. The assumption is that it will be magically taken care of, but this does not always go as hoped, resulting in memory leaks and bugs due to failure to perform necessary cleanup. Tools for troubleshooting such problems are scarce, and not particularly helpful, so finding and fixing such problems is notoriously difficult.

A methodology is presented, which differs from current widespread practices, for maintaining awareness of, and exercising full deterministic control over, the lifetime of certain objects in a garbage-collected environment. We issue hard errors in the event of misuse, and accurate diagnostic messages in the event of omissions, thus improving the robustness of software and lessening the troubleshooting burden.

If you have done any software development under Microsoft Windows you have probably come across this famous error message:

System.IO.FileNotFoundException : Could not load file or assembly 'Acme.dll' or one of its dependencies. The specified module could not be found.

Naturally, when you see this message, you check whether Acme.dll is there, and what you usually discover is that the file is in fact there.

When dealing with computers, most error messages leave some room for troubleshooting; but when the system is reporting that a file does not exist while your eyes are telling you that the file is there, there is nothing to troubleshoot: the situation looks completely hopeless. The computer says black, but what you clearly see is white. What is happening makes no sense, and there is no alternative way to look at it from which a solution might be found. You are stuck. You are stymied. You are frustrated. You are exasperated. You are thinking to yourself: "how can this be happening to me?"

Abstract

A Software Design Pattern for concurrent systems is presented, which makes race conditions something that can be asserted against and thus deterministically eliminated rather than stochastically reduced or minimized.

A description of the problem

Every Software Engineer who has dealt with concurrency knows that it is hard. The bane of concurrency is race conditions: when a thread accesses data without taking into account the fact that the data is shared with other concurrently running threads which may alter that data at any unforeseeable moment in time.

Here is the manual of the ventilation unit in English.

This is a little history of the early World Wide Web (WWW) for the benefit of the younger generation which may have not experienced the Internet in its infancy and therefore might not be aware of the horrors that it involved, and why certain things have come to be the way they are today.

As you are reading this, and thinking to yourself that it could not possibly have been as bad as I am describing it, remember, the general public was experiencing it using 2400 baud modems.