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 [1] 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

[1] major projects like wiki.gotpike.org, modules.gotpike.org, “the book”, 
eclipse plugin, co-organizing multiple conferences, jupyter support, magazine 
articles, among others.


Reply via email to