Is it really impossible to choose between LINQ and Stored Procedures?

For the mathematician there is no Ignorabimus, and, in my opinion, not at all for natural science either. … The true reason why [no one] has succeeded in finding an unsolvable problem is, in my opinion, that there is no unsolvable problem. In contrast to the foolish Ignoramibus, our credo avers:
We must know,
We shall know.

It’s that time of the month again – when all of the evangelically inclined mavens of Readify gather round to have the traditional debate. Despite the fact that they’ve had similar debates for years, they tend to tackle the arguments with gusto, trying to find a new angle of attack from which to sally forth in defence of their staunchly defended position. You may (assuming you never read the title of the post 🙂 be wondering what is it that could inspire such fanatical and unswerving devotion? What is it that could polarise an otherwise completely rational group of individuals into opposing poles that consider the other completely mad?

What is this Lilliputian debate? I’m sure you didn’t need to ask, considering it is symptomatic of the gaping wound in the side of modern software engineering. This flaw in software engineering is the elephant in the room that nobody talks about (although they talk an awful lot about the lack of space).

The traditional debate is, of course:

What’s the point of a database?

And I’m sure that there’s a lot I could say on the topic (there sure was yesterday) but the debate put me in a thoughtful mood. The elephant in the room, the gaping wound in the side of software engineering is just as simply stated:

How do we prove that a design is optimal?

That is the real reason we spend so much of our time rehearsing these architectural arguments, trying to win over the other side. Nobody gets evangelical about something they just know – they only evangelise about things they are not sure about. Most people don’t proclaim to the world that the sun will rise tomorrow. But like me, you may well devote a lot of bandwidth to the idea that the object domain is paramount, not the relational. As an object oriented specialist that is my central creed and highest article of faith. The traditional debate goes on because we just don’t have proof on either side. Both sides have thoroughly convincing arguments, and there is no decision procedure to choose between them.

So why don’t we just resolve it once and for all? The computer science and software engineering fraternity is probably the single largest focussed accumulation of IQ points gathered in the history of mankind. They all focus intensively on issues just like this. Surely it is not beyond them to answer the simple question of whether we should put our business logic into stored procedures or use an ORM product to dynamically generate SQL statements. My initial thought was “We Must Know, We Will Know” or words to that effect. There is nothing that can’t be solved given enough resolve and intelligence. If we have a will to do so, we could probably settle on a definitive way to describe an architecture so that we can decide what is best for a given problem.

Those of you who followed the link at the top of the post will have found references there to David Hilbert, and that should have given you enough of a clue to know that there’s a chance that my initial sentiment was probably a pipe dream. If you are still in the dark, I’m referring to Hilbert’s Entscheidungsproblem (or the Decision Problem in English) and I beg you to read Douglas Hofstadter’s magnificent Gödel, Escher, Bach – An eternal golden braid. This book is at the top of my all-time favourites list, and among the million interesting topics it covers, the decision problem is central.

The Decision Problem – a quick detour

One thing you’ll notice about the Entscheidungsproblem and Turing’s Halting Problem is that they are equivalent. They seem to be asking about different things, but at a deeper level the problems are the same. The decision problem asks whether there is a mechanical procedure to determine the truth of any mathematical statement. At the turn of the century they might have imagined some procedure that cranked through every derivation of the axioms of mathematical logic till it found a proof of the statement returning true. The problem with that brute-force approach is that mathematics allows a continual complexification and simplification of statements – it is non-monotonic. The implication is that just because you have applied every combination of the construction rules on all of the axioms up to a given length you can’t know whether there are new statements of the same length that could be found by the repeated application of growth and shrinkage rules that aren’t already in your list. That means that even though you may think you have a definitive list of all the true statements of a given length you may be wrong, so you can never give a false, only continue till you either find a concrete proof or disproof.

Because of these non-monotonic derivation rules, you will never be sure that no answer from your procedure means an answer of false. You will always have to wait and see. This is the equivalence between the Entscheidungsproblem and Alan Turing’s Halting Problem. If you knew your procedure would not halt, then you would just short-circuit the decision process and immediately answer false. If you knew that the procedure would halt, then you would just let it run and produce whatever true/false answer it came up with – either way, you would have a decision procedure. Unfortunately it’s not that easy, because the halting decision procedure has no overview of the whole of mathematics either, and can’t give an answer to the halting question. Ergo there is no decision procedure either. Besides, Kurt Gödel proved that there were undecidable problems, and the quest for a decision procedure was doomed to fail. he showed that even if you came up with a more sophisticated procedure than the brute force attack, you would still never get a decision procedure for all mathematics.

The Architectural Decision Problem

What has this got to do with deciding on the relative merits of two software designs? Is the issue of deciding between two designs also equivalent to the decision problem? Is it a constraint optimisation problem? You could enumerate the critical factors, assign a rank to them and then sum the scores for each design? That is exactly what I did in one of my recent posts entitled “The great Domain Model Debate – Solved!” Of course the ‘Solved!‘ part was partly tongue-in-cheek – I just provided a decision procedure for readers to distinguish between the competing designs of domain models.

One of the criticisms levelled at my offering for this problem was that my weights and scores were too subjective. I maintained that although my heuristic was flawed, it held the key to solving these design issues because there was the hope that there are objective measures of the importance of design criteria for each design, and it was possible to quantify the efficacy of each approach. But I’m beginning to wonder whether that’s really true. Let’s consider the domain model approach for a moment to see how we could quantify those figures.

Imagine that we could enumerate all of the criteria that pertained to the problem. Each represents an aspect of the value that architects place in a good design. In my previous post I considered such things as complexity, density of data storage, performance, maintainability etc. Obviously each of these figures varies in just how subjective it is. Complexity is a measure of how easy it is to understand. One programmer may be totally at home with a design whereas another may be confused. But there are measures of complexity that are objective that we could use. We could use that as an indicator of maintainability – the more complex a design is, the harder it would be to maintain.

This complexity measure would be more fundamental than any mere subjective measure, and would be tightly correlated with the subjective measure. Algorithmic complexity would be directly related to the degree of confusion a given developer would experience when first exposed to the design. Complexity affects our ability to remember the details of the design (as it is employed in a given context) and also our ability to mentally visualise the design and its uses. When we give a subjective measure of something like complexity, it may be due to the fact that we are looking at it from the wrong level. Yes, there is a subjective difference, but that is because of an objective difference that we are responding to.

It’s even possible to prove that such variables exist, so long as we are willing to agree that a subjective dislike that is completely whimsical is not worth incorporating into an assessment of a design’s worth. I’m thinking of such knee-jerk reactions like ‘we never use that design here‘ or ‘I don’t want to use it because I heard it was no good‘. Such opinions whilst strongly felt are of no value, because they don’t pertain to the design per-se but rather to a free-standing psychological state in the person who has them. The design could still be optimal, but that wouldn’t stop them from having that opinion. Confusion on the other hand has its origin in some aspect of the design, and thus should be factored in.

For each subjective criterion that we currently use to judge a design, there must be a set of objective criteria that cause it. If there are none, then we can discount it – it contributes nothing to an objective decision procedure – it is just a prejudice. If there are objective criteria, then we can substitute all occurrences of the subjective criterion in the decision procedure with the set of objective criteria. If we continue this process, we will eventually be left with nothing but objective criteria. At that point are we in a position to choose between two designs?

Judging a good design

It still remains to be seen whether we can enumerate all of the objective criteria that account for our experiences with a design, and its performance in production. It also remains for us to work out ways to measure them, and weigh their relative importance over other criteria. We are still in danger of slipping into a world of subjective opinions over what is most important. We should be able to apply some rigour because we’re aiming at a stationary target. Every design is produced to fulfil a set of requirements. Provided those requirements are fulfilled we can assess the design solely in terms of the objective criteria. We can filter out all of the designs that are incapable of meeting the requirements – all the designs that are left are guaranteed to do the job, but some will be better than others. If that requires that we formally specify our designs and requirements then (for the purposes of this argument) so be it. All that matters is that we are able to guarantee that all remaining designs are fit to be used. All that distinguishes them are performance and other quality criteria that can be objectively measured.

Standard practice in software engineering is to reduce a problem to its component parts, and attempt to then compose the system from those components in a way that fulfils the requirements for the system. Clearly there are internal structures to a system, and those structures cannot necessarily be weighed in isolation. There is a context in which parts of a design make sense, and they can only be judged within that context. Often we judge our design patterns as though they were isolated systems on their own. That’s why people sometimes decide to use design patterns before they have even worked out if they are appropriate. The traditional debate is one where we judge the efficacy of a certain type of data access approach in isolation of the system it’s to be used in. I’ve seen salesmen for major software companies do the same thing – their marks have decided they are going to use the product before they’ve worked out why they will do so. I wonder whether the components of our architectural decision procedure can be composed in the same way that our components are.

In the context that they’re to be used, will all systems have a monotonic effect on the quality of a system? Could we represent the quality of our system as a sum of scores of the various sub-designs in the system like this? (Q1 + Q2 + … + Qn) That would assume that the quality of the system is the sum of the quality of its parts which seems a bit naive to me – some systems will work well in combination, others will limit the damage of their neighbours and some will exacerbate problems that would have lain dormant in their absence. How are we to represent the calculus of software quality? Perhaps the answer lies in the architecture itself? If you were to measure the quality of each unique path through the system, then you would have a way to measure the quality of that path as though it was a sequence of operations with no choices or loops involved. You could then sum the quality of each of these paths weighted in favour of frequency of usage. That would eliminate all subjective bias and the impact of all sub designs would be proportional to the centrality of its role within the system as a whole. In most systems data access plays a part in pretty much all paths through a system, hence the disproportionate emphasis we place on it in the traditional debates.

Scientific Software Design?

Can we work out what these criteria are? If we could measure every aspect of the system (data that gets created, stored, communicated, the complexity of that data etc) then we have the physical side of the picture – what we still lack is all of those thorny subjective measures that matter. Remember though that these are the subjective measures that can be converted into objective measures. Each of those measures can thus be added to the mix. What’s left? All of the criteria that we don’t know to ask about, and all of the physical measurements that we don’t know how to make, or don’t even know we should make. That’s the elephant in the room. You don’t know what you don’t know. And if you did, then it would pretty immediately fall to some kind of scientific enquiry. But will we be in the same situation as science and mathematics was at the dawn of the 20th Century? Will we, like Lord Kelvin, declare that everything of substance about software architecture is known and all the future holds for us is the task of filling in the gaps?

Are these unknown criteria like the unknown paths through a mathematical derivation? Are they the fatal flaw that unhinges any attempt to assess the quality of a design, or are they the features that turns software engineering into a weird amalgam of mathematics, physics and psychology? There will never be any way for us to unequivocally say that we have found all of the criteria that truly determine the quality of a design. Any criteria that we can think of we can objectify – but it’s the ones we can’t or don’t think of that will undermine our confidence in a design and doom us to traditional debates. Here’s a new way to state Hilbert’s 10th Problem:

Is there a way to fully enumerate all of the criteria that determine the quality of a software design?

Or to put it another way

Will we know when we know enough to distinguish good designs from bad?

The spirit of the enlightenment is fading. That much is certain. The resurgence of religiosity in all parts of the world is a backward step. It pulls us away from that pioneering spirit that Kant called a maturing of the human spirit. Maturity is no longer needing authority figures to tell us what to think. He was talking about the grand program to roll back the stifling power of the church. In software design we still cling to the idea that there are authority figures that are infallible. When they proclaim a design as sound, then we use it without further analysis. Design patterns are our scriptures, and traditional wisdom the ultimate authority by which we judge our designs. I want to see the day when scientific method is routinely brought to bear on software designs. Only then will we have reached the state of maturity where we can judge each design on its objective merits. I wonder what the Readify Tech List will be like then?

Domain Modeling and Ontology Engineering

The semantic web is poised to influence us in ways that will be as radical as the early days of the Internet and World Wide Web. For software developers it will involve a paradigm shift, bringing new ways of thinking about the problems that we solve, and more-importantly bringing us new bags of tricks to play with.

One of the current favourite ways to add value to an existing system is through the application of data mining. Amazon is a great example of the power of data mining; it can offer you recommendations based on a statistical model of purchasing behaviour that are pretty accurate. It looks at what the other purchasers of a book bought, and uses that as a guide to make further recommendations.

What if it were able to make suggestions like this: We recommend that you also buy book XYZ because it discusses the same topics but in more depth. That kind of recommendation would be incredible. You would have faith in a recommendation like that, because it wasn’t tainted by the thermal noise of purchaser behaviour. I don’t know why, but every time I go shopping for books on computer science, Amazon keeps recommending that I buy Star Trek books. It just so happens that programmers are suckers for schlock sci-fi books, so there is always at least one offering amongst the CompSci selections.

The kind of domain understanding I described above is made possible through the application of Ontology Engineering. Ontology Engineering is nothing new – it has been around for years in one form or another. What makes it new and exciting for me is the work being done by the W3C on semantic web technologies. Tim Berners-Lee has not been resting on his laurels since he invented the World Wide Web. He and his team have been producing a connected set of specifications for the representation, exchange and use of domain models and rules (plus a lot else besides). This excites me, not least because I first got into Computer Science through an interest in philosophy. About 22 years ago, in a Sunday supplement newspaper a correspondent wrote about the wonderful new science of Artificial Intelligence. He described it as a playground of philosophers where for the first time hypotheses about the nature of mind and reality could be made manifest and subjected to the rigours of scientific investigation. That blew my mind – and I have never looked back.

Which brings us to the present day. Ontology engineering involves the production of ontologies, which are an abstract model of some domain. This is exactly what software developers do for a living, but with a difference. The Resource Description Framework (RDF) and the Web Ontology Language (OWL) are designed to be published and consumed across the web. They are not procedural languages – they describe a domain and its rules in such a way that inference engines can reason about the domain and draw conclusions. In essence the semantic web brings a clean, standardised, web enabled and rich language in which we can share expert systems. The magnitude of what this means is not clear yet but I suspect that it will change everything.

The same imperatives that drove the formulation of standards like OWL and RDF are at work in the object domain. A class definition is only meaningful in the sense that it carries data and its name has some meaning to a programmer. There is no inherent meaning in an object graph that can allow an independent software system to draw conclusions from it. Even the natural language labels we apply to classes can be vague or ambiguous. Large systems in complex industries need a way to add meaning to an existing system without breaking backwards compatibility. Semantic web applications will be of great value to the developer community because they will allow us to inject intelligence into our systems.

The current Web2.0 drive to add value to the user experience will eventually call for more intelligence than can practically be got from our massive OO systems. A market-driven search for competitiveness will drive the software development community to more fully embrace the semantic web as the only easy way to add intelligence to unwieldy systems.

In many systems the sheer complexity of the problem domain has led software designers to throw up their hands in disgust, and opt for data structures that are catch-all buckets of data. Previously, I have referred to them as untyped associative containers because more often than not the data ends up in a hash table or equivalent data structure. For the developer, the untyped associative container is pure evil on many levels – not least from performance, readability, and type-safety angles. Early attempts to create industry mark-up languages foundered on the same rocks. What was lacking was a common conceptual framework in which to describe an industry. That problem is addressed by ontologies.

In future, we will produce our relational and object oriented models as a side effect of the production of an ontology – the ontology may well be the repository of the intellectual property of an enterprise, and will be stored and processed by dedicated reasoners able to make gather insights about users and their needs. Semantically aware systems will inevitably out-compete the inflexible systems that we are currently working with because they will be able to react to the user in a way that seems natural.

I’m currently working on an extended article about using semantic web technologies with .NET. As part of that effort I produced a little ontology in the N3 notation to model what makes people tick. The ontology will be used by a reasoner in the travel and itinerary planning domain.

:Person a owl:Class .
:Need a owl:Class .
:PeriodicNeed rdfs:subClassOf :Need .
:Satisfier a owl:Class .
:need rdfs:domain :Person;
rdfs:range :Need .
:Rest rdfs:subClassOf :Need .
:Hunger rdfs:subClassOf :Need .
:StimulousHunger rdfs:subClassOf :Need .
:satisfies rdfs:domain :Satisfier;
rdfs:range :Need .
:Sleep a :Class;
rdfs:subClassOf :Satisfier ;
:satisfies :Rest .
:Eating a :Class;
rdfs:subClassOf :Satisisfier;
:satisfies :Hunger .
:Tourism a :Class;
rdfs:subClassOf :Satisisfier;
:satisfies :StimulousHunger .

In the travel industry, all travel agents – even online ones – are routed through centralised bureaus that give flight times, take bookings etc.  The only way that an online travel agency can distinguish themselves is if they are more smart and easier to use. They are tackling the later problem these days with AJAX, but they have yet to find effective ways to be more smart. An ontology that understands people a bit better is going to help them target their offerings more ‘delicately’. I don’t know about you, but I have portal sites that provide you with countless sales pitches on the one page. Endless checkboxes for extra services, and links to product partners that you might need something from. As the web becomes more interconnected, this is going to become more and more irritating. The systems must be able to understand that the last thing a user wants after a 28 hour flight is a guided tour of London, or tickets to the planetarium.

The example ontology above is a simple kind of upper ontology. It describes the world in the abstract to provide a kind of foundation off which to build more specific lower ontologies. This one just happens to model a kind of Freudian drive mechanism to describe how people’s wants and desires change over time (although the changing over time bit isn’t included in this example). Services can be tied to this upper ontology easily – restaurants provide Eating, which is a satisfier for hunger. Garfunkle’s restaurant (a type of Restaurant) is less than 200 metres from the Cecil Hotel (a type of Hotel that provides sleeping facilities, a satisfier of the need to rest) where you have a booking. Because all of these facts are subject to rules of inference, the inference engines can deduce that you may want to make a booking to eat at the hotel when you arrive, since it will have been 5 hours since you last satisfied your hunger.

The design of upper ontologies is frowned upon mightily in the relational and object oriented worlds – it smacks of over-engineering. For the first time we are seeing a new paradigm that will reward deeper analysis. I look forward to that day

StumbleUpon Toolbar Stumble It!

Linguistic development

Child Linguistic Development is a document that I wrote when I was at university on the stages of language development. Since Emily and Thomas are now a week short of 18 months it is time for Kerry and I to start learning about learning. I’d forgotten most of this stuff, so it will make interesting reading for me too! I’ve put a link in to kerry’s gorgeous new blog/journal, where she describes her day-to-day experiences of raising twins. Hair raising more than twin raising, if you want my opinion…

C#, Domain Models & the Semantic Web

I’ve recently been learning more about the OWL web ontology language in an attempt to find a way to represent SPARQL queries in LINQ. SPARQL and LINQ are very different, and the systems that they target are also dissimilar. Inevitably, it’s difficult to imagine the techniques to employ in translating a query from one language to the other without actually trying to implpement the LINQ extensions. I’ve got quite a long learning curve to climb. One thing is clear though: OWL, or some system very similar to it, is going to have a radical impact both on developers and society at large. The reason I haven’t posted in the last few weeks is because I’ve been writing an article/paper for publication in some related journal.  I decided to put up the abstract and the closing remarks of the paper here, just so you can see what I’ll be covering in more depth on this blog in the future: LINQ, OWL, & RDF.

PS: If you are the editor of a journal that would like to publish the article, please contact me by email and I’ll be in touch when it’s finished. As you will see, the article is very optimistic about the prospects of the semantic web (despite its seeming lack of uptake outside of academia), and puts forward the idea that with the right fusion of technologies and environments the semantic web will have an even faster and more pervasive impact on society than the world wide web. This is all based on the assumption that LINQ the query language is capable of representing the same queries as SPARQL.

Continue reading

A Speculative Notation


About 6 years ago I read a book by Edward de Bono, called modestly the de Bono Code Book. His idea was to devise a representation for thoughts and statements that went beyond the simple propositions from predicate logic. Initially, I was intrigued by the idea that I could learn to represent ideas in a way that was both terse, unambiguous and that enhanced my abilities to reason on paper. I quickly became disillusioned by the notation because it was both arbitrary and incomprehensible; there was no obvious way (as far as I could make out) for representing an arbitrary thought. It was more geared to making statements about internal emotional states, rather than giving a way to represent any idea. I decided that it may be a futile effort to even try, but I had a go at producing one for myself.

De Bono’s notation used a string of digits each enhancing the meaning of preceding digits. Codes would be represented as a string of digits read from left to right that started with the general universe of discourse and elaborated upon the speaker’s feelings in that context. I felt it was impossible to create subtle distinctions in this notation, and even harder to see the similarities in related statements. I also felt that it ought to be possible to treat the notation as a kind of programming language of thought. I came up with a little notation that grew into something not unlike an ontological markup language.

The notation has an internal structure that is invariant: [ subject | verb I object ]. The structure of all utterances follows this format except in the case where the subject is yourself (and you are writing to yourself) where it can be omitted if necessary. I augmented that notation by allowing the adornment of the three components of a statement with ‘glyphs‘ that modified the meaning of the nouns and verbs of the statement. Glyphs could indicate certainty of belief or probability like in a modal logic, as well as placing the elements in space and time. I quickly needed to add set definitions and existential quantifiers, since many of language utterances end up defining sets and their properties. Don’t believe me? Look at the previous sentence: “most of language utterances end up defining sets and their properties“. I’m defining a property on the set of all utterances in a natural language! It’s not surprising that set theory was paramount among the early attempts at creating universal languages.

For the sake of consistency in my set definitions, I just borrowed notations from propositional and predicate logic since they were terse, unambiguous and widely adopted. I was influenced by the formal methods courses on Z at university where we nerdily tried to find ways to tell jokes in Z. I even managed to formally specify the song My Old Man’s a Dustman by Lonny Donnegan. Like I said, it was a fun but nerdy pastime. We found ourselves doing that when we studied object oriented languages too. So very soon I introduced set membership, and whole-part relationships using the object oriented ‘dot’ notation. The end result was a mélange of mathematics, object oriented notation, set theory and regular expressions. It had extensions to allow it to be easily used in the arena of human thought where there are no certainties and thought has declarative and imperative modes.

What follows is a little explanation of the system that I posted on Everything2 back in 2000. It describes the notation and how it would be used. It also alludes to a non-formal bootstrapped specification of the notation in a subset of the notation. I still haven’t come up with a good name for it, so at the time I dubbed it ‘N‘ for Notation for want of a better name. In subsequent years there has been a lot of activity at W3C on the topic of ontologies. RDF arose as a popular representation of ontologies that could be expressed in a machine processable form. RDF also follows a 3-tuple (triple) format with relationships defined in a similar way to this notation. Where the two deviate is that my notation is designed to be human produced and consumed. It seeks to pile as much meaning in a proposition as possible. It doesn’t use multiple statements to elaborate the original relationship in space time etc. you could unravel statements in this notation into RDF, and I’ve often thought about creating parsers to do just that. I’ve even produced formal grammars for the language.

I’ll post a full example, plus a bootstrapped spec in my next post. Meanwhile, this will give you a little taste of what it’s like. And if you can think of a good name for it, please leave a comment.


A notational system that combines features from linguistics, logic and object oriented programming to allow complex expressions to be uttered about everyday things.

Use is made of structures and glyphs that allow the gross structure of a sentence to remain constant while the specific context and meaning of the utterance is modified by the glyphs. Such constancy of form allows the meaning to be easily captured, without the complexity required by the syntactic transformations of languages like English.


  • Speculative thought processes
  • Semi/Formal program analysis (Formal Methods)
  • Cleanroom Software Engineering Intended Functions
  • Dense notetaking
  • Semantic analysis of Natural Language Utterances
  • bootstrapping itself

Glyphs and Structures

The structures of N allow you to specify the causal structure of a thought, and then adorn it’s components with glyphs that specify more precisely the relationship between the bare content of the causal sequence described in the structure and the utterer of the sentence.

Formats exist for writing the notation a-la mathematics using TeX (still v-crude) and for using plain ASCII to communicate in a format such as this:

[N.structure_* | describe | causal sequence_*]

[N.glyph_* | adorn | N.structure.entity_*]

[N.glyph_* | modify_? | A.N.semantic]



Structures are employed to encode the causal structures that underlie utterances used in non-poetic (i.e. factual or working) language. Although linguistics distinguishes four broad types of utterance (phatic communion, informative, imperative, interrogative), according to the purposes to which they are put, it is possible to ignore phatic communion since it acts more like a protocol hand-shaking system rather than as a means of communicating. N exploits the regularity in the format of utterances in natural languages. That regularity is the grammar(s) of the language. I think that the grammar of the language reflects a mental model of causation in the brain of the speaker. Since all descriptive utterances in a natural language describe either static or dynamic situations. A dynamic state of affairs is the transition from one state of a system to another. A static description will describe the structure and properties of a system at a specific point in time. “Now” is the default time for most utterances. In general usage a static description would just be called a description. A dynamic description would be referred to as a description of an event.

As in English, N is able to render both static and dynamic descriptions, and within the same sentence. The structures used to describe events have three parts. They reflect the mental model that we use to recognize events. The structure contains a subject, verb and object. Natural languages vary in the order within a sentence that these entities come. Many languages including English included allow the ordering of these entities to vary. Or, to put it another way: English, the order of entities to vary will allow. N enforces a single order for entities in each utterance. The result is that it requires less work to interpret an utterance in N.

English, and all other natural languages, employ syntactic and morphemic transformations to the structure of a sentence, in order to specify details about the time, place, plurality, performer, and subject of an event. In so doing the gross structure of the sentence can be modified radically. For example, consider the sentence “I will drive the car.” and the sentence “I drove the car“. The transformation means that, to a casual glance, the sentences are different. On closer inspection, one can plainly see that they are the same sentence, modified to place the event in the future or past respectively. Similarly, “I am driving the car” incorporates new words and structures to indicate that the event is occurring in the present. The main transformations are to the verb “drive“. The verb is altered to indicate the tense of its operation. To adapt the tense to English sentence structure other syntactic changes must be incorporated. Both N and natural languages specify the role of the performer and subject of an event, but N does so explicitly, whereas natural languages often only give clues.

Dual Purpose Language

Frequently glyphs are used to clarify the relationship between the entities referred to in the bare content of the structure and the speaker of the utterance at the time and place that they uttered it. Language frequently serves two purposes then. The first is to describe an event, and the second is to describe the speaker’s relationship to it. That relationship can be spatio-temporal, moral, psychological etc.

Constant Structure Aids Gestalt Understanding

N is, in the formal presentation below, referred to as “N”. N uses glyphs (or graphical symbols) to adorn the basic present-tense form of a verb to indicate the tense modification. By doing so it does not require structural modifications to indicate the change in meaning of the sentence. For example the three driving examples given above would be represented in N as:

[I | drive_p | car] == “I drove the car.”

[I | drive_n | car] == “I am driving the car.”

[I | drive_f | car] == “I will drive the car.”

Speculativeness Aids Critical Thought

N has the advantage that with the use of glyphs one is able to progressively adorn the sentence which more meaning without changing the basic structure at all. N does not allow the writer to adorn a structure element with contradictory glyphs. In some cases one is able to give a visual representation to an English sentence structure that is not representable without additional glyphs of its own! Consider the following example.

[We | produce_f | Documentation] == “We will produce the documentation.”


might be adorned with the not sure (non-normative) glyph, which modifies the sentence to indicate that the item adorned, is unsure in our minds:

[We_? | produce_f | Documentation] == “Will ‘we produce the documentation.”

[We | \future{produce_?} | Documentation] == “Will we ‘produce the documentation.”

[We | produce_f | Documentation_?] == “Will we produce the ‘documentation.”


Under normal circumstances (N aside) one seldom inserts a linguist’s prime accent (‘) glyph into a sentence to stress a specific word. A prime accent requires active interpretation since its meaning can often be implicit and vague. There is no specific meaning to the prime accent either, so adornment with a prime will not enable the reader to comprehend what the prime signifies at a glance. So, as an alternative one has to adorn the whole sentence with an explanation:

[We_? | produce_f | Documentation] == “Is it us that will produce the documentation?”

[We | produce_f? | Documentation] == “Will we produce the documentation, or not produce it?”

[We | produce_f | Documentation_?] == “Will we produce the documentation, or something else?”


Clearly, the sentence has had to be expanded, modified, and adorned with the ‘?’ glyph anyway! Therefore it is safe to conclude that using glyphs is potentially much more powerful in what it can represent in a given space. It has the potential to allow one to represent something that might otherwise have been left ambiguous, which is a critical failure in all formal documents as well as other forms of communication. N may prove to be useful when using for example SMS messages where space is at such a premium that one already compresses speech beyond intelligible limits ;^}

