The Problems with the Browser

InfoQ: The Problems with the Browser

Why are we building so much software technologies that will eventually fail?

Modular systems share some key features to achieve the characteristics that are shown above. They are build around a message-passing architecture for communicating between components, they are highly concurrent and they often provide the ability to do late binding of modules in various ways. These features encapsulate the components of modular systems very well and when done right also help minimizing the dependencies between modules. Furthermore, existing dependencies are specified using protocols and sometimes the message flow is described by state machines as well [1]. This makes such systems very comprehensible and maintainable.
Modular systems are also reliable and fault tolerant by design. If some component fails only one specific piece of software with known dependencies is crashing. It does not bring the whole thing to a grinding halt. Other components that are depending on the faulty component will be informed thereof and the faulty component may be restarted. Thereafter all the other components are able to recover from the fault and go on.
Thus one can really say that the whole is more than the sum of the parts.
Some good examples of modular systems are Erlang, QNX Neutrino RTOS, Microsoft's Singularity research project, Google's Android, modern web browsers (like Google's Chrome), all the popular internet backends as Google's search engine and Facebook's social network and of course the internet as a whole.

Monolithic systems do not rely on a message-passing architecture at its core. They are made up of coarse-grained building blocks that have much more shared state than the fine-grained components of modular systems. Hence, monolithic systems do very much (on the same machine) in the same address space on the same thread context using the same call stack and therefore have much less concurrency build right into them. To sync the threads that cross the building blocks of monolithic systems there are very complex locking patterns.
Monolithic systems also encapsulate the details of building blocks quite good when done right. The management of dependencies may be also quite good when done right but the monolithic architecture often tempts people to do more hacks. Another problem with dependencies in monolithic system is that it is often not very clear which threads may cross the border from one component to the other (it is not only a message that crosses the border as in modular systems). Because of that reasons you often need much more knowledge of the building blocks that interfere with each other to understand and maintain them (e.g. keep them thread safe during their evolvement). A building block or component cannot be considered a 'black box' as in modular systems. This complicates the maintainability of such systems a lot.
Some good examples of monolithic systems are Microsoft Windows, traditional Linux systems, the Eclipse IDE and a lot of proprietary frameworks that power phones, TVs, cars, medical devices, etc.

So why are we building so much software technologies that will eventually fail? Well, also the modular systems had its drawbacks. Especially one big drawback: performance. It was simply not affordable to build highly modular systems with the hardware resources and software tools of former times. In the 1960s it started with monolithic operating systems like Multics, but there also was LISP which showed that we can do better.
Later in the 1980s we still built very bad systems like MS-DOS, but there also was Smalltalk which got it right. Smalltalk was just too fat for the emerging PC era.
Later in the 1980s QNX started working on their microkernel OS. Also Joe Armstrong started working on Erlang. They all needed some time to get this kind of systems to the scalability and performance they have today. And it took some time until the hardware resources of the average computer got to a level you could work with. If you do not have much resources why do you need high scalability?
A modular message-passing architecture is nice but also has its cost. For operating systems it required some features form the CPU to do context switches really really fast and from their MMU (memory management unit) and TLB (translation lookaside buffer) to do message passing efficiently. For programming languages and their high-level language virtual machines it required some investigations until they got the right paradigms and high-performance implementations for message-passing, concurrency, reliability, maintainability (e.g. software updates), etc.
But now we crossed the turning point as shown in the image above. Thanks to today's hardware resources that allow for modular systems in internet backends, embedded devices like smartphones and desktop computers and thanks to today's software tools that facilitate the building of more and more complex software technologies we should start building modular systems and refactor or throw away the old monolithic stuff.

But this is not that easy. As Bell Labs tried to replace UNIX with their far better successor Plan 9 they learned an important lesson, as Eric S. Raymond put it:
The long view of history may tell a different story, but in 2003 it looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

And also Linus Torvalds' commentary at LinuxCon 2009 makes clear that it is not that easy to maintain monolithic systems:
The Linux kernel has become "bloated, huge and scary" and it isn't "the streamlined, hyper-efficient kernel I envisioned when I started writing Linux."

Happily this is not true for new fields of technology. Yes, it is really hard (if not impossible) to establish new desktop computer systems on the market. But for new areas like smartphones or tablets new modular systems are spreading and also prevail against their monolithic counterparts. The interesting thing is that they are superior to our desktop systems in many ways :-).
The most interesting area today are the internet backends. Here new technologies (like Erlang) that share the modular design principles and reduce the complexity and effort needed to get the systems up and running are used more and more.

