Hacker News Reader

Comment by hansbo | Hacker News Reader

  It's a mistake to introduce new programmers to OOP before they understand the basics 
  of breaking down problems and turning the solutions into code.

Given how well I remember my classmates with little-to-none programming experience struggled with understanding pointers while not being able to write the simplest algorithms, I thought this was a no-brainer. Is it really a controversial opinion?

View on HN

> Is it really a controversial opinion?

I haven't heard anyone argue against it, but for a very long time every single curriculum out there started with either Java or C++, and had to talk about object quite early on (you can't print "hello world" in Java without it, and you can't use C++ streams either).

And arguments I've heard about that practice as a proxy for your question, indicate that it is (or at least, was between the late '90s and the late '00s) controversial.

You must write a class in order to do "hello world" in Java. C++ streams don't require you to write a class, only use what appears to be a strange syntax. You can go a long way in C++ without defining any classes of your own.

You have to write a class to do "hello world" in Java, but you don't have to understand OO. If you just treat the class syntax as meaningless boilerplate you can learn a lot of programming concepts before needing to touch messaging.

Having seen 3000-line single-class Java monstrosities, I can assure you that this is not only true in theory.

I've never understood what's confusing about pointers...

1) Indirection. Pointers require thinking in a few steps. Indirection is hard. It is a vital skill in any kind of programming (or especially debugging), but it does not come naturally to people who've only ever had to deal with the concrete.

2) Early on, you learn that ints and chars and floats and some_structs are fundamentally different data types. Then suddenly you're told that int%s, char%s, float%s, some_struct%s, and even void%s are fundamentally the same. Huh?

3) The fact that C uses % both to create a pointer and to dereference. These are conflicting meanings, and the unrelatedness of those two concepts is not sufficiently explained.

EDIT: Silly HN parser. I now replaced asterisks with %s.

3) That make's sense. For example...

    int *i;

means "When you dereference i, you get an int."

When I see

   int a;

I read "create an integer variable called a".

    int *i;

means, "create a variable that when dereferenced, points to an integer".

Makes sense once you understand it, but I can definitely understand how a beginner would find it confusing.

It may be a problem with the teaching though, rather than the subject matter itself. I understand why it takes a little bit of thinking to get used to, but not why it is fundamentally hard.

Now, algorithms can be difficult to understand and many of them use pointers... Do some people confuse the 2?

I don't think the difficulty is fundamental, and I don't think anyone here claimed that it was. But it is initially challenging nonetheless.

To tie this back in to the beginning of the thread, being able to understand indirection (such as in pointers and algorithms) is a far more important skill than understanding OOP.

http://homepages.tcp.co.uk/~nicholson/alice.html

It's the abstraction that's difficult to get in the first place. In Basic, a variable represents at the same time the data and its memory address, the two concepts are not separated. When you introduce pointers, you split that concept in two: address and data, and to complicate you say address is some form of data. In Basic, the variables are the memory. Each variable you manipulate is equivalent to a piece of memory you can store things in or get things out. With pointers, you loose that equivalence: memory becomes invisible through the code. I can have a memory block that exists in my memory that is no longer pointed by any variable. This means that you get a separation between the way memory is and the way the code looks like. What is difficult when learning pointers is to get that extra level of abstraction: you have to look at the code as an access route to the memory, not as the memory itself.

Reply on news.ycombinator.com