> Get my module accepted into some standard library?
Yes, that is the gist of it. More specifically, the challenge is, "at this point in time, has anyone gotten the appropriate code into a standard library?"
As far as the challenge is concerned, we have to take it on faith that when the challenge was posed, it was no more than a coincidence that pg's language supported an example written in a style pg likes.
I think I'm getting this. Let me try another bit of questioning to make sure I got it.
So let's say I think CSV-file processing is important. If I show doing something useful and common with CSV files in 15-20 symbols with my language of choice would it be fair to challenge other languages to do the same?
If I understand you correctly, this all hinges around what libraries you think languages should have by default and how many symbols it takes to get something "common" done using these commonly-available pieces.
This is a little too subjective for me, although I'll easily grant that web programming is much more common than CSV-file processing.
Instead of relying on the arbitrariness of what components have been built or what various committees have approved, I would amend this to be something like "after an initial bit of programming not to exceed 3 days, how much symbology do I have to piece together to solve various problems in some sort of common domain like web question/response?" Or something like that. Because as a practical matter I'm always taking a bit to ramp up on new pieces of languages anyway and 3 days or so in this context is a nit.
Yes, that's how I understand the challenge. And I agree, it is subjective[1].
I think that the most positive way of looking at it is to declare that session storage in a web app and parsing csv files are understood problems which we don't want to get bogged down solving again. Last week I was writing a small web app to browse a 2GB or so data set, which was provided to me variously in xml and csv data files in a zip file.
If I could have called:
import data_20091201.zip
and gotten something useful, I would be all the happier.
I can now make that call, but in terms of getting stuff done, I'm judging my programming environment on the availability unzip utilities, xml and csv parsing libraries and database tools. As far as the language itself is concerned, I want to be able to structure my code neatly without worrying about forgotten temp files if the import fails.
I see the arc challenge as a proxy for making this sort of judgment, but it does come down to: "Do the people who maintain the language and contribute to its libraries worry about solving the sorts of problems that I would like to solve? And are they successful in making my life easier?"
[1] Subjective in the sense that the problem to solve is one that you may or may not care about solving, or may prefer to solve in a way that happens to use more code to make different aspects more explicit.
Yes, that is the gist of it. More specifically, the challenge is, "at this point in time, has anyone gotten the appropriate code into a standard library?"
As far as the challenge is concerned, we have to take it on faith that when the challenge was posed, it was no more than a coincidence that pg's language supported an example written in a style pg likes.