
Hints on Programming Language Design (1973) [pdf] - ingve
http://i.stanford.edu/pub/cstr/reports/cs/tr/73/403/CS-TR-73-403.pdf
======
Veedrac
> [References'] introduction into high level languages has been a step
> backward from which we may never recover.

I'm young and never lived through such turbulent times, but this thought
struck me as the most disjoint from my reality. Programming without pointer
indirection seems like cycling without legs; indeed high level languages often
move the other way, abandoning value types altogether.

I'm not sure this has much to teach me about language design in the modern
day, but I do appreciate the insight into the early history of these things.

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

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

~~~
Veedrac
> 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²).

I meant O(n) vs O(log n) of course. Not sure what happened there.

------
emmelaich
As I was reading this I found intimations of

1\. Go - compilation should not be too slow and and runtime not to slow.

2\. Ocaml - special notations for certain operations e.g. A.+B

