Seven Paradoxes of Object-Oriented Programming Languages
Wednesday, 29 October
Although many of us have worked to create good object-oriented
programming languages, it would be hard to say (with a straight face)
that any of our creations have totally succeeded. Why not? I believe
that this endeavor is essentially paradoxical. Thus, whenever a
language designer pursues a particular goal and loses sight of the
lurking paradox, the outcome is an all too often fatally flawed
result. One way to think about this is to explore the following seven
- 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'
- 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.
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.