It is a very good film indeed. (I cannot remember the last time I was so gripped by a film shortly after its release.) I was also inspired to read several of le Carré’s novels, including but not limited to Tinker, Tailor, Soldier, Spy. What they have in common is a subtle, rich portrayal of the spy trade from the viewpoint of Britain during the cold war; a world that seems to be, increasingly, a thing of the past. Voice recognition, social profiling and data mining seems to be taking the place of a good chunk of what le Carré calls tradecraft – the concrete skills that spies with 1970′s technology need in order to perform their work on the ground in enemy territory – and computer scientists like myself are to blame.

While being hailed as the anti-Ian Fleming due to his relatively gritty realism, Le Carré is not without his own spy romanticism. But the bleakness inherent in the work comes through on every page.

In his commentary on the film, le Carré states that

[The world of spies is] not so far from corporate life, from the ordinary world. At the time of writing the novel, I thought that there was a universality that I could exploit. The book definitely resonated with the public; people wanted to reference their lives in terms of conspiracy, and that remains central to the relationship between man and the institutions he creates.

There is something profound in this. Spies are merely concentrated versions of something that we all are ourselves, something that we must be every day. Spies project false personalities in order to gain access and information, either about enemy assets or about other spies. They hide to survive, and they hide so that they may uncover a kind of truth. With a view to the spy as the most concentrated form of a certain kind of existence, let us take a look at some other forms that this existence may take.

The modern professional. To be professional means to effectively project a professional identity in the workplace. To be unprofessional almost always means that too much of another, possibly more genuine personality shines through – one has become too unrestrained. The professional needs to always be projecting, to a degree, in order to remain compatible with the workplace and retain his income and career prospects. Young people are socialised into this condition very early – at career workshops, students learn how to polish their CVs, how to embellish their record, and to hide their flaws. This is essentially a partial course in spycraft. But all this is only at the entry level. When any kind of sophisticated politics enters the organisation – as it does – the professional may be pushed ever closer to the spy. A recruiter: “Too bad that we couldn’t hire him, he seemed genuine.”

The academic. The academic can be thought of as a special version of the professional with some essential differences. First, professionals do not yet have universal records that follow them around for their entire lifetime – much of the “record” that they create, which is associated with the persona they are supposed to project, exists only in the memory of people and of one organisation. Academics build their records with units such as publications and conference attendance. Publications in particular form an atomic record that does not go away. On the other hand, the everyday life of the academic may – possibly – be less artificial than that of the professional, since focus is on the production of publishable units, not on pleasing people in one’s surroundings as much as possible.

The philosopher.  Philosophers seek to uncover some hidden truth about the world. In this sense, they are spies without enemies. The philosopher lives among people with a view to analysing them and understanding their behaviour, so that he can explain it to them. But most of the time the philosopher is likely to be a flaneur or a quiet observer, like the spy often is: someone who seeks to learn something hidden from situations that other participants may regard as being routine and their everyday existence. In this sense spies may have something in common with philosophers.

Here I have highlighted a phenomenon but not made any recommendations. Maybe it’s for the better that we are all a little bit like spies. Masks of some kind are worn in most social interactions, not just the ones above, and they are not a recent phenomenon. Exposing something like a true inner self requires that the inner self remains static long enough for it to be possible to expose. But the difference between most social relationships and the relationships we have with institutions today is that the former can change or dissolve naturally to fit spontaneous changes in people’s characters or needs. Relationships between people and modern institutions do not seem to be capable of this dynamic as of yet.

Deleuze’s Nietzsche is the author’s interpretation of Nietzsche’s thought. This is perhaps one of the most coherent interpretations of Nietzsche I’ve read. It succeeds in turning Nietzsche’s notoriously unsystematic philosophy into a system with something like well-defined concepts and their interrelationships at its core. The work feels simultaneously fresh and firmly grounded in Nietzsche’s own ideas. This is a book that I expect I will read again, because I’m quite certain I haven’t understood everything. For example, I don’t yet have a good feel for the difference between Deleuze’s active and reactive force  - I cannot even imagine what an active force is. Reading this work has made me suspect that I’ve thought of every force as being essentially reactive up until this point.

