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

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

  • 7
    speed is the name of the game here, and at some point it needs to go tot the native primitives Apr 12, 2013 at 9:45
  • possible duplicate of What is meant by a primitive data type?
    – gnat
    Apr 12, 2013 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, 2013 at 10:20
  • 2
    @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, 2013 at 10:48

4 Answers 4


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, 2013 at 10:21
  • 14
    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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 13:34
  • I don't think OO necessarily implies less performance, you can use objects/structs without vtables and polymorphism. If you absolutely need the abstraction polymorphism brings, you will suffer the performance penalty regardless of paradigm. I would rather suggest that forced abstractions cause performance issues, like languages that only allow an abstract "number"-type with arbitrary precision,
    – JonasH
    Aug 31, 2022 at 7:52
  • 1
    Note that in C and C++ any data other than bit fields are “objects”.
    – gnasher729
    Aug 31, 2022 at 9:07

First, why not?

Next, in a language like Java, you have a class “Int” or whatever it is called, but it has substantial overhead. You really only want to use it if there is a very good reason to use an object. Try implementing FFT in Java and see if it is “fast” compared to a C implementation.

In Swift, there are five categories of data: Class, struct, enum, tuple, and protocols. Guess what: No objects. And there are value types and reference types. Java objects would be Swift classes except they are nullable, and nullable types in Swift are enums.

In Swift, types like Int or Double are actually structs. The optimiser is good enough to make this zero cost. Being structs allows nicer syntax for some operations. The important thing is that structs are value types. There are primitive types that would only be available to the implementor of the standard library. So in Swift there is no need for anyone else to use primitive types, but other languages are not like that. They allow use of primitive types because they have to.

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