Advogato blog for chromatic

Perl on Google's App Engine

Wed, 23 Jul 2008 07:11:21 GMT

Artur Bergman discusses Perl on Google's App Engine, while Brad Fitzpatrick announced Perl on App Engine. The important information is that Google will support the project only if the Perl community does most of the hard work. (This position seems reasonable to me; gift horses and all that.)

They Call This a Softball Question in Interviews

Mon, 21 Jul 2008 05:07:15 GMT

Recently there has been a feeling of growing discontent: how could Ruby — which felt so new and liberating two years ago — get saddled with so much negative baggage, so quickly?

— Pete Forde, We are RubyFringe

Take your pick of the aggressively dismissive attitude toward other approaches, vigorous and self-congratulatory messianic zeal, egocentric and deliberate misunderstanding of the rest of the world of software development, verbose and willful discussion of, despite baffling ignorance of, other programming languages, misunderstanding of MVC and the Active Record pattern, booing Dave Thomas at RailsConf 2007 for questioning why it was necessary to create a "Women of Rails" website featuring pictures of attendees, cheering at RailsConf 2007 when Chad Fowler said "People call us arrogant" when his point is that that's a bad thing, and the baffling fourteen year old boy sensibilities of the Rails Envy commercials, including my personal favorite, comparing the V in MVC to a drunken prom date.

I can understand arrogance from Olympians or research scientists who've just cured cancer. It seems out of place for people writing CRUD applications, even if they're all shiny with rounded corners and Ajax fade ins.

The Difference Between Jazz and Programming

Sun, 20 Jul 2008 08:09:34 GMT

The modern jazz small ensemble is built upon the rhythm section -- piano, bass, and drums.
The easiest parallel to programming is libraries, frameworks and patterns. These are the building blocks upon which we code. A well-designed library makes your work as a programmer easier and more enjoyable in the same way a solid, experienced rhythm section complements a soloist.

— Nick Sieger, Jazzers and Programmers

One important difference between programming and music is that in programming, correctness often supersedes aesthetics. It's not that aesthetics are unimportant, or that there can or should be no joy in programming -- but if your code doesn't work, it doesn't matter how much of a punk fringe rock star you consider yourself.

Color me (what, two nods to my pseudonym in two paragraphs?) uninspired. I doubt improv will pass my test suite. See Dabblers and Blowhards for a deeper debunking of similarly silly comparisons.

Maybe IFF Everyone Always Gets it Completely Right

Fri, 27 Jun 2008 02:12:06 GMT

[The recent Ruby security vulnerabilities], and others like it in Python/Perl/etc are interesting for a lot of reasons but mostly because too many people point to using these languages as a safe alternative to C/C++...

— Daniel Peck, http://www.digitalbond.com/index.php/2008/06/23/vulnerabilities-in-interpereted- languages/

Right, because there's no difference in requiring everyone to get their pointers and allocations and deallocations and initializations right as you do in C and C++ and requiring only the people writing the compiler or interpreter and possibly any extensions to get these right, as you do in Ruby, Perl, PHP, and Python. A well-designed language extension system will even allow you to reuse the language's memory allocation/deallocation system, further minimzing your risk.

Apparently this part of security is not one where minimizing your exposure is valuable.

(Then again, you may want to reconsider taking security advice from someone whose command of technical details misses the fact that, of the languages listed, only Ruby is "interpereted" [sic] -- and interpret/compile is generally an implementation detail, not a language requirement.)

Perl 6 Design Minutes for 11 June 2008

Fri, 27 Jun 2008 01:08:45 GMT

The Perl 6 design team met by phone on 11 June 2008. Larry, Allison, Patrick, Jerry, Jesse, Nicholas, and chromatic attended.

Larry:

slowly improving
seems like I'm getting smarter, but appearances can be deceiving
my brain's not really back to a lot of spec work yet
continuing to refactor and debug the gimme5/STD5/cursor5 galaxy of pain
making progress on that
parses all of radix.t, though I'm not sure it's doing that correctly
starting to make progress on parsing STD.pm itself, though it's not getting far
hope to be able to parse most of STD.pm using STD.pm by my talk next week
my future plans are to switch over from using lists (which cannot easily be lazy in Perl 5) to using lazy scalar iterators
that'll probably make the produced Perl code look a little prettier too
unless your idea of prettiness is a lot of nested map statements
going to Chicago on Friday
giving a talk a week from tomorrow at Google in Chicago

