Occasionally I browse the London.pm archives to remind myself why I unsubscribed. Quoting Peter Hickman in Re: Better Perl:
Newer languages certainly make a lot more sense to the new comer, consider
versusfor =$*IN -> $guess { ... }for $guess in <IN> { ... }The first is a complete bf, are we honestly saying that we can't come up with something better than that? This is all just adding chrome to a bad design in the hope that the bling will distract people from the design issues.
There are many possible responses. My personal favorite right now is:
What's the point of all of this function calling nonsense? It's just a branch instruction to the processor anyway. It's not clearer where you're going or what's going to happen, you're hiding the details by trying to be clever (and slower), and you'll write clearer code if you don't pretend that you're getitng anything more than a branch instruction.
However, I also considered:
get_free_object()? What's that all about? I've never had any problem withmalloc()andfree(). I don't see the point of hiding the request for more memory behind a totally different interface where people can't immediately identify the lifetime of every allocatable enitity's lifetime explicitly. You're just asking for confusion there.
There's analogy:
Your lack of understanding of chiasm and its effects on narrative structure does not make Pynchon a bad writer nor Gravity's Rainbow any less impressive.
... and finally sarcasm:
Obviously modern human phylogeny recapitulates an ontology where an intuitive understanding that angle braces mean "read a line from a filehandle" and typeglobs sometimes had sigils and sometimes didn't conferred an evolutionary advantage, and that's the way we liked it.
You can generalize this into a principle for discussing programming languages:
If you've never bothered to learn the language, complain about the syntax of a piece of code you find difficult to read, as if learning syntax were the important part of learning a new language.
You get bonus points for pretending that you can evaluate parts of the syntax on their own devoid of the rest of the context of the language. I recommend something like:
Haskell's default invisible partial application is stupid because it's hard to read! There should be cowbells instead!
Invisible syntax is often difficult to read, but I can't think of a better syntax for this feature in Haskell, and pervasive partial application is a Very Good thing. Besides, type inference, purity, and the kind of radical decomposition into small functions that other features of the language encourage makes this much less of a problem than the average ignorant-of-Haskell reader (you know, the kind of person who has no business commenting upon the design of the language) might think upon originally encountering the language.
(I find the use of the word we confusing; I can't find a single message from Peter Hickman either in my three and a half year archive of p6l or Google's archive.)
Re:The Eye of the Beholder
chromatic on 2008-04-04T23:40:29
You might be thinking of PHP, where that knee-jerk "we've put in absolutely milliseconds of design-in-the-small" sentiment has produced such a wonderfully cohesive and consistent gestalt.
Do you know what the
*twigil signifies in Perl 6? Do you know what any twigil signifies? If you don't know what$*INmeans, how can you possibly have any hope of devising an alternate syntax? (Or does your example assume an implicit macro predeclaring a bareword?)Re:The Eye of the Beholder
pdcawley on 2008-04-05T09:57:54
Dear ghod, it's only bloody syntax.
Re:DL$MT%DF@#(hhh
chromatic on 2008-04-05T04:30:33
For what it's worth...I can imagine you'd find it frustrating if people so casually dismissed your work with superficial complaints, especially if their complaints demonstrate little attempt to understand what you're trying to do. Maybe I'm extra sensitive this month from dealing with an underdocumented SOA project with heaps of code generation, WSDL, and EJBs.
Unary prefix
=always iterates over an iterator. The*twigil always indicates a global variable.$*INrepresents standard input. Now that you know enough to read that syntax in individual chunks, is it still line noise?I don't remember when STDIN became
$*IN, but that was a while ago. The others have been in the Synopses for ages; they're pervasive consistencies throughout the language.It took me less than a minute to verify each piece of syntax, starting by typing dev.perl.org into the address bar, clicking a couple of links, and searching in the text of the relevant Synopses, and this is what I don't understand.
Isn't it even faster to look up the documentation for a piece of syntax and read it than compose several snarky messages over several days on a mailing list? There've been dozens of articles about Perl 6 syntax over even the past two years.
I'm sympathetic to the idea that some pieces of syntax have changed, but grabbing a piece of code directly from a Synopsis and complaining that you can't immediately and intuitively grasp every fine point of its meaning is awfully silly. Is that really how most programmers learn to code? Guesswork?
Every character in that example is there for a reason. None of them are random punctuation strewn about. Every character and logical chunk of code there has a meaning, and I believe they're consistent throughout all of Perl 6 and, to people who've used the language or are at least familiar with the consistencies, they make code easier to skim and to understand, like any other form of abstraction.
No one has to agree with me about any of those decisions. There have been several discussions on p6l (and in person) about particular choices of syntax. The syntax has changed in several cases, but there's always careful reasoning behind it in accordance with the design principles of Perl 6. Careful consistency is one of those principles. Immediate, pervasive clarity to Perl 6 novices is not.
Maybe someone else needs to wave the flag of "Don't expect to grok every piece of Perl 6 example code until you start learning the language." If someone did that, I could write instead about the Parrot bugs I fix and the features I add; would that be more interesting to you? (This is a serious question by the way.)
Re:DL$MT%DF@#(hhh
joejoe on 2008-04-05T04:54:17
I can certainly decipher that bit of code with the help of the docs/web (and did), but I really don't want to decipher it everytime I revisit that line. It's not about being a "novice": I expect to have to learn the language, but I'm not going to be able to "learn" punctuation. Maybe that's a limit for me only... I don't know. I know perl 5 pretty well, but I still can't reliably remember whether it's ~= or =~ for regular expressions, and $_ and the $ vars are the only perlvars I have memorized (though $/ pops up in my brain from time to time for some reason).
In answer to the last question, yes. And I do apologize for popping off like that.
Re:DL$MT%DF@#(hhh
chromatic on 2008-04-05T05:01:15
Perl 6 relies on sigils and operators, but our hope is that by gathering and grouping variables such as
$*INand%*ENV(I bet you can guess what that one is) and turning other Perl 5 magic globals into object properties, the conceptual weight of the system is much less. Hopefully at least they'll be easier to look up this way.Unfortunately, some people have trouble reading symbols. I have trouble reading code without judicious vertical whitespace to separate paragraphs, so Python can be a chore. (Is this empty line the end of an block or just a paragraph within the block?)
Thanks for the advice, though. I'll try more practical posts and lay off the theory and advocacy for a while.
Re:DL$MT%DF@#(hhh
duff on 2008-04-05T07:27:05
I think I can see where joejoe is coming from. Perl is often compared to the english language and his is a good example of punctuation-blindness that writers of english seem to have. Witness the use of "im" instead of "I'm" and run-on sentences and that no one knows where to use a comma or a semicolon in their sentences. Et cetera. Perl suffers this malady more because it relies more on punctuation than english does.
So maybe it's the modern (mis)use of the english language that has conditioned people to be punctuation blind.
(Yes, "blindness" might be overstating things a little, but why does he not have trouble composing sentences or spelling words, yet can't remember=~versus~=?)Re:DL$MT%DF@#(hhh
chromatic on 2008-04-05T08:26:18
I have difficulty reading mathematic formulas. The variables keep getting jumbled. If I spent more time with a few formulas, I'd eventually memorize them. Some people are better at words than symbols, and, as programmers, they might find languages with fewer symbols easier to read. That might be the case for joejoe.
Of course, English punctuation is mostly hints anyway. Just like you can represent Koine Greek without aspiration notation, you can represent written or spoken English without punctuation and get the message across. (I find Koine much easier without breath marks, ironically.) Unless you're reading David Foster Wallace or ee cummings, you don't have to analyze the use of punctuation when reading English texts.
I suspect that novice Perl programmers often see the punctuation characters as arbitrary noise at best and deliberate obfuscation at worst. This amuses me sometimes. Native English speakers seem to use pronouns (at least the singular gender-neutral pronoun) effectively, but plenty of people swear that they can't keep track of
$_in Perl. Some of them have even started to learn the language. There's that mental model again. (If you can use the word it without derailing the conversation, you can use$_.)It's possible (especially in Perl) to write plenty of useful programs without ever really learning the language or its linguistic underpinnings. This is why you see people using multiple variant or semantically useless idioms in the same program -- indirect and direct constructor invocations on adjacent lines, assignment of explicit empty lists to aggregate declarations, the use of parentheses around single lexical declarations; they've copied and pasted and program by accident.
The syntactic cues that experienced and mature Perl programmers have learned are obvious to us, but everything is magic to someone who really doesn't know how things work. Think of a single-element array slice, for example. That probably sticks out to you, as well it should.
Strangely, people complain less often that my prose is difficult to read than they do my code.
Re:DL$MT%DF@#(hhh
joejoe on 2008-04-05T18:22:52
What I obviously meant by not being able to learn punctuation is not being able to learn strings of punctuation as syntax. I am actually quite a stickler for proper use of commas and apostrophes (and I despise chat-speak abbreviations), and I don't believe my English usage is a problem in relation to my coding. Besides, one learns the rules of a natural language over years, but I typically need to learn a computer language over days or weeks (not master it, mind you, but at least read it).
I have been using perl since the mid-nineties, and have written some pretty massive programs. Yes, I could memorize what $& and $` meant for the duration, but, like numbers, strings of punctuation aren't memorable, and I'd need to look it up later again when viewing the code. Making longer strings of punctuation is not going to help matters.
Again, perhaps I am in the minority in this. Maybe most people will easily read =$a versus =$*a versus =$^a versus =$.a versus =$:a versus =$+a etc, with or without unary equals.
Perhaps chromatic is right: maybe it'll all become crystal clear and obvious after I become familiar with the rules... AKA memorize that '*', when it follows $, @, %, &,::, or @@, always means "global" (I think, assuming the last two make sense). Ditto for . ^ : + ? = <> and !. (Actually, I'm not sure if that last sentence wouldn't parse without error.) Not to mention all the 2, 3, and 4 character operators.
Maybe I'll be able to learn the rules after a fashion and breeze through a reading of somebody's perl 6 code (or even my own) without a permanent printouts of the synopses wallpapered around my monitor, or possibly I'll just move on to C# on mono.
Re:Pointy blocks seem to bring The Fear
chromatic on 2008-04-05T16:30:59
I'm as skeptical as anyone about new things, but when I looked back on the first non-trivial Perl 6 code I wrote and realized exactly how much code I didn't have to write and how clear it was, I was sold. I don't know how to spread that epiphany other than telling people to get over their initial fears and revulsions and write some code for themselves.
It's a mixed hash - er bag
Ron Savage on 2008-04-06T00:30:44
I'm glad people are speaking up about their likes and dislikes re this new syntax.
After getting a degree in special relativity and waves on the surfaces of stars I can claim to have battled thru many a weird equation, but I don't see Perl syntax as falling into that category.
I'm all in favour of Perl core writers changing the internals of the language in any way they see fit, but I just would have liked a few constructs to be internal-only changes...Re:It's a mixed hash - er bag
chromatic on 2008-04-06T00:52:42
Despite how unsympathetic I sound, I really am sympathetic. (Of course, once you have to assert that explicitly, you've already lost.) I'm not entirely looking forward to rewriting all of the code I depend on. Where I've done that already, I'm pleased with the results though.
I really do believe that the syntax changes make sense in the context of the language as a whole. It's the little things that never really bothered me enough in Perl 5 for me to notice consciously; they're just not there with Perl 6, and the absence of those little niggles is actually very pleasant. It's a very pragmatic consistency, and I don't know how to explain it any better.
