4 ms·

> If you undertake this exercise you will come to know the answer to the question: [...] We could also know the answer if you just told us. It's bad form to ma

> If you undertake this exercise you will come to know the answer to the question: [...] We could also know the answer if you just told us. It's bad form to make readers jump through hoops for insights you could easily share. This is not school, you are not supposed to assign homework to make us learn.

lisper 8y ago
Sharing this insight is not so easy. It's not a pithy aphorism that fits in an HN comment. It would take at the very least a blog post that would probably take me a couple of hours to write. Doing the exercise would take less time (do it in Python or Ruby).
- KayEss 8y ago
  What is the observable effect then? I can really only think of two: A particular performance characteristic, or that modifications of shared tails in lists are observable across lists. Is this latter that is the problem?
  - lisper 8y ago
    Vectors are a lot of work for no gain. They make everything more complicated, especially if you want an efficient CDR operation, and there's just no reason for it. Yes, your code might compile a little faster, but Lisp code is generally compiled incrementally anyway, so compile cycles tend to be measured in milliseconds already. There's just no point in speeding it up any further.
    - KayEss 8y ago
      LOL
- tom_mellior 8y ago
  Don't write the blog post, only write the "conclusions" section. "Not using conses leads to more copying and more garbage being generated" or whatever.
  - lisper 8y ago
    Conclusions: Lisp is invariably implemented in terms of conses rather than vectors for a wide variety of reasons, which were discussed in detail in the preceding post. No one of these multiple reasons stands out as the "killer advantage". Vectors just turn out to be the death of a thousand complexities, whereas conses are simple, extremely flexible, and sufficiently efficient for the purpose. A great deal of additional insight can be gained by actually implementing Lisp both ways and experiencing the differences first hand.

lisper 8y ago

Sharing this insight is not so easy. It's not a pithy aphorism that fits in an HN comment. It would take at the very least a blog post that would probably take me a couple of hours to write. Doing the exercise would take less time (do it in Python or Ruby).

KayEss 8y ago
What is the observable effect then? I can really only think of two: A particular performance characteristic, or that modifications of shared tails in lists are observable across lists. Is this latter that is the problem?
- lisper 8y ago
  Vectors are a lot of work for no gain. They make everything more complicated, especially if you want an efficient CDR operation, and there's just no reason for it. Yes, your code might compile a little faster, but Lisp code is generally compiled incrementally anyway, so compile cycles tend to be measured in milliseconds already. There's just no point in speeding it up any further.
  - KayEss 8y ago
    LOL
tom_mellior 8y ago
Don't write the blog post, only write the "conclusions" section. "Not using conses leads to more copying and more garbage being generated" or whatever.
- lisper 8y ago
  Conclusions: Lisp is invariably implemented in terms of conses rather than vectors for a wide variety of reasons, which were discussed in detail in the preceding post. No one of these multiple reasons stands out as the "killer advantage". Vectors just turn out to be the death of a thousand complexities, whereas conses are simple, extremely flexible, and sufficiently efficient for the purpose. A great deal of additional insight can be gained by actually implementing Lisp both ways and experiencing the differences first hand.