Once upon a time I did a PhD. Tradition in Holland has it that you can add a list of “positions” to your thesis, often unrelated to the PhD work, that you are willing to defend during the Q and A section of the PhD ceremony. I included a position that said something along the lines of “Our DNA does not contain all information necessary for our procreation”. What this alludes to is that there are bound to be “backdoors” in the machinery that creates us from our DNA.

The original source code for Ken Thompson’s C compiler backdoor could be deleted, because it was now part of the machinery. Similarly, it seems likely that the machinery that creates our proteins from our DNA will have evolved in such a way that parts of it no longer need to be coded for by the DNA directly. The information to recreate the machinery is now partly in the machinery itself, and over time the DNA encoding for those parts will have disappeared since the evolutionary pressure to keep that DNA intact is no longer there.

We start out life with DNA from our parents, but we also receive the protein building machinery from our mothers in the fertilized egg. Over time that machinery has evolved to great complexity. Our C compiler has many backdoors that it depends on for its proper functioning. And like Ken Thompson’s backdoor, there is no need to keep its DNA around. Our procreation needs not only our source code, but also that complex backdoor-rigged machinery that turns our source code into us.

When I fished it out, the screen had turned on and showed proof of Apple’s amazing capability of anticipating usage scenarios:

Then the screen faded. Water had entered the screen and camera. What to do?

When dropping a mobile phone in water, here is what you should do immediately:

1. Turn phone off
2. Remove battery

Unfortunately, for number 1 you need a working touch screen, and for number 2 you need to visit the Apple store. The only option was to let it die a painful death. The screen came on a few times, flashing bright white, as iPhone desperately tried to breathe, but it finally died after about 15 minutes.

Not covered, can’t fix, visit Softbank to buy a replacement. This is what the genius in the Apple store told me an hour later. Instead I decided to go to Tokyu Hands and bought a screw driver and a watch case opener. Back home I disassembled the iPhone, and let it dry overnight.

The next morning I put it back together, which was considerably less straight forward than taking it apart. When I finally clicked the screen back into the case, fastened the two screws at the bottom, and  looked at the screen, there was the Apple logo! Some people get warm fuzzy feelings whenever they see the Apple logo. Not me. But this time must have made up for that. iPhone had resurrected. After installing the SIM card, it booted normally, and everything functions OK.

Well, except for the volume up button.

To load a remote a remote javascript file, just construct a script tag and insert it into the document body. To call a function, in order to feed it some data stored in the bookmarklet, set the “onload” attribute to a callback to be invoked when loading is ready:

(function() {
  var d=document;
  var s=d.createElement("script");
  s.onload = function() {enter()}; // enter is a function defined in the loaded script
  s.src="/path/to/java/script.js";
  d.body.appendChild(s);
})();

This works nicely in Firefox, Safari and Opera.

The problem is, loading the script is synchronous in IE (both 6 and 7), and the onload callback does not get called. This in spite of MSDN documentation claiming that onload on script tags is honored. However, since loading is synchronous, the script will have completed loading in IE when the appendChild call returns. A workaround, then, is to call the callback explicitly after the appendChild call, but guard it with a flag so that it is run only once.

(function() {
  var d=document;
  var s=d.createElement("script");
  s.onload = function() {enter()}; // enter is a function defined in the loaded script
  s.src="/path/to/java/script.js";
  d.body.appendChild(s);
  if (window.enter)
    enter();
})();

// "enter" function in included javascript file:
var entered = false;
function enter() {
  if (entered)
    return;

  entered = true;
  //...
}     

java -classpath js.jar
    org.mozilla.javascript.tools.shell.Main  -f test.js

However, if you run a script that bombs out with an exception, you don’t get any line information, just the plain exception message:

js: uncaught JavaScript runtime exception:
    TypeError: Cannot call method "charCodeAt" of undefined

To get line information, you need to ensure that rhino runs in interpretive mode, using the -opt -1 option:

