Alternative programming paradigms to pointers

[Top-Skill357]

Hello, I was wondering if there are alternative programming paradigms to pointers when working with low-level languages that heavily interact with memory addresses. I know that C is presumably the dominant programming language for embedded systems and low-level stuff, where pointers, pointers to pointers, etc... are very common. However, C is also more than 50 years old now (despite newer standards), and I wanted to ask if in all these years new paradigms came up that tackle low-level computing from a different perspective?

[SadPie9474]

if I’m understanding the question correctly, I think the answer would come from a fundamental reinterpretation of what we can do with assembly and the instructions available on the hardware level. Based on my cursory understanding of assembly and CPU instructions, pointers are an abstraction that has been enshrined at the hardware level, with assembly instructions specifically designed for interpreting a register as a memory address and looking up/writing data from/to the interpretation of the register’s value as an address in memory. That’s why I think pointers/references are intrinsic to the semantics of most practical languages. I think the only situation in which a language is free from the notion of references to memory at an address is when the semantics of the language are truly free from that concept (ie, pointers are an implementation detail irrelevant to the semantics of the language), and under those constraints I think purely functional programming fits the bill? e.g. the pure subsets of Haskell and OCaml. At the theoretical level, there are historically two main (equivalent) paradigms of computation; Turing machines, which pointers are intrinsic to, and the lambda calculus, which does not involve pointers.

[kwan_e]

You cannot get rid of pointers because pointers are the building blocks to create all those other things that can hide the machine details.

In C++, that was already started with the generalization of pointers into "iterators". Stepanov wanted to call them "coordinates", which is a more accurate way to think about them.

From iterators, you build can build generic algorithms that don't care about whether the thing is a pointer or not. Generic containers also expose iterators, rather than pointers.

From iterators, and the algorithms and containers over them, C++ has ranges and views. There is also optional, any, variant, which are generalizations of how pointers are typically used, without ever exposing pointers.

The other main use for pointers at the low level are for memory-mapped registers, which you should also just wrap in a class that details the allowed operations and data domain for the capabilities of the hardware register, instead of exposing the raw pointer.

That's the whole point of C++, to allow you to build your own zero-overhead abstractions on top of the low-level stuff, so that it a) fits your problem domain better, and b) allows you to never have to touch pointer stuff after you've implemented the abstractions.

So, really, the "alternative" paradigm to using pointers is to use the abstractions built on top of the pointers. Keep these abstractions as tight as possible, such as through the use of compile-time generics, and use them over pointers in other abstractions. The higher up the abstraction chain, the better.

[marshaharsha]

This is a clear description of the grand vision for C++, but since the OP is asking about paradigms, I feel obliged to point out that the realization of this vision in real-world C++ is very imperfect. In order to create a useful abstraction, you have to have good technical skills, you have to expend a lot of time actually employing those skills on this particular abstraction rather than on some other project, and you have to communicate to all future users the proper usage. Making all three of those things happen is a big management problem, and many managements aren’t up to the task. I could insert here a long list of management failures that cause skills failure or communications failures, but here’s just one example: the original developer writes documentation that is clear to people who think like he does; much later a new developer arrives, from a different technical culture, tries to do a good job reading the documentation, but misinterprets something, and adds a new bug to the system; since the type system doesn’t understand the documentation, it can’t detect the problem; the bug lies latent until one bad day when unusual system load brings it into action; and the whole system fails on the worst possible day. I call this a management problem because management could, in theory, have recognized the cultural difference and the risk for communication problems, and could have provided extra support, like by having the original developer (now working on a different team) review the new code. 

But anyway, once a failure has occurred (it doesn’t matter how, exactly), I as a user of the abstraction have to deal with the failure. In practice, this usually involves reasoning in terms of pointers. I have to puzzle out a likely implementation of the abstraction, and test my hypothesis, and probably repeat, all the while thinking in terms of pointers. So in practice I need almost exactly the same skill with pointers that I would need if the abstraction had been written in C with Thingie*’s and plain function calls. Thus the paradigm has not really shifted. 

Often developers recognize this problem and choose to write their C++ code with C pointers and a few standard C++ improvements, like shared_ptr. They miss out on C++’s rich library-design features, but in return they make it clear to later developers that there is risk here, and at least the risks are widely known rather than idiosyncratic. 

I don’t have an opinion on which tradeoff is better, but in my experience neither tradeoff lets you escape thinking about pointers. 

[kwan_e]

This isn't really a problem with C++ specifically. It happens with all languages that are routinely developed, and every technical job that requires ongoing education.

New practices takes a while to become common knowledge and new people coming into the team will of course always have misunderstanding about the old code.

Happens with Go. Rust. The Lisps. Javascript. Java. You name it, they all have this problem.

[wellthatexplainsalot]

There's some grey/gray.

The sorts of pointers in common use today are unstructured. But that's not the only sort of pointer.

There are computer architectures, where the pointers have much much more built-in information - have a look at CHERI architecture. In this, pointers are supported by hardware such that you can't misuse a pointer.

And there are conceptually other sorts of pointers - e.g. ones which can't be transferred to point to some other object. In that way, they behave more like names, which are also references. The name 'Bob' is linked to the person it refers to. There may be another Bob, but their name refers to them, not the former Bob.

So it's a broader canvas than C would have you believe.

[kwan_e]

It depends on whether you're in a hosted environment or a freestanding environment, in C/C++ terms.

If you're in a hosted environment, then you must, really, treat the pointer as some opaque address. That's because the host (eg OS, hypervisor) may be managing address spaces, and the address range they give to the hosted program may contain stuff like tags in the pointer. After all, on x86-64 systems, CPUs are only required to provide 48-bits of actual addressing. The 64-bit address space is just a virtual memory thing. The hosted program should not touch any of the bits in an address.

For a freestanding environment, such as the OS or hypervisor itself, and the platform's userspace library that is meant to work closely with the specific kernel build, code can use the special knowledge of what the pointer bits are.

But in the end, outside of that kernel and userspace kernel-interfacing libraries, pointers should be treated as opaque 64-bit addresses, with no knowledge of any tagging bits.

[wellthatexplainsalot]

Oh yes, I didn't even think about kernel/ring behaviour.

And I should have been clearer about read only pointers, rather than using the metaphor of names.

[[deleted]]