An additional benefit of this adornment of static structures is that one is quickly able to view the “hidden” assumptions in a sentence. As in the example above, one can look at the basic units of meaning and their adornments and decide quickly whether one is completely sure that they should be there, and what part they play in the statement or instruction represented. Additional adornments allow the use of normative statements like “should we produce the documentation”. In this situation, as well, one can see the need to pull the sentence apart to signify which thing is open to choice.

For these reasons, I was tempted to call N a “speculative notation” since it allows its user to quickly root out the nature of their own mis-understandings, and address them with some sort of thought process. If the user is of a logical bent then they could quite easily use N within a formal proof framework. It has the benefit, though, that it is able to cleanly talk about complex human issues as well.

More Flexible Determiners Support Richer Thought Streams

When dealing with issues of non-trivial complexity, it is seldom possible to elucidate a train of thought without referring to more than one premise or sub-conclusion. The English language allows for just one level of “transferred subject”. By transferred subject I take to mean one that was previously the subject or object of a sentence. The transferred subject has to have been the subject or object of the immediately previous sentence. For example, consider the following sentences.

“N allows any number of determiners, over any scope. It also allows them to be modified in the same way as variables.”

The first sentence is easy:

[N | allow | determiner_* == d]


The second might be rendered with a structure such as the following:

