3 ms·

So, you did tests to show that linked lists are slower AND use more memory? Which we both already knew? Why? > I can also construct cases, where the list is mu

So, you did tests to show that linked lists are slower AND use more memory? Which we both already knew? Why? > I can also construct cases, where the list is much faster. Adding a one element list/vector to the front: Oh good, I'll keep that in mind for the next time I am forced to prepend a bunch of items to a list, which I expect to happen approximately 0 times before I die of old age. > > Are you even capable of admitting that Lisp has serious faults > You seem to be keen to find "faults". Usually things are not black and white. There is no true and false, but engineering trade-offs. These tradeoffs can Lisp make the wrong choice for problems. Many of the trade-offs are also influenced by non-technical issues: like the amount of engineering time invested into a language implementation: see SUN/Oracles investment into Java. So... what I'm hearing here is, that no, you aren't capable of admitting that Lisp has faults. I'm aware that tradeoffs exist. I'm also aware that faults exist. These two can both be true. It seems to me that being slower and using more memory and getting nothing in return isn't a tradeoff.

lispm 2y ago
> So, you did tests to show that linked lists are slower AND use more memory? Which we both already knew? Why? I showed you that it often does not matter much. > Oh good, I'll keep that in mind for the next time I am forced to prepend a bunch of items to a list, which I expect to happen approximately 0 times before I die of old age. It's not that uncommon, for example for a simple stack implementation. > So... what I'm hearing here is, that no, you aren't capable of admitting that Lisp has faults. With this discussion style you won't get very far. > It seems to me that being slower and using more memory and getting nothing in return isn't a tradeoff. Right, I think that's a useful task for you to actually think about: what do we get in return? Why does Haskell use linked lists? Why does INRIA's OCAML ( https://ocamlbook.org/lists-and-structural-recursion/ https://ocamlbook.org/lists-and-structural-recursion/ ) ? Why does Microsoft's F# ( https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/lists https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... ) ? Why does Ericsson's Erlang ( https://www.erlang.org/doc/system/listhandling.html https://www.erlang.org/doc/system/listhandling.html ) ?
- kerkeslager 2y ago
  > I showed you that it often does not matter much. ...which we also both already knew. The thing is, it does matter sometimes; often enough that there's no good reason to take the less performant route by default. > > Oh good, I'll keep that in mind for the next time I am forced to prepend a bunch of items to a list, which I expect to happen approximately 0 times before I die of old age. > It's not that uncommon, for example for a simple stack implementation. 1. Does Lisp not come with a stack implementation? In general, I do not plan to implement simple stacks. 2. Pushing items onto a stack isn't inherently a prepend operation. It's generally a "put it on an end" operation, meaning you could append it. Now, with a linked list that would be slower, so obviously you prepend if you're using a linked list, but if you're using a vector, you append. And, lo and behold, appending-vector-based stack performs better than a prepending-linked-list-based stack, because cache. So if I do implement a simple stack, I implement it with a vector (example[1]). I'm a professional. I'm not writing high school CS level demo programs. If I need a stack, I'm generally using the standard implementation that ships with the language, and if the language doesn't have one, I implement a stack with a vector because there's no upside to implementing it as a linked list. So no, it's not common to prepend to a list, and unless your language is intended for writing high school CS level programs, it probably shouldn't prominently feature linked lists as a normal way to do things, and if it does, that's a problem. Not a tradeoff, because you're not getting anything in return. A problem. > > So... what I'm hearing here is, that no, you aren't capable of admitting that Lisp has faults. > With this discussion style you won't get very far. And how far has your jumping in to defend Lisp and never admitting it has any faults gotten you? > Right, I think that's a useful task for you to actually think about: what do we get in return? Nothing I need or want. Yes, I know the answer you're fishing for is "immutability" but the fact is if you're operating on lists as a whole, i.e. your map/reduce/etc. type operations, you can achieve immutability with vectors, and it will be more performant when you do so. > Why does Haskell use linked lists? > Why does INRIA's OCAML ( https://ocamlbook.org/lists-and-structural-recursion/ https://ocamlbook.org/lists-and-structural-recursion/ ) ? > Why does Microsoft's F# ( https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... ) ? > Why does Ericsson's Erlang ( https://www.erlang.org/doc/system/listhandling.html https://www.erlang.org/doc/system/listhandling.html ) ? Because all these languages are wearing the same FP blinders as Lisp. Why aren't any of these languages popular? ;) [1] https://craftinginterpreters.com/a-virtual-machine.html#the-vms-stack https://craftinginterpreters.com/a-virtual-machine.html#the-...

lispm 2y ago

> So, you did tests to show that linked lists are slower AND use more memory? Which we both already knew? Why? I showed you that it often does not matter much. > Oh good, I'll keep that in mind for the next time I am forced to prepend a bunch of items to a list, which I expect to happen approximately 0 times before I die of old age. It's not that uncommon, for example for a simple stack implementation. > So... what I'm hearing here is, that no, you aren't capable of admitting that Lisp has faults. With this discussion style you won't get very far. > It seems to me that being slower and using more memory and getting nothing in return isn't a tradeoff. Right, I think that's a useful task for you to actually think about: what do we get in return? Why does Haskell use linked lists? Why does INRIA's OCAML ( https://ocamlbook.org/lists-and-structural-recursion/ https://ocamlbook.org/lists-and-structural-recursion/ ) ? Why does Microsoft's F# ( https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/lists https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... ) ? Why does Ericsson's Erlang ( https://www.erlang.org/doc/system/listhandling.html https://www.erlang.org/doc/system/listhandling.html ) ?

kerkeslager 2y ago
> I showed you that it often does not matter much. ...which we also both already knew. The thing is, it does matter sometimes; often enough that there's no good reason to take the less performant route by default. > > Oh good, I'll keep that in mind for the next time I am forced to prepend a bunch of items to a list, which I expect to happen approximately 0 times before I die of old age. > It's not that uncommon, for example for a simple stack implementation. 1. Does Lisp not come with a stack implementation? In general, I do not plan to implement simple stacks. 2. Pushing items onto a stack isn't inherently a prepend operation. It's generally a "put it on an end" operation, meaning you could append it. Now, with a linked list that would be slower, so obviously you prepend if you're using a linked list, but if you're using a vector, you append. And, lo and behold, appending-vector-based stack performs better than a prepending-linked-list-based stack, because cache. So if I do implement a simple stack, I implement it with a vector (example[1]). I'm a professional. I'm not writing high school CS level demo programs. If I need a stack, I'm generally using the standard implementation that ships with the language, and if the language doesn't have one, I implement a stack with a vector because there's no upside to implementing it as a linked list. So no, it's not common to prepend to a list, and unless your language is intended for writing high school CS level programs, it probably shouldn't prominently feature linked lists as a normal way to do things, and if it does, that's a problem. Not a tradeoff, because you're not getting anything in return. A problem. > > So... what I'm hearing here is, that no, you aren't capable of admitting that Lisp has faults. > With this discussion style you won't get very far. And how far has your jumping in to defend Lisp and never admitting it has any faults gotten you? > Right, I think that's a useful task for you to actually think about: what do we get in return? Nothing I need or want. Yes, I know the answer you're fishing for is "immutability" but the fact is if you're operating on lists as a whole, i.e. your map/reduce/etc. type operations, you can achieve immutability with vectors, and it will be more performant when you do so. > Why does Haskell use linked lists? > Why does INRIA's OCAML ( https://ocamlbook.org/lists-and-structural-recursion/ https://ocamlbook.org/lists-and-structural-recursion/ ) ? > Why does Microsoft's F# ( https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... ) ? > Why does Ericsson's Erlang ( https://www.erlang.org/doc/system/listhandling.html https://www.erlang.org/doc/system/listhandling.html ) ? Because all these languages are wearing the same FP blinders as Lisp. Why aren't any of these languages popular? ;) [1] https://craftinginterpreters.com/a-virtual-machine.html#the-vms-stack https://craftinginterpreters.com/a-virtual-machine.html#the-...