3 ms·

Isn't what he's talking about C pointers, which let you mutate the memory location that's visible in the caller? Most modern languages don't let you do that, th

Isn't what he's talking about C pointers, which let you mutate the memory location that's visible in the caller? Most modern languages don't let you do that, though object oriented languages let you work in much the same way by mutating the fields of an object. As for functional programming, the use of pointers seems like an implementation issue. As far as the programmer is concerned, you're just passing around values. Now, part of what he was complaining about was implementation issues, but I don't think that was his only concern in the passage about references. I think you're right that there's a disconnect between what he's saying and modern languages, but it's not because we've adopted the position he's attacking, instead we've gone a third way.

Veedrac 11y ago
Here's the closest thing to a definition he gives: > the concept of reference, pointer, or indirect address into the language as an assignable item of data I think it's wrong to say that ALGOL's pointers are so different to today's pointers. After all, if he were right about their horrors, C/++ style would have moved away from pointers. Later languages have shown that his criticisms of pointers are actually problems of the semantics one can apply to them. Java, Python and similar remove the ambiguity between `x = y` and `*x = y` by disallowing the later. Functional programming removes the danger of indirect side-effects by disallowing mutation. Rust removes the danger by disallowing shared mutation. Rust is actually a very good example; its pointers have almost all of the power that traditional ones, and a very traditional syntax. Yet Rust is a decidedly modern and very safe language.
- hyperpape 11y ago
  "Worse still, an indirect assignment through a pointer, just as in machine code, can update any store location whatsoever, and the damage is no longer confined to the variable explicitly named as the target of assignment" "if x is a reference variable may change any other variable (of appropriate type) in the whole machine" I don't see much ambiguity.
  - Veedrac 11y ago
    > "Worse still, an indirect assignment through a pointer, just as in machine code, can update any store location whatsoever" Aside from functional languages, pretty much every language lets you assign through a pointer. This might be through a field in Java's case, but it's certainly there. You could argue that people have unanimously agreed that mutable references are wrong, but given the popularity of imperative languages you'll probably not be able to argue that well. Plus, I still contend this is a property of the operation, not the type. --- To put it another way, it's like calling cars bad because crashes are bad. People still use cars, because they are absolutely useful, and self-driving car proponents (aka. FP proponents) have managed to take away some of their dangers. They're still cars, even if you don't drive them.
Veedrac 11y ago
> As for functional programming, the use of pointers seems like an implementation issue. As far as the programmer is concerned, you're just passing around values. This is fair if you're OK with time and space complexity being an implementation detail, but I'd wager that this is rarely true. The difference between an O(1) and O(n) destructuring, or an O(n) vs O(∞) size cyclic data structure, is not something I'd want to leave undefined.
- hyperpape 11y ago
  Well, maybe implementation detail is not a good way to put it. But as my other comment shows, I think he's even more worried about the semantics of the construct than how the machine executes it.
  - Veedrac 11y ago
    Sure; but he blames the type for its semantics. New languages have shown that * even with the downsides, pointers are absolutely worth it, and * the type's semantics can be improved, removing many of the types's problems.
- dtech 11y ago
  Are there (non-contrived) algorithms where adding extra pointer indirection increases the complexity? I would say you could transform O(2n) into O(4n), and in practice this matters, but not O(2n) into O(2n^2).
  - Veedrac 11y ago
    It's the other way around - removing pointer indirection would ruin their complexities. If a tree is an unshared value type (eg. there are no references), then a functional tree update is O(n). Using shared references, this is O(n²). Cyclic data structures without pointers are of unbounded size. De-structuring a type (X, Y) is O(sizeof(X) + sizeof(Y)) without pointers, but O(1) with. Tons of examples.
    - 11y ago

Veedrac 11y ago

Here's the closest thing to a definition he gives: > the concept of reference, pointer, or indirect address into the language as an assignable item of data I think it's wrong to say that ALGOL's pointers are so different to today's pointers. After all, if he were right about their horrors, C/++ style would have moved away from pointers. Later languages have shown that his criticisms of pointers are actually problems of the semantics one can apply to them. Java, Python and similar remove the ambiguity between `x = y` and `*x = y` by disallowing the later. Functional programming removes the danger of indirect side-effects by disallowing mutation. Rust removes the danger by disallowing shared mutation. Rust is actually a very good example; its pointers have almost all of the power that traditional ones, and a very traditional syntax. Yet Rust is a decidedly modern and very safe language.

hyperpape 11y ago
"Worse still, an indirect assignment through a pointer, just as in machine code, can update any store location whatsoever, and the damage is no longer confined to the variable explicitly named as the target of assignment" "if x is a reference variable may change any other variable (of appropriate type) in the whole machine" I don't see much ambiguity.
- Veedrac 11y ago
  > "Worse still, an indirect assignment through a pointer, just as in machine code, can update any store location whatsoever" Aside from functional languages, pretty much every language lets you assign through a pointer. This might be through a field in Java's case, but it's certainly there. You could argue that people have unanimously agreed that mutable references are wrong, but given the popularity of imperative languages you'll probably not be able to argue that well. Plus, I still contend this is a property of the operation, not the type. --- To put it another way, it's like calling cars bad because crashes are bad. People still use cars, because they are absolutely useful, and self-driving car proponents (aka. FP proponents) have managed to take away some of their dangers. They're still cars, even if you don't drive them.

Veedrac 11y ago

> As for functional programming, the use of pointers seems like an implementation issue. As far as the programmer is concerned, you're just passing around values. This is fair if you're OK with time and space complexity being an implementation detail, but I'd wager that this is rarely true. The difference between an O(1) and O(n) destructuring, or an O(n) vs O(∞) size cyclic data structure, is not something I'd want to leave undefined.

hyperpape 11y ago
Well, maybe implementation detail is not a good way to put it. But as my other comment shows, I think he's even more worried about the semantics of the construct than how the machine executes it.
- Veedrac 11y ago
  Sure; but he blames the type for its semantics. New languages have shown that * even with the downsides, pointers are absolutely worth it, and * the type's semantics can be improved, removing many of the types's problems.
dtech 11y ago
Are there (non-contrived) algorithms where adding extra pointer indirection increases the complexity? I would say you could transform O(2n) into O(4n), and in practice this matters, but not O(2n) into O(2n^2).
- Veedrac 11y ago
  It's the other way around - removing pointer indirection would ruin their complexities. If a tree is an unshared value type (eg. there are no references), then a functional tree update is O(n). Using shared references, this is O(n²). Cyclic data structures without pointers are of unbounded size. De-structuring a type (X, Y) is O(sizeof(X) + sizeof(Y)) without pointers, but O(1) with. Tons of examples.
  - 11y ago