Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Classes Are Premature Optimization

Classes Are Premature Optimization



Justin Love discusses the difference between the classic OOP programming model based on classes and prototypal inheritance built on objects as done in JavaScript, and how they affect performance.


Justin Love's creed is, in part "To tease order from disorder. To make right what is wrong and make a visible difference in the lives of people I care about." Justin left a steady job in embedded software and IT support for the wild blue yonder. He is an analytical artist and martial artist who presents regularly at ChicagoRuby and JS.chi user groups.

About the conference

Strange Loop is a developer-run software conference. Innovation, creativity, and the future happen in the magical nexus "between" established areas. Strange Loop eagerly promotes a mix of languages and technologies in this nexus, bringing together the worlds of bleeding edge technology, enterprise systems, and academic research. Of particular interest are new directions in data storage, alternative languages, concurrent and distributed systems, front-end web, semantic web, and mobile apps.

Recorded at:

Feb 10, 2011

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Two books may be missing from your collection

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You talked about Plato, and talked about Simula-67.

    Let me recommend you two books, and let me tell you why are they important:

    One of them is Categories from Aristoteles.

    The second is Structured Programming from - amongst Dijsktra and Hoare - Dahl, the creator of Simula.

    Even if you have never read Categories itself, what should be understood is that our culture was influenced by it for centuries, and also that code is written for humans as well. It's strange however, that even in cultures unaffected by the greeks in theory show a strikingly similar system sometimes.

    So I think Categories gives us an overview on how humans - of the western culture - think about things around us in the last 2500 years, and therefore, how we should model those things for them.

    In structured programming, Dahl and his co-authors introduce the construct of a class; they don't do it to gain performance, this wasn't an aim, nor is there some philosophical object-passing: they do it to have scalable understanding of problems.

    What is missing from Alan Kay's object-philosophy is - albeit I've never read any of his books directly yet - that it doesn't scale on comprehension; as I understand, it was thought that programs will, in some time of the future, evolve above human recognition anyway, and we should create a system which is able to do so.

    In contrast, Structured Programming was made as an effort to make people understand the limitations "of their own skull", and being able to design programs reliably with the given constraint of a human brain; that they're still understandable, even if incomprehensible as a whole.

    What is funny, that how we use classes usually is how it was written in Structured Programming; it wasn't overridden by OOP, never. Sometimes I think people liked to say this because of the arrogant personal style of Dijsktra - "arrogance should be measured in nanodijsktra", as Kay once metioned.

    So, I think it's a pretty human activity to classify the things around us, it has roots before OOP, and maybe such kind of classification should be mirrored in the code - and in the coding language itself.

    And I believe this pattern is there to be used in order to scale well; a program shouldn't scale only in performance; it should scale in recognition as well.

  • A few missing slides

    by Justin Love,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Looks like the 20-minute slides were used. The full version is available at In many cases it's just words too go along with what I'm saying, but there are also some additional images and diagrams.

  • Clearer, simpler is often faster.

    by Peter Lawrey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Along the thread of your argument; If your code is clearer and simpler it will often be the fastest both initially and over time.

    IMHO A program which is difficult to maintain will run slower over time. It is reasonably well understood that simple code is often optmised best (by the compiler/VM/CPU), but it worth remembering that as an application matures, it has many changes, sometimes by different developers and the clearer the code, the more likely those changes will be efficient as well. (i.e. you don't end up with work-around on top of work-around)

    "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
    -- Antoine de Saint-Exuper --

  • Re: Two books may be missing from your collection

    by Justin Love,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    While a review of Categories and other literature would probably be beneficial, I'm not arguing that humans don't think in terms of broader generalizations. Prototypal does it bottom up instead of top down. One could probably spend an entire presentation at least as long on the history of the philosophy and psychology of such generalization. In particular, I didn't get into the work of Eleanor Rosch and others which points towards prototypes or exemplars as a better model for how humans actually think.

  • Re: Two books may be missing from your collection

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Prototypal does it bottom up instead of top down

    I don't think classification is a top-bottom approach.

    The most ingenious step of Grady Boochs ever did was to introduce generalization as a relationship, as opposed to inheritance.

    I remember how hard time I had at Uni to explain to freshmen why the arrow is that way, and not the opposite, and it took years after to realize its ingeniusness.

    Boochs at that time was a consultant, a guy who helped companies write specifications basically. What he did realize that customers think about the specific cases first, and it's up to the analyzer (software designer) to realize the general idea behind them, and show this to the clients to prove or deny it.

    My question is, wether prototypes would scale upwards, that means, when I introduce cats alongside dogs in my pet store (or turtles!), will a prototypical system help me cope with this change in the existing software easier or harder?

    The exemplar-based point is valid, though :) Still my concerns are about conceptual scalability. I'm not saying that I know the answers...

    Wether my concerns about conceptual scalability are valid could be also a matter of debate; I would like a program which doesn't turn into spaghetti once outsourced to India after some years of internal maintenance, while still doesn't look like a full operation system with 1000s of classes. What is the best way to cope with this?

  • Re: Two books may be missing from your collection

    by Justin Love,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    top-bottom: I was referring to the fact that a class must exist before an instance.

    Thinking about specific cases first seems perfect for prototypes. Cats might start out as clones of dogs, adding some sort of animal prototype if (and only if) that became awkward.

    I can attest that I heavily refactored a small (compared to 'scale') Javascript program, with it running at pretty much every step, and I don't recall any great pain in doing so. I can't make any personal empirical claims about very large programs.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p