java -classpath js.jar
    org.mozilla.javascript.tools.shell.Main -opt -1 -f test.js

This results in:

js: "test.js", line 577: uncaught JavaScript runtime exception:
    TypeError: Cannot call method "charCodeAt" of undefined

which has the offending line number, and thus is much more helpful. In addition, it it possible to get a stacktrace by invoking your code in a try catch block, and handling the exception as follows:

try {
     // call your code here ...
}
catch (exc) {
    print(exc);
    if (exc.rhinoException)
        exc.rhinoException.printStackTrace();
}

Don’t forget to specify the -opt -1 flag, since otherwise you’ll only see java-level calls. Also, note that the “rhinoException” property is defined on Error objects only, so the object caught should be explicitly tested for it.

 --- support/shobj-conf	2007-12-26 18:30:46.000000000 +0900
+++ support/shobj-conf.new	2007-12-26 18:30:39.000000000 +0900
@@ -142,7 +142,7 @@
;;

# Darwin/MacOS X
-darwin8*)
+darwin89*)
SHOBJ_STATUS=supported
SHLIB_STATUS=supported

@@ -171,7 +171,7 @@
SHLIB_LIBSUFF='dylib'

case "${host_os}" in
-	darwin[78]*)	SHOBJ_LDFLAGS=''
+	darwin[789]*)	SHOBJ_LDFLAGS=''
SHLIB_XLDFLAGS='-dynamiclib -arch_only `/usr/bin/arch` -install_name $(libdir)/$@ -current_version $(SHLIB_MAJOR)$(SHLIB_MINOR) -compatibility_version $(SHLIB_MAJOR) -v'
;;
*)		SHOBJ_LDFLAGS='-dynamic'

and rerun configure and make.

From the Changelog:

Tue Dec 25 23:33:55 2007 Yukihiro Matsumoto

* development version 1.9.0 released.

As promised at Ruby Kaigi last summer, it was released on Christmas day (with almost half an hour to spare).

Get it from subversion at http://svn.ruby-lang.org/repos/ruby/trunk

Congratulations to Matz, Ko1, and all others who worked hard to make this happen!

def y
  -> (x) { x.(x) }.(
    -> (f) { -> (*args) { yield (f.(f)).(*args) } }
  )
end

fac = y { |rec| -> (n) { n < 2 ? 1 : n * rec.(n-1) } }

puts fac.(5)   # ==> 120

Size

Size and bloat hamper the requirement for a programmer to get a piece of code fully into his or her head, to be able fully understand it and to grasp the consequences of changes to that code.

Steve’s focus is on how a language (Java in his case) promotes an increasing code size and how choosing a different language can reduce that size by maybe a factor 2 or 3 or so. Using a more expressive language frees a programmer from writing many lines of tedious, repetitive code. By being able to focus more on the problem at hand, the code’s intention can stand out more clearly as well, which further improves understandability.

Language is certainly a factor, but I’m fairly sure Steve would concur that there is more to it.

Complexity

For one thing, it is not code size per se, but something that is often strongly related to size that wreaks havoc on the understandability of a code base: code complexity.

Code complexity is often taken to be the ease or difficulty of understanding a simple piece of code that implements some common algorithm. Like the implementation of Quicksort in Haskell versus Java. That is not the complexity I am talking about. The complexity that makes programs hard to understand play at a somewhat higher level. In order to achieve its goals, various parts of a program have to interact. All but the most trivial programs contain many parts that must communicate. A lot of the complexity of code is holed up in the countless ways parts of a program talk to each other and influence each other. It is this dynamic complexity that makes things hard to understand.

Over the years, many methodologies were invented to better cope with the complexities of larger code bases. None have proven to be the silver bullet.