One caveat with this work is that it is a book with a mission; the mission is to destroy Hegelian philosophy and dialecticism. This is in line with the historical context of Nietzsche usage in France, where he was used mainly as an antidote to the dominant Hegelian thought, if I understand correctly.

I’ve previously read De Landa’s Philosophy and Simulation, a book about emergence and about corroborating philosophical theories with computer simulations. 1000 Years of Nonlinear History is an earlier, but no less interesting, work of his. It tells the simultaneous history of geology, genes and memes (in the form of languages). In order to fully appreciate this book I think I ought to gain some idea of the mathematics behind attractors and dynamic systems.  Still, there is a lot to be gained even without those insights. The parallels between the three different historical fields are interesting, and the essential point that is made is that there is nothing like progress or determinism about the forms that society, language, ideas, life or matter take today. Instead, the state of the world is a nonlinear system of interacting attractors. We are invited to view the world as rich but essentially accidental, and free of distinctions such as organic-inorganic and human-nonhuman.

It is interesting to compare computer science and bioinformatics with just the hindsight of this short period. In computer science and electronics, we study systems that have been built from the ground up with well known components at various scales. They have been designed with certain high level functionalities in mind, and it is always well known how these high level functions are being realised and what makes them tick. In biology, in contrast, we encounter systems designed by nature. These systems, organisms, have certain high level functions we are aware of. We are also aware of some of the low level functions, such as molecules, atoms and cells (although we may have only a partial understanding of some of these). The problem in biology is now to explain what makes a high level function tick or not tick, how to steer it, enhance it, or suppress it. The intermediate steps are not always revealed to us, and we must painstakingly tease them out with experiments. As always with empirical science, we can never be sure that we’ve obtained the whole picture.

This difference – the fact that we must reconstruct all the design principles and intermediate mechanisms for organisms, but not for computers – leads to different styles of teaching and thinking. Biology texts appear to be very top down and focus on what has been observed and what it appears to be. Technology texts can be bottom up, building up a complex design smoothly by adding one layer at a time, starting from the core, having the confidence that nothing is being omitted. The contrast is striking.

A limitation that both biology and computer science share is the problem of defining the exact capabilities of an organism or a system. In biology we often do not know, and I doubt if we ever will, considering how complex the genetic code is. In computer science, the capabilities of very simple programs can be completely understood, but understanding a nontrivial program — for example, verifying that it does what is desired and does not do what is not desired — usually requires nontrivial formal methods, if it is at all possible.

Being a Ph.D. student in the Honiden laboratory has been a great experience, and I am very grateful to professor Honiden and to the other lab members for their support.

My thesis and the associated slides are available. The abstract is as follows.

In the last few decades, software systems have become less and less atomic, and increasingly built according to the component-based software development paradigm: applications and libraries are increasingly created by combining existing libraries, components and modules. Object-oriented programming languages have been especially important in enabling this development through their essential feature of encapsulation: separation of interface and implementation. Another enabling technology has been the explosive spread of the Internet, which facilitates simple and rapid acquisition of software components. As a consequence, now, more than ever, different parts of software systems are maintained and developed by different people and organisations, making integration and reintegration of software components a very challenging problem in practice. 

One of the most popular and widespread object-oriented programming languages today is the Java language, which through features such as platform independence, dynamic class loading, interfaces, absence of pointer arithmetic, and bytecode verification, has simplified component-based development greatly. However, we argue that Java encapsulation, in the form supported by its interfaces, has several shortcomings with respect to the need for integration. API clients depend on the concrete forms of interfaces, which are collections of fields and methods that are identified by names and type signatures. But these interfaces do not capture essential information about how classes are to be used, such as usage protocols (sequential constraints), the meaning and results of invoking a method, or useful ways for different classes to be used together. Such constraints must be communicated as human-readable documentation, which means that the compiler cannot by itself perform tasks such as integrating components and checking the validity of an integration following an upgrade. In addition, many trivial interface changes, such as the ones that may be caused by common refactorings, do not lead to complex semantic changes, but they may still lead to compilation errors, necessitating a tedious manual upgrade process. These problems stem from the fact that client components depend on exact syntactic forms of interfaces they are making use of. In short, Java interfaces and integration dependencies are too rigid and capture both insufficient and excessive information with respect to the integration concern. 

