As far as I can tell, the whole nominal typing thing is a failure. Inheritance is simply fraught with problems which make it extremely subtly wrong in many, many cases. There’s still a lot to be said for the correctness guaranties of static typing, but making all of that nominal and not structural is just wrong.

BTW, String isn’t too far from an interface these days — check out CharSequence that came in with 1.5. Of course, people still accept “String”s all the time when they could perfectly well expect “CharSequence”s, so the kind of thing where Sun is paddling upstream. But, if you hit a small piece of code or are working on a library and you want to be really nice to future maintainers, there you go.

In Java, not open a class but subclass a class. For example, it would be nice to use the type checking system to enforce certain encoding issues. Let’s use a trivial case: to have two kinds of String, HTMLString where HTML entities are already converted and PlainString where they are not.

if you can subclass String, you can use Java’s strong, static type checking to ensure that you do not accidentally pass a PlainString to a method expecting an HTMLString. But since you cannot subclass String, nor is it an interface you can implement, you must write a container class and constantly reference and dereference an instance member.

Some folks argue this is a good thing, because if they write a method expecting a String, they want a guarantee it is a String and not something else I have deemed to have Liskov equivalence to a String.

I suppose, at the end of the day, I’m just not a fan of running with scissors into production.

http://www.laputan.org/mud/

The shared dependencies issue with Ruby is well-known. It actually reminds me of “DLL Hell” in Windows. If you think of modified classes as versions, you have a version control problem. OTOH, you also have an opportunity to reach out and modify other people’s code without their permission, which is a no-no to some people and a blessing to others.

For example, you may want to modify a base class and make sure that another piece of code you didn’t write uses your modified class. For example, you could wrap some AOP around various method calls and what-not.

Is that a worthwhile trade-off? I don’t know yet. I know that Java takes a very strong position on this: not only can you not modify core classes without magic (I speak as a magician, I have written code that uses a custom class loader to modify the byte codes of classes on the fly), but you also cannot subclass certain core classes like String.

That has been enormously frustrating for certain work I have done, but the powers-that-be have decided that they want to turn the knob over to “safe.” Matz has explicitly said that Ruby is a pair of scissors and Ruby programmers are encouraged to run with them.

Good idea? Bad idea? I honestly do not think the matter can be decided by simple inspection and reasoning. My experience with open classes in Ruby so far is mixed. There are things I like and things that concern me. My experience with Java so far is that I dislike its locked down approach. I am interested in how languages liek Scala are approaching these issues.

BTW, this problem is much bigger than just Open Classes. I recall an exchange of blog posts over final classes and final methods. Declaring that nobody can subclass your class is really very similar to declaring that nobody can open your class.

You’re right in that my second sentence in that post was an unsubstantiated conjecture. What about the hidden dependencies assertion? That’s an actual example of a difference between Java and Ruby which provides a clear protection against code interdependency.

I think we are bandying unsubstantiated opinions around. I find it very hard to believe that any programming language gracefully guides programmers to creating programs with well-separated concerns.

My conjecture (and I admit it is a conjecture) is that if (If!!!) you were to examine a bunch of actual projects in language X and another bunch of actual projects in language Y and you found that X had more BBoMs than Y, the cultures of X and Y would have a much bigger impact than the features of X and Y.

But I can tell you from observation that if it is difficult to write a BBoM in Java, the Java programmers I have met have proven their prowess :-)

I think there’s a problem which you’re glossing over. Sure, you can write a Java program that’s a ball of mud, but it takes a lot more effort than to write a Ruby ball of mud.

Particularly when you factor in “hidden dependencies” like external mangling of the classes (e.g. Logger, Symbol), it becomes very hard very quickly to see what all the dependencies are for a given piece of code. At least in Java, I can lock down my code and know that it’s going to work on any JVM, no matter what other code has been executed beforehand. That’s not something I’ve got in Ruby — that kind of code safety is simply not supported by the language.