4 ms·

You characterized this deficiency in light of your own belief that lists should not be used, so I was responding to that part that I disagree with. It’s like Py

by jolux 4y ago

You characterized this deficiency in light of your own belief that lists should not be used, so I was responding to that part that I disagree with. It’s like Python purposefully crippling lambdas to discourage their use. If you don’t think people should use a feature, just don’t add it. Incidentally I agree with you about lists and only meant to use it as an example of a place where the stdlib authors chose a simple implementation over one that does what you expect. As soon as I started reading the stdlib source and seeing things like that, I immediately understood why Core exists and realized I wouldn’t be able to trust the stdlib in production. It violates the principle of least surprise. It’s one thing to do stuff like this in Haskell where it makes sense because of lazy evaluation, it’s another to do it in an eager language which acknowledges the need to make concessions to practical usage.

yawaramin 4y ago
Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. Also, > violates the principle of least surprise I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given.
- jolux 4y ago
  > Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. The point is that this pattern makes sense in a lazy-evaluated language, not that everything Haskell does makes sense. I think it's a less defensible choice than OCaml in most cases. > I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given. I read the docs and I still disagree with the choice made here. There's no need to include two functions when one will do. This is not pragmatism, it's laziness.
  - yawaramin 4y ago
    > There's no need to include two functions when one will do. This is not pragmatism, it's laziness. If providing two slightly different ways to do something is laziness, then pretty much every language is guilty of that. Also, Larry Wall: 'Laziness is a virtue' ;-)
    - jolux 4y ago
      But again that's not a justification. There's no reason for there to be two functions here, other than that it's easier for the implementers. I'm being serious when I say I don't think I've ever seen another standard library that prioritizes ease of maintenance over ease of consumption. Quite possible that I'm missing something! Maybe Common Lisp or another language nobody uses?
      - yawaramin 4y ago
        Well, you're extrapolating from one example where the standard library doesn't behave as you want, and characterizing the entire library as 'lazy'. I don't agree with that characterization, and as I already said, the justification has been given. You just don't agree with it, that's fine. It's still a valid justification.

by jolux 4y ago

yawaramin 4y ago

Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. Also, > violates the principle of least surprise I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given.

jolux 4y ago
> Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. The point is that this pattern makes sense in a lazy-evaluated language, not that everything Haskell does makes sense. I think it's a less defensible choice than OCaml in most cases. > I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given. I read the docs and I still disagree with the choice made here. There's no need to include two functions when one will do. This is not pragmatism, it's laziness.
- yawaramin 4y ago
  > There's no need to include two functions when one will do. This is not pragmatism, it's laziness. If providing two slightly different ways to do something is laziness, then pretty much every language is guilty of that. Also, Larry Wall: 'Laziness is a virtue' ;-)
  - jolux 4y ago
    But again that's not a justification. There's no reason for there to be two functions here, other than that it's easier for the implementers. I'm being serious when I say I don't think I've ever seen another standard library that prioritizes ease of maintenance over ease of consumption. Quite possible that I'm missing something! Maybe Common Lisp or another language nobody uses?
    - yawaramin 4y ago
      Well, you're extrapolating from one example where the standard library doesn't behave as you want, and characterizing the entire library as 'lazy'. I don't agree with that characterization, and as I already said, the justification has been given. You just don't agree with it, that's fine. It's still a valid justification.