Monomorphic

I now break the longstanding tradition of not posting code on this blog. I just wanted to share what I believe to be a somewhat unusual pattern in Java:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public IMethod findMethod(String name, String[] types) {
		outer:
		for (IMethod m: m_methods)
		{
			if (m.getName().equals(name))
			{
				int i = 0;
				for (IType t: m.getArgList().getTypes())
				{
					if (! t.getName().equals(types[i]))
					{
						continue outer;
					}
					i++;
				}
				return m;
			}
		}
		return null;
	}

On line 2, there’s a label outer: which identifies a location in the code. Normally this feature is used with keywords like the hotly debated goto in C. Java has goto as a keyword, but doesn’t support the feature. However, you can still use the labels with statements like continue above (line 12), which in this case starts a new iteration of the outer loop rather than the inner one.

I can’t remember ever having had to use this feature of any C-like language before (perhaps once) so it was intriguing when it popped up. It’s possible that a neater implementation of this would put the inner loop in a matchesSignature method in the IMethod interface instead.

I have something of an engineering background, so I easily end up thinking of success in terms of quantity. Maximizing this variable or that. Ensuring the greatest possible reward, or the smallest possible cost. But sometimes this is fallacious thinking.

As an academic, I would like to publish prestigious articles. It would be nice to publish 10 papers at second or third rate conferences, but they might all be made irrelevant by a single article at a first rate conference (or even an article in Nature or Science, say). So quality is a better measure than quantity.

I would also like to come up with new and influential ideas, but I suspect I would probably be happier if I managed to influence 10 very highly regarded people than if I managed to influence 10 000 laymen. (These exact numbers were computed using the “wild guess” algorithm and further evaluation may be needed.)

In professional life, I’ve found it dangerously easy to fall into a mode of thinking where you evaluate yourself by your income. This is true up to a point, but I’ve found that there’s a point beyond which additional income has diminishing returns in terms of how much it adds to my overall rewards from life. So beyond this point, quality is a better measure than quantity. What are my tasks, how do they force me to learn and evolve, what kind of satisfaction do I feel and why? So quality is a better measure than quantity.

User satisfaction with computer software can, to some extent, be measured using response time and latency. A snappy, responsive user interface usually produces more satisfaction than a sluggish one. But this can often be compensated for to a surprising extent by having appropriate progress indicators, animations and design features that placate the user in some way, assuring them something is being done. This is in a sense the opposite of the money situation: up to a certain point, quality makes up for quantity, after that point (when the slowness becomes impossible to mask), quantity becomes increasingly important.

What’s most interesting is perhaps the convertibility between quality and quantity. In engineering a device or a software system, quantitative metrics can be crucial tools in the construction process, but the final user experience must be qualitatively right. So quantity is a tool to construct quality. And in the real life situations where quantity is actually the best measure — bargaining, comparing, communicating, constructing, … — I think of it as a way to mask qualities. The numbers are simply easier to consider than the vast number of qualities that lie underneath.

A question for readers who happen to manage bibliographies: what, if any, bibliography management systems do you use?

I started using Aigaion for mine. Then I found out that there’s an open system called bibsonomy, which is potentially much better since it lets you tag and share bibliographies socially, and it seems to already know about all the major computer science papers.

Again (see: The problem with standards), I’m frustrated by the fact that I can’t move my data around between applications as I like without lots of manual effort. A worthy research problem would be making data truly application independent once and for all.

We distinguish between inventions and discoveries. You can own the intellectual property rights to an invention, but not to a discovery (you can’t patent the discovery of mercury or selenium, for instance). Inventions are meant to be created, and discoveries are meant to be sought for. But sometimes, the line between invention and discovery is blurry.

We cannot own the rights to mathematical structures or theorems, since they follow directly from axioms. Anyone with a mathematical education would come to the same results within the same axiomatic system. The creation of a mathematical theorem can be said to be a search process, hence the term “discovery” and not “invention”.

