Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> writes: > In that case, I can similarly discount your attempts to fix up issues with > garbage collectors after they’re pointed out, can I not?
Adapting GC algorithms to improve their performance or better use the capabilities of new hardware is much different than saying they didn't work in the first place. They've been around for 5 decades, they (like Python programs) work fine if you don't mind the performance cost, and for many applications that cost is acceptable even for quite simple and naive GC's. The continued work is to get that cost down even further. (And before criticizing GC performance, Have you ever profiled CPython to see how much time it's spending messing with reference counts? I didn't think so). >> Part of the problem is C itself. > And yet, what are these complicated garbage collectors, that you intend > relying on to work correctly with all their layers of tricks upon tricks, > written in? C. What tricks on tricks? Even the fanciest GC's are orders of magnitude less complicated than any serious database, optimizing compiler, OS kernel, file system, etc. Real-world software is complicated. Get used to that fact, and look for ways to manage the complexity and keep complex programs safe. Choosing to program with unsafe methods because you wish the complexity didn't exist is just deluded. It actually seems pretty crazy to me to write a garbage collector in C today even though it a GC needs unsafe pointer operations in a few places. C made some sense in the 1980's when computers were smaller and people didn't know better. A lot of the C code around today is legacy code from that era. These days it makes more sense to use a safe language with a few isolated "jailbreaks" (like an OS kernel that has a few lines of assembly code) than to write the whole thing in a language whose unsafety is everywhere. Here's a good paper by R. Fateman (criticizing C) that I just came across: http://www.franz.com/resources/educational_resources/white_papers/fault.prevention.pdf He suggests using Lisp instead, but one can't have everything ;-). FWIW, here are a couple pages about verifying GC's: http://flint.cs.yale.edu/flint/publications/hgc.html http://www.cs.technion.ac.il/~erez/Papers/verified-gc-popl09.pdf etc. I just don't understand that weird agenda you seem to have. But whatever. -- http://mail.python.org/mailman/listinfo/python-list
