Thread: Explain Object-Oriented Programming Like I'm 5

Originally Posted by Epy

I don't really see the need to learn Perl or Ruby, since I already know Python...

Yeah, that's about it. I don't think there's a point in knowing more than one language from that category (general purpose, dynamic typing, GC, OO) unless you are required to. As to which one is "the best", I guess it depends on the criteria. They all have an immense range of modules. I learned some ruby for a rails project, I would not bother beyond that because I like perl more. Likewise, I learned a smidgen of python to script-fu gimp. I've had to work in php before. Perl's less stodgy than all of them IMO. Because of the evil sigils.

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes.

Someone who is only using conditions and jumps (i.e. ifs and gotos) could say the same about structures and functions in C

Yes, it's always about organization and making it easier for the programmer. C++ is worth it even if you only use std::string. Using std::string excessively would probably remove half of the bugs ever written.

Originally Posted by Epy

Again, I'm smacking myself for not learning C++ sooner just for std::string alone. basically has all the spoils Python provides you with (I'm guessing Python actually took these from C++), but many many times faster as a compiled language.

That's not really the case, or no one would bother using anything but C++. I kind of agree with Yarin -- I find working in C++ more like working in C than perl.

Dynamic typing and garbage collection are a huge deal. If I had to be concerned with type conversion and safety for the tish I do in perl, it would take me 5x as long and cause 10x the headaches. It makes a lot of data structures much much simpler. Eg this:

Code:

     std::unordered_map<std::string, int> adictionary;

From your first post only superficially looks like a python dictionary. It's way more limited -- the keys have to be strings and the values have to be ints. They can't be, eg, more dynamic dictionaries in a tree. And look at the freaking syntax -- it's almost painful. In perl:

Code:

my %dictionary;

The keys of which are stings which can type convert to numbers, and the values of which can be anything -- arrays of objects, code refs, more tree, etc. Now start to consider the code involved with putting something into a std::map. Then getting stuff out -- iterators are another very tedious, awkward C++ mechanism that has to do with strong typing.

GC is a little less significant IMO, but still saves a lot of hassles, esp. around closures and such.

I think if you take a reasonably complex, well written python program and re-write it in C++, you're going to end up with at least 3-5 times more code.

Originally Posted by MK27

It makes a lot of data structures much much simpler. (...) It's way more limited -- the keys have to be strings and the values have to be ints. And look at the freaking syntax -- it's almost painful.

Pros and cons: if the intention is to map strings to ints, then the C++ code snippet has an advantage over the Perl code snippet as it communicates, and to some extent enforces, that intention, at the cost of verbosity. What is more painful is the verbosity of re-stating the type when initialising a variable with an object of a known type, since the gain in clarifying intention is small, but the new use of auto alleviates this.

Originally Posted by MK27

Now start to consider the code involved with putting something into a std::map.

Depending on the use case, this could actually be very little code

Originally Posted by MK27

Then getting stuff out -- iterators are another very tedious, awkward C++ mechanism that has to do with strong typing.

I note that iterators are not a C++-specific mechanism. I think most of what made C++ iterators in the pattern of the C++ standard library "tedious, awkward" was the lack of a range based for loop, but that has now been fixed. Interestingly, the range based for loop mechanism effectively uses a form of duck typing...

Originally Posted by laserlight

Pros and cons: if the intention is to map strings to ints, then the C++ code snippet has an advantage over the Perl code snippet as it communicates, and to some extent enforces, that intention, at the cost of verbosity.

Well, there are obviously very different intentions behind C++ and dynamically typed languages. In perl, "type safety" is essentially non-existent; if you wanted to implement it, it would be painful and long-winded

I don't think the verbosity of C++ is by accident or mistake -- I think it's intentional and for a purpose -- just personally, I don't consider the purpose worthwhile, because the amount of trouble strong typing saves me is nothing compared to the amount of time it costs me.

