Community

[book]

The goal of the chapter is to:

• present the community
• entice the reader to join

The secret handshakes

• « It's "Perl", not "PERL" »
• Secret operators

People

Perl mongers

A bit of history, where to find one close by, why create one.

Conferences and hackathons

A bit of history, trivia, and information on where to find the next conference.
Why not organize one?

White camels

That should probably fit in two paragraphs and a URL. A list of names repeating the web site has no interest in itself.

Community driven efforts

• p5p
• PAUSE
• CPAN Testers

Fun with Perl

-Ofun

Pugs legacy to Perl.
Audrey gave away commit bits before Git and Github made them irrelevant.

Obfuscation

Larry won the IOCCC twice. And then he created Perl.

Golf

A bit of history, introduce the secret operators.

Secret operators

Some history, give the nicknames of the actual Perl operators that have one (all four of them), and present the most significant (and useful) secret operators.

References and further reading

• Andrew Savige's The lighter side of Perl culture

[osfameron]

I still have doubts about obfu/secret operators -- what is the angle you are suggesting for these topics?

The tone of the book, aiui, is showing people about a side of Perl they were unaware of. If I tell my friends in Python community (for example) "Hey, I bet you didn't know Perl was full of crazy line-noise and obfuscation, geeky in-jokes and shibboleths!" they would just reply "Er, that's exactly what Perl is, isn't it?"

[jjl]

Perhaps we can do the halfway? The goatse operator is actually really useful, for example.

[ghost]

On 23 Sep 2013, at 13:24, James Laver notifications@github.com wrote:

Perhaps we can do the halfway? The goatse operator is actually really useful, for example.

It would be useful to document those "secret operators".

Firstly, they show up in real-world code, and forewarned is forearmed.

Secondly, they are a useful hook. They naturally lead into corners of Perl and computer science that the reader may not be familiar with. For example, goatse is a good way to lead on to discussions about context, whereas inchworm-on-a-stick leads into bit-twiddling, two's-complement arithmetic, and so on.

Yes, I know that those of you with CS degrees did this in the first term. Not everybody doing Perl has had the benefit of formal education.

[osfameron]

pndc: those are good points but they relate to a very different book than the one I'm interested in collaborating on, which isn't "Debugging Stunt Perl", or "obsolete bit-twiddling with Perl".

We probably should cover context, but I'd prefer to cover from a perspective of "Using Perl's notion of context makes your code more powerful / readable / etc." than from a starting point of esoterica.

[jjl]

Goatse, i have to agree with. perhaps we can find an example of context making something simpler (hah!)? Inchworm on a stick, perhaps not, even if the operation is useful.

[osfameron]

is this:

sub count { scalar @_ }
my $count = count( $str =~/\d/g };

less readable or powerful than goatse?

[kentfredric]

I'd argue neither are very obvious as to their purpose*

But if I were to see the count invocation, I can at least get some idea of what is happening.

If you're telling me thats what the goatse operator does, then that is grounds alone for using the count form instead, because there is no way I'd have guessed that is what it does.

