The part I don't get is why a collection of functions and tests needs to be editable on a wiki. This poses severe limitations in terms of versioning if you start having functions depend on each other and editors can only edit one at a time. This will inevitably bring breaking intermediary edits. It seems like reinventing the wheel of code version control on top of a system that wasn't designed for it. MediaWiki isn't designed with the ability to have atomic edits that span multiple pages/items. Which is a pretty common requirement for any large codebase, which this set of functions sounds like it's posed to become.
What reasons does this benefit from being done as wiki editable code compared to a software project (or series of libraries/services) hosted on a git repository? Especially if we're talking about extensive programming and tests, whoever is computer literate enough to master these concepts is likely to know how to contribute to git projects as well, as they would have very likely encountered that on their path to learning functional programming.
Good questions - you may be right, but I think the wiki approach is worth trying. One benefit of being done as a wiki is the openness that is achievable - with a git repo there are always gatekeepers in some form or another - the number of people who are allowed to directly update the repository is necessarily small. Denny's vision here requires people who understand hundreds of different languages to contribute; that will never be a small group. And the more barriers in their way (having to set up a github account, fork, create pull requests etc.) the less likely we are to get that large group of contributors actively involved.
So how to avoid the problem of "breaking intermediary edits"? Denny's ZObject approach at least prevents one common problem - if everything is identified by a Z-Id then changing the name of a function or variable or type will never break things (it's just the label on that ZObject in a particular language, not how it is called)! I think in general other types of breaking changes can be avoided by requiring creation of a new ZObject, rather than editing an existing one, when it would change behavior in a breaking way. Not all functionality changes are necessarily breaking though - you can add function arguments with default behavior if one of the new arguments is missing, for example.
But maybe we will need some way to allow for atomic edits that span multiple ZObjects; if that really is an essential requirement then let's figure out how to do it. There's lots of work ahead no matter how we do this!
Arthur