Object orientation, for example, is, in its essence, an attempt to better organize code in order to reign in some of its increasing complexity, by modeling entities into objects, and encapsulating their implementation while just showing a public interface to the rest of the program. It is beyond doubt that OO does somewhat help to keep a tab on complexity. But it only works to certain level, and there are certain characteristic of OO that, at some point, can be seen as making things worse. For example, it is not always a good idea to hide the implementation behind an interface. It is, for example, well established by now that it is bad practice to hide the fact that an object is local, or at the far side of a network.

More fundamentally, objects can, and very often do, keep a state. Objects interact, and calling an object’s methods often changes its state. By giving objects public methods that can change its state, a programmer is effectively creating a protocol for interacting with the object. Sometimes certain methods have to be called in a certain order, or after a certain other method has been called at some point beforehand. A program then, consists of numerous objects of different classes, calling each other, following many different protocols, whose outcome and effect may be different depending on the state objects were in to begin with.

A programmer reading through a code base must try to grasp these protocols, and try to reconstruct how objects interact. This is hard. OO allows us to create boundless implicit protocols and stateful objects, but gives us few tools to cope with the dynamism of a running program. It’s hard to see how this promotes understandability.

Constraints

So, what can be done to reduce complexity?

When the complexity of a program gets out of hand, it may be a sign that there are too many degrees of freedom in its design. And the answer to that is to add constraints. Constraints can be added at various levels and in various ways. Below are a few examples.

• For example we can drastically reduce the number of protocols allowed on objects. An example of this is REST. But even within a single executable, having only a few well defined ways for objects to communicate can be a great benefit. At first, this architectural style may seem limiting. However, putting in place the right set of constraints forces a developer to think a design through more deeply and ultimately may lead to a better solution. A solution, that has fewer surprises and a less steep learning curve for newcomers to the code, as it adheres to a set of well defined expectations. In addition, constraints at this level, can lead to substantial architectural benefits at higher levels.
• As another example, without any constraints in place, arbitrary objects in a large program may call a public method on other objects far away in a different corner of the program. Having unbounded links between various parts of a large program greatly increases difficulty of understanding. However, depending on the nature of the program, it may be possible to establish, for example, a simple publish and subscribe mechanism of events, so that certain objects are constraint to raise events if their state changes, instead of directly calling methods on other objects, and others, quite independently react to the occurrence of such an event. The objects are decoupled, and the programmer trying to understand the dynamics will have a much easier job.
• Avoiding to store state in objects or systems can also increase understandability. Functional programming languages have seen an amazing rise in popularity in the last few years, even though they have been around since the earliest times. This can be understood, in a way, as a reaction to object orientation. Side effect free functions have many benefits, not the least of which is understandability. Explicitly passing state around, instead of hiding it in objects and changing it as side effects of methods can make things far easier to comprehend. In addition, it comes with fringe benefits involving concurrency and scalability.
• Breaking up programs in smaller parts makes it harder for those parts to communicate. Certain things, that are easy if those parts were in the same memory space are suddenly much harder to accomplish. In general, this will lead to communications becoming less fine-grained. If the boundaries at which to break up a big program in smaller ones are chosen right, this may again lead to less complex, less subtle code. As a result, the now independent parts can often be simplified considerably, having to focus on a more restricted, specialized subset. Understanding the broken up parts may be a lot easier than trying to grasp a big monolithic block of code.

More than five years have passed between 5.8 and 5.10. I’m pretty sure 5.10 was never planned though. A huge amount of effort has gone into the still elusive Perl 6. But who knows when it will be released*. Meanwhile, time has passed, other languages have caught up, and an evolutionary step was in order. Some of the new features (see here for much more):

• Regular expression Improvements
  • Named matching groups in regexes (from C#)
  • Recursive patterns (In an attempt to make them Turing complete?)
  • Possessive quantifiers (/C++/ takes on a wholy different meaning….)
• A switch like statement (“given”) with a smart match operator (a la Ruby)
• Static variables (C style)
• The new // (defined-or) operator

*When Matz was asked, at the 2007 Ruby Kaigi, when Ruby 2 will be released, his answer was “Two years after Perl 6″.