
Best modern language to learn object oriented programming - ds2643
I&#x27;m a programmer who was introduced first to the functional paradigm. I&#x27;d like to better understand the object programming paradigm.<p>In the past, people have suggested Smalltalk as the best medium for learning concepts central to OOP. However, I&#x27;ve found the tooling has regressed in recent decades to the extent that I find using the language unpleasant (please correct me if I&#x27;m wrong).<p>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.
======
probinso
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.

------
git-pull
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](https://google.github.io/styleguide/cppguide.html)
or
[https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](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.

~~~
panic
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](http://wiki.c2.com/?DoesNotUnderstand))
or replace one object with another unless they have a superclass-subclass
relationship.

~~~
git-pull
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...](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-
abstract), how Google Style guide defines it:
[https://google.github.io/styleguide/cppguide.html#Interfaces](https://google.github.io/styleguide/cppguide.html#Interfaces)

~~~
panic
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.

~~~
git-pull
> 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...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf).

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.

~~~
panic
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):

    
    
        Dog *dog = new Dog()
        LoggingWrapper *wrapper = new LoggingWrapper(dog)
        wrapper->runAround()
    

The program should output a log entry like "Dog->runAround() called", then the
dog should run around.

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.
    

It's not impossible to implement a class like LoggingWrapper using vtables --
in order to make a vtable, you have to know all a class's methods at compile
time, but LoggingWrapper can respond to any method its target responds to.

------
panic
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-...](http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-October/025066.html)).

------
solomatov
C# or Java. Most of the best OOP books are written for these languages.

------
Lordarminius
Ruby.

Use David Black's _The Well grounded Rubyist_ or the PickAxe Book

------
pryelluw
Have you tried F#? Its multi-paradigm and might make some thingd clearer. You
can later move to C# and onto others. :)

~~~
ds2643
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?

~~~
pryelluw
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!

------
AlexAMEEE
I wrote many lines about Scala but then I lost the motivation to finish it.

So I'll just write, Scala.

------
mhh__
<plug> D is a very nicely language for doing OOP in</plug>

