This is a superset of a message I sent directly to Duke. I think it would be useful to have a wider conversation around whether there’s much to be done to improve Pike’s standing in the world.
The general assertion that getting started with pike is difficult because there’s no documentation or that it’s crummy. And I think a good portion of that is well-founded, but there’s also often the subtext that what’s really meant is “I want to paste my question into google and have a hundred answers”. Unfortunately, that’s an unrealistic expectation when you’re not dealing with a multi-million user community actively contributing toward solving the problem. When the somewhat limited resources available online aren’t enough, what you have here are mailing lists and (I believe) an IRC channel. Here, you can ask questions and get polite, well reasoned answers from experienced users and possibly even core language developers. I get that might not be everyone’s ideal situation, but it’s what we have to offer at the moment. So, I guess the questions I’d ask (with respect to the community supported language references) are “what do you feel is required to be considered complete?” And “what resources did you examine that you felt were lacking?” It’s been quite a while since I looked at the tutorial on the Pike website, and it indeed appears “incomplete”. I think what has happened is that someone decided to convert the material to a GitHub project and never finished the job. That’s truly unfortunate, and the original content is available from the wayback machine: https://web.archive.org/web/20140102221903/http://pike.lysator.liu.se/docs/tutorial/ It also appears to be available from Roxen.com: https://docs.roxen.com/pike/7.0/tutorial/index.html The only major flaw I am aware of is that the GTK example doesn’t work as described because GTK1 isn’t supported anymore and it wasn’t updated to GTK2. The language constructs that are missing from newer versions are (in my opinion) fairly minor, at least in terms of text required to describe them, and in many cases might not even be appropriate for inclusion in a “basics" manual. Automap comes to mind, as it is more likely than not to cause outright confusion. Pike has a fairly stringent policy of backward compatibility, so it’s not been my experience that being old necessarily equates with being un-useful. Those materials (or the book) would give you 85-90% of the constructs commonly used today. If you’ve got specific examples of problems you’ve run into, reporting those problems is always appreciated. At the end of the day, the situation Pike finds itself in is the same today as it was 15 years ago: it is largely a volunteer project. The Pike High Wizards are busy doing their wizarding, and they have left it up to others to fill in the gaps. That seems to be an entirely reasonable position for them to take. I took that as a call to arms and over the years spent many, many hours trying to fill gaps  and have always welcomed assistance, but almost without exception, it’s been a solo effort. None of it has seemed to move the needle. So, I find myself resigned to the idea that advocacy by one person simply comes across as a crazy person yelling into the wilderness. I continue to use pike because for almost all tasks, it continues to be the most efficient way for me to solve a given problem. I’m always happy to take time when a reasonably well defined problem is identified, so please feel free to do so and we’ll see if it can be solved. Thoughts? Comments? Suggestions? Bill  major projects like wiki.gotpike.org, modules.gotpike.org, “the book”, eclipse plugin, co-organizing multiple conferences, jupyter support, magazine articles, among others.