I always enjoy reading through discussions like this to see if there's anything to be learned. Obviously, a lot of the comments are familiar and center around:

a) I already have a preferred language, why would I ever learn something that isn't already in use by a large percentage of the programming population? b) (probably a corollary) the community is so small, I would need to actually do some learning and write some code rather than swipe answers from google and pip/npm a module!

I don't really think there will ever be a satisfactory answer for these folks, and that's fine. I will note the sometimes comical complexity invoked by people using node, for example. Developing a simple application can easily pull in 700 external modules from npm. I also have to wonder what leads a language community to have a very popular module with one method, that returns the lower case version of a string... did the language not provide such a feature out of the box? Did someone publish that as a means for learning about the module ecosystem (reasonable, even laudable!) and no one noticed it wasn't necessary? Was it a huge joke? Who knows?

For better or worse, if you choose to use pike, you will be somewhat forced (and rewarded) if you do your homework... the vast majority of potential users will be eliminated right there. There were some questions about "tooling" which are potentially interesting:

a) We like mod_php! We like web development frameworks! Where is any of this?

I've tried to keep lists of these sorts of solutions but because they're not linked to from the main pike site, it's almost impossible to find them. mod_php like functionality via FCGI/SCGI/Relaying exists, as does the ability to embed Pike code in pages just like

b) Where's the source code?

Here, I actually sort of agree that there's a discoverability problem. Even now, after decades of experience with the website, I always have to stop and think about where the read-only link is. Most of the links on the sub ribbons seem almost invisible to me. Could something be done to make it easier to find? Seems pretty common for that to be on the front page, or at worst the top of the development page. I imagine the project pays a price for not being GitHub-first, but making the repository location, etc easier to find would be useful for everyone, I think.

c) No discussion forum? No chat room? A mailing list, how retro!

Aside from people not reading text that's very clearly present, I do note that the dev mailing list link is broken. Would it also be reasonable to include a link to the mailing list archive at mail-archive.org? It seems that the back-messages never got loaded, but current messages seem to be present. I assembled a fairly complete archive of the messages back in time, if anyone has an idea for how that could be made available (and googlable)?

Some things I found really interesting:

a) Concurrency, ie the GIL

What are the ways for improving concurrency, and how big of a problem is it? I'm sure it can be a real problem, just wondering if anyone has any experience probing what they are? Aside from unlocking in c-language modules, seems like the solutions for single-process improvements are pretty invasive. Is there an opportunity to provide some tooling to allow tasks to be spread across a number of pike processes in order to get around the GIL? I did some work with zeromq, which positions itself as a way to improve concurrency without the risks of multi-threading. Perhaps some sort of pike clustering module/etc could provide performance improvements?

b) Embedded/embedding

2 possible meanings here;

a) embedding a pike interpreter in another program, which is possible and I've shipped several projects that use this. Don't think this would be of interest to most people, but could be made a lot nicer with just a little effort.

b) running some variant of a pike interpreter on microcontroller scale devices (Ala micropython, etc). Potentially huge audience, but seems like the pike interpreter isn't really suited to being scaled down to fit/run: a pretty hefty controller would be necessary and without a real os and limited ram, you'd probably give up a lot of the things that pike excels at: networking, file I/0, etc. Could be really interesting to see what the smallest device you could run a real OS and pike on and tailor that to embedded development. Ie, can you do it with a device you can get for 10 currency units reliably? I'd certainly be willing to put some cycles toward that if there's interest.

c) Runtimes: JVM, WASM, etc

Probably not ever going to happen, but wouldn't it be nice if it did?

I feel like there is some low hanging fruit that could at the very least make life easier for the random person who ends up on the Pike website:

a) fixing broken links
b) making the repository easier to find
c) how about a faq? all of these things come up from time to time, and it seems like they ought to be written down and easy to find. I know there are several documents like this out there, but perhaps a little effort to collect and present them would be useful? d) Mailing list archive. I have the data, and a search engine with the content loaded, but a browsable archive would be really nice. I could possibly help with that if there's interest. d) Either hosting or prominently linking to tools built with/for pike that could allow someone to use pike for something useful (thinking editor support, fcgi, etc). I've got a lot of this information already,

I was going to include references, but I'm running short of time now. Lots of potential content available from www.gotpike.org.

As always, comments and suggestions are welcome!


Reply via email to