Dmitry Karasik

It is a bit of a long story how I got burned by bad perl internal politics.

For many years I wanted images in Pod. And many others wanted too. And of course, each time I raised this in lists and on facebook, an answer was, if you want it, go and write it yourself. I would tell that myself, the classic "patches are welcome". Until one day I said, well, now, why actually not, right? Especially that I do have experience in creating and actively using images in pod using various hacks, such as direct inclusion of html with images, and even writing a standalone POD viewer capable of showing said images.

However as I'm in software development in so many years, I know that just writing whatever image extension I feel like won't get accepted: people won't necessarily agree on the new sytnax, on the way it is implemented, or even on the very fact that the extenision is needed, at all. So I started by carefully asking around these questions everyone on all perl groups I could reach, and even opened a ticket on github to discuss whether image extension for pod is a good and desired thing to do, and what syntax it should have.

And indeed, both on github and in pod-people archives, there was lots of productive discussions, and some things were pointed to that I didn't think as good as I thought, but step by step, final capacity and syntax emerged. Strangely enough, the best case for all requirement came to be ... YAML! Even though I didn't consider it, and in its full form it is a clear overkill, but if one to go pedantically through every requirement, it seems that strange as it may be, but YAML actually is quite a good candidate, the best actually of all proposal and syntaxes. One clear win is that when you create a new syntax, you need its full specification, and BNF, and a parser. And a standard implementation. However, if the syntax exists already, lots of efforts can be spared, and also other languages can use this extension out of the box. Granted, that can be any other syntax but YAML, but then .. what? Json? Xml? No, thank you, but no. And YAML has excellent, first-class support of multiline text, which is vital for interspersing new syntax with old, for the older parsers. Anyway, whoever is interested in that discussion, it is in pod-perl archives here , and I personally think the extension became very light and intuitive, see the description.

So, next step. After reaching consensus both on github and pod-people, I'm asking several times everyone, if I'm going to start the implementation, would that be okay with what we agreed on? Would that not be ignored, would we continue working on it? I'm not asking for immediate accept , because during the implentation anything could happen, but yes, I was assured by Karl Williamson, Pod::Simple committer, that he would really encourage me to do that work. Thank you Karl for your kind words!

And so it started. I quickly found that I don't what whole YAML, and a rather limited set of it would suffice. YAML is rather esoteric, but as we need something simple, basically, commands about that this is a picture and this is its caption, that was basically it. I chose to implement though inline arrays partly as a fun experience, and partly in case where one would need to specify an image set, srcset, that would contain several images, or something similar. I rather quickly implemented a patch for Pod::Simple and filed a pull request here .

First, there were constructive feedbacks. Tina Muller noted that YAML parser, or even a limited YAML parser, cannot really use word YAML in its name if it parses something that a real parser wouldn't (and fail where real parser doesn't). The rationale is that if someone writes an invalid YAML that will be parsed by the reference implementation, other parser will be in trouble, and we don't want that. But since we're doing the limited YAML, failing on valid YAML is okay by definition, because we never specify that this is a valid syntax in the first place. In addition, she referenced me to a huge YAML test suite, and quite frankly, I had a hell of a time adapting the parser to microscopic special cases in the suite. But in time, that was done, too. I was seriously proud of my work and really hoped for the next step. Unfortunately Tina couldn't check the result because she's busy with personal stuff, and I respect that of course, but on the other hand, I believe I fixed all problems she mentioned, and some smaller stuff can be done later.

However the next step came to be not quite what I expected. Or even worse, it _was_ what I expected, but worked some months in advance to prevent just that. Namely, there started to appear feedbacks that said that they don't want YAML. Well, after having come that far, some would consider it a bit too late probably. But okay, let's find out what the problem is, and let's fix it, and let's move on. But... no. I asked several times what seems to be the problem, and the gist of it seems to be that they just don't want it, without explanation. Just that. Worse, as I understand, this is core people. And so it has halted.

Boy, this was a disappointment. Did I not ask everyone, everyone I could reach, do you have any objection? Do you mind this? Do you mind that? What is, in your optinion the syntax should be? And only after lots of efforts, it ended like this. I'm angry, I'm frustrated, I don't have any stamina left to ask around again, especially the other side doesn't seem to be interested in dialogue. And why should I, really? When I started with perl in 1997, and went on YAPC conferences, there were so many possibilities to expand the language, and Larry Wall was blessing all kinds of crazy extensions (remember rewrite of perl on C++? that was blessed too). It's a pity that a culture once blossoming turned into this. Probably it needs to die so everyone would understand what was lost. I don't know. And I don't care now.