Saturday, January 29, 2005



Ive just been reading through the archives in my aggregator and noticed an interesting point that Joel was trying to make but which he said he had trouble describing in english.

The point is about the difference between the discovery and application of knowledge. I like to refer to this divide as the difference between a technician and a scientist.

The technician is someone skilled in the art of applying knowledge. It is easy to learn and to use knowledge without necessarily understanding it. Its just following a set of instructions, a method if you like. The problem with method is that it does not allow you to solve problems or perform tasks which lie outside the rigid definition of what you have learnt.

If on the other hand you are a scientist, then you are skilled in the art of learning. The first thing a good scientist learns is how to learn. A good scientist will always attempt to understand what it is that they are learning, not just memorise the formulae. You see, the scientist recognises that it is not necessarily the knowledge of facts which is important, but rather the path by which those facts were derived. By understanding the path, you understand the reasoning. And if you understand the reasoning which produced the knowledge then you yourself are more likely to be able to extend that knowledge.

Everything has a context, and understanding that context allows us to move beyond mere recognition and application, it allows us to adapt and invent. To draw on our in depth understanding of how the knowledge was acquired and use it to create something new.

How many of use can truly say that we understand something enough to be able to arrive at it by our own powers of reasoning and deduction ?

Those that truly learn can.

Try it for yourself, take something you know for granted and attempt to arrive at it from first principles. Each time you do this, something in your mind will rewire itself, and your ability to do it again will improove until eventually you get to the point where nothing stands in your way. This is learning how to learn, and is the only important and most valuable education you will ever need.

Here are some examples to start you off, but remember that you don't necessarily have to succeed, you just have to understand how the knowledge was derived.

* Proove pythagorases theorem, with a picture.
* Create the basic components of a computer, with leggo.
* Perform long division in base 2, 8, 10, and 16.
* Proove that the earth is round, using two sticks.

Richard P Feynman is famous for having always taught himself from first principles which is perhaps some of the reason why he became such a magician.

"There are two kinds of geniuses: the 'ordinary' and the 'magicians'. An ordinary genius is a fellow whom you and I would be just as good as, if we were only many times better. There is no mystery as to how his mind works. Once we understand what they've done, we feel certain that we, too, could have done it. It is different with the magicians. Even after we understand what they have done it is completely dark. Richard Feynman is a magician of the highest calibre." - Mark Ka


Saturday, January 22, 2005


Duffs device
The original usenet posting
Google 20 year usenet timeline

I first saw this a few weeks back on googles 20 year usenet timeline. Sometimes optimisation can be so cool.

send(to, from, count)
register short *to, *from;
register count;
register n=(count+7)/8;
case 0: do{ *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;


Things we tried 4 years ago
Enterprise support for dynamic languages
Language oriented programming
Intentional software

If only parsers and compilers were written in a modular fashion. Then we could add anything we like at the abstract syntax tree level and have it compiled and targeted to our favorite binary format regardless of platform and language.

The distinction between logic and code is clear, why are compilers so far behind. This is the whole concept behind the push for intentional programming and domain specific languages. I want to write a search engine, why can't i have my own language for that which compiles into nice fast x86 instructions using GCC, surely its just a transformation ?

But instead i have to spend a lot of time writing good API's so that i can capture the knowledge which would be much better described in a domain specifc language... the domain specific language is what you scrawl on the whiteboard, its what you can describe to a fellow programmer and have them instantly understand what you want to do. And yet its so hard to put that down in syntax, thats because we have to do translation all the time. Surely its better to speak and think in the native language and only do translation when we want the machine to run it...

Theres such a huge gap between expressing an idea and implementing it. But if we break the problem down so that we produce a grammar for description and then a translator for implementation it becomes much easier. We no longer have to worry about bending our minds to describe and implement something at the same time.

I don't think everyone will ever write code as XML, but it makes sense to store the logic in an independent form. Programming should be more like mathematics with metadata. Less focus on the specifics, more focus on the algorithm and the description of intent.

Using a domain specific language is a natural thing for most programmers to do, after all we deal with abstraction every day. The great thing about abstraction is that it separates the problem from the solution and the implementation. We use interfaces to separate purpose from implementation, but we simply don't have the tools to separate language from logic...

What is required is good grammar processing and language description tools which can be combined with extensible editors and compilers. I can't help but think that if programming were more of a science we would have learnt long ago to separate the modelling from the construction.

Update: I noticed Jon Udell has some discussion on this topic, with a link to the same ACM Queue article that we've all read.

Deep structure redux
The deep structure of code