I mostly agree with you in that there are perfectly valid reasons for learning similar languages. The quote is too strong, too absolute. But I still have a weakness for the quote because learning languages that alter your thinking is so much more useful than learning ones that don't.

As to ruby/python, I only have a superficial knowledge of Python, so please correct me if I'm wrong, but my understanding is that ruby blocks let you do thinks you can't in python. Rspec is one of the examples that gets talked about a lot. But if I were asked to sum all the numbers divisible by both 3 and 5 between 1 and 100 in Ruby, I'd do it like this

  (1..100).select{|a| a % 3 == 0}.select{|a| a % 5 == 0}.inject(&:+)

In my mind, that is a completely different way of solving the problem than by running a loop. My understanding is that you can't really do something like that conveniently in Python. Though, like I said, I really don't know python, so please do correct me if I have that wrong.

  sum([x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0])

edit: actually sum the list. Of course, it's even shorter if you realize you can write it as:

  sum([x for x in xrange(1, 101) if x % 15 == 0])

You're better off making that a generator:

sum((x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0))

Notice the parenthesis instead of square brackets. Your version actually creates a list in memory. A generator generates the items one by one and doesn't need to store them all at the same time.

You can just write it as

  sum(x for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0)

and skip the inner set of parenthesis; the parenthesis on a generator expression are not needed if it is the only argument to a function.

Seriously? The discussion is about language features, not optimal algorithms.

One could imagine the question was actually "sum BusyBeaver(n) for n divisible by 3 and 5 between 1 and 100", i.e. no closed form. In Python:

  sum(BusyBeaver(x) for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0)

(And yes, if one was being really pedantic, one could replace the condition with x % 15 == 0.)

The thing is that people start using those libraries w/o thinking before - and theirs' solutions end up doing much more work than is needed

This could be said of most anything high level.

true, but xrange(1,101) is so tiny, who cares!

Despite the answers provided by fellow HNers, even if there wasn't a loop-less way to handle the scenario in Python, I assert that taking advantage of a language feature doesn't necessarily equate to "altering your thinking". You may find yourself, though, altering your thinking after defining language features have accumulated to a certain degree.

I agree, the quote is more applicable to conceptually very different languages (e.g. Lisp, Forth, and Smalltalk) than to clever features of particular languages.

Or in javascript..

  new Array(100).join(1).split(1)
    .map((function() { var i = 0; return function() {return ++i;}})())
    .filter(function(x) { return !(x % 15); })
    .reduce(function(x, a) { return a += x; }, 0);

Some examples

1. Purely declarative animations in a general purpose language http://conal.net/fran/tutorial.htm

2. A recursive descent parser where you can declare your grammar as in yacc i.e. it is not a separate compiler generator but a regular library, and the code is type safe unlike yacc. The best part is that the actual library is just 2 lines of code, thanks to the magic of lazy evaluation and a powerful type system.

result v = \inp -> [(v,inp)]

p `bind` f = \inp -> concat [f v out | (v,out) <- p inp]

http://eprints.nottingham.ac.uk/237/1/monparsing.pdf