Seven Paradoxes of Object-Oriented Programming Languages

David Ungar is giving a keynote at OOPSLA 2003 on the Seven Paradoxes of Object-Oriented Programming Languages. He writes...

Many of these assertions seem nonsensical, misguided, or just plain wrong. Yet, a deeper understanding of these paradoxes can point the way to better designs for object-oriented programming languages.

Apparently this will be a worthy companion to Guy Steele's keynote on growing a language in 1998. I'd like to see their respective points integrated. Growing a language will have varying results depending on where you begin. The beginning and the growing have to respect the paradoxes.

• Because programming languages, development environments, and execution engines are intended for both people and computers, they must both humanize and dehumanize us.
• Adding a richer set of concepts to a programming language impoverishes its universe of discourse.
• Putting a language's cognitive center in a more dynamic place reduces the verbiage needed to accomplish a task, even though less information can be mechanically deduced about the program.
• The most concrete notions are the most abstract, and pursuing comfort or correctness with precision leads to fuzziness.
• Although a language, environment, and execution engine are designed for the users' minds, the experience of use will alter the users' minds.
• Object-oriented programming has its roots in modeling and reuse, yet these notions do not coincide and even conflict with each other.
• A language designed to give programmers what they want may initially succeed but create pernicious problems as it catches on. However, a language designed to give programmers what they really need may never catch fire at all