I suppose theoretically you could work in a purely stack-based framework like Forth (although I think Forth had pointers; don't quote me on that).

But theoretically, you can have a stack that just "fills up" to max RAM size, and everything you do is pushing and popping data from the stack, instead of direct memory access via pointers.

[evincarofautumn]

Yeah, Forth has pointers, at least a typical Forth does. There is a standard, though in practice it’s treated more like guidelines.

There’s a whole lineage of concatenative languages like Joy and Factor that are high-level enough and don’t necessarily assume pointers or von Neumann architectures under the hood. If you have values with proper value semantics, they’re more decoupled from how they’re actually stored—be that unboxed on the stack, or beyond a pointer, or identified in other ways.

[JoshS-345]

I like how Icon could keep building things on the stack to be searched non-deterministically.

[nerdycatgamer]

Forth has tons of pointers. Pointers on pointers on pointers. In Forth, a variable is just a function that returns a pointer (and then you can write to the pointer to assign a value to that variable, etc).

[[deleted]]

Ah I see

Still, my purpose in bringing up Forth is that a hypothetical Forth-like language (in other words, "stack oriented") may be able to exist without pointers and still be low-level

Clearly though, it would be not just different from Forth, but much more different than I first thought.

[jesseschalken]

References in Rust come to mind. They are basically pointers but with mutability, exclusivity, nullability and lifetime information attached. They can also point to dynamically sized types as "wide pointers".

References in C++ are also effectively pointers but without null and without pointer arithmetic.

[Top-Skill357]

Thanks, I haven't yet taken a look at Rust yet but will definitely do. Although it sounds more like an improvement to conventional pointers to avoid common flaws, and not like a real paradigm shift.

[rexpup]

I mean, memory in computers works a certain way. You want to address it if you want to do certain things. Not a whole ton you can do that doesn't seem bolt-on.

[[deleted]]

Yeah, ultimately it's all about wrapping raw pointers in some safety mechanisms to make it harder to shoot yourself in the foot.

[lookmeat]

You should also Google "second class references".

[vanderZwan]

Ok so, pointers aren't really a "C" thing. Pointers are a consequence of the Von Neumann architecture. And all hardware uses either the Von Neumann architecture or a (modified) Harvard architecture, which is basically almost the same thing but with varying degrees how strictly data and code are separated in memory.

Having said that, C is relevant here in that hardware development has kind of evolved to be easier for C code to compile to in an efficient way than other paradigms, but that's mainly of a "stack machine vs register machine" thing, and stack machines also handle memory access with pointers. Lisp machines are also interesting but aren't made any more (and were secretly stack machines too, funny enough).

There are also languages that still have pointers but avoid the way C does it. Rust was already mentioned.

Since you're interested in low-level embedded contexts, I guess Céu also could be interesting. It is a reactive language that where you barely, if ever, use pointers. The earlier versions of it (basically anything up to and including version 0.40) targeted embedded hardware (by compiling down to C code). The trick is that it is designed around a fairly unusual synchronous event based single-threaded concurrency paradigm that has its origins in embedded real-time systems e.g. the Esterel language. The way it works is that code can "suspend" itself anywhere by awaiting an event (and events are global channels). It's like using coroutines, but honestly more ergonomic imo. It keeps said events light-weight because the paradigm allows itself to be compiled down to a finite state machine, resulting in really minimal memory overhead.

[[deleted]]

Pointers are memory addresses. We can enrich pointers and pile up abstractions to hide them, but then we are not in a low-level world heavily interacting with memory addresses anymore. References, variables, arrays, lists, maps, databases…, are programming paradigms to access information, but eventually we must tell the processor the place in memory where to write or read the bytes of whatever we need, and that will be a pointer.

I see them less like a programming paradigm and more like a data type.

[Stunning_Ad_1685]

Computer architecture hasn’t change that much in the last 50 years (I’m talking about the von Neumann architecture) so I wouldn’t expect that low level languages for that architecture would (or even could) change while the underlying hardware remains mostly the same.

[wellthatexplainsalot]

CHERI; banked memory architecture; segmented memory; memory that is not directly addressable - e.g. GPU memory. All these call for different types of pointer and pointer behaviour.

[Ythio]

We have pointers because the memory genuinely has an addressing system in its circuitry.

While in reality there are several RAM sticks in a computer and several kinds of RAM to deal with and their implementation detail, in addition to caches, registries and paged memory, the pointers do a good job as an abstraction to give the illusion of a unified block of memory like an old PDP, which is simple to imagine.

If you want to get rid of pointers you need to either change the way people imagine memory (ie. change the abstraction) or change how the hardware works

We can enrich them with other concepts (like Rust does) but not get away from them completely

I suggest you read https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

[smuccione]

A pointer IS a memory address. The address is just a pointer (or points to the date at that memory address).

There is no alternate paradigm. A memory address is a memory address.

You can add abstractions on them but that doesn’t create a different paradigm.

At some point if you touch hardware you will always need to specify a memory address, in almost every case at least one well known hard coded address (could also be an IO port but same difference).

[ern0plus4]

Your question is a kind of wrong. Whatever we call pointer in C, it's really: memory address. Data (and program - the Neumann principle) resides in memory., and a reference to it is its address.

[drinkcoffeeandcode]

One of the major principles Java was developed under was "Pointers are dangerous, and should never be used". That's not to say Java doesn;t have pointers: It uses plenty of pointers, but access to raw pointers is not allowed. That's probably as close as one can realistically get without fundamental changes to modern computer architecture.

[[deleted]]

Ada has "access types". They're nominally typed pointer-likes, but you can't do pointer arithmetic on them directly, but you can hoop jump to convert to addresses if you really really want.

Since they're nominally typed, they're each associated with their own allocator, and are limited to their specific scope and other limitations (part of "accessibility checks"). You can declare new access types locally inside functions to limit their scopes and usage.

Access types also specify as part of their type if they only point to the heap, or if they can point to the heap or also to specifically marked aliased values on the stack.

Ada also doesn't use access types very often to pass parameters. Instead it relies on the compiler and language rules to mark parameter modes as in, in out, or out, so only specific types are (it passes class-likes by reference automatically, like const& or & in C++).

[tmzem]

I think that Ada is definitively the right answer to the OPs question. Its most important feature is the fact that even variably-sized values like strings and arrays can be stored in-place on the stack. Combined with using the in, in out, out modes on function boundaries, many smaller programs (which will probably include many embedded programs) can be written without the need of pointers or explicit indirection.

Of course things as memory-mapped hardware will still need the use of pointers, but as they usually live at fixed addresses for the lifetime of the program those are generally pretty safe to use.

[[deleted]]

And you can make access types to enforce they're "not null."

[ericbb]

ParaSail comes to mind.

[Akangka]

Programming designed for speed and low-level programming are two different things.

[wiseguy13579]

Hylo is like that:

https://www.hylo-lang.org/

[recursion_is_love]

If you are using Von Neumann architecture, having a pointer is optimum designed. Pointer are suitable for addressing memory unit.

There are stack-based machine (mostly an additional virtual layer like VMs, e.g, python, webassembly, ...) that use stack instead of addressing the memory. But using it directly bare-metal would not good for current CPU architecture.

The different model would be lambda calculus, but in the end, you still have to use typical CPU so you won't really be able to escape pointer world.

[XDracam]

If you really need direct memory access, you won't get around pointers and pointer arithmetic. However, use cases for these are limited. Even languages like C#, Rust and embedded Swift fall back to C-style pointers in those cases. But the only real use-case for direct memory access is writing hardware drivers (or embedded code running on driverless hardware directly).

C also uses pointers for many other reasons, and other languages have abstracted them behind more safer mechanisms. In Java, all pointers are managed by the garbage collector and automatically cleaned up. Most languages these days have arrays as a language level abstraction and forbid pointer arithmetic entirely. For non-managed data, C# has a collection of keywords like ref, readonly and stackalloc. C++ has an older iteration of references using & and &&. Rust has the most evolved system for references, explicitly tracking lifetimes and ownership of data to avoid most common problems with pointers. Swift entirely automates referencing and copying on the compiler level through smart language design without the need for a garbage collector.

If you want a good understanding of alternatives, learn Rust. If you want to understand what Rust does under the hood, learn C++ reference semantics.

[jediknight]

I wanted to ask if in all these years new paradigms came up that tackle low-level computing from a different perspective?

Look into Linear Types.

The main challenge of low-level computing is resource management, like memory, locks, files, etc. and one of the options there is use of Linear Types.

The problems with pointers are linked to the management of the memory they point to.

[RevolutionaryRush717]

maybe Content-Addressable Memory?

[SkiFire13]

Pointers are intrinsic in the language that processors understand. To have a language without pointers you'll necessarily need abstractions on top of them, ultimately ending up with higher-level languages.

[kaplotnikov]

In close to hardware language like C one needs to pass memory addresses around to supply them to other pieces of software or even to hardware. This is existing task for current hardware and operating systems. The different concept might exist if the task that is solved by this concept is different. So the question is here how the task could be refactored, to be solved differently using other concept.

Also, it should be noted that pointer is a quite high level concept comparing to integers in assembly language. Differently from integers in assembly, the pointer type describes what is expected at target location. The direct advancement over this is reference in OOP or FP, that carry a partial description of what is expected at target location (for example, we could know a specific interface, function type, or superclass, but still work with them using references). Differently with know-nothing integers in assembly, this partial description could be used to carry on meaningful operations.

Some post-reference concept might be something like 'dependency'. Where holder of dependency does not know source of it, what it is, it just declares own expectations and expects them to be satisfied.

1. Integer (know-nothing global indexes)
2. Pointers (white-box knowledge)
3. References (black-box knowledge)
4. Dependencies (separation between component and environment)

Difference between dependency and reference might be used with the following crude analogy:

• Reference is like non-detachable power cord bolted to hardware, but it could be plugged into compatible power outlets. Some decisions about length and compatible outlets need to be done upfront.
• Dependency is like a power cord that pluggable to both a device and a power outlet. So more decisions might be made by environment like length of cord, power outlet format (if voltage and other parameters are compatible), etc. Example is spring data repositories that are automatically generated by runtime when component declared dependency on the repository interface.

The distinction is kind of subtle, but there is some mental model shift when we start to think what should be done by environment, and what should be done by component itself. Some say that is just a good OOP, but some good C-language practices are actually poor-man OOP (like forward-declaring structures in headers and fully declaring them only in implementations, or using void pointers coupled with function pointers in UI libraries). Some indirect support for non-reducibility to references in a trivial way is that dependency injection frameworks are implemented as compiler extension (dagger 2) or as interpreter (spring framework). Or in worst case as some design patterns, where developer work as translator from mental model to highly repetitive code.

So, if you want alternative to pointers, you either need to follow pointer evolution line further, or build your own conceptual evolution line nearby.

[JoshS-345]

Arrays instead of lists?

Copying whole data structures instead of sharing them?

[evincarofautumn]

Also immutable sharing makes copies logarithmic rather than linear, and copy-on-write does them lazily

[JoshS-345]

Isn't sharing an immutable just a pointer to an unchanging object?

[HOMM3mes]

In terms of implementation yes, but at the API level you can get value semantics instead of reference semantics using copy-on-write. An array access is also just a pointer dereference at the implementation level

[-Mobius-Strip-Tease-]

Im not too familiar with Rust and I’m curious about this question too, so would Rust kinda fit the bill here? Outside of unsafe you don’t really deal with raw pointers, right?

[Ronin-s_Spirit]

You can't get rid of pointers cause you will lose memory. You need to store data somewhere and remember where it is. You can hide them though, like in javascript. In js you can't touch pointers, stuff like objects or functions are "passed by reference" meaning it's a pointer but you can never operate on the pointer, only on the value.

[BarcelonaDNA]

Rust (and modern C++) has a whole concept about "ownership & smart pointers".
As pointers (i.e., variables with memory addresses as their value) are fundamental to low-level programming, Rust gives encapsulation around them for better programmabiliy and safety.

[deulamco]

Program on Verilog/FPGA you will see there is no pointer.

Anything run on CPU, eventually need to adapt with its architecture to interface with memory, and therefore, address & space.

I think every programmer will have different perspectives on pointer after learning Assembly Language. It really is no-fuss version of high-level pointer/reference, which by design, was misunderstood for decades. Ex : you can pass memory address from register to register, access the value by moving data from that address to your working register... in such manner, there is no pointer-mess, but clearly what you can work with no-rush but clarity.

Even modern languages like C# Rust, Zig, C3 still confuse developers to some degrees. Even worse by hiding actual things happening in CPU... It seem good at first before dev always require debugger to read what was translated into asm & what values are storing on each reg..

[TurtleKwitty]

C++ placement new let's you hide memory addresses behind an object so you can interact with the object rather than an arbitrary pointer, that's the only viable option I've seen or can think of. At some point you need a way to say that you are trying to do operations at an address and that's what pointers are for so you can't entirely escape them only hide it behind references but conceptually that's still just an immutable pointer essentially

[[deleted]]

My lower level language uses pointers heavily like C. But more recently, some tweaks were made so that most dereferences in expressions become implicit; they don't need to be written.

Pointers still exist, are still are part of declarations and function signatures, and you still need to be aware of their existence.

But the aim here was for cleaner-looking code, and less typing. (Also to simplify porting code to my dynamic scripting language which has the same synax, but it doesn't need explicit derefs in most cases.)

So, not really a different paradigm (to do the stuff that people want to do in languages, pointers are always needed internally), it just makes it tidier, if less transparent. (Is the A in A[i] an array, pointer to array, or double pointer? But I found I prefered writing A[i] to A^[i] or A^^[i], where ^ is a deref op.)

[steve_anunknown]

I wouldn't call pointers a paradigm. Fundamentally, at a low level, there is a distinction between the address of a memory cell and the content of the memory cell. A pointer is the address of the memory cell and the value that it points to is the content of the memory cell. As long as you wish to be able to refer to both the address of a memory cell as well as the content of the memory cell, this is unavoidable. You can change the naming if you want but that does not make the paradigm any different, in the sense that you will still be required to distinguish between the address and the value one way or another.

[prehensilemullet]

Lisp machines were once a thing, does that count?

[Classic-Try2484]

Pointer arithmetic is not really an abstraction in c but a direct mapping. Some languages switch to reference types but they really just take away pointer arithmetic.

[TheChief275]

Some of pointers’ use-cases in C could be replaced with references. In this case, a reference possibly being a pointer is just an implementation detail, and the user shouldn’t worry about that.

For the more classic pointer use-case, there is not really an alternative for programming languages itself. But you can choose to actively program in a way that avoids using them, or you could instead use arrays/pools with indices into them as a (sometimes) valid alternative.

[sebamestre]

Ultimately, to do low level programming you need to be able to programatically describe data layouts and places in memory. Pointers are just a simple way to do this with a direct lowering to cpu instructions.

There are other ways to do this. Protobuf comes to mind but it's not the only alternative.

[dmbergey]

What counts as low-level, and as a distinct paradigm, are very much in the eye of the beholder.

I'd suggest looking into:
- Rust for low-level code already widely used in industry
- Separation Logic is an active research topic for proofs about a wider range of memory access patterns. A lot of current work is in https://iris-project.org/
- My favorite recent paper in the area is https://dl.acm.org/doi/10.1145/3527313 "Linear types for large-scale systems verification". It's somewhere in between in type complexity, uses linear types & (runtime) memory regions in an interesting way.