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.

Now for something quite different from the philosophical entries I’ve been writing recently. We finally got the time to release the game “JTron” on Sourceforge. It is there under its new name Jtronic.

This game is designed for programming competitions; participants program an agent that plays the game by obtaining information about its environment and making decisions. The programming language is Java. The game itself combines features of Pac-man and Tron in what we think is an interesting synthesis.

This game was used for the ACM-ICPC regional contest in Tokyo 2010, for the “Java Challenge” part. I’ve had the honour to work with some great people in the Honiden lab in developing this game, and we spent time on it on and off for almost a year. A very educational process, and the final result was not bad at all.

If you can program in Java, you can have fun with this framework by programming your own agent and competing against others (including some pre-made ones that are included in the release), or you can contribute to the game framework itself, should you feel so inclined. It’s GPL licensed. The documentation is still slightly sparse, but we will release more “shortly”.

A similar framework is the “Icy Challenge” that was used in the world final ICPC Java Challenge. It has much nicer graphics than our game. Maybe someone would take the time to make 3D graphics for JTronic?

object Util {
 
	//sum of floats (probabilities) should be at most 1.0
	def multiAction(acts: Seq[Tuple2[()=> Unit, Float]]) = {
		val r = Math.random
		var soFar: Float = 0
		var acted = false
		for ((act,prob) <- acts) {
			soFar += prob
 
			if (soFar > r && !acted) {
				act()	
				acted = true
			}
		}
	}
 
}

The idea here is that we supply a list of tuples. The first element of each tuple is a function, and the second element is a float value between 0 and 1 representing the probability that each function is evaluated. Only one of the functions supplied is actually evaluated.

This is how I put it to use (excerpt from another class):

Util.multiAction(
  List( 
  (() => {
     cellsWrite(x, y-1) = cellsRead(x, y-1) + 0.01f;
     cellsWrite(x, y+1) = cellsRead(x, y+1) + 0.01f 
    }, 0.2f),
  (() => { 
     cellsWrite(x+1, y) = cellsRead(x+1, y) + 0.01f;
     cellsWrite(x-1, y) = cellsRead(x-1, y) + 0.01f 
    }, 0.1f)
 )
)

Once you take in the braces here it is actually quite simple. We have two anonymous functions taking zero parameters of two statements each. The first one has probability 0.2 and the second probability 0.1, meaning that there’s a 70% probability that nothing will happen. We can also make an arbitrarily long list of such functions on the fly.

To the best of my knowledge, the only way of reproducing this flexibility in Java would be to create anonymous inner classes and put them inside an array. Certainly that would be quite a bit more verbose than this.

The easiest technologies to understand on an intuitive-emotional basis seem to be those that involve physical processes. Objects rotating, moving, being lifted and displaced, compressed, crushed. Gases and liquids being sent around in conduits, mediating force and energy. In short, the technology that has its foundation in classical mechanics.

If these are easy to get a feel for, it would probably be in part because an understanding of mechanical processes has been of use to us throughout history, and also before the advent of civilisation. An intuitive understanding of things such as momentum, acceleration, gravity has no doubt benefited mankind and its ancestors for a very long time.

It gets trickier when we get to the more recent technologies. Take electricity to be an arbitrary watershed. We have no intuitive idea of what electricity is, apart from the fact we might be afraid of thunder. Electricity has to be taught through the abstract idea of electrons flowing in conduits, a bit like water in pipes (to name one of many images being used).

And then there’s analog and digital electronics, integrated circuits, semiconductors and so on, where intuition has long ago been left behind. We are forced to approach these things in a purely abstract domain.

