Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday April 04, 2008
05:27 PM

That Old "Intuitive to the Ignorant" Canard

[ #36061 ]

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

for =$*IN -> $guess { ... } versus 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 with malloc() and free(). 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.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Re: for =$*IN -> $guess { ... } versus for $guess in { ... }.
    IMHO the first form is fucking ridiculous.
    • 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 $*IN means, how can you possibly have any hope of devising an alternate syntax? (Or does your example assume an implicit macro predeclaring a bareword?)

    • Dear ghod, it's only bloody syntax.
  • Wow, you really taught that guy I've never heard of a lesson!

    You know, I keep getting your articles through planet parrot in my RSS reader, and waaay too many of them are you doing this kind of petty bitching about what "some guy" said. I wouldn't care what you say either, but these things are being pumped out through planet parrot (and planet perl), which annoys me greatly.

    For what it's worth:
    for =$*IN -> $guess { ... }
    is a trainwreck. It's the =$* that gets me. I like the ->. I'm OK with the non
    • 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. $*IN represents standard input. Now that

      • 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 $/
        • Perl 6 relies on sigils and operators, but our hope is that by gathering and grouping variables such as $*IN and %*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 th

          • 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
            • 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

            • 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 usin
  • I'm at Scotland on Rails at the moment, and one of the talks yesterday was on changes in Rails 1.9. Rails 1.9 has pretty much lifted pointy blocks from Perl 6 and the muttering that was heard (including from the presenter) about this was astonishing. "Why does the arrow have to be in front of the parameters?" "Eww... why can't we get the new parameter declarations inside the block like the old form?"

    Why? Because Parsing is Hard. The new block form buys both Perl 6 and Ruby 1.9 massive benefits because the p
    • 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.

      • 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...
        • 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