Ruby, Clojure, Ceylon: Same Goal, Different Results 138
snydeq writes "Charles Nutter, Rich Hickey, and Gavin King each discovered that 'simplicity' doesn't mean the same thing as they developed Ruby, Clojure, and Ceylon, respectively. 'Languages that are created with similar goals in mind may yield highly disparate final results, depending on how their communities understand those goals,' writes Andrew Oliver. 'At first, it surprised me that each language's creator directly or indirectly identified simplicity as his goal, as well as how differently the three creators and their languages' communities define what simplicity is. For Ruby, it is about a language that feels natural and gets out of your way to do what you want. For Clojure, it is about keeping the language itself simple. For Ceylon, it is a compromise between enabling the language to help, in King's words, "communicating algorithms to humans" and providing proper tooling support: the same general goal, three very different results.'"
Re:java backend is not simple. (Score:4, Interesting)
That's interesting. The creators of C# have a somewhat similar philosophy: they say that they would like it to be a "pit of quality", it should be easy to write correct code. But that doesn't mean they removed features that can be abused.
As a consequence, the things you mention (pointers, gotos, operator overloading) are all included. But for example in the case of pointers they are "hidden" (they have to be in an "unsafe" block).
On the other hand, for example fall-through switch cases are not allowed in C# at all, they thought those are not worth all the bugs they cause.
Re:java backend is not simple. (Score:2, Interesting)
Interfaces are about type checking and making your compiler happy, MI is about sharing implementation (which is mixed with type-checking in most of programming languages). Part of the confusion about interfaces and MI in Java is caused by tutorials and docs which wrongly mentions interfaces as a way of doing MI (Sun training I'm blaming you!).
The biggest problem with MI is the implementation: it leads to lots of "exceptional" cases in the handling on instance variables and method dispatch. If you google for "Principles of design behind Smalltalk" at the end of the article it mentions that future work will be to add MI to Smalltalk (that was in the 80's). They never added that "feature", because they found very little gains compared to the lots of exceptional cases and added complexity.
An alternative that's better from the implementation point of view is Traits. You can find examples of traits in Self, Smalltalk, Scala, and (I think) Dart.