- Assertions:
The language should make it possible to equip a class and its features with assertions (preconditions, postconditions and invariants), relying on tools to produce documentation out of these assertions and, optionally, monitor them at run time.
- Information Hiding (Java is not good either on that one, the protected keyword is of dubious value):
It should be possible for the author of a class to specify that a feature is available to all clients, to no client, or to specified clients
- Static Typing:
A well-defined type system should, by enforcing a number of type declaration and compatibility rules, guarantee the run-time type safety of the systems it accepts.
- Genericity:
It should be possible to write classes with formal generic parameters representing arbitrary types.
Tags: book review
- Java really doesn't have first class support for pre/postconditions, although you can fake it with some 3rd party tools (JContract I think?). In reality you could probably add first class support for that in Ruby since all classes are open.
ReplyDelete- The value of static typing is dubious and could be debated until the end of time.
- Java's generics are hacky and erased at runtime anyways.
- The libraries available for Java is a major strong point, I'll give you that one. Performance - eh, its not like we are writing device drivers or operating systems in either of these languages.
Two other pluses you forgot for Java - the countless programmers available, and the acceptance at the corporate level.
Let's not forget its (and RoR's) lack of i18n features! Here's an experiment -- go to the bookstore and look for a chapter (or even a sentence!) on i18n features in RoR or Ruby in the two main published books. Can't find a chapter? Can't find a sentence? That's because it's not there.
ReplyDeleteI fail to see how Ruby lacks information hiding and genericity.
ReplyDeletehttp://en.wikipedia.org/wiki/Duck_typing
Maybe I misunderstood Ruby, but from what I have done with it, my impressions are:
ReplyDelete- duck typing _is_ different from genericity. For example you can't put anything in a Collection[Duck] but with duck typing, there is no such check, there is actually no way to know you really have Ducks in your collection except by checking everyone of them.
- private things can be extended in Ruby. So there is no information hiding possible when you extend a class.
If you really care that everything in the collection responds to a certain message, then you can easily enforce it by creating a DuckCollection, and overriding <<(object) or []=(object) to check to see if object.respond_to?(:message)
ReplyDeleteBertrand Meyer is barking mad.
ReplyDelete