Or you could use a language that uses object orientation in a more natural way, such as Ruby and Scala, which both are fundamentally OO languages.
You can do procedural-y things with both languages, much to their credit, but packaging up functionality is both natural and intuitive.
Over building APIs is not a hallmark that Objects are bad. They're a hallmark of bad design.
So, yeah, i agree, prototype a minimal solution and iterate, and teach others to do this. This is an issue that is orthogonal to object orientation. At least, it is in languages that don't make you jump through weird hoops (C++ & Java, i'm looking in your general direction).
The delta between Python and Ruby is way, way smaller than the Ruby community seems to think it is. You are aware that everything is an object in Python, too, right? The idea that that isn't true still seems to be knocking around the Ruby community. Everything he said about Python applies precisely to Ruby (or fails to apply in exactly the same way if it is a bad argument), because there's hardly any difference that matters to a newbie.
"But, but, len is a function! And you can't monkeypatch the base classes even though you can monkeypatch everything else!"
Yes, please, by all means burden your neophyte with that tirade. They'll really appreciate it while they're trying to figure out what an "if" statement really does or why calling a function with the wrong capitalization doesn't work.
If you don't buy it then don't get distracted by it.
In Ruby's REPL, i can interrogate any object for the methods it has on it (unless it's using method_missing in horrible ways), effectively allowing me to list out it's API.
As far as i'm aware, that's not the case in python's REPL, or at least, i was never able to figure out how to do it (i will fully admit to not being a python expert, but at the same time i'm not a n00b either).
Also, please note, i'm not dissing Python, i like python (just not as much as i like Ruby).
I stand by my argument about OO. It should be possible to quickly and succinctly describe what OO is supposed to do, and demonstrate how your language uses them to bundle up functionality. If you can't do that, you're doing it wrong.
Objects should not get in the way of being able to write code.
Lastly, please don't put words in my mouth. I don't think monkeypatching is relevant to the discussion, and the fact that len is not a method on objects is weird, but ultimately inconsequential.
In a python repl dir(object) and help, help(object) are what you are looking for. Both these functions are in the default namespace
dir(__builtins__)
Returns a list of strings for all the names bound in the prelude namespace.
dir(list)
Returns a list of strings for all the methods on the list class.
dir([])
Will return a all the methods on a particular instance.
etc… the same caveats apply to dir with getattr etc as to method_missing. additional caveat i dont care to test; it may not work on an old style class instance.
help has its __repr__ defined to tell you how to use it. It will allow you to read the doc strings for a namespace, object or function. However i prefer to run 'pydoc -p 8888' in my projects top level; this will start an http server on port 8888 that lets you interactively browser your projects docstrings and all the modules on its pythonpath.
Better yet, use the help() function instead, which also displays the docstrings for said object and functions (assuming the programmer gave those, which fortunately holds for the entire stdlib).
> You are aware that everything is an object in Python, too, right?
Python is missing encapsulation and message passing. It's object model seems to be similar to something like PHP or JavaScript: objects are essentially hashes. In practice, that's not a huge deal, but they aren't quite the same.
This is not important for beginning programmers, but for programmers thinking about their toolset more information can only help.
"Any traditional OOP programmer might tell you that essential elements of OOP are encapsulation and message passing.
The Python equivalents are namespaces and methods.
Python doesn't subscribe to protecting the code from the programmer, like some of the more BSD languages. Python does encapsulate objects as a single namespace but it's a transluscent encapsulation."
TBH, private fields are a stupid idea. It's just a cutesy concept that gives the newbie a false illusion of being in control. I've never seen a program where a private field was actually important to the integrity of the program.
I'd have to politely disagree; if your class has mutable state and you want to maintain some invariant relationships amongst the elements of your class then as far as I can see you really need to be able to specify that some operations can only be performed within the class. If your class is immutable then I'd agree that in most cases privacy offers you few benefits.
Yes, that's the theory. In practice it doesn't seem to work out so well. Neither the promised benefits of using private fields actually manifest, nor the promised costs of not having private fields, but the costs of actually having the private fields manifest in spades. In cost/benefits terms, the benefits are almost entirely theoretical and the costs much higher than advertised. I consider them a major net loss for OO.
I wouldn't really agree that it doesn't work out in practice. For the systems that I work on, the concept of privacy is extremely useful, perhaps we're doing things 'the wrong way' to believe that but I don't think that's all that likely.
What would you suggest as a better alternative, outside of a purely functional approach? Just as an example, suppose that Java's LinkedList class didn't have a cached size and that instead it went and iterated its elements to calculate its size each time someone asked for it. I might write a wrapper around LinkedList with two private variables, the LinkedList and an int to cache its size in. Then I would update the int each time an operation was performed on my member list. If I can't make those two members private, how can I ensure that no one accidentally updates the list without updating the size, or vice-versa. It mightn't be an unreasonable mistake for someone to think calling mylist.size = 0 would empty the list. What is the 'safe' way of constructing this concept?
> If I can't make those two members private, how can I ensure that no one accidentally updates the list without updating the size, or vice-versa. It mightn't be an unreasonable mistake for someone to think calling mylist.size = 0 would empty the list. What is the 'safe' way of constructing this concept?
Conventions. In Python, for instance, all private fields and methods start with a double underscore, i.e., '__'. This is merely a convention, outlined in PEP8. Documentation tools don't pick up "private" fields. Even when they do, they don't list them in the same section as the public fields.
You could argue about the safety of this approach, but at some point you have to let go of the training wheels and let programmers make their own judgments.
I think the point is precisely to take design entirely out of the picture when you're teaching a new comer about programming. The fact that you have these problems and you can write executable recipes to solve them is already more than a mindful, everything else only confuses.
Reminds me of my AP Computer Sci class in high school a decade ago.
There were five people in the class, two of them being my brother and I. Two of the three left had zero prior programming experience. I could only sympathize with them as we rushed through the "syllabus" learning about everything from pointers to classes to inheritances.
Suffice to say they were completely lost and dreaded the class as much as math. I wasn't particularly good at math and could not imagine seeing programming as "math" because of how much fun I was having with VB/ASP(yes, you can chuckle) at home. I don't even want to think what perception of programming the two people left with.
I recently finished college with communications degree, make a decent wage doing programming and haven't needed to even think of the word "inheritance." Of course there are many great uses for it.
But to assume everyone should learn about it is to assume that everyone wants to be a genius programmer at google. There is so much gray in between the curriculum just ignores.
I still get a chuckle out of it, too. Then again, how else do you end up in a debate class full of basketball players who are gonna win the NCAAA Championship later in the semester?
You can do procedural-y things with both languages, much to their credit, but packaging up functionality is both natural and intuitive.
Over building APIs is not a hallmark that Objects are bad. They're a hallmark of bad design.
So, yeah, i agree, prototype a minimal solution and iterate, and teach others to do this. This is an issue that is orthogonal to object orientation. At least, it is in languages that don't make you jump through weird hoops (C++ & Java, i'm looking in your general direction).