That's a trite response. Complexity, power, and culture differ between languages. In Perl, people make a game out of doing as much in a single line as possible. Experts do things that are mystifying to a beginner. In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a less expert programmer couldn't understand.
In Perl, people make a game out of doing as much in a single line as possible.
Wrong. It's not 1995 anymore.
Experts do things that are mystifying to a beginner.
And this is a Perl thing? What I've found from listening to beginners is that they accuse every programmer of intentionally mistifying them. OO is too hard. Macros are too hard. Monads are too hard.
Unfortunately, the experienced programmers use these features because there is a significant productivity advantage in doing so. They don't use the features to intentionally confuse beginners. The good news is that the beginners can use these features too, as soon as they are willing to admit that maybe the experts aren't actually out to subtly screw them over.
In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a less expert programmer couldn't understand.
I don't think you get that cultures differ, or that Perl one-liners capture something about the Perl culture. There's nothing wrong with the Perl culture, and the Perl language is well-suited to it. It's certainly different from the Python culture. Not only that, the "Python culture" in the sense of people who write about and influence Python is not synonymous with Python programmers, not by a long shot. Programmers are different -- "programmers are programmers" only if you define programmers fairly narrowly as professional programmers who measure their worth by their ability to use programming languages in the most elegant and powerful way possible.
Among software developers, Python programmers are of course keen to demonstrate that Python is just as awesome as other languages. That isn't really the point of Python, though. Python's value was never in how it served people who could afford to devote a lot of time to mastering it. You wouldn't judge a Prius by how fast Michael Schumacher could drive it around a track, would you?
There is a whole population of programmers out there who really don't give a damn about programming languages and who rightly don't invest a lot of time in mastering programming. They exist, they do important work, and Python's ability to serve them is important -- that's the bottom line and the truth, even if this audience isn't eager to hear it. People like that are sensitive to the difference between Ruby and Python, and they've mostly never seen decorators.
> It would be un-Pythonic to write code that a less expert programmer couldn't understand.
I assume you have syntactical concerns and syntactical concerns only in mind, as domain knowledge and local style and creative decisions are far more important for maintainability. Even so, I don't believe you. I've seen far too much Python code which uses decorators and generators and list comprehensions to believe that it's un-Pythonic to "write code that a less expert programmer couldn't understand".
The point is that as a Python programmer, even a casual one, I know what decorators and generators are and can look up how they work. I can pretty confidently expect to figure out what they mean in any case I need to.
And yeah, the language has arguably become less Pythonic as it caters to more expert programmers at the expense of less expert ones. From the beginning, there have been people who claimed that primitive, clear, inelegant code is worse than elegant, concise code that depends on extra language features. Usually that claim has been rejected, but as sometimes happens in politics, the people who care enough to influence the process are not always the people for whom the process is supposed to work. I see decorators as something of a Trojan horse through which Python became more of a language for me (a software developer who copes with, and sometimes even likes, C++) and less of a language for my customers (scientists and engineers). Which is tragic because there are plenty of languages for software developers and not enough languages for people who just need something stupidly simple yet powerful enough for all practical purposes.
Still, despite the erosion of its simplicity, Python stands out for its philosophy of simplicity and its adherence to it. There remains a gulf between a language that sounded a clarion call for simplicity and has slipped a little from its principles and a language that chose the red pill and dove down the rabbit hole basically for the sheer beautiful hell of it.
> There remains a gulf between a language that sounded a clarion call for simplicity and has slipped a little from its principles and a language that chose the red pill and dove down the rabbit hole basically for the sheer beautiful hell of it.
I'm don't understand what the difference between Scheme circa 1975 and R6RS has to do with Python.
It's awfully circular to claim that Python is beautifully Pythonic despite that it's become less Pythonic even as it's adhered to its philosophy of simplicity. If anything, I'd think that a language that "reads like pseudocode!" to the uninitiated wouldn't require even casual programmers to look up syntactic elements in the documentation, the way some people talk about Python.
