Re:The Memory Models That Underlie Programming Languages
by kragen on Monday January 02, 2017 @04:34PM
(#13304745)
Thank you for pointing out how that part is confusing! It's certainly true that C usually does not have a garbage collector.
As chubot said, what I was saying is that C and similar languages take (the simplified ur-form of) the COBOL memory model and add pointers to it, and programmers in these languages mostly use pointers when they want one of the things you can't get in the COBOL memory model: aliasing, nullability, cyclic relationships, or dynamic memory allocation.
You could very reasonably argue that the distinction between GC'd and non-GC'd languages is more profound than that, since in a GC'd language you can make all your data immutable and toss around entire subgraphs of the object graph as if they were integers, simply by referring to them by a pointer, not worrying when or if they get deallocated. While I agree that this is a big difference, I think the differences I'm focusing on in the essay are actually even more pervasive — so pervasive that we rarely even take note of them at all. That's why I feel justified in lumping Golang with C instead of Lisp here.
As chubot said, what I was saying is that C and similar languages take (the simplified ur-form of) the COBOL memory model and add pointers to it, and programmers in these languages mostly use pointers when they want one of the things you can't get in the COBOL memory model: aliasing, nullability, cyclic relationships, or dynamic memory allocation.
You could very reasonably argue that the distinction between GC'd and non-GC'd languages is more profound than that, since in a GC'd language you can make all your data immutable and toss around entire subgraphs of the object graph as if they were integers, simply by referring to them by a pointer, not worrying when or if they get deallocated. While I agree that this is a big difference, I think the differences I'm focusing on in the essay are actually even more pervasive — so pervasive that we rarely even take note of them at all. That's why I feel justified in lumping Golang with C instead of Lisp here.