My YAPC::NA 2012 Madison

I was very surprised how beautiful an american city can be. I was prepared. An independent analysis put Madison at position 3 for best place for all american young adults to live in.

"Average paychecks for young adults aren't anything to brag about, but Madison does pride itself on other unparalleled pros: steady job growth, a perennially low unemployment rate and a huge population of twentysomethings. The Wisconsin capital has added more than 24,500 jobs since 2000, and state officials recently announced plans to add 25,000 more bioscience jobs in the next five years. Madison is also known for its quirky, progressive and hyper-literate urban culture. Satirical stalwart The Onion got its start here in 1988, and the University of Wisconsin, a host of music venues and one of the country's largest farmers' markets call Madison home."

I saw a lot of negative comments about republican governor Walker vs the unions and the sad state of their budget, and I wonder why. He was the first governor ever who won a recall election according to Wikipedia. A big slap into the democrats and unions face.

It was for sure the nicest YAPC I ever visited.

Then Madison made headlines for breaking the US record of attendents. YAPC Sold Out was the amazing headline, though Madison is a hop-2 city, the next big airport being Chicago. YAPC Madison attracted more people than New York, Houston or San Francisco, even if trip costs were much higher. It's not at the YAPC Asia level, but compare the inhabitants numbers first. From my overview over the talks and job posts it could be a real renaissance of Perl, or it could be the programming targetting newbies. There were many many YAPC first timers. My company cPanel came with 38 people alone, most of them were their first time at a YAPC and they loved it. Even if most us were surprised about the low level in the technical aspects of the given talks, many said why we are not we giving any talk, we know much better. The separation into two separate buildings was a bit unfortunate, but everybody was happy with the organization. You cannot have everything. And americans are so much better public talkers than europeans or asians. All naturals or so it seems.

I was pretty sick over the whole week, and could not sleep well. I could not look to the right most of the week because of the unhealthy soft american beds and pillows. I attended almost no talks at all, just 5 or so, and mainly did the hallway session. mst++. Meaning sitting around and talking. But this is the real meaning for such a conference. We fight endless fights on mailing lists on technical issues and programmers are normally not easy to talk to. Decisions made on our mailing lists are usually technically bad decisions. But such a process must be public. So we have to meet up from time to time in person to get personality issues cleared out, and be able to understand someone better and revisit technical opinions and see the big picture. I was surprised how many people agreed with my opinions though online it looked completely different. This encouragement lets me continue my work, though I still think its worthless to write any bigger patches still in the current climate.

Madison was also a good opportunity to hire some good people. I spoke to several candidates and I think we have interesting projects to work on and a super management, but rarely someone wants to relocate to Houston. Which is interesting, because cPanel moved from the east coast to Houston because of the better job market here. We have almost no native Texans, everybody relocated and likes it here.

Rik seems to be a much better and realistic manager then Jesse. He has humor. I like this guy. Jesse never dared to talk to me in person, Rik did. Rik wants to avoid big failures, Jesse wanted to bring new exciting features forward. And I even did talk to Schwern, even after I called his policies aggressive publicly. I hope we came to an agreement over EUMM backcompat. 5.6 will be gone in fall to be able to support easier abstraction and clearer code to maintain. Karl Williamson discussed with me my concerns about "unicode bloat" with folding tables and what he did already and what he is planning to do. We completely agreed on everything. Now I only have to redo the same optimizations in the compiler if possible, and maybe I have time to write the xs parts. And reinvent icu.