Patrick:

things are going very well
Rakudo and PCT now support the return statement
hooks for the other types of exceptions implemented
have a version of fail implemented, but it fails in certain cases
want to clean that up

Larry:

it fails to fail?

Patrick:

it fails badly
mostly need to find where we did things the Parrot way and layer the Perl 6 way on there instead
fixing little bugs here and there to get more spectests running
wrote my own small version of Test::Harness to get the output results in a format that makes it easy for us to chart our progress
this one tells us how many we passed
running a test right now to find out where we were this morning
essentially, we're passing around 700 spec tests this week
last week we were passing 624
we may be quite a bit more than 700
all of this will show up in a journal post in the next day or two
writing code distracts me from journal posts, or vice versa
no other distractions
looking forward to YAPC and the hackathon
putting together a list of things to work on at the hackathon
one big thing is how people can help us with the spectests
doing more thinking about how to update PGE to do protoregexes and longest token matching
seems doable this summer
maybe between YAPC and OSCON
tomorrow is Jonathan's Rakudo day
we'll do lazy lists in Parrot

Jerry:

applied a few patches
answered some questions
we set up the Parrot Foundation, a new non-profit for supporting Parrot in specific
assigned directors, incorporated, set up a bank account, will announce at YAPC and OSCON
involved in the logistics of setting that up and so on
finalized the purchase of parrot.org
we'll put up a site there as soon as the domain transfer happens

Jesse:

what are you transferring over?

Jerry:

the Parrot milestone funds

Jesse:

are you getting your own infrastructure for this, or will it run on perl.org?

Jerry:

need to talk to TPF about that
just met with Auzon about the Perl 6 tests
have some questions for discussion
Kevin Tew's back on track with his project as well
fighting some PGE brainos
#parrot helped him move on
he can parse a 6000 line C++ header file in a minute and a half

fixing some bugs
still working on the string system
made some improvements there
cleaned up some grotty code, more to go
might look at the string PDD after the hackathon
continue to mentor Andrew's GC work; he's on the right track and I have high confidence in him
helped Kevin profile his code
found some spots in PGE that could use optimization
Patrick could put in a couple of hours and get some improvements for everyone

Patrick:

I spent a couple of hours on that this morning
too much backtracking
found some other stuff I want to clean up in the process
we'll get more speed from longest-token matching though

and a better garbage collector, Parrot-side
but a 20% improvement now is a good thing

Patrick:

also for people who aren't using protoregexes and such

Larry:

the xor problem is between whether you treat them as binaries or list precedence
do you think treating them as lists makes optimization more effective?
it's not the only thing in that precedence level
if we treated them all as list precedence, does that open up more general optimization improvements?
I'm getting the feeling that the answer is yes

Patrick:

PGE's issue is implementation
with eleven alternations, it stored ten backtracking points

Larry:

it's simpler to implement short-circuit logicals as binaries
implementing them as a list operator might not buy you anything
but they degrade to left-associative anyway, if the operator changes
I could change all of those left-associative ops to list-associative with no change in the binary case
I'm going back and forth on that for infix:xor
should they have the useless semantics of parity?
it's a tradeoff

Patrick:

if they were listops, I don't think we'd get that big an improvement
it wouldn't bother me if it were there
it's not hard to implement them that way

Larry:

the listop could implement them in terms as binary, if it wanted
that's fine

Patrick:

having the one sense would have been really handy

Larry:

you have an explicit one now, but that's just junctions

Patrick:

and it doesn't short-circuit

Larry:

if you have one that's true, tell me which one
that's probably more useful

Patrick:

I could do parity easily

Nicholas:

would be nice to restart the Perl 6 list summaries
the Perl 5 summaries have produced some productive work
David Landgren spends about a full day of work on the summaries every week
the Perl 6 lists have a bit more traffic combined than p5p

Jesse:

we've had trouble finding anyone interested in doing the summaries last time

Nicholas:

there's also the huge problem of trying to summarize IRC
David's reaction was "ugh"

Patrick:

