I don't know why you got downvoted so hard, I think you have a fair opinion (even though I disagree with it).
IMHO, the absolute best programmers I've ever worked with looked at programming as a game, as something clever to do. They reveled in the beauty of elegant code, and they got angry when reading bad code, and laughed heartily at particularly clever code etc.
To them, they had internalized the language of the machine and were trying to create art with their code, not science.
One thing that I've never been unsure of is that L. Wall understands that machines can be approached 2 ways, either as a raw tool, issuing instructions to be completed precisely as directed. Or the other approach, which is to think of the machine as a being (albeit one with a particularly different kind of mind) and the language is a lingua franca that you can use to communicate with it. Perl false squarely on the side of a programming language being a language (in the communication sense) vs. being a language (in the "set of instructions" sense).
The reason Perl 1 liners are so interesting, for example, is that they convey implicit little secrets between you and the machine, much like you might do with a certain kind of nod to a friend at a party when a certain topic comes up that conveys a world of meaning between you and your friend.
The reason these little "operators" are so witty is that they convey lots of meaning between you and the machine relatively simply, and look clever at the same time.
I think most programmers at one time or another realize that though, in theory, computers are supposed to do exactly what you've told them to do, the ecosystem their software is running in is just on the edge of nondeterminism and wish for a way to convey to the computer what they "mean" for it to do rather than what they tell it to do. "Machine, I wish for you to open this file and count the number of times the words foo and bar show up in it". Perl is targeted at these kinds of cases.
That's now to say that other languages are bad, just different. Perl also has the unnerving ability to so quickly become obfuscated that it can be very hard to untangle by another developer. Languages like Python aim for code simplicity and readability and thus are much more suitable to large scale development practices than Perl is (that's not to say that Perl isn't used in these kinds of large projects, or that Python isn't used for one off scripts).
IMHO, the absolute best programmers I've ever worked with looked at programming as a game, as something clever to do. They reveled in the beauty of elegant code, and they got angry when reading bad code, and laughed heartily at particularly clever code etc.
To them, they had internalized the language of the machine and were trying to create art with their code, not science.
One thing that I've never been unsure of is that L. Wall understands that machines can be approached 2 ways, either as a raw tool, issuing instructions to be completed precisely as directed. Or the other approach, which is to think of the machine as a being (albeit one with a particularly different kind of mind) and the language is a lingua franca that you can use to communicate with it. Perl false squarely on the side of a programming language being a language (in the communication sense) vs. being a language (in the "set of instructions" sense).
The reason Perl 1 liners are so interesting, for example, is that they convey implicit little secrets between you and the machine, much like you might do with a certain kind of nod to a friend at a party when a certain topic comes up that conveys a world of meaning between you and your friend.
The reason these little "operators" are so witty is that they convey lots of meaning between you and the machine relatively simply, and look clever at the same time.
I think most programmers at one time or another realize that though, in theory, computers are supposed to do exactly what you've told them to do, the ecosystem their software is running in is just on the edge of nondeterminism and wish for a way to convey to the computer what they "mean" for it to do rather than what they tell it to do. "Machine, I wish for you to open this file and count the number of times the words foo and bar show up in it". Perl is targeted at these kinds of cases.
That's now to say that other languages are bad, just different. Perl also has the unnerving ability to so quickly become obfuscated that it can be very hard to untangle by another developer. Languages like Python aim for code simplicity and readability and thus are much more suitable to large scale development practices than Perl is (that's not to say that Perl isn't used in these kinds of large projects, or that Python isn't used for one off scripts).