An example of magical thinking / user-interface that I didn't notice before :

We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells.

I'm debating Simon Wardley (read comments) over what generalist computer programmers with their understanding of abstraction can bring to specialist science.

Meanwhile he finds a great video of embedding electronics in paper.

Why Geeks are doomed in a Suit world. :-(

Joel Spolsky said something interesting in his critique of Java-oriented Computer Science eduction.

Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer

This is so true. Great geeks understand the importance of the mental ducking and diving and wheeling and loop-the-looping up and down the layers of abstraction. The Geek's job is to see at all levels so that the requirements of one level can be solved by implementations further down.

But now consider the perenial Suit complaint of the Geek : that he starts getting bogged down in unnecessary technical details when he should just be giving a high-level progress report or talking to the customer about her problems.

He doesn't "understand business" the Suit thinks.

How tragically, irritatingly wrong. The Geek's job is to make the abstraction levels fit together. Of course the only way to achieve this is with an understanding of both the higher and the lower levels : simultaneously. And the easy shifting from one to another.

But Suits love to keep the levels separate. Their whole reason for existence, their positions depend on the notion that the levels are distinct. The rigid company hierarchy is the reification of non-traversable levels of abstraction.

It is obvious to them that "business" can be understood through the abstraction of accounting. And that the senior managers make visionary plans which require highly abstract inferences about strategic relations but don't require understanding the gritty details of technology.

To the Suit, Geek thinking, that swoops between the layers of abstraction, that claims the right to think of the problem from any perspective, is anathema.

Tim Berners Lee unconsciously pinpoints exactly what is wrong with the idea of a Semantic Web.

He thinks Semantics are a kind of "higher-level" of abstraction on top of existing syntactic web-technologies. So, for example, "documents about people" are somehow "higher-level" than mere documents.

But he's got things standing on their head.

"3 oranges" is not an abstraction on top of the number "3". In fact the idea "3" is an abstraction out of all the concrete cases like 3 oranges, 3 apples, 3 Pan Galactic Gargle Blasters etc.

The higher up the levels of abstraction you go, the fewer semantic commitments you make. That's why Alan Kay points out that higher-levels of abstraction are associated with later binding in programming languages. A dynamically typed language like Python only binds names to types at run-time, whereas a more statically bound language like Java binds them at compile time. Hence it's possible to write more generic routines in Python (ones that don't care whether they're working on integers, strings or Pan Galactic Gargle Blasters) than it is in Java.

The greatest "hits" of software : relational databases, spreadsheets, word-processors, blogs etc. are those which provide powerful syntactic abstractions (relational operations, pivot-tables, paragraphs, feeds etc.) while leaving the semantic commitments as late as possible. Usually up to the end-user or some specialist business analyst working in a domain specific language like SQL.

OTOH, often the worst (heaviest, clumsiest, hardest to change, least pleasant to use etc.) software is that which either through necessity or bad design is riddled with premature semantic commitments. Software which tries to bake "customer" in at a fundamental level and assumes "customer" has-one phone-number and has-one web-site, but didn't know that we'll be sending Tweets to customers about the status of their order, and so doesn't know that customers have Twitter ids.

This is the problem with the SemWeb ... it assumes we want applications that start from the semantics. But most of the time, we don't. We want powerful syntactic abstractions over which we layer our own meaning.