I'll try this and report it in the next two weeks
I haven't been reporting on my progress as frequently as I'd like
weekly might be better, especially given our velocity
I prefer that someone else does the summaries
getting more people to participate is more important
and it's easier for someone involved to summarize than someone who isn't
I'll look for some interested people at YAPC
if that doesn't happen, I'll set aside a day a week to write a summary report

Jesse:

I'd happily pay in beer or whatever for that

Jerry:

conference season is a great time to find someone

Patrick:

if we don't, I'll make that one of my deliverables for my next grant, if I get one
one question from the SoC meeting before this
how do we handle design questions?
I feel badly dumping these on Larry, but I don't know where else to go for resolution of these things
what should my approach be?

Larry:

I treat p6l as a queue of things I ought to have thought about

Patrick:

I'll start posting to p6l then
I was thinking of p6c, but if p6l works better, I'll use that

Larry:

p6c tends to read to me like a lot of implementation things my eyes glaze over

Patrick:

we'll use p6l from now on

Larry:

you get a little more noise from the theory folks at times

Patrick:

if things still get Warnocked, I'll bring it up again

Larry:

that's one reason we have a weekly phone call

Jesse:

speaking of that, no phone call next week while everyone's at YAPC

At Least the FAIL Part was Accurate

Mon, 23 Jun 2008 19:14:51 GMT

Dear CPAN Testers,

I know you're trying to help, but if you can't configure your client to build any modules at all, your failure reports aren't telling me anything interesting that I can fix about my software.

If you really want my help getting this code to install, I'll send you my rate card in exchange for sudo access to your machine.

All the best,
chromatic

(See FAIL UNIVERSAL-can-1.12 x86_64-linux-gnu-thread-multi 2.6.8.1 and its two replies, as well as FAIL parrot-0.6.2 i686-linux 2.4.27-2-386.)

The Fallacy of "If You Ask Me"

Fri, 20 Jun 2008 00:10:03 GMT

And if you ask me, there's nothing wrong with non-commercial redistribution of publicly-available content.

— Shlomi Fish, Why Closed Books are So 19th-Century

Snarky response: maybe you should ask the copyright holder instead, or a legislative body in your jurisdiction, or a legal scholar.

Substantive response: how about another quote?

By making your book available online, you're giving yourself a huge publicity, and earning a lot of repute.

— ibid

Substantive response cont'd: I can't decide if this is the Lake Wobegon fallacy or the In A Perfect World fallacy. Of course it's possible that Stephen King's first novel made him millions of dollars and helped him become a full-time novelist with dozens or hundreds of other books. It's easy to point to a big success like that.

Guess what? There are plenty of other novelists like me, whose first novels didn't sell very many copies at all (if they even made it to bookshelves -- so this is not complaining on my part; I achieved my artistic goals with that book long, long ago). You hear about the one-in-a-million successes and you don't hear about the nine-hundred-ninety-nine-thousand-nine-hundred-ninety-nine-in-a-million modest successes and (mostly) failures.

Put another way: it's no surprise that Cory Doctorow, editor of a site with millions of page views, popular speaker, long-time writer, long-time activist, and effective publicist can write a book, give it away online, and get a lot of attention. He's good at getting attention, especially when he does something that's very consistent with the goals and mores and ethics of the people who pay attention to what he does.

Similarly the argument that copyright infringement didn't cost J.K. Rowling substantive money fails to move me.

If my argument here fails to convince you, here's another quotefrom an earlier essay:

Perl is very hard to learn from public electronic resources alone. I believe there may even be a clash of interests because the core Perl people also write them and so may not have enough motivation to improve the online documentation. Making them public will resolve that.

— Shlomi Fish, "Usability" of the Perl Online World for Newcomers

Good things happen not because magical candy-flavored unicorns fly over and drop sparkly glitter on projects where some hand-waving pundit said "All you have to do is make it a wiki and in mere seconds your teeth will be whiter, your waistline slimmer, your hair thicker, and all of your problems disappear." Good things happen because someone sat down and did the hard work to make good things happen.

Is the Perl FAQ materially better than it was ten years ago because it's easier to work on now? (I'm not sure it's even substantively different than it was ten years ago.)

