Which would be the same Steve Yegge who also said:
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'
So if his essay on the state of the art in Perl5 years ago scared you off, presumably the fact he's now noticed that we're (a) moving forwards (b) a happy, pragmatic and effective community will make you go look at it now?
There's even a new www.perl.org recently released (next big project - improving learn. ...)
That's a real pity. I like Steve, but his essay demonstrates a severe lack of understanding of at least two fundamental features of Perl, namely context and lists.
That's OK though. What I really love about the Internet is that Perl sucks because it has pointers, but Haskell sucks because it doesn't. It's almost like people throw around the word "sucks" without actually understanding the concepts that they are discussing.
If you have evidence that it's lack of understanding, rather than lack of liking (coupled with a snarky, hyperbolic style), perhaps you'd care to present it?
Where did Yegge claim that parentheses create rvalue lists?
Other commenters here seem to think you're referring to his complaint about (1,2,3,(4,5)) equalling (1,2,3,4,5), but I don't see how that complaint has anything to do with whether parens create lists. Rather, he's complaining that the comma operator is append instead of cons, kinda.
Note also that here he's talking about a bad decision made "very early on", back when Perl had no references; at that point the only way to make anything like nested lists was by giving names to all the sublists and using typeglobs or explicit calls to eval. That's a semantic point and has nothing to do with the syntactic role of parentheses in the grammar. Yes, nowadays you write [1,2,3,[4,5]] instead and make references everywhere, and that's better, but it's still not very nice because Perl references are ugly, and what Yegge's doing here is explaining how Perl came to need something so ugly.
But that's exactly what he's complaining about: it simply doesn't make sense that you have to use parentheses, or crazy q// construct to create a list. At the same time they don't really "create a list", because it's flattened again. It requires remembering rules again, just like with the contexts. It just doesn't "make sense".
It does if you bother to learn the language, rather than assuming that it's a pastiche of whatever features you bothered to osmose from a smörgåsbord of whichever other languages you might have encountered.
> It just doesn't "make sense".
The notion that a programming language both can and should be completely intuitive to novices who don't have to bother to learn an arbitrary list of syntax rules is absurd on its face.
Parentheses never create first-class lists in Perl. They only ever group expressions and disambiguate precedence.
Parentheses sometimes create first-class lists in Python and Ruby, for example. They also sometimes group expressions and disambiguate precedence. If you want an arbitrary set of rules to memorize, look at the languages which conflate various and orthogonal uses of the same punctuation character.
"Parentheses sometimes create first-class lists in Python"
No, they never do. (don't know about ruby) Square brackets are for that. No problems with syntax this way.
"They also sometimes group expressions and disambiguate precedence"
But it's obvious: "expr ( [expr ,]* expr)" is a call - always. "(expr)" is for precedence. "([expr,]+)" is a tuple. Same as in 99% (made up number) of languages you encounter.
OTOH, in Perl, you've got the same expression that creates a list in one case, but not in the other, which is simply confusing. To be honest, I don't know of any other language that does it. You can call my expectations to be appropriate for a pastiche of whatever other language - yes - all the other languages I know / heard of, work the way I expected... and don't force me to learn rules that work based on context. Similarity between languages is a "good thing".
If you like that syntax, good for you. But I fully understand people who'd rather not be surprised this way. To me it doesn't make sense to be that different. I think Steve Yegge knew exactly what () do when he was writing his blog - he was simply complaining about that unexpected behaviour.
Your "obvious" rules are as arbitrary as those of any other language.
What is the difference between a tuple and a list that's "obvious" to a novice programmer? (Yes, you may claim that I change my argument to talk about lists versus tuples, but if you want to press on this line of thinking, Python's syntax for list and list-of-list declaration is the same as Perl's syntax for anonymous array declaration.)
Which parts of the requirement for a trailing comma after the first element of a single-element tuple are "obvious" to a novice programmer?
Which of those "obvious" rules are obvious cognates with other programming languages?
(What's "obvious" about Smalltalk having a strict left-to-right evaluation order, ignoring "obvious" mathematical precedence rules which schoolchildren learn?)
> ... in Perl, you've got the same expression that creates a list in one case, but not in the other...
This is still not true. The comma operator creates lists in Perl.