Yet, when our Mp3 players, game consoles, mobile phones and computers do things for us, we are left with a sense of wonder. Our minds, always looking for stories and explanations, want to associate the impressive effects produced by these devices with some stimuli. With a steam engine, it’s easy to associate the energy with pressure, heat and motion, all of which are well understood on a low level. With a mobile phone, not so much. A lot of very abstract stories have to be used in order to reach anything that resembles an explanation, and still it doesn’t reach the essence of the device, which might be in its interplay between radio transceivers, sound codec chips, a display with a user interface and software to drive it, a central CPU, and so on, together with, of course, the network of physical antennas and their connectivity with other such networks. Is it too much to suppose that the human mind often stops short of the true explanation here? That we associate the effects produced by the device with what we can touch, smell, see and hear?

This is of course the point where many computer geeks worldwide start to feel a certain affection for the materials that make up the machines. Suppose that we are in the 1980′s. Green text on a black terminal background. A particular kind of fixed width font. The clicking of the keyboard. The dull grey plastic used to make the case. All of these things can acquire a lot of meaning that they don’t really have, because the users lack a window (physical and emotional) into the essence of the machine. The ultimate “disconnected machine”, to relate to my field, is software.

This brings up questions such as: how far can we as a species proceed with technology that we cannot understand instinctively, how can we teach such technology meaningfully and include it in democratic debate, and how can we use people’s tendencies to associate sensory stimuli with meaning and effects in a more meaningful way? – for instance, when we design hardware and software interfaces.

Sometimes, though, the generalizers get it right. These are often moments of exceptional and lasting innovation. One example of such a system is the fabulously influential (but today, not that widely used) programming language Smalltalk. Invented by the former jazz guitarist and subsequent Turing award winner Alan Kay, Smalltalk was released as one of the first true object-oriented programming languages in 1980. It is probably still ahead of its time. It runs on a virtual machine, it has reflection, everything is an object, and the separation between applications is blurred in favour of a big object box. On running Squeak, a popular Smalltalk implementation, with its default system image today, users discover that all the objects on the screen, including the IDE to develop and debug objects, appear to follow the same rules. No objects seem to have special privileges.

Another such system is an application that used to be shipped on Mac computers in the distant past, Hypercard. Hypercard enabled ordinary users to create highly customized software using the idea of filing cards in a drawer as the underlying model, blurring the line between end users and developers through its accessibility. I haven’t had the privilege to use it myself, but it seems like this was as powerful as it was because it served up a homogenous and familiar model, where everything was a card, and yet the cards had considerable scope for modification and special features. Even though, in some ways, this system appears to be a database, the cards didn’t need to have the same format, for instance. (Are we seeing this particular idea being recycled in a more enterprisey form in CouchDB?)

There are more examples of successful highly general design: the Unix file system, TCP/IP sockets and so on. They all have in common that they are easy to think about as a mental model, since a universal set of rules apply to all objects, they scale well in different directions when used for different purposes, and they give the user a satisfying sense of empowerment, blurring the line between work and play to draw on the user’s natural creativity. Successful general systems are the ones that can be easily applied in quite varied situations without tearing in the seams.

While not widely used by industrial programmers today, Smalltalk was incredibly influential. In 1981 Objective-C was created by Brad Cox and Tom Love, directly inspired by what the Smalltalk designers had done. Objective-C was subsequently used as the language of choice for NeXTStep, and later for Apple’s MacOS X when Apple bought NeXT. Today it’s seeing a big surge in popularity thanks to devices like the iPhone, on which it is also used. In 1995 Java was introduced, owing a great deal of its design to Objective-C, but also introducing features such as a universal virtual machine and garbage collection, which Objective-C didn’t have at the time. In some sense, both Objective-C and Java are blends of the C-family languages and Smalltalk. Tongue in cheek, we might say that it seems evolution in industrial programming these days consists of finding blends that contain less of the C model and more of smalltalk or functional programming.

One way of making a name is stringing words together until the meaning is sufficiently specific. E.g. “morphism averse co-dependent functor substitutions in virtual machine transmigration systems”. Thus the abstruse academic research paper title is born.