There's an interesting discussion on the subject of mechanisms by which to encourage participation (and I do believe that liberal policies of contributions and licensing can encourage such participation), but the argument that merely allowing non-commercial redistribution summons those delicious sexy unicorns is hollow, shallow, and completely unsupported by facts and experience. (That's even laying aside the ridiculous conspiracy theory that suggests that Perl book authors are organized and sinister enough to plot to keep the core documentation skimpy and yet stupid enough not to realize that it's easier to get rich flipping burgers for a living than writing technical books full-time.)

Dear CPAN Tester, Please Join Us in the 21st Century!

Thu, 12 Jun 2008 21:15:36 GMT

UNIVERSAL::can 1.13_001 fails on Perl 5.005 running on FreeBSD 6.2.

Wrap your head around that for a second -- that's the same FreeBSD 6.2 released in January 2007. There were sixteen stable releases of Perl 5 between the releases of Perl 5.005 and FreeBSD 6.2. Surely in nine years, someone might have had a few moments to try to upgrade to a version of Perl released sometime in the 21st century. Just skip the commercials during a week's worth of television, no?

Or, you know, stick with the modern version of Perl included with FreeBSD 6.2.

Possibly my favorite part is that my Build.PL requires at least Perl 5.6.2, which is in my mind now also ancient Perl (seven stable releases old). This is the last bit of motivation I need to stop coddling this ridiculous situation by writing passthrough Makefile.PL files. What a waste of my time for such an unbelievably stupid situation.

Perl 6 Design Minutes for 04 June 2008

Wed, 11 Jun 2008 23:12:57 GMT

The Perl 6 design team met on 04 June 2008 by phone. Larry, Allison, Patrick, Jerry, Jesse, and chromatic attended.

Jerry:

things are going well with GSoC
Kevin's on vacation, and due back tomorrow
he'll be getting to work then
the other students seem to be working according to plan
we'll start using the Pugs Trac to track additions to the Perl 6 test suite
a place to request new tests

Jesse:

is there a really good reason to use two different ticketing systems?

Jerry:

it's already there and already has a category for Perl 6 tests

Patrick:

already in use for Pugs
and the Pugs repo already hosts the tests
Rakudo still uses RT

Jerry:

and there's nothing Perl 6 spec-related I know of that lives in any other ticketing system
applying some good patches from contributors
modified the test suite tools to make it easier to work with the spec tests in Rakudo
you can specify a local list of tests to run
added the ability to run the spec tests purely as they are, or fudged
you can use a test config file for that

Larry:

fudge already kinda has that built in

Jerry:

if there are no directives in the file
my addition allows you to ignore implementation-specific directives and run the file directly

Larry:

and take the consequences
that's fine

Jerry:

talked to Patrick about Rakudo management
we're considering adding some new committers
looking for a better way to handle tickets for patches
it's getting difficult for Patrick to apply all incoming patches
interrupting his work
we want to be able to appoint a person or persons to apply approved patches

I'm happy to apply anything once you've approved it and it's ready to apply

Jerry:

that's what we're looking for
that should make things easier for Patrick

Patrick:

mostly Parrot time this week
refactored list and array handling in Rakudo
list assignment now works!
the various composer works
bare curly hash composition doesn't work yet
that won't be hard to do
just need to write some rules to detect when to build a block versus build a hash
it'll happen soon
Jonathan implemented a Mutable PMC, which implements Perl 6 scalars
forwards its operations to what it contains
we can assign to it and do type checks in the process
some issues in Parrot's type management
not always clear when we want to talk about the scalar as a scalar versus what it's containing

Allison:

container type versus value type?

Patrick:

yes
the particularly nasty vtable entry for that is find_method
we'll look more into that in the next couple of weeks
it's not impeding progress on us anymore
lots of cleanup of the AST building routines
some duplicated code, some refactoring there
more of that coming in the next few days
lots of little improvements and changes
small cleanups
more tests pass
starting to keep a daily count of the number of passing tests of the official test suite
I'll report improvements on a daily basis
as of yesterday afternoon, we had 55 files and 638 passing tests
that's an improvement of 344 over the passing week
Jerry and Moritz deserve special compliments for the work they've done on the tests and the suite
much easier to work with now
much easier to find low-hanging fruit
optimistic about our progress over the next few weeks
Jonathan is doing a lot of work on classes and types and subsets
you can declare subset types and have them work
a variety of improvements are on the way there too
things are coming together a little faster than I expected
like Jerry said, one day this week, I spent a few hours applying patches
that's a good problem to have
would be nice to read over it for sanity then have someone else test to see that it doesn't break things and perhaps apply it
not always easy for me to do without colliding with what I'm doing currently

