[jmcomets]

One-liners are bad if they are obscure and experienced programmers know that. However I wouldn't go as far as say that experienced programmers don't use one-liners at all. As usual in programming, it's all about balancing clarity/conciseness.

For example, I find this much clearer as a one-liner (Python):

    validated_items = filter(is_validated, items)

rather than

    validated_items = []
    for item in items:
        if is_validated(item):
            validated_items.append(item)

[graton]

Or:

validated_items = [x for x in items if is_validated(x)]

[im3w1l]

I prefer the other one, because then I don't have to consider whether there is an outer variable 'x' that is being clobbered.

[aidos]

In python 3, x is locally scoped to the comprehension :-)

[Singletoned]

Most linters would have suggested correcting it to:

validated_items = [_ for _ in items if is_validated(x)]

where _ is used as a safe variable that can always be clobbered. (Though this does also clash with its use as a gettext function for strings).

[brobinson]

Ruby version is a pretty clear one-liner:

    validated_items = items.select { |item| is_validated?(item) }

Though I'd expect a check for validation to be an instance method, so it'd probably look like:

    validated_items = items.select(&:validated?)

[Singletoned]

I don't find either of the Ruby versions clear at all. Both contain unnecessary syntax.

Ruby seems to be going down the same path as Perl in trying to make all possible combinations of characters valid programs.

[mfontani]

    my @validated = grep { is_validated($_) } @items;

I'd argue the Perl version is clearer... assuming you know its syntax, that is.

[lparry]

Even if it's not an instance method you can write the first as

  validated_items = items.select(&method(:is_validated?))

(Typed on my phone but I'm pretty sure that's the right syntax)

[brobinson]

It is! I'd forgotten about Kernel.method. Thanks!

[andrewprock]

"filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation. On the other hand "append" feels like a much more conventional and comprehensible name.

[jmcomets]

I agree with you that `filter` is less explicit than something like `copy_if` (C++).

Does it return elements matching the predicate or not matching it? I struggled with this for a while in CS.

After learning different programming languages and getting some field experience I noticed that the `filter` pattern is pretty common in the programming world. It's one of those pervasive functional patterns that are so practical that they were included at some point in imperative languages.

[coldtea]

>"filter" has to be the worst library name. I have no clue what it's doing unless I read the documentation

It, I dunno, FILTERS a collection keeping only certain elements (those that match the filter)? What else would it possibly do? Besides a standard CS term, it's also a concept from real life...

To me the name is crystal clear.

[andrewprock]

A filter creates two sets, one with the thing, and the other without. When you filter something, you might be interested in what is filtered in, or what is filtered out.

Ponder for a second the phrases, "filtered water", "coffee filter", "camera filter", etc. In all of those cases, you are interested in the set without the filtered thing, not with.

Compare this to "select" which is a much clearer name.

[coldtea]

>Ponder for a second the phrases, "filtered water", "coffee filter", "camera filter", etc. In all of those cases, you are interested in the set without the filtered thing, not with.

Filtered is akin to "cleansed" (it refers to the "main body") not akin to "picked out" (which would have applied to the undesirable elements.

It's actually the water (or the light, in the case of camera filter) that's filtered (hence the name "filtered water" and not "filtered dust and detritus").

The other stuff is not what's being filtered -- just what's "filtered out".