Sciences sometimes give new meanings to existing words. This could be called overloading, following the example of object-oriented programming. E.g. a “group” in mathematics is something different from the everyday use of the term. A “buffer” in chemistry is something different from a software or hardware buffer, even though a fragment of similarity is there. And so on. This overloading of words gives newcomers to the field a handle on what is meant, but full understanding is still impossible without understanding the actual definitions being employed.

Sometimes new terms can be created using inventors’ names and everyday words. E.g. a “Lie group” or the “Maxwell equations”, or “Curry-Howard correspondence”. This is potentially useful, but perhaps not something you can do freely with your own research without seeming like you’re trying to inflate your ego excessively. (Even though researchers love inflating their egos, nobody wants to admit it.)

There’s a similar problem in software development. When we invent names of functions, classes and variables, the lack of words becomes very clear. Intuitively, what is an “adapter registry”? An “observer list”? Or an “observer list mediation adapter?” My feeling is that we often end up compounding abstract words because we have no better choice. And here lies a clue to some of the apparent impermeability of difficult source code. We need better ways of making names. We’re inventing ideas faster than our language can stretch.

In addition, we live in a world with timezones and regional differences in when countries go on and off daylight savings time, if they have such a system. As yet another example of Japanese rationality, Japan does not have a DST system.

Implementing date and time computations correctly can be very hard for computer programmers and is invariably a source of many hidden bugs that may take a long time to discover. Yesterday, a large amount of Sony’s Playstation 3 game consoles stopped working normally.  This was later fixed. There was speculation the error was due to incorrect leap year handling. It wouldn’t be the first time this occurred if this was indeed the reason.

In a software company where I used to work, there would usually be massive troubles every time some country went on or off daylight savings time, or any other time calculation hit a sensitive spot. I’m fairly sure that the world’s software systems, including government, finance, insurance, health care, suffer untold billions of damage every year due to the complexity of the system. Maybe we should simplify it.

I suggest having “years” with 365 x 4 + 1 = 1461 days instead of the usual year for starters. This would move the leap year problem ahead until year 2100, when the next special rule comes in. By that time, software engineering technology should have improved enough that this should no longer be an issue, I hope. If not, we can invent another system by then. Let’s also scrap all daylight savings time everywhere. It’s easy to do and the savings would be huge.

A common misconception is that these techniques only are useful with large projects and large teams. I find, though, that they can help reduce much of the growth pains even in small projects, helping them reach maturity much faster.

Use version control. Classical, but invalid, counter arguments include “it’s a hassle and too much work to set up”, or “there’s only one person working on this project anyway”. Even if it’s only you, you will benefit massively from being able to undo your changes far back in time. It will let you experiment safely. Plus, setup is no longer an issue with free and easy-to-use services like github and bitbucket. My tool of choice is now Mercurial, and I used to use SVN. And there are many other good choices.

Use a debugger. If there is a debugger available for your language, and there most certainly is, then you should use it to find nontrivial errors, rather than extensive printf style testing.

Don’t optimise prematurely, but when you need to, use a profiler. Profilers tell you where a program’s performance bottlenecks are. You can profile things like heap usage (what classes use most space in Java, for instance) and CPU usage (which functions use the most CPU time). For Java, I’ve discovered that the NetBeans IDE has a very good built in profiler. Eclipse also has one, but it didn’t work on Mac last time I checked. For C/C++, GProf used to be good and probably still is.

Use unit testing wisely. All of the above apply even to very small projects, but I think some projects are too small to need unit tests, at least initially. You be the judge. I find that unit tests can have a lot of benefit when applied to the fragile, complicated parts of a system, where many different things interlock. If you are ambitious you can also write tests first and code later — test driven development.

Use a good IDE if you can. For a language like Java, where you have to type a lot of code to get something done and spread out your code across lots of files, a good IDE that can generate boilerplate code and navigate quickly can really speed up your work. It’s beneficial for other languages too. But I have no problem with people who use pure vim or emacs, after all these are practically IDEs.

I believe that honing your software development skills as an academic can pay off. Also see: Daniel Lemire on why you should open source your projects. (I will get around to doing this eventually, I promise )