Skip to main content

Posts

Concept Oriented Markup

I have long been frustrated with all the different text mark up languages and word processors that I have used. There are many reasons for this; but the biggest issue is that markups (including very powerful ones like TeX) are not targeted at the kind of stuff I write. Nowadays, it seems archaic to still be thinking in terms of sections and chapters. The world is linked and that applies to the kind of technical writing that I do. I believe that the issue is fundamental. A concept like "section" is inherently about the structure of a document. But, what I want to focus on are concepts like "example", "definition", and "function type". A second problem is that, in a complex environment, the range of documentation that is available to an individual reader is actually composed of multiple sources. Javadoc exemplifies this: an individual library may be documented using Javadoc into a single HTML tree. However, most programmers require access to multip...

Comments Should be Meaningless

This is something of a counterintuitive idea: Comments should be meaningless What, I hear you ask, are you talking about? Comments should communicate to the reader! At least that is the received conventional wisdom handed does over the last few centuries (decades at least). Well, certainly, if you are programming in Assembler, or C, then yes, comments should convey meaning because the programming language cannot So, conversely, as a comment on the programming language itself, anytime the programmer feels the imperative to write a meaningful comment it is because the language is not able to convey the intent of the programmer. I have already noticed that I write far fewer comments in my Java programs than in my C programs.  That is because Java is able to capture more of my meaning and comments would be superfluous. So, if a language were able to capture all of my intentions, I would never need to write a comment. Hence the title of this blog.

Robotic Wisdom

It seems to me that one of the basic questions that haunt AI researchers is 'what have we missed?' Assuming that the goal of AI is to create intelligence with similar performance to natural intelligence; what are the key ingredients to such a capability? There is an old saw It takes 10,000 hours to master a skill There is a lot of truth to that; it effectively amounts to 10 years of more-or-less full-time focus. This has been demonstrated for many fields of activity from learning an instrument, learning a language or learning to program. But it does not take 10,000 hours to figure out if it is raining outside, and to decide to carry an umbrella. What is the difference? One informal way of distinguishing the two forms of learning is to categorize one as `muscle memory' and the other as 'declarative memory'. Typically, skills take a lot of practice to acquire, whereas declarative learning is instant. Skills are more permanent too: you tend not to forget a skill; but i...

A Tale of Three Loops

This one has been cooking for a very long time. Like many professional programmers I have often wondered what is it about programming that is just hard . Too hard in fact. My intuition has led me in the direction of turing completeness: as soon as a language becomes Turing complete it also gathers to itself a level of complexity and difficulty that results in crossed eyes. Still, it has been difficult to pin point exactly what is going on. A Simple Loop Imagine that your task is to add up a list of numbers. Simple enough. If you are a hard boiled programmer, then you will write a loop that looks a bit like: int total = 0; for(Integer ix:table) total += ix; Simple, but full of pitfalls. For one thing we have a lot of extra detail in this code that represents additional commitment: We have had to fix on the type of the number being totaled. We have had to know about Java's boxed v.s. unboxed types. We have had to sequentialize the process of adding up the numbers. While one loo...

The true role of domain specific languages

It is easy to be confused by the term domain specific language. It sounds like a fancy term for jargon. It is often interpreted to mean some form of specialized language. I would like to explore another role for them: as vehicles for policy statements . In mathematics there are many examples of instances where it is easier to attack a problem by solving a more general, more uniform, problem and then specializing the result to get the desired answer. It is very similar in programming: most programs take the form of a general mechanism paired with a policy that controls the machine. Taken seriously, you can see this effect down to the smallest example: fact(n) where n>0 is n*fact(n-1); fact(0) is 1 is a general machine for computing factorial; and the expression: fact(10) is a policy 'assertion' that specifies which particular use of the factorial machine is intended. One important aspect of policies is that they need to be intelligible to the owner of the machine: unlike the...

Single Inheritance and Other Modeling Conundrums

Sometimes a restriction in a programming language makes sense and no sense at all — all at the same time. Modeling the real world Think about the Java restrictions on the modeling of classes: a given class can only have one supertype and a given object's class is fixed for its lifetime. From a programming language perspective these restrictions make a good deal of sense: all kinds of ambiguities are possible with multiple inheritance and the very idea of allowing an object to be 'rebased' fills the compiler writer with horror. (Though SmallTalk allows it.) The problem is that, in real life, these things do happen. A 'natural' domain model is quite likely to come up with situations involving multiple inheritance and dynamic rebasing. For example, a person can go from being a customer, to an employee, to a manager to being retired. A given person might be both an employee and a customer simultaneously (someone else may not be). Given a domain that is as flexible as th...

Too Many Moving Parts

A common, if somewhat informal, observation about a large code base is that there are "too many moving parts" in it. In my experience, this is especially true for large Java systems but is probably universally true. What do we mean by ‘too many moving parts’? Simply put, there is always a significant semantic gap between a programming language and the program. The larger this gap, the more that has to be expressed in the language, as opposed to simply using it. For example, consider the problem of traversing a recursive tree structure. In Java, we can iterate over an Iterable ; structure using a loop, for example, to count elements: int count = 0; for(E el:tree) {   count++; } If the Tree class did not implement Iterable we would be forced to construct an explicit iterator (or worse, write a recursive one-off function): int count = 0; for(Iterator<E> it=tree.iterator(); it.hasNext();) {   E el = it.next();   count++; } This version illustrates what ...