I had great talks with Josh Ben Jore, Scott Walters, Stevan Little, Liz and more folks about future optimizations. It's such a relief to hear that progress seems to be appreciated by others. Even if I probably drop typed SV's for the beginning, and start with typed arrays and hashes as they really optimizable. And really easy. Typed SV's will not be faster and smaller for uncompiled code, but it might help optimizing method and function calls, besides the obvious integer loop counters. Compile-time lexical or read-only @ISA and stashes are the most important concepts for optimizing the mop. Immutability. And it probably should be changed to be the new default. 80% need immutable classes, 20% mutable, dynamically at run-time changed classes. So I heard. Unfortunately we still have a blocker in optimizing ints at compile-time, constant folding was butchered long time ago. I wonder if this can be resolved at all in the current state of affairs. The butchering was against consensus then, so p5p had rough times then also.

I had great discussions about perl6 and parrot testing and the release process. It's getting into shape slowly. Still a lot to do though.

I had no hallway session about AddressSanitizer and I kept mostly silent about my 5.16 security concerns. Everybody seems to know better. Chip seems to be turned against me now. I did not see him. I'm sure he misunderstood something.

The most talked about topic was interestingly JSON::XS. Different people had different problems with it, and everybody wants to have a properly maintained fork, and nobody dares to do so. For various reasons. If it's the refusal to take simple extensions, to force common::sense upon us or to use a public bug tracker. Nobody knows what kind of bugs are lurking, because there's no public tracker. github or google have pretty decent trackers. Technically I looked at the XS code and really wonder why Lehmann must reinvent utf-8 parsing and numeric representation on the binary level. A lot of complicated micro-optimizations mixed with sometimes silly, sometimes entertaining comments, which certainly had their merit at the times being written. Why must a simple perl-javascript-perl transport layer care about unicode and numbers at all? If it's a string write the octets, if it's a number the number and not the stringification, and if its both check for roundtrip-safety. If safe to roundtrip write a number, if not the string. I'm personally very happy that I have not to maintain such a complicated module. We are still happily using JSON::Syck, but JSON::XS without common::sense for all our code would be preferred. It's okay for a module to enforce strict policies for itself, but it's not okay to enforce those upon its caller also. Not everybody needs warnings::register hashes and strictness checks in compiled production code. And one wants to expect civil discussions about changes. Otherwise changes will not happen.

My favorite talk was Joel Bergers usage of "slow" Moose for his science project, a simulation model with a one-dimensional fixed-width solver. It was small, precise, natural and fast. Easier to write, understand, change and maintain than our usual models in Simulink, Mathematica or Lisp. I don't think that it will scale and is comparable to Lisp models, but the fast parts are in C and pdl. Moose is just the beauty layer upon it. Maybe we really need a good FFI sooner or later. Maybe we should use Moose for the type system. Many bioperl folks were also around and appreciating perl. Interesting.

My public question to Larry was if he thought about solving the concurrency and multi-processing problem not in the library level, but on the language-level. Like Erlang or Go. He said certainly. But he is not sure yet how. In perl6 only of course, since perl5 has too much global data around. It's a problem the language has to solve. I agree. I might try to prototype it in qore, as this is a modern better perl already, just lacking concurrency and IPC abstraction as in Go. Think of qore as a perl7 prototype.

3 Comments

There seems to be a lot of hysteria and misunderstanding over common::sense. The fact that JSON::XS uses common::sense doesn't mean that you, by using JSON::XS are forced into strict mode.

The following executes fine without complaining about global symbol $x requiring an explicit package name.

use Data::Dumper;
use JSON::XS;
$x = '{"foo":"bar"}';
print Dumper decode_json $x;

OK, so you need to have common::sense installed, but you're not forced to use it yourself. And if you were really that desperate to avoid it, you could always add this somewhere near the top of your code...

BEGIN { $INC{'common/sense.pm'} = __FILE__ }

Thanks for the kind words Reini! Just to clear up one point, while my example used a fixed-width solver, my main simulations use an RK8 from my PerlGSL::DiffEq module, and yes I don't expect it to scale well, but luckily it shouldn't have to. Thanks again!

About Reini Urban

user-pic Working at cPanel on cperl, B::C (the perl-compiler), parrot, B::Generate, cygwin perl and more guts, keeping the system alive.