Hacker News Reader

Comment by nkrisc | Hacker News Reader

I think a lot more people than most HN readers realize simply struggle significantly with abstract thinking and reasoning.

It's natural that people who enjoy programming and hacking and related fields are very comfortable with such abstract types of thought. But I really think that isn't all that common amongst most people. I think the average person has to learn such thinking abilities with difficulty (though they can). I'm sure many people here got into programming precisely because abstract thinking came easily to them.

> the idea that the same filename in two places was two unrelated files would just lead to a mental block.

Which is actually why the "files and folders" metaphor is apt. In a filing cabinet in a school office (once upon a time) there were likely hundreds of documents labeled "Report Card" in many different folders, each labeled with a different name.

View on HN

> I'm sure many people here got into programming precisely because abstract thinking came easily to them.

Counter here: When I wanted to switch from TurboPascal during school (14y/15y) to C++ (because it was "more cool" and that was the tool that the 'big boy' game-dev-pros were, we thought), it was so damn hard for me - really! I was struggling so massivly, I head massive problems with this pointer stuff - it took me years to fully understand it.

And I was hell-bad at math in school (or maybe just too lazy), the only thing to which I a relation was all this geometric stuff (because this was needed for .. game dev! :-D )

Pointers are famously difficult to learn and reason about even though the basic principles are simple. Programming in a style that requires direct manipulation of pointers when it's not actually necessary is usually regarded as unwise because it's so hard to get right.

OP had no problem with pointers prior to trying C++. I think there is a case to be made that C(++) makes pointers unnecessarily confusing and there is no real disconnect between understanding pointers in theory and in practice otherwise

And C++ makes everything extra confusing with the capability of operator overloading.

That has to be one of the worst features ever added to a language.

> C++ makes everything extra confusing

> I head massive problems with this pointer stuff

no, OP explicitly had problem after getting introduced to pointer concept

...thats the reason why I love managed environments like C#/Java/etc :-))

Pointers aren't hard, it's C/C++ that make them complicated. Addresses and indirection in any assembly language are simple and straightforward, easy and even intuitive once you start actually writing programs.

Tell that to the thousands of comp sci students who drop out every year because they don't like programming in C!

I used to think I was incapable of learning "real" programming because I didn't get C. When I later read a book on programming in assembly, I realized that everything that had felt so complex was actually not so difficult. C pointer syntax is weird and doesn't parse naturally for many people, especially programming novices who might not yet have a solid grasp on what/how/why they're doing anything.

Right, but it's hard to tell how much confusion is caused by C syntax vs the idea of a memory address.

In particular I think people are very confused by declaring pointers and the overloaded meaning of the dereference operator.

C and C++ pointers aren't any harder than pointers in assembly, at least as far as novices complaining about pointers being hard are concerned.

They are though! Indirection in assembly is just something like:

  ldr dest, [src, offset]

It's straightforward and pretty hard to mess up, and easy to read to because the format is consistent.

Whereas in C all the following are valid (and it becomes even more confusing with assignment in the declaration statement, tons of footguns and weird syntax):

  int* a;
  int *a;
  int a[];
  int a[5];

Assignment is weird too, especially because dereferencing and defining a pointer both use '*'.

  *a   = c;
  a[0] = c;

Then you have structs/unions and their members, and what if those are pointers? You get . and -> syntax. It's weird and complicated, much much more complicated than assembly. That's before you get to casting and types which make C much more complicated than assembly for doing low level stuff.

> Which is actually why the "files and folders" metaphor is apt.

It's a starting point, but I certainly wouldn't say it's the best metaphor that there could be. The idea of subfolders just doesn't make sense in a filing cabinet analogy, because you have to consider paper size - any folder which could fit into another folder is not going to be able to contain your regularly sized documents.

That said, I can't think of a better metaphor.

People understand hierarchy. That named file is in a folder in a particular drawer of a particular cabinet in a particular room of a particular building in a particular neighborhood in a...

What some people struggle with is recursive hierarchy where each step doesn't change the kind of container. I guess they never saw a Matryoshka doll when they were little.

A better metaphor would be trees and branches. Which is already somewhat used for computing.

> The idea of subfolders just doesn't make sense in a filing cabinet analogy,

Sure it does. The document is located in Building C, Sub-basement 2, Room 123, cabinet 415, folder labeled "Accounts". And a physical folder can certainly contain other folders. Nit-picking the analogy wastes everyone's time.

A metaphor doesn't have to be a 1:1 facsimile.

Reply on news.ycombinator.com