Co-created the Self Language and devised many advances in Garbage Collection algorithms and dynamic (runtime) compilation.
See also Ungar Method
Outline of OOPSLA2003 presentation (a note taker said last 4 paradoxes were left to discuss over beer)
Seven Paradoxes of Object-Oriented Programming Languages
Wednesday, 29 October — 8:30-10:00
David Ungar, Sun Microsystems
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? I believe that this endeavour 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 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 centre 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 modelling 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.
See original on c2.com 