[it | modify | them]=>[it.determiners =~ variables]


Obviously, the solution to disambiguate the English determiner ‘it’ is to substitute N for ‘it’ and d for determiner/many.

[N | modify | determiner]=>[N.determiners =~ variables]


This system works in exactly the same way as the determiners of English (the, that, it, them, etc). But consider what level of expansion would be required for the following group of statements

[consumer == C | receive_n | data]@local_host

[producer == P | transmit_p | data]@remote_host

[{P & C}.connection = “peer to peer connection”] == PPP

[{P & C & PPP} | provide_f | OSI.layer one]


These propositions (whether accurate or not 😉 form the structure of a set of statements about the basic elements of a TCP/IP connection. The final statement refers to the set of producer, consumer and peer to peer connection as the subjects of its statement. The obvious translation would be something like “they provide an OSI layer”. But, the previous statement is likely to have used “they” to refer to the set of P and C. So to use they again, when a new entity has been defined would confuse the situation, therefore the speaker is unlikely to use it. They will probably have to refer to all of the entities in the set explicitly by enumerating them. The articles them, and that refer to the objects of previous sentences. The articles he, she, they and it refer to the subject of previous sentences.

It can be seen that such variable-like determiners allows the simplification of arguments, as well as greater brevity and specificity when referring to a previous entity. In addition the determiners allow something like

[bob | drive_p == D | Car]


Which we can then augment with a following statement

[D == [drive = {unsafe & reckless & too fast}]]


English does not allow the use of determiners to refer to verbs within previous sentences, without explicitly referring to the verbs as an object, which would confuse the intent of the sentence altogether.

The Hidden War

Several years ago, I worked on a contract in Central London (That’s in Great Britain, an island off the coast of America) and I used to commute to work by train (that’s a bit like a long chauffeur-driven car on rails). Every few weeks or so, people used to commit suicide by hurling themselves under the trains. Generally, these terminal events took place in or around the Crawley or Hayward’s Heath areas. It just so happens that this area was a single line stretch of track and there was no easy way to go around the affected area. The net effect was always massive tailbacks and confusion in the rail network that spread out from the terminals (Hmmm, no pun intended, but weird huh?) affected in London to cover the whole region. This butterfly effect always happened during rush hours and always on weekdays.

I used to curse the departing souls of the selfish imolators to hell, blindly assuming that there was a continual stream of people killing themselves all over the country, and I had just been unfortunate enough to be affected by one of them at random. Now I realise that the imolators were guaranteed their place in heaven (with 72 virgins to cater to their every need, and presumably a free rail-pass for good behaviour). You see, I have penetrated the veil of happenstance to see the evil designs of a master-criminal at work. This spider-like Moriarty figure would never be so crude as to send people to blow up trains and buses (note the public transport links here. I’m not kidding) were he not trying to draw attention away from a more subtle and insidious gambit. One which is – I exaggerate only slightly – equivalent to Hitler, Stalin, Mao, Amin and Pol Pot combined in its cumulative horror.

You see, it all stems from Utilitarianism. As any morally sophisticated person can tell you, in a sentence, utilitarianism is that branch of ethics that seeks to do good by maximising the greatest good for the greatest number of the population. There is an implied calculus of pain in this statement that is being exploited by our criminal mastermind for the punishment and/or education of us infidels. It is easy to deduce the coefficients of this calculus as well. We can see from Newton’s laws that for every action there is an equal and opposite reaction. One man (or woman)’s death in Haywards heath is roughly equivalent to frustration and irritation for about 50,000 people for about 2 hours. To standardise, we shall call that unit the ‘crawley’ and it’s equal to roughly 100,000 grumble/hours.

We know that around 2 million people attended the march against war in Hyde park, London in Feb 2003. They were in attendance for about 5 hours, giving a total of 10 million grumble hours or 100 crawleys. That is – Osama bin Laden did the equivalent of 1.7 London Bombings without even having to get out of his seat. Multiply this by all of the demonstrations across the globe since then against the war and we have several times the devastation of the twin towers, and all he has to do is sit there, nice and cozy, in his dialysis machine in his cave there in Afghanistan, without moving a muscle. Add to that the huge dissatisfaction of the world with George W. Bush. Lets face it, how many people in the world have not spent at least an hour a week complaining about the wickedness of his regime and the general blindness of the Americans for not noticing, or caring.

It all adds up. If all the people in the world grumbled for just one hour – that would be equivalent to 20 times the September 11 attacks. Doubtless they have done a lot more than that! You’re not including areas of highly crawleyage such as the middle east, and amongst the poor. There’s a few more thousand crawleys for you. I find it shuddersome how this architect of woe has turned the very principle of a just and sane society, the very root and branch of liberal democracy, against us. Is it any wonder that this man has not been found, he needs to hide, to best achieve his nefarious ends. In fact he could achieve them even if he were dead. He’s a lot like Jesus Christ in that respect, a man who he must respect for the countless giga-crawleys of misery he has spread posthumously across the world.

Any relation to any persons past or present is wholely coincidental. Please don’t burn my effigy in the streets.

Books that I have loved.

I produced this list for Chris Palmer, who was interested in doing some background research on design patterns, design issues and programming best practice. I was planning on just jotting down some titles as they occurred to me, but when I sat down to think about all the books (of Computer Science or programming) that had inspired me, the list began to grow and grow. So I thought it might be worth committing it to a blog entry that I can refer to and extend later on.

These are things that were influential to me – some of them are now obsolete or irrelevant technologies (at least to someone specialising in C#/.NET), so should be ignored where appropriate, but there are nuggets of wisdom in them too. The design section is a little short – I guess my opinions are a combination of having made mistakes (the ones I noticed) and the consensus that is emerging out there (reflected in countless best practice articles on the forums and esp. MSDN which is a distillation of the forums) Some of the techniques rub off from using particular APIs – some rub off from watching the way APIs have changed over the years. Anyway, the ones that are there, are generally _current_ best practice…

Computer Science (& AI)
Gödel, Escher, Bach: An Eternal Golden Braid – Douglas Hofstadter
Probably the most beautiful book ever written. This is without doubt the most inspiring book I have ever read. It ties together strands of ideas from computer science, art, mathematics and neuroscience and (playfully) demonstrates the equivalence of so many deep and seemingly disparate ideas that I came away with a whole new outlook. I spent a whole summer working through this book, doing paper and pencil simulations of his languages and automata. It won the Pulitzer prize, which for a book on cognitive science is quite amazing. I can quite understand why, because it draws you into a deep and complex subject without you ever feeling out of your depth.

The Art of Computer Programming, Volumes 1-3 Boxed Set – Donald Knuth
This is arguably one of the best books on computer science. It is a distillation of the early work on computer science and contains an in depth analysis of the fundamental data structures and algorithms for sorting, searching, random number generation &c. It doesn’t reflect current programming concerns and all fo the code examples are in assembler, but it is deep and wide, and thus worth a $150 of anybodies money.

Introduction to Algorithms, Second Edition – Cormen, Lieserson and Rivest
This is my default reference for algorithms, much more clearly written and illustrated with pascal style pseudocode rather than MIX assembler. Less depth than Knuth, but with good analysis of algorithm time/space complexity.

Compilers – Aho Sethi and Ullman
This book is famously known as “The Dragon Book”. Compilers are one of the most complex peices of software you will ever write. This book focussed very heavily on state machines, and language equivalencies. I learned more about computer science from this book than from any other two books I ever read (except possibly GEB-AEGB). I guess I ought to place this near the top of the list.

Artificial Intelligence (3rd Edition) – Patrick Winston
A broad introduction to the science. A background reference. (This guy runs/ran MIT AI lab)

Out of Control: The New Biology of Machines, Social Systems and the Economic World – Kevin Kelly
A very inspiring look at the inter-connections between various sciences that inform and are informed by complexity theory (It was so hot 10 years ago, but where is it now?).

Adaptation in Natural and Artificial Systems: An Introductory Analysis with Applications to Biology, Control, and Artificial Intelligence – John Holland
This is the book that introduced the genetic algorithm, and promoted the emerging science of complexity theory. It contains a hard but cool mathematical analysis of the process of evolution.

The Age of Spiritual Machines: When Computers Exceed Human Intelligence – Ray Kurtzweil
This guy is a futurist who prodicts an omega point very soon. His ideas are over optimistic, but leave you breathless in their scope.

Mind Children : The Future of Robot and Human Intelligence – Hans Moravec
Very similar to the above. Radical hard AI with apocalyptic overtones, but very inspiring especially if your interested in how one of the leading roboticists views the future of his science.

Object-Oriented Analysis and Design with Applications – Grady Booch
Booch was a leading methodologist prior to the introduction of UML, and is arguably the largest influence on that standard. This book provides various heuristics to employ when designing OO software. I came away thinking that there was a lot of truth in this book, but that I was only ever going to ‘get’ it by going out there and programming. Design is not an academic subject in that sense – its got more to do with practice than theory. Just as one could read about aesthetics but never learn to paint, so one can read about design but never master it. I suppose its more of a way of criticising your efforts rather than a framework. I guess a design pattern is what’s left when you criticise your design in various problems and find that you’ve boiled your designs down to something similar each time. (I need to take a writing course – sorry)

Design Patterns – Gamma, Helm, Johnson and Vlissides (the gang of four)
The boiled down essence of 20 years of object oriented design. High value stuff, only depart from these designs after much thought…

Patterns of Enterprise Application Architecture – Martin Fowler
The same, only for enterprise designs. Lots of good stuff about data persistence and O/R Mapping here.

Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions – Hohpe & Wolfe
The same.

Inside OLE – Kraig Brockschmidt
This really got me into component based design. The whole thought process of working with COM is conducive to better software development, and (if you extend the idea to its logical conclusion) to service oriented development.
Advanced C++ Programming Styles and Idioms – James Coplien
Eiffel : The Language – Bertrand Mayer
This book explains the value of design by contract. It also demonstrates the core class libraries of the eiffel language, that were extremely elegant. It’s a pity this language didn’t take off.

Exceptional C++ Style : 40 New Engineering Puzzles, Programming Problems, and Solutions
(C++ in Depth Series) – Herb Sutter
This book explores some advanced reasoning behind the use of exceptions that apply as well to C# as to they do to C++. Some valuable concepts for dealing with errors.
Modern C++ Design: Generic Programming and Design Patterns Applied – Andrei Alexandrescu
Effective C++ : 55 Specific Ways to Improve Your Programs and Designs – Scott Meyers
The C# Programming Language – Anders Hejlsberg
Advanced .NET Remoting (C# Edition) – Ingo Rammer

Techniques & technologies

  • Write a compiler (any compiler) it’ll expand your perspective of how software works.
  • TCP/IP programming – write a sockets based programming system – send objects down it. It’ll give you an insight into how far we’ve come from 10 years ago, and why it is a good thing.
  • Master nant – write nant scripts for a complex project, then augment it with a task of your own. This is the build tool of the moment, and is better than VS.NET project files.
  • Mess about with NMock and mock objects – see where this leads you in developing code. You’ll find that to use it your code will have to be cleaner.
  • Develop an abstraction framework around some complex system that allows it to be removed/enhanced without writing/modifying any client code. This is hard to do and naturally promotes good design. This is where the bulk of my design efforts are spent these days – everything else flows out of this effort. Once you start doing this sort of thing you’ll notice that most best practice is actually idiomatic application of this technique.
  • Develop/use a code generator – most code is the expression of desires through the expansion of code (design patterns) with metadata. Name anything that you have written lately that wasn’t like that to some extent.