Background
Python, Kotlin or Java, which best supports Object Oriented Programming (OOP)?
History.
Simula 67 (in 1967) was probably the first Object Oriented Language. It was a great language, but wow was it slow! And slow even on the massive mainframe computers it lived on.
The origin of C++ was to add the power of Object Oriented Programming to the very efficient language C, while still delivering real performance. In first reference book on C++ was released in 1985 (tired of waiting for everyone to have access to the internet?) at a time when micro-computers were popular, but far slower than even old mainframe computers. The result was a language with great control over how objects were created, but in reality necessarily severely compromised by the features to deliver performance.
Java began life as Oak in 1991, but was only used by the original team until 1995 and then had a very short gestation to reaching 1.0 in 1996. Java delivered greater ease of Object Oriented Programming than C++, and with good performance even with the added layer of a virtual machine. While the language is hardly truly Object Oriented throughout, it struck winning formulae with a balance of Object Oriented and performance.
Python had origins also in 1991, but did not really get public exposure until python 2.0 in the year 2000, and did not get full object orientation until ‘new style classes’ were introduced at the end of 2001. Computing power had moved a long way between 1996 and 2001 (consider the 150Mhz 1995 Pentium pro vs the 1.3Ghz 2000 Pentium 4), and python was targeting easy of programming over ultimate performance anyway. As you can guess as a result python was able to be Object Oriented throughout instead of just having an outer veneer of being Object Oriented. But yes, still slower than Java.
Of course for Kotlin, designed in 2011 and having version 1.0 released in 2016, having Object Oriented structure throughout and adding features for functional programming as well was not even really a challenge. But slower than Java? Sometimes, but a 2016 technology compiler that ran run in a 2016 computer with gigabytes of memory available (windows 3.1, the common version at the time of Java release, required 1MB of Ram!) can optimise and produce almost the same code. Oh yes, the compiler is slower than a Java compiler can be, but is it a problem?
OOP Myths.
But Java has created some OOP myths with almost a generation of programmers learning OOP on Java.
“This program cannot be True OOP, where are the getters and setters!”
That encapsulation requires getters and setters is actually true. That you have to write your own getters and setters just to access and store data is not true. Both python and kotlin automatically provide getters and setters without the programmer noticing unless the program requires non-standard behaviour from the getters and setters. Java requires the program writes their own getters and setters in order to allow breaking the rules of OO for performance reasons.
True OOP requires and functions and data to be inside a class so every thing is an object!
True OOP does have everything as an object. Functions, all data types, everything. For performance reasons Java broke this rule. Understandable, but breaking the rules of OOP does not make the language more OO. Functions should be ‘first class functions’ and in java they were not, for performance reasons. Putting the non-OOP functions inside an object at least gave them an Object Wrapper, and the same applies for Java primitive data types. Modern OO languages do not need to wrap functions or data in a class because functions and data are always already objects.