> "A language that doesn't affect the way you think about programming, is not worth knowing"

Makes a good quote, but I don't buy it from a practical perspective. Library support is my primary motivation in choosing which scripting language to use for work projects. I don't think much differently at all in Ruby than in Python, but knowing both is extremely helpful.

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

As you point out, Project Euler and other simple puzzles are good for picking up new languages. Of course, Euler actually has a broad set of tough problems, but many people prefer solving the first tenner using one-liners.

It's slightly vintage now, but there is nothing better for getting actual algorithmic problem solving ability per time invested than USACO at http://train.usaco.org/usacogate. It was developed by the US high school competitive programming coaches. If you can plow your way through the first couple of sections, even the toughest interview questions will seem easy.

Serious.

I also like the Python Challenge: http://www.pythonchallenge.com/

oh I like how they get harder quickly and are not just about math and string/number/list manipulation like most puzzle sites. They make you delve into python (of course I used `requests` instead of the suggested `urllib` for problem 4) and have some very nice (but so far not too hard) riddle elements!

... And I just finished problem 5. very cool!

sorry for the double post, but seriously these challenges are some of the most original I've seen!

it reminds me a bit of +Malattia's 3564020356.org website. although those are sometimes quite a bit "reversing" (reverse engineering/cracking/code=data) oriented and (IMO) get pretty hard. Of course I don't know how complex these pythonchallenges are going to become, but most of +Malattia's levels require a couple of hours or to be solved over days. You can solve the first few without programming skills, although they do help :) I forget how far I came with these, maybe level 6 or 7. Seems he lost accounts made before 2006, so I can't check for sure.

The site itself is pretty old (10 years, at least), so any hints that refer to external web resources/material might be long dead, and you either have to use archive.org or accept the additional challenge of finding other mirrors (I'm fairly confident most stuff must have been mirrored in some dusty corner of the web, since the "scene" that's behind these challenges were not so much "reversers" as they are "+seekers") (try googling for filenames, and such).

Good luck! (those who are up for it ;-) )