Abstractions
in [Lisp]
|
From: Scott L. Burson on 7 Aug 2010 14:33 RG wrote: > In article<8c21hdFfp3U1(a)mid.individual.net>, > Pascal Costanza<pc(a)p-cos.net> wrote: > >> I don't doubt that run-time changes are important, to the contrary. I >> still believe that the collections is the wrong level of abstraction to >> make such changes. > > Yes, I get that. What I don't get is *why* you think that. But at this > point maybe we just ought to agree to disagree. I agree :) I can see both sides of this. It seems to stand to reason that a generic collection interface can be useful, but in my experience, it isn't useful -- at least, not critically so -- as often as one might think. -- Scott
From: RG on 7 Aug 2010 17:20 In article <i3k8tu$r4g$1(a)news.eternal-september.org>, "Scott L. Burson" <Scott(a)ergy.com> wrote: > RG wrote: > > In article<8c21hdFfp3U1(a)mid.individual.net>, > > Pascal Costanza<pc(a)p-cos.net> wrote: > > > >> I don't doubt that run-time changes are important, to the contrary. I > >> still believe that the collections is the wrong level of abstraction to > >> make such changes. > > > > Yes, I get that. What I don't get is *why* you think that. But at this > > point maybe we just ought to agree to disagree. > > I agree :) > > I can see both sides of this. It seems to stand to reason that a > generic collection interface can be useful, but in my experience, it > isn't useful -- at least, not critically so -- as often as one might think. I don't think anyone ever claimed that collection abstractions were going to solve every software engineering problem or bring about world peace. But it still seems to me that the benefits are, at least potentially, substantial even if they do not accrue "as often as one might think" (however often that might be) while the cost is essentially zero. So I don't understand the vehemence with which people resist using them. I am particularly mystified by this because one could (and people do) make exactly the same argument about, say, macros: yes, they can sometimes be useful, but not "as often as one might think" (again, however often that might be). I would have thought that if any group of people would see the flaw in this reasoning without having to have it explained to them it would be the people who hang out here on c.l.l. Alas. rg
From: x on 8 Aug 2010 16:43 RG <rNOSPAMon(a)flownet.com> wrote in news:rNOSPAMon-553208.14204807082010(a)news.albasani.net: > I am particularly mystified by this because one could (and people do) > make exactly the same argument about, say, macros: yes, they can > sometimes be useful, but not "as often as one might think" (again, In theory, generic collections are often useful, and macros are sometimes useful. But, in practice, macros are useful a lot more and generic collections a lot less. This is because CL provides a good set of built-in collections that cover most cases very well, and are more efficient than generic collections, and because macros make the interfaces cleaner when building layers of domain specific languages, which is the main activity of developing good software.
From: RG on 8 Aug 2010 18:23 In article <tFE7o.45552$Zp1.12845(a)newsfe15.iad>, x <a(a)b.c> wrote: > RG <rNOSPAMon(a)flownet.com> wrote in > news:rNOSPAMon-553208.14204807082010(a)news.albasani.net: > > > I am particularly mystified by this because one could (and people do) > > make exactly the same argument about, say, macros: yes, they can > > sometimes be useful, but not "as often as one might think" (again, > > In theory, generic collections are often useful, and macros are sometimes > useful. But, in practice, macros are useful a lot more and generic > collections a lot less. > > This is because CL provides a good set of built-in collections that cover > most cases very well, and are more efficient than generic collections, and > because macros make the interfaces cleaner when building layers of domain > specific languages, which is the main activity of developing good software. The vast majority of the software engineering world would disagree with you that "building layers of domain specific languages ... is the main activity of developing good software." The vast majority of software is built in languages that don't have macros, and where as a result building domain specific languages is very hard, and as a result is very rarely done. It is only in the Lisp world where one finds this enlightened attitude towards things like macros, and more to the point, things like being able to redefine functions, methods, and classes, resume a computation after an error, and even (gasp!) change the class of an existing instance in a running system without having to restart. The value of being able to make changes at run time is implicitly acknowledged in nearly every aspect of CL's design. I would also disagree that CL "provides a good set of built-in collections that cover most cases very well, and are more efficient than generic collections." CL provides linked lists, arrays (with vectors as a special case), and hash tables. Then it provides a hodgepodge of puns on top of linked lists (alists, plists, sets) and a half-assed non-extensible unification of linked-lists and vectors as "sequences". That's it. No heaps. No tries. No trees. And that's even before you get to contemporary issues like distributed collections, or collections with a non-volatile backing store. As for being "more efficient", the only efficiency difference between a generic and a non-generic collection would the cost of a method dispatch, and even that could be compiled away with the proper declarations. So I'm sorry, but your explanation does nothing to dispel my bewilderment. At the risk of repeating myself, the value of being able to make changes at run time is implicitly acknowledged in nearly every other aspect of CL's design. So I still don't understand why adding that ability to this aspect of the language is resisted so vehemently. rg
From: George Neuner on 8 Aug 2010 21:09
On Sun, 08 Aug 2010 15:23:57 -0700, RG <rNOSPAMon(a)flownet.com> wrote: >The vast majority of the software engineering world would disagree with >you that "building layers of domain specific languages ... is the main >activity of developing good software." The vast majority of software is >built in languages that don't have macros, and where as a result >building domain specific languages is very hard, and as a result is very >rarely done. The vast majority of the software engineering world doesn't understand what programming is about. Any time you construct a set of functions designed to let you address a problem in its own terms, you are creating a domain specific language. This is done all the time in every flavor of programming language. Macros are not required. George |