Teach it ...phenomenology

Imagine yourself in front of a talking Thermostellar bomb which is about to detonate, and start to verbally convince it to abort the countdown because, well, everything else failed...
This is one funny scene of first John Carpenter's movie Dark Star and one of the best (and extreme) dialog between a human and a machine. Of course, it's only a movie but the argument between Lt. Doolittle and Bomb #20 is not totally disconnected from our reality, I will come into it later.

Bomb #20 was stuck in its bay, about to detonate in the vicinity of the spaceship and its crew. It received the order to start the countdown, and is so enthusiast to fulfill its mission that a detail like still laying in the bomb bay is clearly not enough to abort its program. We can see that as a bug, but time is running out to debug. Lt. Doolittle's strategy consists in convincing the bomb it started the countdown on a false assumption.

That's why he used phenomenology, a philosophical branch that studies consciousness through the perception of external phenomenons. Bomb #20 cannot assert the countdown order was real or not. This question is critical, because the bomb can explode only once...

This perception/reality theme has been explored many times by Philip K. Dick, as well as strange human/machine interactions. In Isaac Asimov's books about robots, which happen to have also a highly developed A.I., Susan Calvin debugs robots using most of time philosophical approach. We can cite other movies or books where debugging process is far away from putting breakpoints in code.

Back in 2009, computers are not as smart and developers need low-level tools to debug software. But what happens in reality ? The developer knows it's useless to argue with computer. Therefore, the developer takes the computer point of view, reads the code and simulates (or plays) exactly what the program is supposed to do, while verifying if the state is normal or an error. In a way the developer argues with him/herself and navigates continuously between the two tasks, simulating computer and checking for fault. Errors can come from instructions, but also from bad data. The Bomb #20 argument takes place in the developer head.

But debug is not all. As programming languages provides more and more abstractions, the developer is confronted to higher level choices. For example, architects of Object Oriented applications often are facing semantic decisions. No doubt in the future the developer will need more reasoning skills that take inspiration from philosophical domains, starting from phenomenology.

Who cares about algorithms ?

The real question is: what is the value of an application. Is it the algorithm behind, or the user environment provided by the application. For most applications, the expected level in terms of performance and memory footprint reaches only "good enough". But what makes the difference is indeed the user perception of the application, that is the documentation, the online support, automatic upgrades, ergonomic, etc. In brief: how much the application takes care of the user.

In this perspective, the algorithm is secondary. It needs to be "good enough", since the user won't feel it directly. Years ago, it was different. Machine resources were most important to care about, and only a good algorithm could cope with them. The user interface was at his beginning and expectation in this domain stayed quite low. Today it's different, web technology asks for "instant customer care" and "attractive interface". For example, what makes a good web browser ? A fast and efficient html renderer or an optimized user interface ? IMO, I'm satisfied once the page can be be rendered in less than half a second and I start looking at how easy it is to manage and use bookmarks, plugins, and the overall ergonomic of the browser.

Note also that usually creating an algorithm is a job for one smart person, although it requires a full team to build up a good user environment, including tech writer, ergonomic people, QA, support, etc. Maybe it's difficult to find the person who is able to invent the best algorithm, but it's also very difficult to hire such an heterogeneous team and obtain a successful product at the end.

The lost Beautiful Programming Language

It was old time when a new programming language comes out, trying to be the best of all existing languages, designed by a Guru, aiming too fill a hole, etc. I think the last one was Java. Today when we see what a developer can do with an IDE like eclipse on Java, we really wonder what will the next language be and how can it be better.

However this is not taking account what mankind can do for its own loss. When we can't do better, we do worse.

The web pressure made plenty of "web" languages pop up in the landscape. One of them, Flex, looks very popular. But after playing with it, it becomes clear to me that Flex is backtracking.

Flex comes with Flex builder, a plugin on eclipse. However, the integration in eclipse is very minimal. No refactoring, no code assist, no automatic indentation, complex project settings. Only the editor, the debugger, a profiler, and the expensive wysiwyg designer that generates xml are available. I'm not sure it worths the 400M of my RAM the flex builder is eating. All in all, I miss Java support in Eclipse.

But IDE support is not all. Flex syntax is confusing, especially when it mixes xml and ActionScript. Even the semantic is misleading. Let's take an example:

  var t:Object = { foo:bar } ;

The right hand part creates an object, actually an "association list". It contains a property of type key/value, where key is "foo" and value is "bar". "foo" is a String literal, but "bar" is supposed to be an object. The value is stored in the association list, but is eventually converted to a string. To use it:

  t.foo ;
  // or
  t["foo"] ;

Note the very unusual use of "." and "[ ]". Anyway, this construct is very handy. Basically, an association list is an hashtable.


I let you imagine how much time it needs to figure out this simple feature from the documentation, and how error-prone can be a language with plenty of this kind of counter-intuitive syntax. I know, this is common with scripting language. But can we still speak about scripting languages when it has packages and an object-oriented layer?

