A. Pagaltzis writes: > Hi all, > > so Guido is talking about his reasoning behind dropping lambda, > reduce(), filter() and map() in the next generation of Python: > > http://www.artima.com/weblogs/viewpost.jsp?thread=98196 > > [Prime quote: "I think having the two choices side-by-side just > requires programmers to think about making a choice that's > irrelevant for their program; not having the choice streamlines > the thought process."]
Hmm. As people have pointed out, this is essentially reinforcing a Python philosphy: TOOWTDI. Guido's point about map and filter I can understand. He points out that both of them can be easily transformed to list comprehensions. He's using a design philosophy that Java started with: when you give programmers fewer choices about how to do something, the probability that they'll do it in the conventional, widely-understood way goes up. Where Guido's philosophy falls down is around the Hard Things. Many problems can be solved easily with simple procedural code. But when you run across a problem that can't, say, in programming an AI, then you have Python programmers doing a *lot* more work than Prolog programmers. So in that regard, I think dropping lambda and reduce is idiotic. Dropping filter and map is not; there's another WTDI which does the exact same thing. That's certainly not Perl's philosophy. Perl intends to be multiparadigmatic so that whatever your programming background, you can find a sweet spot in Perl. Of course, that makes it hell for most people reading code who don't have backgrounds in every paradigm. But Perl and CPAN culture facilitate that quite well: unlike in Java, CPAN modules' documentation is separate from the code structure. This encourages authors to write something *useful* about their module, to explain their module to the most basic programmer. What can we reap from Guido's reasoning? It's actually pretty simple, I think. He found two functions which were doing the same thing as list comprehensions, and so he got rid of them. If we see one feature that can always be done as easily or more easily with another feature, it can probably go. Note that I'm not identifying "easy" with "short". If feature A can always be expressed more concisely with feature B, feature A may deserve to stick around for those people who don't understand feature B yet. Hyper operators come to mind. Luke
