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.

> 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

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.

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.

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.

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

> 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.

> 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 better metaphor would be trees and branches. Which is already somewhat used for computing.

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

I can't blame them. We've been force-upgraded to Windows 11 at work and that OS and its apps do their upmost to obscure where files are located.

I've frequently saved on OneDrive instead of locally, by accident, and then been perplexed when I try to reopen the file later.

And I've been using filesystems for 35+ years, so I feel sympathy for those who don't understand the abstraction. At this point Android is more transparent about its files.

> We've been force-upgraded to Windows 11 at work and that OS and its apps do their upmost to obscure where files are located.

That's because there's research that users don't understand filesystems. So then stupid companies who make bad decisions like Microsoft and Apple decide that that means they should pretend filesystems don't exist.

More like Microsoft has incentives to push people towards their cloud storage. If there were studies involved in these changes they are just excuses for things that were already decided without them.

Did they also struggle to understand that some people have the same name yet are not the same person?

By that logic, operating system developers struggle to understand that putting two files with the same name into the same folder(1) is very much possible in the physical world.

(1) or referencing them from the same directory, which was the earlier metaphor.

I've seen two people with the same name and birthday, in different departments of the same building. Caused regular problems with management and HR.

I've also seen two different customers with the same name and phone number - the number got recycled and went to second one while the first hadn't updated their number on file. We had to tell them apart by address.

But why are filenames equated with spacetime coordinates? That doesn't make any sense - reflect on why you leaped to that analogy. The spacetime coordinates are the disk ID and sector number. We've been using operating systems that work a certain way for so long that we think filenames are like spacetime coordinates.

The analogy is location. file : directory :: person : geocoordinates. I thought it was a straight-forward analogy, but clearly I was mistaken.

In the time it took you to write this comment, you've thought more about the abstraction than most of the people who are confused by it -- and it will never succeed to coax them out of their confusion with such logic. :)

I think that's perfectly understandable. File systems require the user to remember a hierarchy in their head (even if there are tools like breadcrumbs to help you out), and many people aren't willing or aren't able to hold an arbitrarily complex structure like that in their head. A name is a flat piece of information, no extra structure to imagine.

I worked with a professor one time that used floppies for all his files (after they had been surpassed by thumbdrives) because each floppy was essentially a single folder, and he could wrap his head around that conceptually.

it's not complicated at all, it's how operating systems present them to the users.

> two unrelated files would just lead to a mental block

Because in the analog world, each "document has usually a single/unique headline" and file names are often perceived as some type of unique identifier as well, Id guess?

> It is between some developers, and most of the world.

sigh