We propose a Java extension, Poplar, which enriches interfaces with a semantic label system, which describes functional properties of variables, as well as an effect system. This additional information enables us to describe integration requests declaratively using integration queries. Queries are satisfied by integration solutions, which are fragments of Java code. Such solutions can be found by a variety of search algorithms; we evaluate the use of the well-known partial order planning algorithm with certain heuristics for this purpose. A solution is guaranteed to have at least the useful effects requested by the programmer, and no destructive effects that are not permitted. In this way, we generate integration links (solutions) from descriptions of intent, instead of making programmers write integration code manually. When components are upgraded, the integration links can be verified and accepted as still valid, or regenerated to conform to the new components, if possible. The design of Poplar is such that verification and reintegration can be carried out in a modular fashion. Poplar aims to provide a sound must-analysis for the establishment of labels, and a sound may-analysis for the deletion of labels. We describe the semantics of Poplar informally using examples, and provide a formal specification of Poplar, which is based on Middleweight Java (MJ). We describe an implementation of a Poplar integration checker and generator, called Jardine, which compiles Poplar code to pure Java. We evaluate the practical applicability of Jardine through a case study, which is carried out by refactoring the JFreeChart library. We also discuss the applicability of Poplar to Martin Fowler’s well known collection of refactorings. Our results show that Poplar is highly applicable to a wide range of refactorings and that the evolution of integrated components becomes considerably simpler.

To a degree it is possible to come up with a new product by simply improving on some numbers from an old one. “Here’s a new hard drive with 1.3x more space.” However, such innovation will always be incremental.

The challenge for technology is how to create products and solutions that are not justified or evaluated from a quantitative, utilitarian perspective, but from an entirely different one, perhaps an aesthetic perspective. And this is also the challenge for social innovators and policymakers in society. Solutions that maximise numbers have value and can enable qualitative change in the long run, but in themselves they never constitute true progress.

To see how far the utilitarian thinking has gone, think about how many technology products are justified with sentences along the lines of “it makes more information available”, or “it makes X cheaper” , or “it makes you more connected”. In all seriousness, there are situations when it is not desirable to have more information.

I’m sure I’ll find a lot of answers to this in the philosophical literature in time (maybe I should read Schopenhauer). But what I came up with myself, as a preliminary definition, is this:

A system can be said to have will if it makes progress towards some goal state in a wide array of circumstances, circumnavigating obstacles (including other systems with will) to some degree.

Here, progress doesn’t need to be an achievement - progress in the form of maintaining some state should also qualify.

This definition is dependent on definitions of states, progress, circumstances and systems. An intuitive conception of all of these should suffice for the time being.

One of my friends suggested that instead of trying to define will as an intrinsic property of something, it should instead just be understood as a human heuristic, a cognitive tool that we use as a lens through which to view the world. These two views are not incompatible, since the question here becomes: what is the minimal set of attributes that something must have for us to view it through the conceptual lens of “will”?

(The multi-month hiatus here on Monomorphic has been due to me working on my thesis. I am now able to, briefly, return to this and other indulgences.)

Life presupposes taking responsibility. It presupposes investing people, objects and matters around you with your concern.

In particular, democratic society presupposes that we all take full, in some sense, responsibility for society itself, its decision making and its future.

However, he who lacks information about some matter cannot take responsibility for it. And thus we often defer to authorities in practice. Authorities allow us to specialise our understanding, which increases our net ability to understand as a collective, assuming that we have sufficiently well functioning interpersonal communication.

