On 16/02/2011 18:15, Ulrik Mikaelsson wrote:
2011/2/16 Bruno Medeiros<brunodomedeiros+spam@com.gmail>:
We must not be saying (or thinking) the same thing then, because I do think
it is worthwhile to have orthogonality as one of the primary design goals.
I believe we are still not thinking of orthogonality in the same way. You
seem to be thinking in terms of pure simplicity, how easy a language is to
describe, learn and understand. I'm thinking of how much expressiveness you
get per amount of "complexity" (how easy it is to describe, learn, and
understand).
So considering C++ and Java again: then yes, C++ is much more complex than
Java (even new-school Java, barring generics perhaps). But I never said
otherwise. I did say that Java is not more orthogonal than C++, but not in
the sense that Java is just as orthogonal as C++. Rather I was trying to say
that the comparison doesn't make much sense in the first place, because Java
has much less "capabilities". Like, you can compare D's meta-programming
capabilites with C++, because in D you can do pretty much the same things as
C++ (if not more) meta-programming-wise, yet the way things work in D are
much more orthogonal, more simpler to describe and understand (and probably
because of that, more powerful). The same comparison could be done with
other features, like operator overloading between D and C++. But not between
C++ and Java because doesn't support most of this functionality (and it
doesn't make sense to compare with the Java alternatives)
I completely agree in all of this, but I think orthogonality is a poor
term for it.
I think what you're describing is closer to the term "elegance", in
the mathematical sense
(http://en.wikipedia.org/wiki/Mathematical_elegance). Mathematical
elegance is basically about
- Finding the "simplest" expression or solution for a problem, that
still accounts for all possibilities.
- Finding generally applicable solutions for many similar problems.
(Even when the do not seem very similar. Consider, for instance
physical velocity, and bitrates in computers)
- Finding a solution few dependencies on other work or assumptions.
It is also very close to the principle of Occams Razor,
(http://en.wikipedia.org/wiki/Occam's_razor), basically saying that
given two solutions to a problem which is equally "correct" (or equal
probability of being correct), the one that is "simpler" is
preferable. (The exact meaning of simpler is open to interpretation
though. ;)
A couple of good related quotes;
"Simplicity is the ultimate sophistication." - Da Vinci
"Make everything as simple as possible, but not simpler." - Einstein
Indeed. And also, to give some concrete examples of this principle in
terms of D language design (so as to not be talking in abstract terms only):
* making static arrays value types. The kind of hybrid/weird reference
type it was before was but a relic from C days, it did not add value to
the language, on the contrary...
* foreach_reverse... Although the presence of this statement did not
complicate the language in any significant way (unlike the static array
issue, which did make it harder to write generic code), it was clearly a
very specific functionality that could be generalized much better. Which
is what the idioms/API of ranges brought, and added much more value, in
a generalized and orthogonal way.
And finally one from Ockham himself:
"It is futile to do with more things that which can be done with fewer."
Yes! Very good quote, I love it. :)
--
Bruno Medeiros - Software Engineer
