gc


On Thu, Jun 23, 2011 at 07:37, Johan  Lundberg <joe...@gmail.com> wrote:
I have a novel idea concerning all manner of "helpful" memory
management, like Garbage collection (GC) and Reference counting: Drop
it, bury it, forget it.
>
Manual memory management is really not difficult. All you need to know
can be summarized on one sheet of paper. Make a few mistakes and in a
couple of days you will have figured it out. Your programs will be
fast and predictable.
>
Automatic GC starts up randomly, which is a huge problem in time
critical applications, such as in the financial markets. Someone at
Oracle told me that 98 percent of all JVM optimization investments
concerns the garbage collector. This, and the fact that automatic GC
makes programmers lazy and unaware, is a very high price for the
miniscule convenience of not having to release memory. Reference
counting is slightly better in that it is predictable but it is very
confusing to many programmers. Unless you have a very powerful
development and simulation environment it is therefore more prone to
memory leaks than manual memory management.
The same arguments can be made for programming using just
NAND gates, which can be summarized on just a post-it note.

It turns out that, compared to writing programs using NAND gates,
when I write programs in Go, I can write the program in less time,
the program is more likely to be correct, and the program is easier
to debug and fix if not.  It is true that the program is slower and
less predictable than if I'd written it using just NAND gates, and
not having to think about NAND gates probably does make me
lazy and unaware at some level.  For the programs I am writing,
the advantages of using Go outweigh the disadvantages of not
using NAND gates.

Of course, programmers and programming environments differ,
so if you find that NAND gates are a better fit for your work,
no one here is going to force you to use Go.

Russ

I have not written something large in a manual memory language that did not include some kind of buggy slow informally specified form of automatic memory management.

Programmers are INHERENTLY lazy. If you don't give them the 'lazy' tools, they will reinvent them poorly. Evidence: half of Boost is an attempt to make up for manual memory management, and the inherent laziness of programmers means that instead of using these tools wisely, they mainly just copy memory. It is IDIOMATIC in C++ to copy memory instead of sharing it, and this is TERRIBLE problem when it comes to getting your program to do anything useful.

The simple facts of the matter are these:

- that how memory is handled has almost nothing to do with the problems we try to solve with computers. Why not explicitly manage CPU registers as well?

- that the ability to share references is essential to creating decent abstractions, and that there are a couple of well accepted ways of implementing this on modern hardware.

- that manual memory management creates unreasonable paranoia in programmers in the long term and stunts their thinking.

- that all evidence suggests that manual memory management greatly increases the defect rate of programs.