Why do some object oriented languages let the programmer use primitive data types?

Aren't classes like Integer, Boolean, etc. enough?

  • 6
    speed is the name of the game here, and at some point it needs to go tot the native primitives Apr 12 '13 at 9:45
  • possible duplicate of What is meant by a primitive data type?
    – gnat
    Apr 12 '13 at 9:59
  • speed and convenience. even though its strictly not good OOPs it makes the central task - a good solution to the problem / for the customer possible. Here good is from the point of view of the initial dev team , user and the maintainer(s).
    – tgkprog
    Apr 12 '13 at 10:20
  • 1
    @ratchetfreak There is no reason why one could not have primitive types appear as objects at the language level and be converted during code generation, without losing speed. This is, for instance, the approach of Scala.
    – Andrea
    Apr 12 '13 at 10:48
  • 5
    You ask the wrong question, it should be: why are primitive data types in some languages (like Java or C++) no classes, but in other languages (like C#, Ruby, Smalltalk) they are? That's the reason for my downvote.
    – Doc Brown
    Apr 12 '13 at 11:03

Sometimes you need full control of the size a number takes in memory. Or you may want to directly process binary data you read from a file, or copy from video memory if you process a screenshot or grab from some port, network connection, whatever.

In theory you could add more classes that are specialized in processing binary data, but depending on the actual history of a certain language and what exactly its usage intentions were at some time.

Performance may be a reason too in some cases. Especially with highly optimized compiled languages.

There are quite some languages that don't have primitives and are "object only".

  • even for a simple for next loop a primitive would come handy
    – tgkprog
    Apr 12 '13 at 10:21
  • 10
    For example, in C#, the size of "int" or "char" in memory is minimal, and the binary representation is exactly what you expect. Nevertheless those types are classes. So it is possible to design a language where get both - high efficiency and full object orientation.
    – Doc Brown
    Apr 12 '13 at 12:59
  • 1
    Example: The LMAX architecture's optimization making a hashmap with long primitive keys rather than Long object keys speed it up significantly. This optimization wouldn't be possible in an object only language.
    – user40980
    Apr 12 '13 at 13:32
  • 3
    @DocBrown Technically they are structs (though they inherit from the Object class, and they can be "boxed"). But, yes, high efficiency and full object orientation are indeed possible.
    – luiscubal
    Apr 12 '13 at 20:28
  • @tgkprog Why would a primitive be handy for a simple "next loop"? I assume we are not coding in assembly language here, but a high-level OO language.
    – Andres F.
    Apr 13 '13 at 1:26

Because 90% or more of the time you use primitive objects with primitive semantics anyway, not typical object semantics. The compiler has to carve out special privileges and restrictions for primitive objects, like:

  • They are automatically instantiated for a literal.
  • They must be immutable, in order to allow it to optimize down to a computer architecture's native types.
  • They have value semantics for assignment, when other objects usually have reference semantics for assignment.
  • They are allowed to overload or define operators, even if other objects aren't allowed to do so.
  • They can be used as constants and as part of constant expressions at compile time.

If you're going to make a primitive object that the compiler treats differently than every other kind of object, some language designers feel you may as well provide separate and explicit syntax for primitives. In other words, if an int and an Integer have different behavior and are used in different contexts, it makes sense to make them different types.

It makes the language more internally consistent, and makes translation to native instructions much easier. It's also more consistent with the mental model of most programmers. Even in languages where primitives are objects, most programmers don't consider a statement like int a = 0; to have all the overhead of regular objects, and they would be right.

In other words, primitive objects aren't "just like" other objects, no matter how big of a superficial resemblance. Some languages just don't try to hide the differences from the programmer.


The ultimate reason is performance. There's a modern-day problem where people have gotten used to the very high level abstractions some languages provide and think that that's all there is to computing, unfortunately computer hardware still works like it used to back in the 70s.

This means that, whilst you may like to think that an elegant language should not support primitives, and that everything needs a default base class and every type needs to be a class, the level of abstraction involved would absolutely kill performance of your programs - simply because the computer still operates on the primitive types. Does this mean that your OO apps are slower than low level ones? Why yes - and they are, there's a reason things like device drivers are still written in C and not Ruby or Java (and its not just down to the programmers involved)

For the most part, OO apps don't notice too much performance problems when written as OO apps (even though I have seen some programs go into a massively convoluted mode where there are so many calls between objects the system spends all its time looking up vtables!) simply because the vast majority of the data processing is performed on primitive types. Replace then with objects and you'll see an entirely different performance characteristic. eg, just look at questions like this one where the questioner explains that using a double instead of a Decimal class made his program run "about 15x faster".

  • Um, isn't Double in C# not a primitive type, just like Decimal? In which case, the performance increase had to do with the differences between both abstract types, rather than with primitive vs non-primitive. Double is an example of a performant non-primitive type.
    – Andres F.
    Apr 13 '13 at 1:33
  • @AndresF. - Both double and decimal are structs in C# and hence allocated inline. You're right that the performance difference was not down to value vs reference types.
    – Lee
    Apr 13 '13 at 10:12
  • @AndresF. I think he was comparing a double vs Decimal. The point is still that there is more work for the compiler to do with an object than there is with a primitive. These fundamental types get used a tremendous amount of time, so even a tiny performance impact quickly adds up to something significant.
    – gbjbaanb
    Apr 13 '13 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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