Oct 30, 2010

Semantics only works in a context

I am a believer of semantics. What is why name the domain as semanticsworks.com. But let me take a step back to explain what I mean semantics here. You may find the definition in Wikipedia, but what I mean semantics here is the true intention or need to do something. For example, when I say " I need a car to go to work", the true intention is "I need get to work", "a car" is just a means, or an implementation. If I work at home, I wouldn't need a car at all. As a software developer, I can easily apply semantics into programming. For example, I would prefer writing semantic html rather mix presentation html, I would focus on abstraction(interface) rather on implementation(class) and so on. When I study a a new technology, a new programming language, I will first think what problem it is trying to solve, then I focus how it solves the problem more efficiently and elegantly. When I want to propose my solution or design to my client, I would raise the what the existing problem is, and how my solution solve the problem in a better way. Semantics seems to work. But one important thing shouldn't be forgotten, that is a context. Here is what javascript guru Douglas Crockford said in his Loopage presentation


A little while ago I was talking to a friend of mine — a really bright guy, one of the smartest programmers I know – about what we should do next with JavaScript. I suggested to him that we should get the tail recursion thing going, we should get that fixed. Why do we want to do that? Well, I said, among a lot of other things it would allow us to do continuation style passing. I think that would be a useful option for us to be able to provide within the language, and if we don't optimize the tail calls then we don't get that. His answer was: I've never used continuation passing, so I really don't see the value of it, which I immediately recognized as a really stupid answer.

The way I was able to recognize it so fast is that I have used that same argument myself, and I've been hearing that same argument throughout my entire career. Basically, the core of that argument is: "I'm not qualified to make a decision about that. The onus is on you to educate me deeply about this thing that I'm not even interested in." There's no way to overcome that kind of requirement, nobody can win that argument. But it turns out that usually that reasoning is wrong. I've heard that argument about why we shouldn't have to worry about closure. I've heard it about why we shouldn't use recursion. I've heard it about why punch cards are better than timesharing. You can go all the way back to 'it's better for us to be programming with digits, I don't understand why we need compilers'. It's been going on from the beginning. That's why software development is so slow, because basically we have to wait for a generation to die off before we can get critical mass on the next good idea.

Semantics does not always works as we expect. Seemingly, Crockford forgot his friend's context. He should have let his friend buy in his context in the first place. When you try to propose a solution to solve a problem, which your client does not think as a problem, or does not see a need to solve it immediately, then your semantics will not work in your client's context. So here is what you can do.


  1. Think in the context of your client, don't propose a solution to solve a problem that your client has not interest in solving, only propose the solution in your client's context
  2. Think in the context of your client, guide your client to think in your context and make him believe that it is a problem, then propose your solution. Sometimes, this can be very hard, if the contexts collide heavily.
  3. Ignore your client and move on

There are lots new technologies coming, like Domain Specific Language, Cloud computing, Service Oriented Architecture etc. How soon they will be adopted will depends on how people can accept the contexts in which their designer think, and how soon people can accept these context will somewhat depend on the result the early adopters achieve.


A friend of mine asked me recently, what versioning control system should be used. I said "Git". He asked why? I said it is distributed versioning control system and it is scalable. Then He said, "We don't need it to be distributed.". You know, I made the same mistake, I lost the context of friend.