Perl dying? Well now I don't care

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.

7 Comments

If at first you don't succeed, try, try and try again.

I have many enhancements to Pod. You don't need to add anything to the basic Pod to get what you want because you can always write your own translator to get it. I think that's a better way to go.

See, for instance, my Pod to DocBook translator, which I use for my O'Reilly books. I use =begin figure blocks to do basically what you are doing

https://github.com/briandfoy/pod-pseudopod-docbook

For my Perl School books, I have Pod translators to ePub and LaTeX too, and these have much more sophisticated transformations.

I have other PseudoPod modules too, and if you are really interested, send me an email with your GitHub name and I'll add you to one of my private book repos so you can see more.

I particularly wouldn't want YAML either, for a variety of reasons. First, I just hate the format for the basic same reasons most people do. Second, I don't want added complexity in a base class. Third, I think there are ways already in Pod to get what you want.

But, having said all that, if you want YAML, write a subclass of Pod::Simple that has it, or use various mixing to inject that stuff. That way you can do whatever you want without worrying about the base class.

I can understand the push back on YAML. YAML is a huge specification, way more complex than you need. There's already a cut-back broken implementation in core, adding a second cut-back broken implementation seems a bad idea, and adding a full implementation seems like overkill for such a trivial task.

The concerns people seem to have had about locating the image file once a distribution has been installed are also valid.

Seems to me a simple implementation would be something like this to embed an image file, along the lines of how links already work:

J<Yes|checkmark.jpeg>

A code like that would allow images to be embedded even within the flow of a paragraph if desired.

Plus add the option of embedding the images as base64 data at the end of the pod:

=for embedded checkmark.jpeg

[...base64 data here...]

=cut

(If it was unclear in my previous comment, the "Yes" was supposed to be alt text for the image, to be displayed if the image cannot be shown.)

Your anger, frustration and fatigue makes sense to me. I'm so sorry to hear about your experience, and very glad you shared it in such detail, which took a good deal of your time and represents yet another effort you've made to benefit the community. We're all technically-focused geeks to a degree, but it's surprising to me that responses to your post have been almost exclusively technical ones as to your method for adding an image extension, rather than solution-oriented comments addressing the problem you've described in detail, which is to say the political problem you encountered rather than implementation of an extension. Maybe that's just too sensitive or perhaps uncomfortable in this forum; I don't know. Sure hope you can find a way to hang in here, but it sounds like it will be a big challenge.

I'm not sure being a cry baby on the Internet is going to help your cause any, but judging from the many Fortune 500s that use Perl for their back end infrastructure, I'd wager to say Perl will be around longer than you or I. LMFAO

Dimitry, I have encountered many comparable problems as you described. For instance, I have attempted to get markup like =method =sub =example and inheritance information into plain POD, to help produce nicer HTML already 20 years ago. Many mechanisms block those developments unless you are a core maintainer. That's why I wrote OODoc (not to be confused with OpenOffice, which arrived much later)

For your YAML implementation: I basically agree with Tina: do it 100% or don't do it at all. We have too many modules which are just 80%; which break when you start using them in the real world. When you can complete the test-set, you do not need her approval anymore, do you?

My interest in the core, both software and people, has disappeared when they started limiting the freedom of speech for participants of an event; kicking people out with inconvenient opinions.

Leave a comment

About Dmitry Karasik

user-pic I blog about Perl.