Abstractions
in [Lisp]
|
From: Pascal Costanza on 30 Jul 2010 18:15 On 30/07/2010 22:53, RG wrote: > This is a meme that needs to be nipped in the bud: > > In article<8bgijdF9jgU1(a)mid.individual.net>, > Pascal Costanza<pc(a)p-cos.net> wrote: > >> In general, I'm >> quite skeptical about abstracted interfaces for different kinds of >> collections: Each of them has their own advantages and disadvantages, >> and you don't easily change from one to the other without considering >> performance and other implications. So what's the real use of an >> abstract interface, other that you _can_ abstract it? > > ... > >> I don't want to discourage you, but again, what's the real use of such >> abstractions? > > To make it easier to change implementations if the assumptions that led > you initially to choose a particular one turn out to be wrong. Which > happens a lot. > > Why do you doubt the value of this? I find it hard to imagine that this matters beyond simple examples. But that may just be a limitation of my imagination... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: RG on 30 Jul 2010 18:57 In article <8bh17mFf2U1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 30/07/2010 22:53, RG wrote: > > This is a meme that needs to be nipped in the bud: > > > > In article<8bgijdF9jgU1(a)mid.individual.net>, > > Pascal Costanza<pc(a)p-cos.net> wrote: > > > >> In general, I'm > >> quite skeptical about abstracted interfaces for different kinds of > >> collections: Each of them has their own advantages and disadvantages, > >> and you don't easily change from one to the other without considering > >> performance and other implications. So what's the real use of an > >> abstract interface, other that you _can_ abstract it? > > > > ... > > > >> I don't want to discourage you, but again, what's the real use of such > >> abstractions? > > > > To make it easier to change implementations if the assumptions that led > > you initially to choose a particular one turn out to be wrong. Which > > happens a lot. > > > > Why do you doubt the value of this? > > I find it hard to imagine that this matters beyond simple examples. But > that may just be a limitation of my imagination... Who are you and what have you done with Pascal Costanza? Do you believe that latent typing has value? What exactly is that value if not the ability to defer the choice of data type? What is the point of deferring the choice of a data type if you cannot also defer the choice of algorithm? (What does it even *mean* to defer the choice of data type without deferring the choice of algorithm?) Or do you think that latent typing has no benefits beyond "simple examples" and that complex systems ought to be written in statically typed languages? rg
From: Pascal Costanza on 30 Jul 2010 19:50 On 31/07/2010 00:57, RG wrote: > In article<8bh17mFf2U1(a)mid.individual.net>, > Pascal Costanza<pc(a)p-cos.net> wrote: > >> On 30/07/2010 22:53, RG wrote: >>> This is a meme that needs to be nipped in the bud: >>> >>> In article<8bgijdF9jgU1(a)mid.individual.net>, >>> Pascal Costanza<pc(a)p-cos.net> wrote: >>> >>>> In general, I'm >>>> quite skeptical about abstracted interfaces for different kinds of >>>> collections: Each of them has their own advantages and disadvantages, >>>> and you don't easily change from one to the other without considering >>>> performance and other implications. So what's the real use of an >>>> abstract interface, other that you _can_ abstract it? >>> >>> ... >>> >>>> I don't want to discourage you, but again, what's the real use of such >>>> abstractions? >>> >>> To make it easier to change implementations if the assumptions that led >>> you initially to choose a particular one turn out to be wrong. Which >>> happens a lot. >>> >>> Why do you doubt the value of this? >> >> I find it hard to imagine that this matters beyond simple examples. But >> that may just be a limitation of my imagination... > > Who are you and what have you done with Pascal Costanza? These rhetorical games get a bit on my nerves. > Do you believe that latent typing has value? Yes. > What exactly is that value > if not the ability to defer the choice of data type? That's one among many advantages of "latent" typing. There are others. > What is the point > of deferring the choice of a data type if you cannot also defer the > choice of algorithm? (What does it even *mean* to defer the choice of > data type without deferring the choice of algorithm?) If you have to change the data type, you probably also have to change the algorithm manually yourself, at least that seems to be the case based on my experience. A good example is 'elt: It's a good accessor for vectors, but a very bad one for lists. It may be convenient that 'elt abstracts away from lists and vectors, but eventually, it probably matters to remove 'elt and rewrite your algorithm, at least when you arrive at using lists. To me, such an abstraction seems like a minor advantage. There are better examples, I know. But they don't really convince me that much either. Maybe your experiences are just different from mine, who knows. > Or do you think > that latent typing has no benefits beyond "simple examples" and that > complex systems ought to be written in statically typed languages? This is not an implication of what I said. I'm not trying to argue against building a good abstract collection API, if you believe that's going to buy you something. I'm just trying to express my skepticism about their usefulness, which seems to be considered higher than it actually is, IMHO. YMMV. Don't let me stop you. Everybody should do what they think is right. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: RG on 31 Jul 2010 02:31 In article <8bh6paFspuU1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 31/07/2010 00:57, RG wrote: > > In article<8bh17mFf2U1(a)mid.individual.net>, > > Pascal Costanza<pc(a)p-cos.net> wrote: > > > >> On 30/07/2010 22:53, RG wrote: > >>> This is a meme that needs to be nipped in the bud: > >>> > >>> In article<8bgijdF9jgU1(a)mid.individual.net>, > >>> Pascal Costanza<pc(a)p-cos.net> wrote: > >>> > >>>> In general, I'm > >>>> quite skeptical about abstracted interfaces for different kinds of > >>>> collections: Each of them has their own advantages and disadvantages, > >>>> and you don't easily change from one to the other without considering > >>>> performance and other implications. So what's the real use of an > >>>> abstract interface, other that you _can_ abstract it? > >>> > >>> ... > >>> > >>>> I don't want to discourage you, but again, what's the real use of such > >>>> abstractions? > >>> > >>> To make it easier to change implementations if the assumptions that led > >>> you initially to choose a particular one turn out to be wrong. Which > >>> happens a lot. > >>> > >>> Why do you doubt the value of this? > >> > >> I find it hard to imagine that this matters beyond simple examples. But > >> that may just be a limitation of my imagination... > > > > Who are you and what have you done with Pascal Costanza? > > These rhetorical games get a bit on my nerves. Oh come on, grow a sense of humor. > > Do you believe that latent typing has value? > > Yes. > > > What exactly is that value > > if not the ability to defer the choice of data type? > > That's one among many advantages of "latent" typing. There are others. Really? Like what? > > What is the point > > of deferring the choice of a data type if you cannot also defer the > > choice of algorithm? (What does it even *mean* to defer the choice of > > data type without deferring the choice of algorithm?) > > If you have to change the data type, you probably also have to change > the algorithm manually yourself, at least that seems to be the case > based on my experience. > > A good example is 'elt: It's a good accessor for vectors, but a very bad > one for lists. Really? What would you recommend to use instead? NTH? > It may be convenient that 'elt abstracts away from lists > and vectors, but eventually, it probably matters to remove 'elt and > rewrite your algorithm, at least when you arrive at using lists. To me, > such an abstraction seems like a minor advantage. You're missing the point. If you use ELT then it's easier to replace lists with vectors than if you use NTH. So why not use ELT? > There are better examples, I know. Indeed. A much better example is GETF/ASSOC/GETHASH. There is no equivalent in CL of ELT for these accessors, so the design of CL *requires* you to make a premature optimization if you want an associative map. (Worse, CL doesn't provide reader syntax for hash tables, which implicitly disparages them in favor of ALists and PLists, both of which are almost never the right choice for anything except the simplest examples.) > But they don't really convince me > that much either. Maybe your experiences are just different from mine, > who knows. Have you never had to change large sections of code because you found out after you wrote it that it ran too slowly because you used a list where you should have used a vector? Or an AList where you should have used a hash table? Or a hash table where you should have used a red-black tree? > > Or do you think > > that latent typing has no benefits beyond "simple examples" and that > > complex systems ought to be written in statically typed languages? > > This is not an implication of what I said. It wasn't intended to be. It was intended to be a possible explanation of why you said what you said. > I'm not trying to argue against building a good abstract collection API, > if you believe that's going to buy you something. I'm just trying to > express my skepticism about their usefulness, which seems to be > considered higher than it actually is, IMHO. YMMV. But that is exactly what puzzles me. You see the value in latent typing, but not in abstraction. And yet the value in those two things is exactly the same, namely, the ability to write code in a way that lets you defer decisions. So I don't understand how you can value one and not the other. rg
From: Pascal Costanza on 31 Jul 2010 07:02
On 31/07/2010 08:31, RG wrote: > In article<8bh6paFspuU1(a)mid.individual.net>, > Pascal Costanza<pc(a)p-cos.net> wrote: > >> On 31/07/2010 00:57, RG wrote: >>> In article<8bh17mFf2U1(a)mid.individual.net>, >>> Pascal Costanza<pc(a)p-cos.net> wrote: >>> >>>> On 30/07/2010 22:53, RG wrote: >>>>> This is a meme that needs to be nipped in the bud: >>>>> >>>>> In article<8bgijdF9jgU1(a)mid.individual.net>, >>>>> Pascal Costanza<pc(a)p-cos.net> wrote: >>>>> >>>>>> In general, I'm >>>>>> quite skeptical about abstracted interfaces for different kinds of >>>>>> collections: Each of them has their own advantages and disadvantages, >>>>>> and you don't easily change from one to the other without considering >>>>>> performance and other implications. So what's the real use of an >>>>>> abstract interface, other that you _can_ abstract it? >>>>> >>>>> ... >>>>> >>>>>> I don't want to discourage you, but again, what's the real use of such >>>>>> abstractions? >>>>> >>>>> To make it easier to change implementations if the assumptions that led >>>>> you initially to choose a particular one turn out to be wrong. Which >>>>> happens a lot. >>>>> >>>>> Why do you doubt the value of this? >>>> >>>> I find it hard to imagine that this matters beyond simple examples. But >>>> that may just be a limitation of my imagination... >>> >>> Who are you and what have you done with Pascal Costanza? >> >> These rhetorical games get a bit on my nerves. > > Oh come on, grow a sense of humor. I don't share your sense of humor. I find these parts of conversations with you unpleasant, which is a pity, because I find most other parts of conversations with you quite interesting. >>> Do you believe that latent typing has value? >> >> Yes. >> >>> What exactly is that value >>> if not the ability to defer the choice of data type? >> >> That's one among many advantages of "latent" typing. There are others. > > Really? Like what? Static type systems have to reject programs that can be nevertheless correct, which can get in the way. Dynamically typed languages can support higher degrees of reflection at runtime. Just two more. >>> What is the point >>> of deferring the choice of a data type if you cannot also defer the >>> choice of algorithm? (What does it even *mean* to defer the choice of >>> data type without deferring the choice of algorithm?) >> >> If you have to change the data type, you probably also have to change >> the algorithm manually yourself, at least that seems to be the case >> based on my experience. >> >> A good example is 'elt: It's a good accessor for vectors, but a very bad >> one for lists. > > Really? What would you recommend to use instead? NTH? I would recommend not to use random access into lists, but rather using mapcar and loops over list elements, and the likes. >> It may be convenient that 'elt abstracts away from lists >> and vectors, but eventually, it probably matters to remove 'elt and >> rewrite your algorithm, at least when you arrive at using lists. To me, >> such an abstraction seems like a minor advantage. > > You're missing the point. If you use ELT then it's easier to replace > lists with vectors than if you use NTH. So why not use ELT? If you use lists with ELT, this is already fishy anyway. >> There are better examples, I know. > > Indeed. A much better example is GETF/ASSOC/GETHASH. There is no > equivalent in CL of ELT for these accessors, so the design of CL > *requires* you to make a premature optimization if you want an > associative map. (Worse, CL doesn't provide reader syntax for hash > tables, which implicitly disparages them in favor of ALists and PLists, > both of which are almost never the right choice for anything except the > simplest examples.) Alists have the easiest way of determining whether an association was actually in a list or not. Plists mesh best with keyword arguments, and similar mappings, and I somewhat prefer them over alists for subjective reasons. Hash tables are only more efficient if there are more than 50, or so, mappings in a table (unless the hash table does automatic adaptation of its internal representation, but I'm not aware of a good implementation of such an adaptive hash table). To me, this is another good example of data structures that provide slightly interesting differences that I nevertheless find worthwhile to be able to take advantage of. I would not like these differences to be removed because of an attempt to make everything look the same. Fortunately, there is no contradiction there. You could use a collection library, while I could continue to use the low-level substrates... >> But they don't really convince me >> that much either. Maybe your experiences are just different from mine, >> who knows. > > Have you never had to change large sections of code because you found > out after you wrote it that it ran too slowly because you used a list > where you should have used a vector? Or an AList where you should have > used a hash table? Or a hash table where you should have used a > red-black tree? Sure. It's a trade off. I still prefer being able to make the fine-grained distinctions. >>> Or do you think >>> that latent typing has no benefits beyond "simple examples" and that >>> complex systems ought to be written in statically typed languages? >> >> This is not an implication of what I said. > > It wasn't intended to be. It was intended to be a possible explanation > of why you said what you said. I don't know what to make of this. I'm pretty sure you are aware of my position against static typing. So it seems to me that you're asking this rhetorical question to provoke a certain reaction in me. Why do you do that? >> I'm not trying to argue against building a good abstract collection API, >> if you believe that's going to buy you something. I'm just trying to >> express my skepticism about their usefulness, which seems to be >> considered higher than it actually is, IMHO. YMMV. > > But that is exactly what puzzles me. You see the value in latent > typing, but not in abstraction. And yet the value in those two things > is exactly the same, namely, the ability to write code in a way that > lets you defer decisions. So I don't understand how you can value one > and not the other. I see value in abstraction, but not as much as seems to be the common case. It's not an either-or thing, there are different degrees possible. For example, static typing allows for stronger abstractions than dynamic typing, yet I still prefer dynamic typing, with a reasonable amount of abstractions here and there. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ |