It seems that this isn't for CS paper writing, but for writing pseudocode during design, which needs much more flexibility than communicating results in a POPL paper.

Regular pseudocode, formal specs close to programming (eg VDM language), and graphical stuff like Statecharts worked well in industry for a long time. Including for high-assurance systems where ambiguities lead to catastrophic failure. Middle option was advantageous where it was precise enough for tools to catch errors or prove properties. Any of these worked well enough and didn't look as weird as OP to average programmer.

Those are fairly established notations that...when hey first came out, weren't as obvious as they appear now.

It is unfair to expect that pseudo code notations be static at this point in history when new programming languages that look "weird" pop up all the time.

I've been a huge fan of computer science papers going the literate route. Imagine if more were of the variety of https://smile.amazon.com/dp/0123750792.

Though, I also feel that that adds to the time of creating these papers. So, by my own view this might be more expensive than it is worth.

To be fair, it seems like you linked to a textbook, rather than a paper. Textbooks have different aims than papers (pedagogy vs. succinctly conveying necessary info to an expert in the field)

I'm not sure which direction that takes the "fair" though. I expect textbooks to take a long time to write. Writing a paper that is also executable should be a lot easier than a textbook that is the same. Or, a textbook period.

In particular, it saddens me that I can't find any examples of papers that are literate examples. I started dabbling with the idea here[1], but I think I fundamentally misunderstood some of the ideas when I did that. I keep meaning to take up the idea again. I can't deny that it is a slow process, though.

[1] http://taeric.github.io/DancingLinks.html

Nope, writing papers takes longer. The collective amount of time it took to write the papers (I'm not counting the research time) that a textbook is based on, is much greater than the time it takes to write the textbook.

Also, there is no incentive because of the reasons I stated (pedagogy to someone new vs. succinct explanation to expert)

I can't claim you are wrong. But this is so non-intuitive to me that it hurts. I get why "covered ground" for text books would be easier to do. But many textbooks should be pushing the field, as well. Right?

And I fully note that the book I linked to is exceptional. It won a oscar.[1] And was basically required reading at pixar, if I recall.

[1] https://www.youtube.com/watch?v=7d9juPsv1QU

There is nothing original in textbooks? They just need to cite the relevant papers? I find it perfectly intuitive that it is harder to come up with an original argument/idea than it is to summarize one you've already heard.

Papers are very condensed and probably scrutinized more than textbooks are, via the peer review process. Papers have to have proofs for any theorems, whereas textbooks might omit them (especially the less important ones).

Also, to be fair, a textbook might rely on a dozen different papers in the span of a single page (just taking key insights or arguments for the papers).

Both of those claims seem... off to me. Specifically, this is a reductionist view of them that makes them sound easier. I do not claim they are harder, just different. Each difficult in their own way.

I would be interested in seeing the publication times for many text books. Empirically, we should see something in the difficulty in relation to the time it took to create. Right?

Edit, since I saw your point of referencing many papers in a single page. Don't papers do the same?

We were comparing the amount of time it takes to write a textbook versus the amount of time it takes to write all the papers the textbook cites (or relies on, I guess). So I don't think "hardness" and the fact that papers also cite other papers really changes this comparison.

I mean, a textbook might take years to write/edit (on and off) But it takes at least a month (on and off) to write/edit a paper.

But you don't think this is a learnable thing? Doing a paper, you already have to write code. Just structure it differently.

As it is, the code is often neglected. And rarely shared. Both bad facets.

And making a full text book that is executable is what I was comparing. That entire book is a program. I'd imagine that was much harder than the typical paper. Many of which are surveys and gloss over deficiency of the supporting code. (Again, I still concede the black swan nature of that book.)