A larger vocabulary is clearly better for communicating the programmers intent. If that weren't the case, then you'd just use a for loop and the list size to do everything keeping the smallest possible interface on the list. Using detect without using the result is deceptive, you're lying to the reader and trying to confuse him.
 

I'll argue that Ruby does make a difference here; there's a semantic difference between detect and what I expect out of any. It can be defined in a very brief irb session:

>> x = [nil, false, true]
=> [nil, false, true]
>> x.detect {|y| y == nil}
=> nil
>> !!x.detect {|y| y == nil}
=> false
>> x.any {|y| y == nil}
=> true
 

Again though, it could just be python influencing my intuitions:

>>> x = [True, False, None]
>>> any(y == None for y in x)
True
 

Reading over my comments, I should clarify why this matters to me, because of course you are using detect to look for integers, where of course it will function perfectly well. (It wouldn't in python because zero is falsish).

My problem with doing so is that it's not thinking axiomatically. In my head, I would look for a function that always returned a truish object upon finding it, and detect wouldn't fit the bill (as shown above).

Thus, my argument is that you have not presented an example of a situation where a convenience method may be useful instead of a manipulation of an axiom, but instead a place where there is clear necessity for a further axiom.

(Side note #1: What would be your favorite modification of the "detect" idiom to be correct for all values of x? I'd use x.index I think?)

(Side note #2: I forgot to mention the very clean python idiom for checking for an element's existance in an array:

>> x = [True, False, None]
>> None in x
True
)
 

I agree that since you're not using the result, the version with detect does not as clearly show your intent.

While not meaning to stir up arguments about premature optimization, efficiency is a concern as well. Because of your usage of some exotic structure(e.g. Bloom filter, "ropes" instead of strings, etc.) perhaps a method like any can take advantage of something "clever" that would be impossible to take advantage of from a more "axiomatic" interface.
 

The language that makes up the technical base is the foundation for expressing your specific programming solution. It is best to completely encapsulate that technical level with a higher problem-domain-specific one.

My reasoning is that you have to create a higher level vocabulary anyways, so the most readable solution doesn't flip flop between the two (doubling up in size) it sits complete at an upper level.

There is nothing wrong with framing the problem with your own primitives, but within that context it must be consistent and used consistently to be easily readable.

I'm working on a new post to dig a bit deeper into readability. Hopefully it will be finished in a day or two.

Paul.
http://theprogrammersparadox.blogspot.com
 

Personally, I think that any language feature which encourages the use of the bangbang operator (!!) is a misfeature. English classes discourage double negatives for a reason.
 

It's 'any?' not 'any'

That to me makes a big difference, because the ? signals a boolean test.

I love how ruby does that with blah? and modify! methods, nothing would make me happier than for them to enforce it, the same way C++ enforces const member functions.

Anyway, I'm firmly on the side of large vocabularies. They let you write your code more as a sentence or statement for a human to read, rather than a list of instructions for a computer to execute.

With small languages everyone ends up reinventing the wheel, and writing a zillion helper functions to do things like .any?, so apart from the disk space required to ship a larger standard library, there's no downside to having a bigger vocab IMHO
 

AFAICT, the rule in Ruby is that "?" does signal apredicate method (like foo-p in CL), but "!" is only used to disambiguate destructive vs. the non-destructive versions of the same method (like reverse and reverse! or compact and compact!)
 

and here I was typing:

some_array.inject(false){|bool, el| bool = bool ? el.test : bool}

at least today I know I learned something.
 

I think that problem spaces have a certain vocabulary size and that source code solving problems in that space should scale relative to that.

There may be ways to trivially disprove this assertion (i.e. a problem with a small vocabulary that requires an enormous vocabulary to solve, like an NP-complete problem solved in P).
 

I'm mostly with bill mill. detect was a bad choice.

But you do mention fold, which i think is the same as reduce/inject.

I was going to mention the code nathan posted as the alternative using inject.

but now i'm going to go on tangent.

I often transform an array into a hash by some property of the array. For example I might want to group a list of people by lastname. I generally do:

people.inject(Hash.new{[]}) { |h, p| h[p.lastname] << p; h }

or

people.inject({}) { |h, p| (h[p.lastname] ||= []) << p; h }

Once I abstracted that away and created something like

array.hash_by { |n| n.foo }

but i never remember to use it.

I think using inject here shows the intent more clearly, because everybody knows how inject works, but no one knows hash_by, probably not even me, a few weeks in the future.

What I guess I'm trying to get at is: you can build a great language with just map/filter/reduce (collect/select/inject, etc). But part of that great language will be the helper methods you write with these building blocks. The same code you started with could be implemented in many ways with them:

list.map { |n| n > 100 }.inject { |a, b| a && b }
list.select { |n| n > 100 }.length != 0

and the aforementioned reduction by nathan.

And yet, I'm all for #any? as a language feature. Not at all because it's performance-wise better than inject because it can exit early (and detect/find do that too), but because it's pretty damn obivous.

In the end I just think your example shot itself in the foot because detect is really bad there, and any is really great. Instead, how do you feel about my hash_by?
 

Of course, the any? version is clearer, it's also less likely to hide a bug. But even if it weren't, !! brings me out in hives. It's pure noise - there's absolutely no reason to go coercing any result into a boolean in such a simple minded fashion because everything that deals with truthy values already knows about what is truthy.

Seeing !! in code tells me is that the author hasn't got over static typing yet.
 

user.has_photo?
user.photos.count > 0

What do you think about this more subtle difference?
Do you think both can live together in a single codebase?
If so, how do we make programmers use the right one?