Best modern language to learn object oriented programming
8 comments
The problem is that your programming is styled by the language you choose. If you decide to go down the route of python then the curse of consenting adults will paint the way you believe object-oriented programming should be done. Likewise if you select something like C++ or Java, then the curse of privacy will paint the way you think about object-oriented programming.
The curse of privacy dictates that the existence of a public method will act as documentation for an object. methods only exists for the purpose of Performing operations on that objects type. This will make you think a lot more about how objects systems provide secure and well dictated data flow. Your objects will be authored to respect these ideas.
The curse of consenting adults dictates that human readable code trumps control flow. The idea of inheriting from a dictionary in Python to Define your own class object makes for extremely powerful objects that are immediately designed to interface with the Python language. There however may be operations that can be applied to dictionaries that you may not want applied to your objects.
If you really want to understand object-oriented programming, then you should use both. You should find as many programming languages as possible and explore how their idioms paint the color of your code.
I expect this isn't a preferred answer, but the real message is if you pick one and learn it, don't stop there. It will take you time to become comfortable enough to Warrant breaking into another language.
That all being said, python and ruby are easier as a programming languages (in general) than many Alternatives. So if you have to learn programming at the same time as object-oriented programming they aren't bad choices.
The curse of privacy dictates that the existence of a public method will act as documentation for an object. methods only exists for the purpose of Performing operations on that objects type. This will make you think a lot more about how objects systems provide secure and well dictated data flow. Your objects will be authored to respect these ideas.
The curse of consenting adults dictates that human readable code trumps control flow. The idea of inheriting from a dictionary in Python to Define your own class object makes for extremely powerful objects that are immediately designed to interface with the Python language. There however may be operations that can be applied to dictionaries that you may not want applied to your objects.
If you really want to understand object-oriented programming, then you should use both. You should find as many programming languages as possible and explore how their idioms paint the color of your code.
I expect this isn't a preferred answer, but the real message is if you pick one and learn it, don't stop there. It will take you time to become comfortable enough to Warrant breaking into another language.
That all being said, python and ruby are easier as a programming languages (in general) than many Alternatives. So if you have to learn programming at the same time as object-oriented programming they aren't bad choices.
<plug> D is a very nicely language for doing OOP in</plug>
Ruby and Objective-C both have a strong Smalltalk lineage. You typically use the C part of Objective-C to perform basic operations like arithmetic and function calling -- if you know C already, it may be a more comfortable starting point, but it doesn't show off the power you get when every value is an object (and you can do things like add new numeric types while the system is running: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...).
Have you tried F#? Its multi-paradigm and might make some thingd clearer. You can later move to C# and onto others. :)
I've tried OCaml, which I absolutely loved. I'd considered approaching F# before, since the language seems promising from a functional perspective, but I'm skeptical of the multiparadigm claim. In your experience, is F#'s OOP support beginner friendly? Also, is there decent literature available on F# as an OOP language?
Python is more beginner friendly, but lacks many of the enterprise patterns others have. Its a good intro though.
The OOP docs for F# are average (not amazing). Feel free to email me!
The OOP docs for F# are average (not amazing). Feel free to email me!
I wrote many lines about Scala but then I lost the motivation to finish it.
So I'll just write, Scala.
So I'll just write, Scala.
C# or Java. Most of the best OOP books are written for these languages.
Ruby.
Use David Black's The Well grounded Rubyist or the PickAxe Book
Use David Black's The Well grounded Rubyist or the PickAxe Book
I don't know if it's best, but I took on OOP in little bites:
- ECMAScript 5
Mixins, scopes, instance variables, and instantiation.
As a bonus, but not OOP, callbacks. It's a straight-forward language that's available abundance.
- Python
For it's class inheritance being easy to navigate. Instance variables, instantiation, method resolution order (MRO), mixins.
- C++
This is the hardest language I can think of. It does everything OOP, and more, including allowing for a lot of stuff that's not legible.
Despite that, it's a solid language.
Something that goes great with constraining the many features of C++ are https://google.github.io/styleguide/cppguide.html or https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.
I think ES5 and Python are used very often and in terms of bang for the buck, give they cover a lot of the bread and butter OOP concepts.
- ECMAScript 5
Mixins, scopes, instance variables, and instantiation.
As a bonus, but not OOP, callbacks. It's a straight-forward language that's available abundance.
- Python
For it's class inheritance being easy to navigate. Instance variables, instantiation, method resolution order (MRO), mixins.
- C++
This is the hardest language I can think of. It does everything OOP, and more, including allowing for a lot of stuff that's not legible.
Despite that, it's a solid language.
Something that goes great with constraining the many features of C++ are https://google.github.io/styleguide/cppguide.html or https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.
I think ES5 and Python are used very often and in terms of bang for the buck, give they cover a lot of the bread and butter OOP concepts.
C++ doesn't do everything OOP: it doesn't support the late bound message-send style OOP of Smalltalk at all. In particular, you can't implement #doesNotUnderstand: (http://wiki.c2.com/?DoesNotUnderstand) or replace one object with another unless they have a superclass-subclass relationship.
It's the first time I heard of #doesNotUnderstand
Despite it looking cool and useful, IMO it's more of a (quite pleasant) sugar than an OOP concept. There's also a try/catch example where you'd get similar behavior.
I feel this is a bit opinionated:
> "but this is clearly rather verbose and it has to be repeated for every call."
I think the example in the link is what try/catch is meant for. Message passing systems in C/C++ handle situations where a disabled/unavailable service receives communication and recovers.
As for C++ and replacing objects:
I feel this is also a language-specific gotcha that doesn't hinder a learner understanding OOP. But C++ has many more gotchas than that.
For instance, there's no pure "interface" keyword. It can still be done (and is), code example: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., how Google Style guide defines it: https://google.github.io/styleguide/cppguide.html#Interfaces
Despite it looking cool and useful, IMO it's more of a (quite pleasant) sugar than an OOP concept. There's also a try/catch example where you'd get similar behavior.
I feel this is a bit opinionated:
> "but this is clearly rather verbose and it has to be repeated for every call."
I think the example in the link is what try/catch is meant for. Message passing systems in C/C++ handle situations where a disabled/unavailable service receives communication and recovers.
As for C++ and replacing objects:
I feel this is also a language-specific gotcha that doesn't hinder a learner understanding OOP. But C++ has many more gotchas than that.
For instance, there's no pure "interface" keyword. It can still be done (and is), code example: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., how Google Style guide defines it: https://google.github.io/styleguide/cppguide.html#Interfaces
In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship.
The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime, not at compile time like Java or C++. Looking things up at runtime makes the system less efficient, but makes it easier to change pieces of the system independently.
The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime, not at compile time like Java or C++. Looking things up at runtime makes the system less efficient, but makes it easier to change pieces of the system independently.
> In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile.
I read the page, I liked it. It shows a try/catch is how it'd be done.
> In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship.
I find that fascinating. But still, another case where it's more a rule and intricacy of the language.
This is the latest C++17 draft (2017-03-21) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465....
So here's why I go on about it being an intricacy of the language: The amount of casting / type rules and so on in C++, for instance, is mind-boggling.
> The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime
Which is interesting. And cool.
Isn't that similar to, an extent, virtual functions / vtable'd methods in C++?
But how does this wrap into C++ not handling an aspect of OOP? In your words. Even though I feel #doesNotUnderstand is a sugar and not necessarily a whole OOP concept, I think it can handled via an event system and try/catches.
I read the page, I liked it. It shows a try/catch is how it'd be done.
> In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship.
I find that fascinating. But still, another case where it's more a rule and intricacy of the language.
This is the latest C++17 draft (2017-03-21) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465....
So here's why I go on about it being an intricacy of the language: The amount of casting / type rules and so on in C++, for instance, is mind-boggling.
> The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime
Which is interesting. And cool.
Isn't that similar to, an extent, virtual functions / vtable'd methods in C++?
But how does this wrap into C++ not handling an aspect of OOP? In your words. Even though I feel #doesNotUnderstand is a sugar and not necessarily a whole OOP concept, I think it can handled via an event system and try/catches.
Here's a concrete example: say I want to write a class which wraps an object, logging all the methods called on it. So if I say (in C++-ish syntax):
In Smalltalk, you can implement `LoggingWrapper doesNotUnderstand:` to output the log entry; something like:
Dog *dog = new Dog()
LoggingWrapper *wrapper = new LoggingWrapper(dog)
wrapper->runAround()
In Smalltalk, you can implement `LoggingWrapper doesNotUnderstand:` to output the log entry; something like:
doesNotUnderstand: aMessage
Logger log: target class, ' ', aMessage selector, ' called'.
^ aMessage sentTo: target.
In the past, people have suggested Smalltalk as the best medium for learning concepts central to OOP. However, I've found the tooling has regressed in recent decades to the extent that I find using the language unpleasant (please correct me if I'm wrong).
In your opinion, which modern language best (and most simply) serves as a vehicle for teaching concepts core to OOP? I have no strong preference whether the type system is static or dynamic.