[jjm]

True, but taking that aside and focusing on practicality, both underscorejs and Preludejs together provide one heck of a toolbox. I really enjoy functional programming a great deal and have been using it every which place I can the last several years. I totally understand that this is your take on the subject matter and so far so good, though the docs and usage for me are strange. If you have the goal of mass adoption you'll need to convince people like me why it needs adding to the toolbox.

[ionfish]

I don't think one can ignore that and also focus on practicality. Using these JS dialects is a practical issue. Learning them and remembering how they work imposes a certain amount of overhead, albeit a reasonably small one. Of greater concern is maintaining projects written in these dialects: what if the support around key parts of your toolchain goes away? Of course they're open source, so you can maintain them yourself—but that may be a lot of work, and will rarely be the highest priority. Ultimately it may be more effort than it's worth, even if it's a lot more enjoyable to write than vanilla JavaScript. I'm not saying that this will always be the case, but it's an issue that does need to be addressed before jumping in and using them on a major project.

Anyway, Udon was really just a personal library which I tidied up and documented in case it might be of use to somebody. I think this is generally good practise: it encourages one to write clean, maintainable code, some documentation, and a test suite with reasonable coverage. In principle one should always do these things, but somehow putting it somewhere public makes it more likely that they'll actually happen. I was actually quite surprised to see it on Hacker News today, since I first wrote it two years ago and last made any changes to the source code over a year ago.

In other words, I'm not exactly falling over myself to promote it to the wider world or make it fit people's needs other than my own. Patches to increase the functionality of the library or improve the documentation would of course be welcome, and several good suggestions have already been made on this thread. But I'm not too concerned about convincing people here or elsewhere that they should be using it. In fact, they probably shouldn't: as you and others have said, most or all of its functionality is provided by other libraries which are far more actively maintained (this is really just a corollary of my first point).

However, I would be interested in hearing what you think is strange about the documentation and usage.

[jjm]

It's an issue I see when things go public. Public then mainstream. As such mainstream users mean mainstream docs. So my evaluation was in those eyes. The most important thing to gain is refinement that can be learned for the next lib you may or may not start/contribute to.

[jjm]

Yeah and I 100000% thank you for contributing!!!

It is a great contribution to the community and personally, regardless of my or other's personal technicalities.