There are whole categories of problems that routinely are assigned to specific, predefined authorities and experts; for instance legal matters, constitutional matters, whether some person is mentally ill, medical matters, nuclear and chemical hazards, and so on. Fields where some degree of extensive training is generally required. (However, under the right conditions, these authorities could probably also be called into question by the public opinion.) The opposite is those categories of problems that are routinely assigned to “public opinion” and all of its voices and modulating contraptions and devices, its amplifiers, dampeners, filters, switches and routing mechanisms.

Responsibility aside, in order to maximise an individual’s prospects for life, and by extension society’s prospects for life, it seems important that the individual possess just the right knowledge that they need in their situation. Adding more knowledge is not always a benefit; some kinds of knowledge can be entirely counterproductive. Nietzsche showed this (“On the use and abuse of history for life”), and we can easily apply the idea of computational complexity to see how having access to more information would make it harder to make  decisions.

This is especially true for some kinds of knowledge: knowledge about potential grave dangers, serious threats, monumental changes threatening to take place. Once we have such knowledge we cannot unlearn it, even if it is absolutely clear that we cannot act on it and that we do not have the competence to assess the situation fully. It  takes effort and an act of will to fully disregard a threat on the basis of one’s own insufficient competence.

On the other hand, knowledge about opportunities, about resources, and about problems that one is able to, or could become able to deal with, would generally be helpful and not harmful. However, even this could be harmful if the information is so massive as to turn into noise.

Even disregarding these kinds of knowledge, one of the basic assumptions of democracy – that each individual takes full responsibility for society – seems to be an imperative that is designed never to be fulfilled. An imperative designed to be satisfied by patchworks of individual decisions and “public opinion”, and whatever information fate happens to throw in one’s way. Out of a basic, healthy understanding of their own limitations, individuals generally assume that the democratic imperative to know and to take responsibility was never meant to be taken seriously anyway, but one does one’s best to match one’s peers in appearing to do so.

It seems to me that the questions we must ask and answer are about the proper extent of responsibility, and the proper extent of knowledge, for each individual. For the individual, taking on no responsibility seems detrimental to life; taking on full responsibility for all problems in the world right now, here today, would also be an impossibility. There would be such a thing as a proper extent of responsibility. One’s initial knowledge and abilities would inform this proper extent of responsibility, and the two might properly expand and shrink together, rather than expand and shrink separately.

In a democratic society, in so far as one wants to have one, we should ask: what is the proper level of responsibility that society should expect from each individual, and what level should the individual expect from himself as an ideal?

More generally, empirical studies of how public opinion functions and how democracies function in practice are needed. It is inappropriate to judge and critique democracies based on their founding ideals when the democratic practice differs sharply from those ideals – as inappropriate as it is to critique and judge economies based on the presumption that classical economic principles apply to economic practice in the large.

I gave a talk about my project, Poplar, at the FREECO workshop. At the same workshop there was a very interesting talk given by Klaus Ostermann, outlining some of the various challenges facing software composition. He linked composition of software components to concepts in classical logic, and informally divided composition into a light side and a dark side. On the light side are ideal concepts such as monotonicity (the more axioms we have, the more we can prove), absence of side effects and a single, canonical decomposition of everything. On the dark side are properties such as side effects, the absence of a single decomposition, knowledge that invalidates previously obtained theorems, and so on.

One of the ideas that resonated the most with me is the tyranny of the dominant decomposition. (For instance, a single type hierarchy). Being forced to decompose a system in a single way at all times implies only having a single perspective on it. Is this not platonism coming back to haunt us in programming languages? (Ostermann did indeed say that he suspects that mathematics and the natural sciences have had too much influence on programming). What we might need now is an antiplatonism in programming: we might need subjectivist/perspectivist programming languages. If components can view their peer components in different ways, depending on their domain and their interests (i.e. what kind of stakeholders they are), we might truly obtain flexible, evolvable, organic composition.

What makes a programming language attractive and competitive? How can we evaluate its quality? There are many different aspects of this problem.

