> My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensit

> My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#? That's still true. The "feature" I has in mind is that methods in C# are not virtual by default. This is in direct contrast to Java where they are. This interview has a discussion on the motivation behind this (IMO incredibly tiresome) feature: http://www.artima.com/intv/nonvirtual.html http://www.artima.com/intv/nonvirtual.html. My view is that the real issue is that inheritance is all too often used when composition is more appropriate, which problem this change does nothing to help. > What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly? If it only makes the language better for "bad" programmers, I would consider it patronising. It also comes down to the intent of the language designer, by definition. > "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor? I think that's worthy of a different descriptor. A failure to anticipate the needs of programmers who are smarter or more disciplined or whatever - which is what such an omission seems like to me - may be a problem, but I don't see it as patronising.