From ... From: Erik Naggum Subject: Re: Why garbage collection? Date: 1996/01/15 Message-ID: <19960115T003635Z@arcana.naggum.no>#1/1 X-Deja-AN: 135255168 references: <19960114T050927Z@arcana.naggum.no> organization: Naggum Software; +47 2295 0313 newsgroups: comp.lang.lisp summary: elaboration [Richard Villanueva] | I realize how unlikely it is that I would break new ground on the | subject. Hence my puzzlement. A friend of mine who has worked in | support of AI researchers for many years told me that garbage | collection was one of the obstacles that was hindering the acceptance | of Lisp. This got me wondering. I take it that he must be | ill-informed. most people are ill-informed about the issues of memory management in general and garbage collection in particular. as I hinted: it is a very complicated topic. e.g., people think that manual memory management is always faster than garbage collection, and on top of this think that C's malloc and free are time- and space-efficient. _none_ of this is true. it is no accident that none of the standard Unix programs use dynamic memory unless absolutely necessary, and instead are rife with arbitrary (small) limits. the arguments used against garbage collections today were probably used against dynamic memory as a whole not too long ago. it is, however, very true that the acceptance of Lisp was hindered by a particular brand of ill-informed misunderstanding, namely prejudice towards automating one particular complex manual task. for some bizarre reason, programmers have been taught to automate complex manual tasks and have consistently made them several orders of magnitude faster, but memory management is somehow exempt from this rule. why? of course, it isn't, but automatic storage reclamation was perceived as wasteful ("what? there are _dead_ objects out there, wasting _expensive_ memory?"), time-consuming (it is actually much faster to pause infrequently (perhaps never) to do garbage collection than to slow down the program all through its lifetime with part-time garbage collection, but most people care about small and immediate things, not big issues), even unnecessary ("relax, I can handle this. besides, I know better what my program needs than some newfangled automatic algorithm ever could."). some programmers also feel an acute lack of control, and will argue about everything but their actual reasons for not automating their memory management, preferring to micromanage individual bytes instead of managing memory. so your AI research supporter (?) was not ill-informed, but what he told you was not what you thought you heard. garbage collection hindered the acceptance, but garbage collection was not at fault, the _perception_ of garbage collection was the actual cause. lack of understanding of what it was made for a scape goat and an easy excuse. also, popularity and lack of it are both self-propelling. (how often have you heard that somebody doesn't want to learn Lisp because nobody uses it? that's why!) | : I have misplaced the address of the mother of all sites on garbage | : collection, but there is one that has an excellent survey, and there | : are many papers available. | | Someone else provided the site info. I'll FTP it. it is customary to supplement such vague information with harder information if you get it. I would still like to know where it is. # -- the problem with this "information superhighway" is mainly that if you ask people to go play in it, they don't even understand when they get run over.