Ease of reading and writing, or: directness of the mapping between the problem in your head and the model you are creating on the computer. This can be highly domain dependent, for instance languages such as LaTeX, Matlab and R are designed with specific problems in mind and cater to users from that domain. Their limits show quickly when you try to stretch them beyond their envisioned purpose. Speaking of general programming languages, I think Python deserves to be mentioned as a language that is extremely readable and writable. It has other shortcomings though – see below. Prolog is also highly read- and writable if it suits your problem.

Runtime performance. Arguably this is one of the few reasons to bother with using C++. For the majority of programming projects though, performance is much less of a problem than one might think, especially if one considers how close the performance of many JVM languages get to C++. When programmers think about their overall productivity and effectiveness in developing and maintaining a system, C++ is often not the best choice, obviously.

Scalability to large teams. The key property here is: does the language do anything to help me, as a developer, work with code that other people wrote? Ease of maintenance may be strongly correlated with usability in large teams. An anti-pattern here is languages that allow for solving the same problem in a huge amount of ways with very variable syntax. For instance, Perl and C++ can lead to notoriously unmaintainable code if used carelessly. Some say that Scala also suffers from this problem. Basically, the language helps here if it prevents me from doing things that other developers might not expect, and that I might forget to document or communicate. This is why Gosling famously called Java a blue collar language; it restricts you enough to make teamwork quite practical. It even restricts the layout of your source file hierarchy. (Now we begin to see that some goals are in conflict with each other).

Scalability to large systems. This is related to the preceding property, but whereas team scalability seems to be mainly about avoiding the creation of code fragments that surprise people other than their creators, system size scalability seems to be about avoiding the creation of code fragments that surprise other code fragments. Here one needs invariants, good type checking, static constraints of all kinds. Scripting languages like Perl and Python, lacking static typing completely, are some of the worst in this regard, since we cannot even be sure at startup time that methods we try to invoke on objects exist at all (Python).

Scalability over time (maintainability). If there is both system size scalability and team scalability, then the system is also likely to be able to live for a long time without great troubles.

Developer efficiency and rapid prototyping. Depending on the nature of the system being developed, this may depend on several different properties listed above.

Availability of quality tools. Mature runtime environments, such as the JVM, have many more high quality tools and IDEs available than a language than Ruby. Mature languages also have more compilers for more different architectures available.

These points begin to give us an idea of how we can evaluate programming languages. However, I also believe that making a good language and making people use it is largely about luck and factors outside the design itself. Just like there’s a big step between imagining and specifying an utopian society and making that social order an actuality, there’s a big step between designing an ideal programming language and achieving widespread adoption for it. We have seen a way forward though: with generalised runtime environments such as the JVM and the CLR, we may develop and deploy languages that take advantage of a lot of existing infrastructure much more easily than before. And what I hope for is in fact that it becomes even easier to deploy new languages, and that new languages are as interoperable as possible (insofar as it doesn’t constrain their design), so that we could see more competition, more evolution and more risk taking in the PL space.

But they also complicate reasoning about programs enormously. Both human reasoning and automated reasoning. Pointers allow any part of the program to have side effects in any other part of the program (if we have a reference to an object that originated there), and they make it very hard to reason about the properties that an object might have at a given point in time (since we generally have no idea who might hold a reference to it – it is amazing that programmers are forced to track this in their heads, more or less). In my effort to design my own language, multiple pointers to the same objects – aliases – have come back from time to time to bite me and block elegant, attractive designs. I believe that this is a very hard problem to design around. Aliased pointers set up communication channels between arbitrary parts of a program.

Nevertheless attempts have been made, in academia and in research labs, to solve this problem. Fraction-based permissions track how many aliases exist and endow each alias with specific permissions to access the object that is referred to. Ownership analysis forces access to certain objects to go through special, “owning” objects. Unique or “unshared” pointers in some language extensions restrict whether aliases may be created or not. But so far no solution has been extremely attractive and convenient, and none has made it into mainstream languages. (I know that someone Philipp Haller made a uniqueness plugin for the Scala compiler, but it is not in wide use, I believe.)

If we are to attempt further incremental evolution of the C-family languages, aliased pointers are one of the most important issues we can attack in my opinion.