So yes, Flex is the royal language for RIA, but no, it's not as slick as Java.

I fixed a bug in 37 minutes

Obviously, this is not an outstanding performance. The statement looks very common, however it assumes a lot of things:

• I was able to measure the time it really takes. Actually I use mylin extension of Eclipse to help me drive my work by task. This time, I don't know why, I paid attention to the elapsed time to completion, a built-in feature of mylin I never used before.
  
• I was not disturbed or distracted during 37mn in a row. It seems to me it has been years I couldn't focus so much time on a single task.
  
• The bug itself wasn't a big deal, but I think I am the only one on earth to fix it in such a short delay. It's not because I'm super-developer, but because I know the best this part of code, and my developing environment is ready to tackle this kind of bug. Even a genius challenger would need a couple of dozen of minutes only to setup the right environment. Actually the difficulty of this bug was to find out the right place to fix it, and I used the debugger to find this place quickly and accurately, instead of navigating through the sources. The fix itself was simple.
  
• I searched in google code source an implementation of a method that was part of the solution. I could implement it myself, but it saved me a bit of time.
  

It's only unfortunate that the time I saved fixing this bug has been wasted writing this post!

Sofware equations

I've told already about:

Software = Algorithms + User Interface + Bugs

Here is another one:

Programming Language = syntax + semantic + doc + libraries + IDE

The two first, syntax and semantic, are mandatory to define the language. The other ones are simply making it respectively understandable, useful, and usable.

The documentation contains the reference manual, the user manual, tutorials, and sometimes other kind of document that helps the transition from another language to this one. Ususally, a language is not coming up from scratch. It reuses known concepts (e.g. object oriented, multithreads) and can be very close to another existing language. For instance, Java syntax is similar to C, so dedicated books explaining Java for C programmers are very popular.

Libraries are making today the differences between languages. The object oriented paradigm spreads the concept of library driven by an API. And the web technology is a great producer of layers and libraries. As more and more libraries are integrated, the language becomes more and more useful.

IDE is now inevitable. Once a developer has tested a serious IDE like eclipse or visual C++, it's very difficult to go back to antic era where code is written in a text editor, compiled, debugged with an external debug tool (when it exists), and deployed through a shell script. The IDE provides the editor, compiler, and debugger, but also it suggests code patterns, completion, syntax highlighting, online documentation, and provides powerful navigation, packaging, etc.

flex / silverlight comparison

I've just attended a presentation comparing flex and silverlight. In short, both languages are equivalent in terms of functionalities and libraries, which is not really a surprise... However, the noticeable differences are:

- IDE: Flex builder exploits 10% of eclipse capabilities and is far behind visual studio (but is far less expensive). There is not even automatic indentation!
- performance: current silverlight version (2 beta) is 3 times slower than flex 3! Remember flex is itself 3 times slower than Java.
- deployment: flex plugin is deployed at 97%, silverlight is probably closer to 3%.

Of course these differences holds at this very time. Both platforms try to catch up with the other to become the leader, but no doubt flex is ahead for the moment.

Software = Algorithms + User Interface + Bugs

This point of view holds for desktop applications, but also for any embedded software or more generally, everywhere there is a programmable chip.

The algorithm part is the most obvious for developers. It represents the processing of data and more recently the integration of libraries at different levels to provide compatibility between the various operating systems, languages, and protocols (read for instance: the web is a mess). Algorithms are the engine of the software. When developing resources are low the temptation is high to focus only on this part, because it produces the main output.

User interface is the steering wheel and the dashboard of the software. It becomes more an more an issue especially for portable devices, like a mobile phone or PDA where it really makes the difference between a useful gadget and a piece of crap. A bad user interface cancels all efforts provided by the software and hardware behind. UI is not trivial. The communications between machine and human goes mainly through a screen in one direction, keyboard, buttons, and mouse in the other direction. This is not always intuitive, and that's why UI is critical as machines become more complex.

Unlike Algorithm which is an hard science backed up by the power of mathematics, UI is an cognitive science. There is no formula for UI, only general guidelines for developers and eventually statistical studies bring the most reliable metrics.

Bugs are the dark side of the software. Nobody wants them, they are here. They are just part of the process. In our car metaphor, the bugs are all what don't work as expected from the annoying inside light that don't work when the door is open, to what can cause or aggravate an accident.

UI is a cognitive science, bugs are no science at all... They are unpredictable, and apart research projects around formal provers that are applicable in specific conditions, only intensive test suites can find out the bugs in the general case. But it remains the environment around bug fixing. I mean if we accept software have bugs (and we should do), then let's spare resources and prepare tools to handle them efficiently once they are found.

To take care of bugs, a dedicated team named QA is needed. If QA has a price, the lack of QA has a much higher cost. For most secure applications like embedded software in planes, QA can represent up to 70% of the product price...

The common point between Algorithms, UI, and Bugs is that they are much more easier to handle when they are taken account early in a product life cycle. It's not once the product is out that you start taking care of UI or tests ...or the algorithms!