However, I don't know if it is feasible to have a 100% compiled, dynamically typed language, I suspect not without disguising something like a runtime interpreter into a core library. So it goes with the territory, I guess.

Presuming that purely compiled languages really are stuck with certain constraints, it would seem that the main purpose of the verbosity is really to deal with those constraints. I don't think you can completely justify the syntax on the basis of it being "more communicative", altho that may be, as you say, a beneficial side effect. How beneficial seems pretty subjective tho.

I note that iterators are not a C++-specific mechanism. I think most of what made C++ iterators in the pattern of the C++ standard library "tedious, awkward" was the lack of a range based for loop, but that has now been fixed.

Thanks for the tip. Better late than never.

I wasn't trying to slam C++ excessively, BTW. Just pointing out to Epy that it is not the final solution or anything, and does not at all have "all the spoils Python provides you". Conversely, perl or python do not provide all the spoils of C++. Considering the difference between languages may be at least as important to understanding them as considering their similarities.

Originally Posted by Elkvis

how does it cost you any time? any time spent dealing with type safety should more than pay off in time saved debugging and maintaining your code.

For starters, because you can assemble complex data structures on the fly that would require writing a class in C++. The rough equivalent of std::map in a dynamically typed language does not have any limitation on its values, just as arrays do not have limitations on their elements. They can be heterogenous, like members of a class, including more heterogeneous arrays and maps, and also code references, like class methods. Also, they can be reassigned some other type. All the dynamically typed languages I know of have some means of easily determining the type of a reference if needed. All that can save oodles and oodles of code if used proficiently. Dynamic typing is the major reason people will observe, "you could re-write that in language X and reduce the codebase by 70-80%".

However, I'm pretty sure that handling dynamic typing is also the major runtime expense that makes interpreted languages slower than purely compiled ones. Like I said earlier, I think true, purely compiled languages require strong static typing for technical reasons. After all, perl, python, et. al. could be "purely compiled" if you built a complex runtime machine into every executable, or pieces of such into libraries they link against. But nobody does this because (presumably) it makes more sense to just have a generic interpreter. I'm sure this has to do with the fact that dynamic typing involves complex runtime handling, whereas it with static typing it is dead simple (and therefore, higher performance).

So the concept of "type safety" evolved to embrace a necessity. I don't know if anyone claims it is purely about good programming practices, I think such a claim would be specious. Which is also why I think it can be silly when taken to extremes. The types are not there to make your code more communicative or comprehensible. They are there for the compiler.

Originally Posted by MK27

The types are not there to make your code more communicative or comprehensible. They are there for the compiler.

That is the other extreme, which is also "specious" and "silly"

Originally Posted by Yarin

That's actually only mostly true

I'm sure there's a way to do that for a lot of languages (it can't be impossible, just more or less awkward); someone mentioned hiphop for php here a few weeks ago.

Beyond allowing you to deploy a static exe without worrying about interpreter installations, I'm not sure if I see a point tho. I guess it could improve performance for non-persistent applications that are run to perform a one off task and exit.

Originally Posted by laserlight

That is the other extreme, which is also "specious" and "silly"

I'll agree that type safety is important because of the necessity for strong typing in compiled languages. But sans such necessity, I'd consider someone who wanted strong typing purely to facilitate type safety a little loony. Perhaps: data type obsessive compulsive disorder.

OOP at the core, is this idea: all actions a program makes, are performed by objects, which are self-contained entities that hold data, and the procedures which operate on that data. This is not a programming technique but a way of organizing your thought processes. C++ just makes it natural to express these sorts of thoughts.

Some people include inheritance, protected scope, dynamic dispatch and some other things under the OOP umbrella. Most OOP languages provide these features, but a language which doesn't can still be OOP.

Virtual functions, operator overloading, inheritance, exceptions, private/public all just add flavor to the C++ language. Its OOP-ness comes from the class concept.