> What else is good about Perl, which is 1) not in Python/Ruby/JavaScript or 2) overly terse/clever? (Honest question)
Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense.
Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.
OK thanks for the answer. I agree that this context sensitivity is probably the most Perl-ish part of Perl. I just read over the Camel book section on this, and it says:
"This is the most important section in this chapter. In fact it's the most important section in the entire book."
"Not only that, but you can't make any general rules to apply what you know about some expressions to others. Each expression can make up its own rules. ... Perl is very much a language that tries to do the most common, mostly right thing for you."
"In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do".
Those quotes don't inspire confidence in me -- it sounds like a battalion of mostly correct special cases... mostly correct meaning "sometimes wrong". However, I do appreciate that the linguistic part of your brain is very large and powerful, and once you internalize all these rules they can lead to a beautiful expressivity. Larry is making use of a different part of your brain than other languages do.
But I have to work with 5 languages regularly, and I see this polyglot trend only increasing in the future. So I appreciate when languages are a little more predictable, and a few months away from them won't diminish my fluency.
"Not only that, but you can't make any general rules to apply what you know about some expressions to others."
has been greatly improved in Perl 6 over Perl 5. That is, the very rules of the parser feel more concrete and the degree of composability between interlocking syntactical constructs has far fewer rough edges. The explanations for the edge cases, when you do come across them, tend to feel more "justifiable" to me as well, in the sense that Perl 5 justifications can and will often be implementation oriented where Perl 6 justifications will tend to come from the language design itself. (Where implementation demands in excuse in Perl 6, it tends to be of the NYI variety).
So the fear of 'mostly correct' is not an issue in Perl 6, in my experience. FWIW, I've also written a lot of Perl 5 code at this point and I've found 'mostly correct' to be absolutely fine in practice, if a bit of a WTF in a few cases going on (edit: going in).
"Each expression can make up its own rules."
While at the same time as becoming more predictable in the manner I describe above, Perl 6 also pushes this to the absolute limit by making it LITERALLY true. For Perl 5, this sentence is pretty true in spirit, if a little bit of a fib practically. The language just didn't have the design that would allow it to, say, produce a real AST. Things like source filters were attempted early on in the language cycle and were already considered harmful by the time I started Perl in 1998.
In Perl 6, every expression can easily make up its own rules, but you don't do it in some oddball one-liner. Instead you have an operator (that is, "a subroutine with a funny name") defined somewhere in scope using the same definition mechanism as every native operator in the language. You get absolute guarantees for behavior on your own operators -- anything core can do, you can do. And it's (edit: core is) always there as a reference to guide you while writing your own operators.
But then again, maybe you actually just don't define that many custom operators. The syntax is terse and expressive enough that I don't find myself doing it very often.
I think in the long run, Perl 6 has everything you need -- and if you don't like the way it looks, it has everything you need to change that, too. And your code wouldn't be transpiled as we do in JavaScript today. It would instead be parsed by the same grammar engine that parses Perl 6 itself.
> In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do.
Haha, this reminds me of Ruby's Matz:
> The principle of least surprise means principle of least my surprise.
The key insight here is that without unusual levels of care, the principle of least surprise always is about what would surprise the author least, and this can be subjective.
I find hard to think of a single positive thing of contexts in Perl. For me, this is one of the worst aspects of the language (along with references) because is really confusing and it doesn't provide any benefit at all, i.e. there is nothing that you can do with contexts that you can't do in a better way without them.
Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense.
Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.