2011/2/10 Bruno Medeiros <brunodomedeiros+spam@com.gmail>: > I'm very much a fan of simple and orthogonal languages. But this statement > has a big problem: it's not clear what one actually considers to be "simple" > and "orthogonal". What people consider to be orthogonal can vary not only a > little, but actually a lot. Sometimes it can actually vary so much as to be > on opposite sides. I remember seeing that first hand here on D: two people > were arguing for opposing things in D (I don't remember the particular > issue, but one was probably a greater language change, the other as for the > status quo, or a minor change from the status quo), and explicitly argued > that their alternative was more orthogonal! I remember thinking that one was > stretching the notion of orthogonality a bit further than the other, but I > didn't find any of them to actually be incorrect.
For the sake of discussion I'll define orthogonal as "non-redundant". For instance, orthogonal dimensions in a coordinate-system is when the dimension is completely unrelated to other dimensions, i.e. there is no redundancy in the coordinate-system. Likewise orthogonality in a language in my definition means it does not have redundancy in features. Now, the problem with orthogonality is that, it is not good for exploiting 80/20 optimisations. Example: for most (imperative) languages, you'll somewhere have the general way of iteration; list x; int i = 0; while (i < x.length) { // do something with x[i]; i++; } Now, if the language is truly orthogonal, you cannot add the "foreach (x in list)"-feature, since it's a redundant way of doing a subset of the same things. Yet, it's highly likely practical thinking says that for most programs in the language, 95% of all iteration will be list-iteration, where the foreach-version is both shorter to write, easier to read, and not as prone to a typo.