Since quite many dynamic programming languages have the feature of duck typing, and they can also open up and modify class or instance methods at anytime (like Ruby and Python), then…

Question 1) What’s the need for a class in a dynamic language? Why is the language designed that way to use a class as some kind of “template” instead of do it the prototype-way and just use an object?

Also JavaScript is prototyped-based, but CoffeeScript (the enhanced version of JavaScript) chooses the class-based way. And it goes the same for Lua (prototyped-based) and MoonScript (class-based). In addition, there’s class in ES 6. So…

Question 2) Is it suggesting that if you try to improve a prototype-based language, among other things, you should change it to class-based? If not, why is it designed that way?

  • 9
    Many programmers don't want to be bothered learning something new. (It's too foreign and "difficult"). Hence all those class-based libraries and languages that compile to them. Commented Feb 1, 2015 at 3:11
  • 1
    I agree with Thomas, but what's funny is that after you learn the dynamic approach, it is actually easier (not harder). The concept of objects is still there, its just that the objects can be changed without recompiling some stupid "blueprint" first. If I want to put a 5th leg on a chair, I don't want to have to alter a blueprint first, I just want to just add the leg. Dynamic languages more closely model reality in my opinion. Commented Feb 1, 2015 at 6:44
  • 1
    OOP was invented in a statically typed context, where types have to be declared. There, classes are a sensible step forward from records and modules. Prototype-based OOP was only ever an interesting research topic for the Self language, and somehow made it into JavaScript as the simplest way to tick off the “OOP” buzzword for an essentially functional language. The nice thing is that you can implement classes on top of prototypes. While I like metaobjects, separating classes from their instances makes it easier to write well-factored, simple, loosely coupled code.
    – amon
    Commented Feb 1, 2015 at 10:15
  • 3
    First thing first: JavaScript itself supports the class keyword as of the next ECMAScript standard (ECMAScript 6). Support for classes in JavaScript has been planned for a long time. Now for what it is - classes are just syntactic sugar, an easier to reason about model for objects of the same type. It's this way in JS and it's this way in Python and other dynamic languages. Commented Feb 1, 2015 at 10:17
  • 1
    @BenjaminGruenbaum "...classes are just syntactic sugar..." wow, this is kinda a quite novel idea to me, really, for languages like ruby and python, it seems that it doesn't matter whether to use an object or class as the template —- both can be modified on the fly anyway. And it doesn’t really matter how they handle the inheritance neither. So, maybe there’s no need to distinguish between the class-based approach and prototype-based approach for a dynamic language :)
    – iceX
    Commented Feb 2, 2015 at 5:44

4 Answers 4


Question 1) What’s the need for a Class in a dynamic language? Why the language is designed that way to use a class as some kind of “template” instead of do it the prototype-way and just use a object?

The very first OO language (even though it wasn't called "OO"), Simula, didn't have inheritance. Inheritance was added in Simula-67, and it was based on classes.

Around the same time, Alan Kay started working on his idea of a new programming paradigm, which he later named "Object-Orientation". He really liked inheritance and wanted to have it in his language, but he also really disliked classes. However, he couldn't come up with a way to have inheritance without classes, and so he decided that he disliked classes more than he liked inheritance and designed the first version of Smalltalk, Smalltalk-72 without classes and thus without inheritance.

A couple of months later, Dan Ingalls came up with a design of classes, where the classes themselves were objects, namely instances of metaclasses. Alan Kay found this design slightly less appaling than the older ones, so Smalltalk-74 was designed with classes and with inheritance based on classes.

After Smalltalk-74, Alan Kay felt that Smalltalk was moving in the wrong direction and didn't actually represent what OO was all about, and he proposed that the team abandon Smalltalk and started fresh, but he was outvoted. Thus followed Smalltalk-76, Smalltalk-80 (the first version of Smalltalk to be released to researchers), and finally Smalltalk-80 V2.0 (the first version to be released commercially, and the version which became the basis for ANSI Smalltalk).

Since Simula-67 and Smalltalk-80 are considered the grandparents of all OO languages, almost all languages that followed, blindly copied the design of classes and inheritance based on classes. A couple of years later, when other ideas like inheritance based on mixins instead of classes, and delegation based on objects instead of inheritance based on classes surfaced, class-based inheritance had already become too entrenched.

Interestingly enough, Alan Kay's current language is based on prototype delegation.

  • 1
    "...Alan Kay's current language..." which is...?
    – Javier
    Commented Feb 1, 2015 at 13:37
  • @Javier: I don't think it has a name, and the name of the system keeps changing. Commented Feb 1, 2015 at 13:38
  • This should be a good answer to point to next time someone lists inheritance as a requirement for OO :)
    – Hey
    Commented Feb 1, 2015 at 19:01
  • 1
    @iceX: Alan Kay founded the Viewpoints Research Institute to work on his ideas. Unfortunately, information is really scattered on the website. Commented Feb 2, 2015 at 6:56
  • 3
    Alan Kay quote on OO: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them." Commented Feb 2, 2015 at 8:30

