"Don't Model Everything"

From different directions I received links to Steve Yegge's post "Portrait of a N00b" and although the length of it certainly qualifies it not to be read by me, at a certain point you just give in.

Now Yegge's post is long, read it during your lunch break or something. This is my 100-words-or-less summary: new programmers are metadata obsessed and as you grow older (10+ years or more programming experience) you start to see that metadata (such as comments and excessive modeling) is not the answer to all problems in life.

The picture of Heidi Klum at the right is completely unrelated to this post by the way, except for the fact she's also a model (and often objectified) -- and not everything nor everyone has to be a model. There's some random wisdom for ya.

Anyway. Some quotes I find relevent to my work:

And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success, for the exact same reason the Semantic Web is a failure. You can't force people to provide metadata for everything they do. They'll hate you.

One very real technical problem with the forced-modeling approaches that static type systems are often "wrong". It may be hard to imagine, because by a certain definition they can't be "wrong": the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is "wrong" whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java's type system, Java is "wrong", because it can't do what you want. You have to take the most natural design and corrupt it to fit Java's view of the world.

[...]

Java has been overrun by metadata-addicted n00bs. You can't go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can't actually model everything; it's formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you're a Bad Citizen.

I feel I should respond to this, because it seems to be a direct attack at the work that we are doing. Are we the part of the "static-typing movement within academia"?

We do like static typing. WebDSL is fully typechecked. And we do force you to model everything. I'm not so sure this the kind of modeling that Yegge refers to here though. In my view there are two kinds of modeling:

  1. Modeling as a means to organize the software (directories, libraries, modules, classes, methods) -- this is what I think Yegge refers to
  2. Semantic modeling (in WebDSL: entities, pages, actions, access control rules) -- this is what we try to do

The first one you could argue is not always absolutely necessary. Your software works just as well when you dump everything in one directory and one namespace or even class (why else would there be such a thing as a God class?). The second kind of modeling is what we attempt to do. The win in this kind of modeling is that we can write software that actually "understands" these models and can do clever things with it.

You should really avoid abusing models for means they were not intended for, as Yegge points out. Often you can achieve a lot with clever tricks, but what should really be done is extending the meta-model. Meta-wha!? Extending the programming language, essentially. In Java this is not really possible, of course. The compilers we build for our modeling languages (such as WebDSL), however, are designed to be (relatively) easy to extend so that if you cannot model something, it is easy to extend the language to add construct that make modeling of it possible, or at least simpler.

The third point from Yegge's quote is about how you cannot model everything. That is probably true, so in the future we will work on "back doors" within our modeling languages to lower-level languages such as Java. So that if there is something you cannot model, and it is really not worth extending the language to add a modeling mechanism for this, you can just quickly hack it in Java, or whatever the target language may be.