Some links:

Plan 9: The Way the Future Was

Can We Make Operating Systems Reliable and Secure?

Building a dependable Operating System: Fault Tolerance in MINIX 3

QNX System Architecture Guide

Microsoft Singularity

Linux Kernel Architecture

Erlang

LLVM

Virtual Machines: Versatile platforms for systems and processes

Google Chrome

Representational State Transfer

...

Pid ! Message

Some tenets from Joe Armstrong (a.k.a. the philosophy behind Erlang):

• The world is concurrent.
• Things in the world don't share data.
• Things communicate with messages.
• Things fail.

The Internet of Things

Now, after Facebook has brought the social network to the web, it's time for the internet of things :-).

I think Google is one of the few companies that are able to start building the internet of things, with all their server farms, smartphones, TVs and some self-driving cars ;-).

Then you no longer need to query Google's search engine for timetables or nearby shops and restaurants. The internet of things just tells you everything you need to know.

It is really interesting which technologies will clear the way for the interconnected mesh of systems. Thereby Erlang will hopefully find its way to more and more backend systems :-).

Alan Kay: A powerful idea about teaching ideas

I linked to the video "The Inner Life of a Cell" within my older blog post The Inner Life of a Cell. The mental model that the Harvard guys used to demonstrate the whole stuff is just too simple and therefore the inner life of a cell got very mysterious. At time 06:22 Alan Kay gives a more accurate view for the model of a cell; e.g. he explains how multiple complex shapes are able to match each other at the right place.

Alan Kay on Object-Oriented Programming

Some interesting statements of Alan Kay (one of the Smalltalk creators) about object-oriented programming:
"My original thought was to have something like recursive biological cells. We have about 10 to the 14th power of cells in our body. That is a hell of a lot more cells than there are nodes on the Internet. Those cells spend almost all of their effort keeping themselves normal. They're self-repairing, and you don't have to stop the organism in order to affect repairs. And then there are some interesting mathematical properties of this kind of thing that also occurred to me, and I called those things objects." [1]
"So I thought of objects being like biological cells, only able to communicate with messages (so messaging came at the very beginning - it took a while to see how to do messaging in a programming language efficiently enough to be useful)." [2]
"Object-oriented programming to me means only messaging, encapsulating and hiding state, and extreme late-binding of all things. It could be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." [3]
"The big idea is "messaging" - that is what the kernel of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be." [4]
"Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects." [5]

I think, Erlang and the QNX Neutrino RTOS definitely belong to those kind of systems. The fact that the above statement also defines QNX Neutrino RTOS as an object-oriented platform shows that particular technologies often do not matter as much as the right architectures and paradigms.
Also Apple's Objective-C platform and Google's Android OS are heavily based on message passing. That's why all this stuff works so great :-)

PS: some thoughts on message passing from the Erlang, Scala and F# creators.

Solitude and Leadership

If you want others to follow, learn to be alone with your thoughts
By William Deresiewicz

Androiden lieben lernen

Der Amerikaner Alan N. Shapiro ist Technologe und Zukunftsforscher auf den Grundlagen von Philosophie und Soziologie. Als Programmierer fordert er eine neue soziologische und ästhetische Bewertung von Software, um die Menschheit auf phantastische Weise weiterzubringen: Software sollte lernfähig und autonom sein. Dabei lässt er sich von der TV- und Kinofilmserie "Star Trek" inspirieren, über die er sein Hauptwerk geschrieben hat: "Star Trek: Technologien des Verschwindens".

Podcast auf Bayern 2 - Zündfunk Generator

The Inner Life of a Cell

The cell is the elementary unit of all living organisms. The following picture shows a typical eukaryotic cell.

(Source: Wikipedia)

