D vs Go on reddit

[Bruno Medeiros]

On 16/02/2011 18:15, Ulrik Mikaelsson wrote:
> 2011/2/16 Bruno Medeiros<brunodomedeiros+spam at 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