We can own the rights to music and paintings, since these are considered to be inventions. But isn’t the process that leads to a painting or work of music being created also a search process? Doesn’t the artist search for possible combinations that work together, in a — albeit very large and continuous — search space? But this is considered to be creation/synthesis rather than search.

The software developer is, at least sometimes, somewhere in between. A vision of a user interface that interacts with end users in a certain way can perhaps be said to come from the same large, continuous space as music and paintings come from. But given the constraints imposed by such a vision, and by the platform on which the system is to be built, the available libraries, the languages, etc, I would say that the construction of much of desktop/consumer software is a search problem. We look for combinations of components that fit the constraints, and when we have decided on this combination, we must connect the pieces together correctly. The space of possible solutions here, at least for someone who follows good design principles, is in essence much smaller than the music/painting search space. Of course there are considerations of taste and style, but they are completely irrelevant to the compiled product. They are a programmer aid.

Artificial intelligence problems are defined as search problems. But what are search problems, and what are “creational” problems, precisely? Is it merely a question of the size of the search/design space?

I use the tool Evernote on my iPhone and my desktop computers. It’s pretty nice. You can upload “notes” such as PDFs or images from your desk or from the phone, and the software makes them all searchable and syncs all data between all the different places where you use it. It OCRs photos, so if you take a photo of text, that text will be searchable. It can also show on a map where notes added from the phone were taken.

But this seems to be the icing on the cake: Pixily can scan your paper documents for you, supposedly even handwritten notes. (If they can do my handwriting, and I’m not sure they can, then they can surely decipher absolutely anything, even lost alphabets.) Apparently you send them all your stuff in boxes or envelopes, and they will OCR it into your Evernote account so it all becomes searchable. I would definitely do this if it were cheap, but I suspect shipping to and from Japan is too expensive for me to do this in bulk.

Today an oppressive, passivizing heat covers Tokyoites like a massive woollen blanket. Summer is here. In a feeble attempt to defy the heat, I follow up on my previous post on languages and automata.

That post ended with the suggestion that we can apply these concepts to interactions in society. But can we? As a starting point, let’s think about stateless and stateful interactions in a system. Stateful interactions involve a change of state, in some sense. Stateless interactions involve no such change. What counts as stateful depends very much on how detailed the model is – these might be examples:

• You make a purchase in a convenience store – the obvious changes of state are the balance in your wallet/bank account, the amount of items you possess/carry with you, and the corresponding opposite changes on behalf of the store.
• You greet somebody you know on the street and exchange some small talk. Even though no actionable information is exchanged, you both feel happier afterwards and in a better mood because you were acknowledged by someone else. This is a change of state. The precondition is that you are in a state where you know the other person – this interaction would not be possible with a random person in a random state. (On a different level, a typical such exchange goes through at least three discrete states in itself – “greeting”, “exchange of information”, “goodbye”).
• You go to your job in an office, read some documents, write some reports and leave. We can think about the wear and tear on the furniture and the building, the carbon dioxide-oxygen exchange in the air, and the changes to your company’s total body of information as changes of state. Which to choose depends, again, on the model.

Are there any stateless interactions then? Within the context of a particular model, yes. If we only care about monetary and material transactions, the meeting on the street might be stateless. If we only care about “mood” states, the purchase in the store might be stateless, and the office job might have a negative effect on accumulated mood.

In software engineering, we always try to hide state as much as possible. State makes the system far harder to understand and reason about.  We like immutable objects, whose state never change. If we look at reality through abstractions, maybe such things can exist, but in the physical world I don’t believe they do (I’d have to ask a physicist to know the answer though).