*( I'm rather tired and my head hurts, so even that $str =~ /\d/g stuff took me a while before I realised it would emit a list )

If I was trying to be obvious, I'd have gone with the more verbose

my $count = scalar grep { $_ =~ /\d/ } split //, $str ;

And even that is something I'm not too keen on because it often does a cache-miss in my brain when I try to remember what scalar does.

[kentfredric]

You can also replace $count here with say or any other function.

Whereas my reading of the goatse operator suggests you need an assignment for it to work, which seems like a bug imo.

$ perl -E 'say =()= "hello56" =~ /\d/g'
# Can't modify say in scalar assignment at -e line 1, at EOF
# Execution of -e aborted due to compilation errors.
$ perl -E 'say $x =()= "hello56" =~ /\d/g'
# 2

[kentfredric]

Also, if you don't like the verbosity of grep, why not

say scalar @{[ $str =~ /\d/g ]}

It may be messy, but its much more obvious whats going on. ( And also doesn't require assignment )

[kentfredric]

pndc: those are good points but they relate to a very different book than the one I'm interested in collaborating on,
which isn't "Debugging Stunt Perl", or "obsolete bit-twiddling with Perl".

I have to agree, I believe this book should be focusing on more on how to write perl code in a maintainable way, not so much how to resolve the wonks from code you're seeing

If secret operators are covered, I'd recommend them being in the sense of read only, write never, because they are by nature not maintainable, and not easy to understand.

[kentfredric]

If you want a case of something where context makes things simpler,

if ( grep { $_ =~ /\d/ } @list ) { 

}

might be a good case. Its an inefficient case, sure, but its effective.

if ( first { $_ =~ /\d/ } @list ) { 

}

Is probably slightly better

[book]

My view of the "community" chapter was that would be the chapter where we would go into anecdotes. After all, if "you don't know Perl" you probably don't know the Perl community either. In this view, the secret operators, golfing and obfuscation show some of the Perl folklore.

It is not my intention to produce something similar to chapter 10 of Advanced Perl Programming, 2nd Ed, where the author spent three pages explaining his obfuscated Boggle solver. I'm more interested in telling some Perl history (Larry discovered @{[]}, I think Randal found out about =()=, Abigail's }{ exploits Perl's tricks when dealing with -n and -p) and showing a lighter side of the community. The Acme::EyeDrops module and its counterpart of using only letters and space (not sure if there's a module for it, but it can be automated in the same way) are probably worth a quote.

This issue's comments seem to focus mostly on the secrets operators, so here are a few arguments in favor of showing some of them. First, they are part folklore, part idiom. Second, several of them are actually useful; this is why people recognized the sequences, and gave them a name. That people keep looking for new ones and try to find names for them is just the sillyness of the Perl community at work. For example, things like =<>=~, ~~<> or 0+!! don't belong to the book.

My short list would be:

• 0+: actually useful, it's also how the numification is named in overload
• @{[]}: also useful, maybe its unnamed sibling ${\ ... } is worth mentioning
• =()=: I found it useful a few times. Goatse also has a safer name: saturn (the planet, but also the son of Uranus)
• ()x!!: ever since I've learnt about it, I'm using this one the most often
• actually, most of the "conditional" secret operators are very useful. They are basically combination of something with !! (another idiom), to produce or not an effect (see the list of screwdriver operators in perlsecret).

I would also be very interested in telling more about the community-driven efforts like CPAN Testers. Are there any others of similar scale inside the Perl community? Outside?

[kentfredric]

Maybe we could , in the community section, cover these things as follows

Much of what Perl gets shit for, ... is ironically, not stuff that is used in production. Most the things people give Perl shit for, are the "coding in line noise" things, and Acme::EyeDrops, under the guise that "Hey, look at this, this is what real Perl looks like!", when in reality, they're just seeing Perl in a selective light, seeing Perl hackers having fun by goofing off with the language.

Though you should give any Perl coder who uses obtuse code like this in production, a 1000 yard stare, and then maybe quietly revoke their SCM access ( You have an SCM right? RIGHT?! )

[kentfredric]

=()=: I found it useful a few times. Goatse also has a safer name: saturn (the planet, but also the son of Uranus)

I am very very joyful at this description.

[osfameron]

BooK, Kent - hurrah, this all sounds perfect, this "angle" works for me and
clarifies for me what this topic contributes to the book. Thanks!
On 24 Sep 2013 03:06, "Kent Fredric" notifications@github.com wrote:

Maybe we could , in the community section, cover these things as follows

Much of what Perl gets shit for, ... is ironically, not stuff that is used
in production. Most the things people give Perl shit for, are the "coding
in line noise" things, and Acme::EyeDrops, under the guise that "Hey,
look at this, this is what real Perl looks like!", when in reality, they're
just seeing Perl in a selective light, seeing Perl hackers having _fun_by goofing off with the language.

Though you should give any Perl coder who uses obtuse code like this in
production, a 1000 yard stare, and then maybe quietly revoke his SCM access
( You have and SCM right? RIGHT?! )

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-24970145
.