Tuesday, July 26, 2005


I was fumbling through some old code this evening after discovering that my original interpretaion of the slightly skewed BNF grammar used in FRC2396 was incorrect. Obviously despite creating the standard Sir Tim Burners Lee hadn't quite got the hang of hyperlinking yet, and so it is generally left up to the reader to discover the reference to RFC822 in the third paragraph of section 1.6, and hence forth seek out the correct interpretation.

Speaking of hyperlinking, i found an amusing anecdote in my comments which i thought might be worth sharing. It originates from the W3C axioms of web architecture, and pretty much states that the internet in its current form is a complete abomination.

All the same, a word of caution is appropriate about the indiscriminate or deliberately misleading abuse of the identity of the object referred to by a URI. A web server is often in a position to know a lot of context about a request. This can include for example, the person who is asking, the document they were reading last from which they followed the link. It is possible to use this information to ramatically change the content of the document referred to. This undermines the concept of identity and of reference in general. To do that without making it clear is misleading both to anyone who quotes the URI of a page or who follows the link.

Unless it is clearly indicated on the page (or using a future protocol) , to return differing information for the same URI must be considered a form of deception. It also of course messes up caches.

Reflect on this next time you create some dynamic content...

Saturday, July 23, 2005


Sometimes, just sometimes the compiler is actually right.

The problem is, not always. Like every nascent computer user sometimes even seasoned programmers arbitrarily distrust the machine.

Technofear.n - The result of seemingly random
consequences caused by the actions of inept users
leeding to a deep sense of confusion and distrust
for technology. i.e. "programming the vcr"

You see, as a programmer, even more so than a user it is essential to be able to trust the tools that you use to produce the results that you expect. The programmer must have faith that the compiler tells the truth in all matters and all things.

For if the compiler lies, then the programmer is sure to spend many countless frustrating hours chasing bugs which don't exists. And eventually their confidence will be eroded to the point that they will also waste countless hours swearing at the compiler for producing an error, which in fact is genuine.

Unfortunately its a bit of a boy who cried wolf scenario, and the horrible truth and shame about the software industry, is that even today, all compilers lie.

Anyone who has ever misplaced a curly brace or two and received a cascade of endless random errors from their compiler knows this shameful fact of life.

So then, it is left to the programmer to develop their own intuitive understanding of the particular tools and compilers that they use, to the point that they know when an error is and error and when the machine just needs a good kick. This truly is the art of programming, and perhaps more than you might think it can separate the good programmers from the great programmers, and at the very least, the frustrated from the productive.

Ive just fixed a rather good example of such an error. And fortunately for me, i chose wisely in trusting the compiler in what seemed like a perfect opportunity not too. You see, my program was operating correctly in debug, but failing in release.

An obvious problem you may suggest, but not quite. You see, if i slowed the program down in release, it worked correctly. Ahhh! i hear you say, "clearly youve got a race condition between one or more threads". But alas, there is only a single thread and the timing is very subtle.

It sure did look like one of those occasions where one may be tempted to start looking under the rug for a wolf. But i held fast and debugged the code into the long hours of the night. And after much toiling, and tracing, and printing as there are only limited ways one can effectively debug release code, i started to narrow the trail.

After two days of debugging i found the problem.

It was caused by two objects being compared by memory addresses. In the world of debug code, memory addresses are consecutive manufactured things, contrived to make the task of debugging easier for the programmer. But in release code, memory addresses are random highly variable things. So in debug, object A was less than object B, but in release where the memory was different, object B was less than object A.

At its root was an innocuous problem, but it was burried deep in thousands of lines of code. Knowing when to trust and when to distrust your tools is critical, becuase sometimes...

The compiler is actually right.