> Languages such as C# and Java have done many a disservice with their keywords abstract and interface. There is a common misconception that by creating an interface one can make an object abstract and improve the design of a system.
This doesn't make any sense. In Java, etc., "abstract" is just a technical term relating to the type system. It means these are types which do not have a complete implementation, so instances cannot be created. The word is used as an antonym of concrete, another technical term which describes types that can be instantiated.
It doesn't mean any of this stuff about changing the abstraction level or improving the design of the system. The author seems not to understand that a word can have two different meanings even within a single subject area.
While I'm griping, if you are looking at the semi-arbitrary choice of programming language keywords and letting that shape the big picture of how you view software design, you're going to have a bad time. "It said 'abstract' so this must be the way of creating abstractions." If that's the type of reasoning you use, the programming language designers aren't the ones doing you a disservice; you are.
While you are right, I find you a bit rude. If the new generations of developers cannot easily grasp the vocabulary or past concepts of a language, why do you think the new generation is disservicing itself? If the new generation feels disserved by an older language, they will move to, or create, something that better fits their needs.
You can't ask everyone to learn the history of everything since the beginning to understand how things were thought initially. Java, the language, is aging.
Maybe the author confused terms or didn't used them in the right context, but maybe Java is simply a confusing language that accumulated too many experiments, requires too much expertise or experience to grasp.
This doesn't make any sense. In Java, etc., "abstract" is just a technical term relating to the type system. It means these are types which do not have a complete implementation, so instances cannot be created. The word is used as an antonym of concrete, another technical term which describes types that can be instantiated.
It doesn't mean any of this stuff about changing the abstraction level or improving the design of the system. The author seems not to understand that a word can have two different meanings even within a single subject area.
While I'm griping, if you are looking at the semi-arbitrary choice of programming language keywords and letting that shape the big picture of how you view software design, you're going to have a bad time. "It said 'abstract' so this must be the way of creating abstractions." If that's the type of reasoning you use, the programming language designers aren't the ones doing you a disservice; you are.