Many programmers prefer working with classes. It's a very easy-to-understand concept that is a good model of human thought processes about the world (that is, we instinctively relate real objects to the abstract group of items we consider them to belong to, which is what a class is). Also, classes make reasoning about object types easier: in a class-based language, applying principles like Liskov substitution is simpler than it is in a language where we just have objects that may have different methods, or whose type may even change at run time, as is the case in JavaScript.

Note that even in JavaScript, an awful lot of code simply uses the prototype facility to emulate classes. This is mostly because a lot of programmers prefer thinking that way.

There is also another reason class-based languages are preferred: it is easier to compile them to efficient code. The most efficient JavaScript VMs effectively dynamically create classes to represent the types of JavaScript objects as their methods and prototypes change. See this description of V8's implementation for a rationale on why this is done.

  • 4
    Your last paragraph actually supports the exact opposite of what you are saying: V8 proves that you do not need classes in the language in order to compile to efficient class-based code. Commented Feb 1, 2015 at 11:10
  • 4
    Yes, you don't need them - but the fact that V8 (and presumably Self, although I haven't read as much about the design of that system) effectively creates virtual classes means that starting from a language that natively uses classes is almost certainly easier, and would therefore probably end up with the JIT needing to spend less time compiling the code.
    – Jules
    Commented Feb 1, 2015 at 11:19
  • 11
    Sure, and the fact that V8 effectively creates GOTOs and registers means that just giving up all abstractions and writing directly in assembly is almost certainly easier, and would therefore probably end up with the JIT needing to spend less time compiling the code. It's the job of a compiler to support higher-level abstractions. Commented Feb 1, 2015 at 11:45
  • 1
    Yes, but its a trade-off, as the higher level abstraction is in most cases harder to implement and often has a run-time performance penalty, especially when working with a JIT rather than an AOT compiler. I suspect that many language designers pick a class-based structure for one or both of those reasons; I know that's why I chose classes with fixed members for the (otherwise dynamic) language I'm working on, but can only speculate about other languages.
    – Jules
    Commented Feb 1, 2015 at 13:35
  • 1
    I'd argue that the only way programmers prefer "thinking in classes" is because that's how most of us are taught. I can definitely remember a lot of my fellow students in college who had trouble grasping and understanding some really fundamental Object-Oriented concepts for several years, though. It only seems obvious and easy in hindsight.
    – KChaloux
    Commented Feb 2, 2015 at 16:40

I've heard that on big projects, where teams of people are working together on the same code, that flexible languages (where you can modify an object's properties and methods during run-time) are liberties that other team members don't want you to have.

They want to know, when they are dealing with an object, that the object will act just like the blueprint says, and not some morphed way that some other ambitious developer decided to change it to in order to complete his own task.

So, the only reason I can conceive, that someone wouldn't want the flexibilities offered by these awesome dynamic languages, is that they want to simplify team development, debugging, and auto-documentation.

Personally, I've developed applications in both methodologies, and I get things done way faster with dynamic languages. I do not use any of these frameworks designed to turn my dynamic language back into a class-base language again. Such things are a regression to my tastes.


OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things -- Alan Kay

So what he is saying here is that OO is all about making black boxes that respond to messages. In a way REST is the ultimate OO system in that it uses verbs (ie a message) and resources (ie an opaque box that contains some data).

So the question of why some are class-based and others prototype-based miss the point that it really doesn't matter, they're both mere implementations. A system that solely uses messaging instead of method calls is just as OO as the two instances you mention.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.