The most complex interactions in society, I think, take place among people and organisations that have long lasting relationships. These entities can modify each other’s state over a long period of time. If I’ve known somebody for years, there’s a very large number of possible states a conversation with that person might be in, a large number of topics I might possibly bring up and discuss. But the limitations of societal norms and my own knowledge imply that a conversation with a stranger might be a very small state machine indeed. (On the other hand, maybe this is why getting to know a new person can be very satisfying – the newness of building a new structure from scratch in your head to represent this person’s states). Companies that interact with customers in short, anonymous relationships almost never present them with complex interactions (convenience stores, taxi drivers). With other companies we have more complex interactions and longer relationships (doctors, banks).

These transitions of state are, again, like words that make up sentences in formal languages. We all live these languages every day. How many states do you have?

Computing is very new as a science. Blaise Pascal devised a mechanical calculator in 1645, but Charles Babbage’s analytical engine, widely considered the first programmable computer, was not conceived of until the mid-19th century. However, it was never constructed (unlike Babbage’s simpler “difference engine”), and even at this time there was almost no theory to go with the invention. Today, the fundamental abstractions of computing and programming are Turing machines and Lambda calculus, described in the 1930′s. So essentially, the theory has had less than a century to mature, and is being viewed by many as a branch of mathematics.

The newness of computing means that we don’t know that much about its role or its applicability outside of devices built specifically for computing, nor do we know if today’s fundamental computing abstractions are the best ones.

Languages and automata are two of the most fundamental ideas in computing. In contrast to human languages, which are informal and rather unsystematic, in computing we often speak of formal languages. Something like the following is an example of a formal grammar:

• Sequence-list: Sequence [ Sequence-list ]
• Sequence: Wake up Action-list Have lunch Action-list Go to sleep
• Action-list: Action [ Action-list ]
• Action: Work | Answer the phone | Attend meeting | Relax

Using this grammar we can model the life of an office worker. We can generate an infinite list of potentially infinitely long “sentences”. The following are examples of valid sentences in the grammar:

• Wake up, Work, Have lunch, Attend meeting, Go to sleep
• Wake up, Work, Have lunch, Work, Go to sleep, Wake up, Work, Have lunch, Work, Go to sleep
• Wake up, Answer the phone, Answer the phone, Answer the phone, Have lunch, Work, Go to sleep

A grammar such as this has a 1-1 correspondence with what is known as a deterministic finite automaton (DFA) – a very simple building block of software and hardware models. A formal grammar like the above is in a sense just a more natural way of thinking about a DFA.

What is the applicability of formal languages outside computing hardware and software?

For one thing, we see them in nature, not least in ferns, which on a miniature level appear to have used the same rules as on the macro level. We see them in trees and flowers. In fact, the formal language paradigm appears to be a very good fit for many natural phenomena. One reason for this might be that formal languages allow rich structures to be constructed from a very small description.

One idea I find fascinating is trying to apply these models to human society: people and institutions. Can we describe the interactions in society as automata and formal languages, and if so, what can we learn about them?

A senior manager at a company I used to work at once said that (making) software is a very social activity. I didn’t have much experience, and was very surprised at the time, since I had never thought about the human aspect of software development. But of course this aspect is extremely important. For example, in any setting with more than one programmer working on a project, the need for well functioning communication is huge, as much as in any other job I suspect. Projects often fail due to a lack of communication.

Another human side to software development is that some developers, this author included, easily start seeing the code they write as their own intellectual turf. If somebody challenges the developer’s practices or code, offering a better solution, it will be met with massive resistance. Partly out of laziness, but partly, I think, out of a desire to protect their territory and their legacy.

I do this myself more often than I would like. And it leads to bad results because it creates obstacles to communication and means that team members pull in different directions. Thus, somehow the incentives are wrong. If everybody’s goal were to allow the team to deliver a good product quickly, this would not happen. Why is it that your goal after some time with a project sometimes becomes to defend what you have created? Why do we identify with the code we wrote, and not with the bigger project?

This doesn’t mean that looking to your own interests or to your ego is a bad thing – rather that it’s easy to be shortsighted about what is in your best interests.