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!
Bill
