Archive for November, 2010


Optimise Selectively, Type-Check Selectively

November 30, 2010

Heard of “write, first, optimise later”?” If you had
an infinite amount of time, you could optimise everything. Since you
don’t, you need to optimise the areas of code that need optimisation.
Likewise, if you apply high-strength static constraints to all your
code, you will spend a lot of time fixing pedantic issues that don’t make
a difference. (A correct programme will work without any checking.
Checking doesn’t make anything work. It tells you what
what isn’t working and why). Therefore, you need to selectively type-check
code regions that seem problematical — as already occurs in the selective use of runtime checks such as assert()s and error logging commands.


The Hardness of the Hard Problem in Computational Terms

November 28, 2010

Concerning David Chalmers’s Hard Problem of consciousness

There’s roughly four grades of easiness-difficulty:

  1. Complete theoretical and practical sucess, eg chess
  2. Partial theoretical and practical success, eg translation
  3. Practical failure, theoretically explained, eg halting problem
  4. Not even a theory, eg qualia. Ask a programmer how

to write a feeling algorithm, and they’ll look at you
like you’re crazy. There isn’t even a theory explaining
why it’s impossible. No-one knows where to start.


Scripting Languages and Prototyping

November 25, 2010

Prototyping — instantiating an object from another object rather than a class– is a useful feature in an object-orientated scripting language. (Javascript is an example of language with this feature).

A feature of scripting languages is that each line does some work — it should be possible

to write a 2 or 3 line programme that does something useful, and the “hello world” programme should be one line long. Scripting langiages are intended for small projects and immediacy. Class-based OO does not suit this , since there could be significant preamble before getting to the meat of the matter. Consider

with the Java “Hello World”

public static void main(String args[])
System.out.println("Hello World!");

Prototyping allows one to construct a useful object, rather than a class,

and inherit from that, obviating the need for a class framework that must

be instantiated before anything happens.


Languages that are static, dynamic and both

November 25, 2010

Software systems typically consist of low-level components

written in static and strongly type languages, strung together

with dynamic and loosely typed languages. (this is

still true of something like a stand-alone perl or python programme,

since the dynamic language calls standard routines written in C or C++).

By close coupling a mean an approach where there is a strong system

of typeing and other constraints which is implemented before

run time, so that explicitly coded run time checks are largely


Neither approach is right or wrong per se.

Close binding is appropriate to components, because building blocks

need to be reliable. Close binding is also possible with small building

blocks, because everything in a non-distributed system can be compiled

and linked together at a single point in time. However, with dstributed

systems (web services, RPC calls), one part of a system can be upgraded

separately from the other parts. There is then no way of guaranteeing

apriori that data passed will be of the appropriate kind and format.

This problem can be ameliorated by sending meta data along with

messages (as in XML) so that recipients can dynamically check that

the sender and format are what they are expecting.

Whilst dynamic, loosely coupled systems, and the languages associated

with them, have grown considerably since the 1980s, it would be a mistake

to think that static languages will die. Dynamic languages require interpreters

and virtual machines, and you cannot have an infinite stack of these. A compiled

language is needed at the bottom of the stack. Interpreters,

system software and low-level libraries will continue to be written in C and C++,

the survivors of a number of procedural and strongly typed languages of the 1970s

and 1980s.

Whilst the typical complex system is written in multiple (at least two)

languages reflecting the different paradigms, there is no logical

necessity for this: specifically there is no necessity to adopt

a different *syntax* in order to achieve stronger constraints.

A multi-paradigm language could do it all.


A syntactic tweak for recursion and function wrapping

November 25, 2010

In most languages

function myfunc(){

is a recursive call. This is  a pity, since  it *could* represent a piece of code that gnerated a new myfunc by calling an old one with some extra functionality , represented by the dots. This can in fact be done with operator overloading, but only if the type signature of the parameter list is changed, which may not be desirable. It can also be done by inheritance in an object context, but again an object context generally requires a modifiable resource, whereas it may be desirable to wrap a pure function


The Object-Relational Impedance Mismatch

November 25, 2010

As described here:

The origin of the problem is the expectation that everything should have an object description
or equivalent because the object view is general purpose. But in fact there is a more
general purpose paradigm: message passing. A method call on an object is  a special case of passing
a message, which is more tightly bound and less flexible with regard to when the resulting action
occurs and which object or process ultimately handles it.
Message-passing is a natural fit for the way database engines work.
database engines receive
messages (SQL queries) and generate responses from their encapsulated data.
Who cares in their encapsulated data isn’t object-style itself? The
point of  object orientation is encapsulation, and the point of encapsulation is that implementation
details don’t matter.

Encapsulation isnt an end in itself…the end is correctness of data. The ACID objectives are more general and powerful.