It's true that if you make programming more difficult to learn then you will self-select only programmers who are especially dedicated or intelligent.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.
I think that letting beginners rediscover this for themselves and then exposing language constructs that make this easier probably allows a smoother path to enlightenment.
It's often not obvious to beginners why copy-pasting code a bunch of times is bad compared to using loops and functions for example. It certainly wasn't for me, until I tried to build a program that was not highly trivial.
It makes it more difficult for a beginner because it is yet another concept to learn when you are at a stage at which they are not yet comfortable with variables and loops. It's also a pretty vague concept where different languages and different developers have different ideas about how objects should work.
I find that it only really makes sense from a code structure point of view once you have got to programs that are significantly bigger than the average beginner is likely to be writing. Even as somebody who understands OO I don't tend to use it for programs that are less than at least a few thousand LOC because I find that it just gets in the way.
class Hello {
public static void main(String args[]) {
System.out.println("Hello, world!");
}
}
Versus:
(print "Hello, world!")
Yes, this is a deliberately extreme example, but the point is that object-oriented code does not make it easier to structure CS101-level programs. All it does is introduce a bunch of keywords that students have trouble understanding until they are sitting in a much higher-level course.
I think it can help once you've dealt with dictionaries and functions. Classes are handy for storing a bunch of variables and functions together, and that's how I'd teach it.
The problem there is you have to know which variables and functions belong together. You have to commit to coupling them early on, meaning you have to make a design decision that a beginning programmer might not be prepared to make. This means they may struggle figuring out the best way to organize their code when solving problems when such organizational concerns are really not that important.
Here's a sample programming problem a beginner might encounter: CIDR data is available as a "127.0.0.1/8" style string and you need to access the IP and Netmask separately. In python, the simplest, most straightforward path to a solution that still results in encapsulated, re-usable code is to write a standalone function that accepts a string and returns a tuple. You could also create a CIDR class with a "to_tuple" method, or that stores the values in 'ip' and 'netmask' attributes, but this is simply extra scaffolding and without knowing more about the larger context of the program it's impossible to know whether such a design will be beneficial.
The problem with beginners is that they'll see the straightforward solution, but because they're not just trying to solve a problem but also demonstrate "Object Oriented Programming" skills to their teacher, they're going to worry about doing a whole bunch of extra work that may not be appropriate. I believe this is wasted energy that could be spent gaining real experience solving problems and learning about how computers and software work.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.
"Spend any time" implies substantially more experience than what most beginners possess, hence the term "advanced." "Intermediate" might be a better term in an absolute sense. OO design is something to learn after you understand the basic tools and techniques.
Also, a lot can be accomplished without OOP (for most values of OOP) and even if you're writing de facto OO code, it's not always clear whether using explicit OO language features is a net win or not.
Obviously. I strongly disagree. There are many more important things to learn first. OOP can be introduces little by little as it gradually becomes relevant.
> I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.
Only if you start with C. I find that if provided with reasonable alternatives (like function composition) or consistently restricted problem domains (vector manipulations) you very well might never create anything resembling objects.
That's not my premise. I just point to PHP (and its community) as it has some examples of it.
>The reason OOP should not be taught to beginners is that it is an advanced concept.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.