(1) Nucleolus (dt. Nukleolus)
(2) Nucleus (dt. Zellkern)
(3) Ribosome (dt. Ribosomen)
(4) Vesicle (dt. Vesikel)
(5) Rough endoplasmic reticulum (ER) (dt. Raues Endoplasmatisches Reticulum)
(6) Golgi Apparatus (dt. Golgi-Apparat)
(7) Cytoskeleton (dt. Mikrotubuli)
(8) Smooth Endoplasmic Reticulum (dt. Glattes ER)
(9) Mitochondria (dt. Mitochondrien)
(10) Vacuole (dt. Lysosom)
(11) Cytoplasm (dt. Zytoplasma)
(12) Lysosome (dt. Mikrobodies)
(13) Centrioles within Centrosome (dt. Zentriolen)

One of the cell's tasks is to produce proteins. Proteins give the cells their structure and they are the molecular machines that transport substances, catalyze chemical reactions, act as messengers and recognize molecular cues (work as receptors). Proteins consist of amino acids. The process of building proteins begins within the nucleus where the DNA is transcribed into mRNA (messenger RNA) and tRNA (transfer RNA). Later, the mRNA and tRNA diffuse out of the nucleus into the cytoplasm. The DNA never leaves the nucleus.
Afterwards, the ribosomes translate mRNA and tRNA into proteins.

(Source: Wikipedia)

A ribosome does this by using the mRNA as blueprint for the protein building process. The tRNA acts as input building block with each tRNA having bound one animo acid. The output of this process is a chain of amino acids, the protein. First, the ribosome reads three nucleic acids from the mRNA. Then the complementary nucleic acids of some matching tRNA are bound to that piece of mRNA. At the same time the amino acid of the tRNA connects to the newly synthesized protein. Afterwards the next three nucleic acids of the mRNA are read and so forth.

If proteins leave the cell after being build to act as messengers or to recognize molecular cues they do this with the help of vesicles and motor proteins. Therefore the vesicles and motor proteins carry the proteins to the cell membrane where they merge with it and free their cargo.

Now e.g. the messenger proteins trigger the building process of proteins within neighboring cells and the whole game starts all over again.

The Harvard College did a great video that visualizes the inner life of a cell.

At 4:31 you see some mRNA leaving the nucleus. At 4:49 and 5:22 a ribosome builds a protein out of mRNA and tRNA. 5:43, 6:17 and 3:43 show how a motor protein transports a vesicle (e.g. containing some proteins and other stuff) to the cell membrane. Later at 6:25 the vesicle and the cell membrane merge and the vesicle frees its cargo. Some of the contained proteins act as messengers and some others act as receptors as it is shown at 6:40.

What impresses me most is the massive concurrency present within each of our body cells. And we have many of them :-) (the human body has approximately 100 000 000 000 000 cells).

The surprising truth about what motivates us

Eric Schmidt twittered the following video of "The surprising truth about what motivates us" yesterday. Really great :-)





Some more interesting stuff:
The Empathic Civilisation
The Secret Powers of Time

Android concurrency

I really like the way Android handles concurrency with its Handler and Looper classes. E.g., it helps you if you want to perform some task as background job and later push back the results to the calling thread via message passing. For convenience, there is also the AsyncTask class which does all the Handler, Looper and thread pool stuff for you. The callback interface of AsyncTask ("onProgressUpdate", "onPostExecute", etc.) will be executed within the context of the calling thread (e.g. the UI thread). That's really nice :-).
In this way Android reminds me very much of Erlang or QNX Neutrino RTOS.

I also used this classes in Quickdroid a lot. Quickdroid allows you to quickly search, find and launch apps, contacts, bookmarks, artists, albums and songs on your Android phone. It is just like Quicksilver for Mac OS X, Launchy for Microsoft Windows or GNOME Do for Linux.
The Quickdroid source code is freely available here under the Apache 2 license.

Hobby projects

• Concurrency Shootout (Erlang, Scala, Clojure, maybe F#) --> e. g. HHsearch
• Energy efficiency of highly scalable cloud services (Erlang, Scala, C++) --> e. g. SHOUTcast
  Which language and platform scales best and consumes the fewest energie to get things done. My gut feeling says it is Erlang, but we will see...
• Take a really deep look into the Erlang VM
• Do some Google Android and Microsoft .NET stuff
• Make: Electronics