A pointer (or reference, or just 'address') is a general concept that by definition is part of any language featuring mutation.

Any language that makes use of mutation for primitive constructs (not saying that's the case here specifically) needs an understanding of "observing/causing change" pretty early on.

> is a general concept that by definition is part of any language featuring mutation.

One counter-example is Mathematica. I can mutate any object any time I like, and doing so is extremely common. Yet under "pointer" its help tells me about some unicode symbols, and some GUI stuff about mouse pointers.

In reality, some of its lists are dense memory like C, some contain arbitrary objects (such as expressions, or high-precision numbers), but these implementation details aren't part of the language, and most users never know them.

Mathematica is also not a low-level programming language. It's math-based, so it deals with abstract concepts, not concrete hardware implementations.

0-based arrays are based on hardware implementations; 1-based arrays are based on abstract collections; you could make the argument that 0-based arrays are a leaky abstraction, but the question then becomes: what abstraction? C explicitly tried not to abstract away the underlying hardware.

If "any language" means "any language sufficiently low-level to have C-like pointers", then no contest!

Surely the point of any language at all is to abstract away some details of the underlying hardware. Both for portability and to make things easier for human brains. How much you should abstract away obviously varies, based on what you're trying to do, and on how varied the hardware is.

And it depends on how much computation & memory you can give your compiler. One reason new languages can have nicer abstractions is that they don't have to compile on 1970s hardware.

Ada, Pascal, Modula-2,....

lisp, smalltalk, scheme, R.

0-based arrays/indexes are also based on abstract concepts. 1-based ordinal numbers (in both maths and language) are just tradition from time before 0 was generally accepted. Set theory (as a clean design of math foundations) also starts ordinals at 0.

The specific word or implementation isn't important.

In Mathematica's case (and most other languages, sadly), presumably the concept of 'variable' is overloaded with the semantics of a pointer/reference. Meaning, you cause and observe changes to locations via a variable.

Trying to program without understanding how data is stored in memory is like trying to cook without understanding how heat affects food.

At this point even assembly language is an abstraction of a simpler machine overtop of a much more complicated one, and few programmers really understand what's happening underneath. It's not like a chunk of 'memory' in your C program corresponds exactly to a physical location on a DRAM chip anymore. There's N layers in-between, not just in the OS's virtual memory model but also in the chip's caches, etc.

We're all dealing with abstractions over abstractions at this point, so it's really about finding what model of understanding works for the learner and then going from there.

Terrible analogy. The beauty about computer science lies in abstractions. You don’t have to understand the low level details to be productive at the higher levels, you just have to understand the interfaces. If we go down this rabbit hole, do you have to understand how the memory bus works, how the operating system is implemented, etc... before getting to hello world?

There is a huge difference between explaining how indexes come from offsets and understanding operating systems. I think more emphasis should be put on the insane amounts abstractions underlying the high level language at hand when teaching programming. Explaining that 0-based indexing comes from offests seems like a good start in that direction for a kid learning python.

And when beginners won't be beginners anymore they'l have to learn how the underlying abstractions work anyway. A programmer that doesn't at least superficially understand how operating systems work is not going to be able to write performant or secure software, let alome combine those qualities.

Digital logic is a good start...

You don’t have to understand the low level details to be productive at the higher levels, you just have to understand the interfaces.

I've worked with programmers like that. They can glue a lot of things together, but when the slightest of problems appears, they are absolutely lost with how to debug. They usually resort to making pseudorandom changes until it "appears to work", and are also unable to appreciate just how fast computers are supposed to be.

I learned physics and transistors at comp-sci. It didn't help with programming at all (though it made wonders for my understanding of the philosophy of computation).

The kind of understanding you're rooting for relies on formal logic, not electronics.

That depends entirely on the kind of programming you're trying to do. For beginners working in high level languages it is an implementation detail they need not be concerned about.

Growing up with BASIC, I didn't have any understanding of pointers or how memory worked. PEEK and POKE, which I only saw used in other people's programs and examples, were black magic as far as I could tell. It wasn't until I learned C that I actually understood them but I still managed to write a whole lot of programs without ever using them.

To be a professional programmer I'd agree though. If you don't understand how pointers work, regardless of the language you're using, you're probably not good at your job.

This is an unfortunate analogy given how complicated and poorly understood the heat-affects-food chemical reactions are. And yet food gets cooked.

I'd say that makes it an apt analogy.

It just makes a point opposite to the author's intent.

Are you sure about the author’s intent? Unless you know the writer very, very well, I think it’s impossible to tell from written text.

You make an excellent point. I shouldn't have been sure about the author's intent.

Thank you for pointing out my error.

Exactly, you don't need to know how molecules act under the hood to be productive cooking.

Until you need to substitute ingredients, you use a different type or rangetop, the pan metal or thickness is different, or something else changes. This was a perfect analogy. People can follow the recipe of assemling various frameworks and toolkits to create software, but they will eventually encounter difficulty.

You may not need to understand molecular differences, but knowing hows fats, proteins, and carbs work, along with how to substitute ingredients, and different theories of cooking all help to actually understand why you can cook until mysteriously things don't work the same as yesterday.

I've been learning to cook recently and I haven't the slightest idea how heat affects food.

It is said that each fold on a chef's hat represents a different way they know how to cook an egg. Thet need to understand when to apply low heat, high heat, add liquids, when proteins denature and when they coagulate.

Of course, following a recipe in specific ideal circumstances works, as long as nothing changes.

Lisp programmers don't care how heat affects food since the 1950s.

a pointer is an array index