YAPC Reflections (2013)

Well, I’ve just gotten back from my second YAPC, and I thought I’d take a moment to share a few reflections.

First, general thoughts: I had an excellent time.  I knew far more people than I had the first time, which is partially just having met a bunch of folks in 2011, and partially because more of my current and former coworkers were in attendance.  Plus I met a whole lot of new people, so now I’ll know even more folks next time.  This is nice for me, as I’m one of those weird half-introvert-half-extrovert people.  I’m not much for walking up to people I’ve never met before and starting a conversation.  On the other hand, if I already know you, you can’t get me to shut up.  So, the more people I know, the more people I’m likely to meet.

I also spoke for the first time (the first time at YAPC, I mean).  This encouraged a lot of people to come up to me and just start chatting, which is nice, as it removes the burden of conversation initiation from me and I’m forced to just go with the flow or seem like a jerk, which I’m not.  (Well, not most of the time.  To people I just met, anyway.  People who know me well: just shut up.) So, overall, socially this was a good conference for me.

Also one of my former (and future) coworkers was actually from Austin, and he pointed us to all the best places to eat.  So the meals were awesome.  I brought my son along (he doesn’t program, but it was a chance for him to see Austin and have some father-son bonding time), and he was entertaining at meals and other gatherings.  The Bad Movie BOF, by the way, was insanely awesome.  Seriously: my cheeks were aching that night from all the laughing.  I can’t understand why more people don’t come to these.

The venue was pretty nice.  A/C was cranking, which is good because Austin is now officially the hottest place I have ever been to.  I used to spend a week or so every single year in Florida, I’ve visited New Orleans three or four times, and I live in Southern California, but nothing compares to Austin.  It’s the first place I’ve voluntarily put my shoes on to walk around in parking lots since I was a teenager.  I thought I could go barefoot anywhere, but the Austin blacktop defeated me.  And this was June.  What it must be like in August ... I can’t imagine.

But I digress.  The venue.  The talks were set up well, the auditorium in particular was nice, and the technology worked flawlessly as far as I was aware.  If I had to make a couple of nitpicks, I would have wished for more plugs in the auditorium—the room must have held over a hundred of us, all fighting over the three or four outlets—and possibly for a shorter walk between the buildings.  Due to the heat more than anything else.  But it reminded me of college days, trying to haul ass to the next class without being late.  Except I’m older and fatter now.  Like, a lot older and fatter.

One specific thought: I had an interesting time analyzing and comparing three of the different talks that I saw.  The talks were: Perl—The Detroit of Scripting Languages by Stevan Little, Perl 5: Postcards from the Edge by Ricardo Signes, and Velociraptor of Christmas Future by Matt Trout.  Now, in many ways these talks were in agreement.  Most especially about the future of Perl 5 being in the many experiments and offshoots of the language (such as Moe, perlito, p2, and so forth).  All these gentlemen essentially agreed that the best way forward for Perl was to have these experimental projects break backwards compatibility so that Perl 5 didn’t have to.  Then, whatever parts were successful despite the fact that they weren’t backwards compatible could be stolen for mainline Perl with the justification that it had been tested and proven in the wild.

This is all good, and I tend to agree this that this is a pretty decent way of moving forward.  Where the interesting part comes in, though, is in how the different talks approached the topic of backwards compatibility (or “backcompat” for short, as I believe all of them put it).  Now, backcompat is a tricky area in the best of times, and many would argue that, as far as Perl’s popularity as a programming language goes, these are hardly the best of times.  Perl is an older language, and it’s now in the very difficult position of needing to attract new blood without pissing off any of its existing userbase.  Much like a band that’s just past the peak of its success, if it keeps playing the same old stuff, its fans will inevitably just die off, but if it radically reinvents itself, it puts the existing revenue stream from the diehard fans at risk.  It’s quite a dilemma, and I think it would be interesting to have a discussion about the best way to go about this.

