What's the benefit of having everything as an object in dynamically typed programming language? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

modern dynamic programming languages like Python, Ruby and Javascript all take the approach of treating everything as an object, what's the benefit of this approach, and what's the curse of it?

Benefit I can think of: first class functions, duck typing.

Drawbacks:performance issue, especially performance of primitive types like integer etc.

Answer 1

It's not entirely clear whether you are talking about the semantics or the pragmatics here. Your question reads more about semantics, but in the comments you say you are asking about pragmatics. I'm going to answer about both.

Semantics

• Pros: simplicity. Why have two concepts when one will do?
• Cons: none.

Pragmatics

• Pros: simplicity. Again.
• Cons: Performance.

The Real World

The way this is used in the real world is that you have pure object-oriented languages whose implementations use primitives without ever exposing them to the programmer. So, the only people who need to deal with the complexities of having two different "things" (objects and non-object primitives) are the compiler/interpreter implementors. Language users simply use objects.

So, in other words, use semantics without primitives, but implement them with primitives. YARV, Rubinius, MRuby, MacRuby, pretty much all Lisp and Smalltalk (and derivatives such as Self and Newspeak) implementations, some ECMAScript implementations, and probably many others do this.

The techniques for doing this have been known since (at least) the 80s. Like many other useful things, the designers of the Java platform seem to have forgotten them when they designed the Java platform, and are now fighting a decades long uphill battle against backwards compatibility constraints to remove primitives again. (They are rumored to be gone by Java 10, but then again, this rumor has been going around for 15 years now.)

Answer 2

Performance doesn't matter. Or rather: compared to providing developers the best tool with which they can express and model what they want the computer to do, performance is the easier problem to solve.

Types, classes, objects, functions, lambdas - all those concepts help organize your thoughts and your code. At this point, they're all quite unrelated to how the processor is going to actually execute your code. The 'curse', if there is one, is when your language of choice forces you into a particular model (classes vs object, of object vs functional) when you'd like to use another for a particular problem.

Regarding actual implementation, I don't know enough to comment about it. However consistency is valuable: having everything appear as an object to the developer might make implementing the language slightly harder, but makes using it much easier. It doesn't matter (in most cases) wether internally it has special treatment because it's an int or not.