On 10/02/2011 21:38, Ulrik Mikaelsson wrote:
2011/2/10 Bruno Medeiros<[email protected]>:
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.
Ok. However, my notion of orthogonality is fairly different from that one.
--
Bruno Medeiros - Software Engineer