But, somewhat oddly (at least in my opinion), it seems we can’t come to any agreement on where we currently stand with backcompat right now.  And I don’t believe we can have a meaningful discussion about where we’re going if we don’t know where we are.  Stevan Little said that backcompat was a serious issue that was holding us back from innovating.  Ricardo Signes said that backcompat was no problem at all and everyone should feel free to patch away.  Matt Trout said that backcompat was definitely restraining us, but that that’s a good thing, because it ensures that we can continue to just get things done in Perl.  I’m exaggerating just a bit here to make my point (all three speakers were actually more nuanced in their pronouncements than that—yes, even Matt!), but not very much, I don’t think.  I believe the talks will be available in video form sooner or later, so please do watch them yourselves and draw your own conclusions.  But my point is that I’m not trying to distort anything these guys said, or at least not intentionally.

Now, if you think about it, these three radically different positions—the issue exists and it’s good, the issue exists and it’s bad, and the issue doesn’t exist at all—basically represent the entire spectrum of possible opinions on backcompat by covering all three possible extremes.  (Can I refer to a continuum with three endpoints as a spectrum?  Feel free to suggest a better word.) I told Ricardo after his talk that his view seemed diametrically opposed to Stevan’s, but that was before I heard Matt’s.  Perhaps they’re triametrically opposed?  Whatever you want to call it, it sure does seem like these three don’t agree at all.

But here’s the weird thing: while I don’t know these three guys very well, I have interacted with two of them online, and have had a couple of long discussions over multiple beers with the other (and, if you’ve met them, you’ll probably know which is which from that description), and I have thus far found them all to be very reasonable, intelligent, and amiable fellows.  I even gathered, from various conversations, that they get along well with each other.  I bet that if we were to put all three of them of them in a room together and tell them to work it out, they would just stare at us blankly and say they were all in basic agreement, and there was nothing to work out.  So why did their three talks all sound so contradictory?

I wish I could follow this exploration with a brilliant conclusion that clears up the whole mess, but, after long pondering, I still don’t know the answer myself.  First of all, it’s possible that it’s just me, and no one else heard any conflicts at all.  Certainly Ricardo seemed confused when I asked him why he’d said the exact opposite of what Stevan had said.  But I don’t think that’s it.  I think there’s probably just a difference in the way each of the three approached the question that caused them to end up in different places.  I suspect that they’re all three wrong ... and that they’re all three right (which fits my theory of balance and paradox).  I’m not sure how to tease out the truth from among the three perspectives ... I’m not sure there even is a “truth” there.  Like an optical illusion, it’s probalby all in how you look at it.  Still, I think having a comprehensive theory on where we stand on the issue of backcompat—sort of a backcompat unified theory, if you will—is important for us to be able to move forward.

But, hey: I could be wrong there too.

Final addendum: The first night I spent in my own bed after returning from Austin, I dreamed about Perl.  I rarely do this, but obviously the conference had seeped into my brain.  In the dream, I had to write a module which not only loaded itself secretly, but also foiled attempts to load the actual module it was supposed to be imitating.  (Yeah, I know that doesn’t necessarily make a lot of sense.  Dude: it was a dream.) Considering the dream involved writing a Pegex parser and an @INC hook, I feel fairly confident I even know exactly which talks are to blame.

Looking forward to next year!

My reflections on my first YAPC are available on my Other Blog.

Perl 5 Porters Weekly: June 3-9, 2013

Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the perl5-porters email list.

Topics this week include:

  • DAVEM TPF Grant May 2013 report
  • dtrace sub-entry probe against lexical sub segfaults
  • COW and THINKFIRST and related safety

I love pre-modern Perl and so should you, my introduction

My name is David Shultz, I've been working with Perl since the late 1990's where I live in wonderful Portland, Oregon. I'm self taught, I code because I love the challenges and excitement it provides. I got my first job as a programmer working for a small porn company, then a small spam company, financial analysis firm, and finally my current employer of over 11 years, a medium sized data warehousing company. For the last 6 or more years I've worked as a project manager/lead programmer with a small team of really great people. I've worked with a few prominent people in the Perl community, and a few more have graced my employers doors over the years. I've had an amazing time over my years with Perl but not all has been rosy.

