Why would many duck-typed dynamic programming languages use a class-based approach instead of prototype-based OOP?

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?

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.

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.

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.

Filed under: softwareengineering - @ 19:21

Thẻ: duck-typing, dynamic-languages, object-oriented, programming-languages

Thiết kế website giá rẻ

Danh mục

Why would many duck-typed dynamic programming languages use a class-based approach instead of prototype-based OOP?