38 ms·

There’s a lot missing from Go’s stdlib, including obvious uses for its builtin types. If you want Common Lisp’s (remove-if-not #'oddp #(1 2 3 4 5)) you have

There’s a lot missing from Go’s stdlib, including obvious uses for its builtin types. If you want Common Lisp’s (remove-if-not #'oddp #(1 2 3 4 5)) you have to write a loop from scratch, and then everyone has to read it carefully to learn what it’s doing (and especially what it’s not). Don’t get too excited about having HTTP or JSON built in, we weren’t using those in 1990 and they’ll surely be replaced by 2050.

kazinator 4y ago
Strangely, ANSI CL says that remove-if-not is deprecated. That probably wouldn't be the case if it had been named retain-if or keep-if; the issue is likely the double negative. A function which pares down a sequence to just those elements which match a predicate is very useful; why would you deprecate such a thing.
- lokedhs 4y ago
  Probably because the idea of the standards group was that you already had REMOVE and COMPLEMENT, so there was no need for it. These days the function is usually called filter, but I'm not sure it was a commonly used term then.
  - kazinator 4y ago
    Even GNU make has $(filter ...) and $(filter-out ...). It'a terrible name, by the way. A filter separates; it has two outputs. Does a function named filter return the filtrate or the residue? And I just had to look up filtrate to check which one of the two it refers to and what is the opposite term. From now on I will remember that there is residue captured in a filter, and filtrate is not that.
jstimpfle 4y ago
> you have to write a loop from scratch That would be terrible, those loops are crazy dangerous. I would avoid writing a loop and rather come up with a whole different programming paradigm. Maybe a macro system or something based on category theory?
- erik_seaberg 4y ago
  The problem is that find first, find last, find all, filter, map, flatmap, and reduce all look pretty much the same when written as loops, and writing and reviewing any of these more than once is a poor use of time.

kazinator 4y ago

Strangely, ANSI CL says that remove-if-not is deprecated. That probably wouldn't be the case if it had been named retain-if or keep-if; the issue is likely the double negative. A function which pares down a sequence to just those elements which match a predicate is very useful; why would you deprecate such a thing.

lokedhs 4y ago
Probably because the idea of the standards group was that you already had REMOVE and COMPLEMENT, so there was no need for it. These days the function is usually called filter, but I'm not sure it was a commonly used term then.
- kazinator 4y ago
  Even GNU make has $(filter ...) and $(filter-out ...). It'a terrible name, by the way. A filter separates; it has two outputs. Does a function named filter return the filtrate or the residue? And I just had to look up filtrate to check which one of the two it refers to and what is the opposite term. From now on I will remember that there is residue captured in a filter, and filtrate is not that.

jstimpfle 4y ago

> you have to write a loop from scratch That would be terrible, those loops are crazy dangerous. I would avoid writing a loop and rather come up with a whole different programming paradigm. Maybe a macro system or something based on category theory?

erik_seaberg 4y ago
The problem is that find first, find last, find all, filter, map, flatmap, and reduce all look pretty much the same when written as loops, and writing and reviewing any of these more than once is a poor use of time.