A few things have happened over the years both with Perl as a language and with the community itself that has kept me fairly quiet, not anymore. I'm not here to bash anyone or any idea specifically, rather I am here to promote a simpler way. You see I don't love "modern Perl", in fact I kind of hate it. I've been working with Perl long enough to see fads come and go both inside and outside my work.

I will never forget the day I saw my first mixin class added to our shared corporate code base. At first I thought it was an interesting idea, then I found out the greatest feature of a mixin was to hide functions from me, this amazing power was only amplified when combined with multiple layers of inheritance. My current code base is well over 3 million lines of code, mixins haunted my dreams until I banned them from my project roughly six years ago.

Then Moose came along and with it mixins in the form of roles. I've been using a 1.x version of Class::MethodMaker for many, many years but Moose kept creeping up in conversations both online and off with increasing frequency and appreciation. Due to my experience with mixins in the past I decided to take the wait and see approach. Other groups at my company began adding Moose to their projects and it wasn't long before Moose found it's way into our shared corporate code base. This code base is the core of every project at the company, every project but mine. I had severed ties with this shared code base many years previously due to constant incompatible changes being applied from other projects.

I've watched as Moose increased the hardware requirements, the load times of child processes and the verbosity of basic class definitions, I believe I chose wisely to stay away. Then came Mouse, Moo and Any::Moose. I'm not sure the community has really decided what it wants, but I know what I want, Class::MethodMaker version 1.12 from Sept. 12th, 2003. Thank you Martyn J. Pearce for such a simple and functional bit of code, I use it daily, it's worth it's weight in gold as far as I'm concerned.

P5P has done some amazing work over the years, that being said I'd love to see switch/given/when/etc get solidified so I can start using it. Also Perl 6, can't really say anything that many of you don't already know.

I love Perl, more specifically I love Perl 5. I have not been loud, I have not spoken up in public about Perl, even at work I have generally stayed quiet. But no more, beginning with my next post I will write monthly about a topic of interest to myself, likely related to my work using core Perl 5. I'll do my best to provide code samples, explain my thinking, and hopefully provide some examples of earlier work that failed and why. I strongly believe in test driven code, a detailed naming scheme and small concise functions.

All the new features, ideas, modules, etc. are great fun for the community, but it is my opinion that for each of us to increase our skill set and productivity, we must increase our understanding and use of the core language. I do use work from the community. I love the CPAN, but my posts won't be about the latest cool module and how it will change your code. So if you're interested in clean basic code used to solve real business problems with a strong emphasis on data warehousing then I hope you'll stick around.

Wing

Wing:

Woot. Just got my first non-Plain Black employee patch for Wing.

[From my blog.]

Extended Exuberant Ctags rules for Perl?

Some time ago I made a tiny github repo to share my .ctags file that I use for better Perl support . I use it for my Mojolicious projects, yet it should be good enough for any Modern Perl project.

I would be happy if we can improve it!

Please feel invited!

META.yml is not my friend today

I want my github repo to show up in a module's META.yml file. And given that META.yml is generated by ExtUtils::MakeMaker, I put some META_MERGE stuff in my Makefile.PL, having carefully checked the documentation in CPAN::Meta::Spec to see what we're supposed to do this week (META.yml's structure has always been a bit of a moveable feast). And, of course, it doesn't work. Grrr.

Can someone tell me who fucked up what?

https://metacpan.org/source/DCANTRELL/CPAN-ParseDistribution-1.51/Makefile.PL

Counting the number of statements in a Perl codebase

I'm looking for ways to count the number of statements (or lines) in a Perl codebase. Any tools out there that do it?

JT's New Blog

A lot of people have asked me over the years if I had a blog or twitter feed that they could follow, and I've always answered with the blog or twitter feed of the various ventures I'm involved with. I've decided that it's high time for me to release my own blog and twitter feed for the things that aren't appropriate to any of those ventures. 

If you're interested, you can subscribe to my new blog or my new twitter feed now.

I'll still be posting relevant Perl-related articles to blogs.perl.org, but I've decided to create a new primary blog, because I often want to blog about non-Perl topics such as creating startups and designing games. So if you want to follow more than just my Perl activities, please subscribe to my new blog or twitter feed.

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.