Larry:

did a little bit of spec work
trying to remain responsive
due to a confluence of very many factors, I've been running as hard as I can to stay in one spot

Allison:

closing out a few last bugs in the concurrency branch
adding a few new features
PGE uses bsr and branch heavily
they don't play well with continuations
added a new feature for continuation-safe branching
about to submit the paperwork for the new foundation this week or next

fixing bugs, closing tickets
mostly adding polish
did some work on optimizing string usage; will have more benefits there shortly
watching over Andrew and his GC work
he's on the right track, hasn't needed much guidance
otherwise preparing for YAPC

Jesse:

not much to report
just work
what do you need?

maybe encouraging people on #parrot to apply patches and test them locally and report their results would help out

Jesse:

maybe doing that as an example would help?

Patrick:

we're going to require all patches to go through RT first
that gives us a little process

Jesse:

how many patches need massaging?

Patrick:

some 80% apply and work, but make incorrect assumptions
I can apply it and say we'll fix the assumptions later
or I can respond and give guidance to resubmit the patch
or I can make the minor changes and fix them as I apply it
pretty rare to get a 100% patch
but I don't want to become the bottleneck

Jesse:

what's the time-consuming part of the apply and test cycle?

Patrick:

I'm trying to avoid something
someone comes out with a patch that solves a test case
they submit it somehow
you want to give them instant gratification
if I'm in the middle of working on a feature myself
and many that I work on aren't small
I need a separate checkout to apply and test and commit
that takes a few minutes, maybe ten
then I have to pick up where I was, merging their changes into mine
the low-hanging fruit is all in the same files

Jesse:

it doesn't sound like tooling is the important thing to fix here

Jerry:

it's the process

Patrick:

a lot of it will fix itself in a short period of time
part of the problem is that I was absent from code review for a couple of months
I'm glad we made progress during that point
but now it's the time to refactor away some of the assumptions there
it may not be as big a deal if I get caught up soon
that will happen sooner if I don't have to deal with the other things

about 80% of the patches I see for Parrot in general are high quality
not a lot adding new features, which may affect that
but the quality is good, and I'm pleased

Kwalitee Without a Point

Mon, 9 Jun 2008 07:10:37 GMT

Gabor Szabo requested comments on several new CPANTS metrics. Short comment: these are the worst metrics yet.

Medium comment: Yeah, yeah, Kwalitee isn't a measure of Quality. I get that, but it's no excuse for piling on even more lousy metrics that not only don't know Quality, but have never even bumped into Quality accidentally at the grocery store.

Longer comment:

distributed_by_debian -- I'm sure all users of Win32-specific modules, for example, will be happy to learn that their Kwalitee could be higher if they sweet-talked a Debian Developer into polluting their repository with code useless to Debian.
latest_version_distributed_by_debian -- maintainer on vacation? Sorry, no Kwalitee for you!
has_no_bugs_reported_in_debian -- finally, the Win32 developers get a break. Again, I'm not sure what this really means for them, but hey, it's a free Kwalitee point. Life is good.
has_no_patches_in_debian -- I've only been doing this for a decade, but I'm still under the impression that most of the OSI-certified licenses seen in CPAN distributions allow downstream modification and redistribution. In that decade, I've also seen how often downstream never notifies upstream of changes. (Though Brendan O'Dea of Debian is one of the most responsive downstream developers from any distribution for Perl 5.)
uses_test_nowarnings -- because the POD testing metrics work oh-so-well and because testing for custom lexical warnings is evil and bad and wrong, or at least stuffing a do-nothing string "use Test::NoWarnings" in your t/ directory somewhere is a certain sign of Kwalitee.

80% of these new metrics only measure Kwalitee of a distribution to Debian users. That may be useful for Debian users, but it's highly inappropriate (and worse, irrelevant) for everyone else. (I believe Ubuntu has a bug somewhere that not all of the world uses a Debian-based distribution.)

Constructive criticism: How about a way to opt into only the useful CPANTS metrics? I'd hate for users of my code to get confused by meaningless Kwalitee Theater.