map/filter/reduce/lambda opinions and background unscientific mini-survey

[Steven D'Aprano]

On Fri, 01 Jul 2005 13:42:10 -0400, Mike Meyer wrote:

> "iK" <Ik at sdsfsfd.com> writes:
> 
>> Seems like he wants python programmers to solve their problems all in the 
>> same way. While that is great for corporate slaves it is terrible for the 
>> creative programmer.
> 
> No, he wants Python to be Pythonic. TMTOWTDI is not Pythonic.

Too Many T--- Only Way To Do It?

There Might Tangle One Way To Do It?

T--- M--- Two Obvious Ways To Do It?

Nope, sorry, still not getting it.

>> Python is quickly becoming the visual basic of the 21 century. If you want 
>> to have fun while getting some work done you need to look elsewhere. It's a 
>> shame... 
> 
> If you'd rather spend your time figuring out which of multiple ways to
> do things is the best for the job at hand than producing code, there's
> a language that makes TMTOWTDI a way of life.

Figuring out which of multiple ways to do things is the best for the job
at hand _is_ part of producing code. There will always be multiple ways to
do the job. For starters, there is the choice, which language should I
use? Top-Down or Bottom-Up design? Test-driven or not? For loop or list
comprehension or generator? Procedural programming or object-oriented or a
mixture of both? Singleton or Borg design pattern? Test your data first or
deal with the exceptions when they happen? And so on.

Only One Obvious Way makes a nice slogan, but it is easy to turn a
flexible language like Python into a straight-jacket where there is Only
One Way To Do It Regards Of Whether It Is The Best For The Job On Hand Or
Not. Not such a short and concise slogan.

Now that Python has list comps, should for loops be removed from the
language? Why did Python bother introducing list comps when there is
nothing they can do that a for loop can't?

Functional programming using map etc does require a slightly different way
of thinking about programming than does procedural programming, just as
object-oriented needs a different way of thinking than spaghetti-coding
using GOTOs. Different ways of thinking about programming should be
encouraged, not discouraged. Even the much-maligned GOTO has its modern
usage case: the Exception.

If map/filter/reduce have to be removed from the built-ins, and I don't
think they should, I'd prefer for them to be moved into a module rather
than dropped altogether. Provided list comps are made as fast as map and
filter, then at the cost of readability they can be replaced by list
comps. But reduce can't be written as a list comp, only as a relatively
complex for loop at a HUGE loss of readability -- and I've never used
Lisp or Scheme in my life. I'm surely not the only one.



-- 
Steven