Le mer. 15 juil. 2020 à 17:00, Gilles Dubuc gilles@wikimedia.org a écrit :
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.
I disagree with the fact that it must be done with the existing wikimedia codebase. Tho, I believe it is possible to build an integrated development environment that fuses programming language with a version control system. That is what unison is doing with content-addressable code. Unison has different goals, but they have i18n identifiers/docstrings on their roadmap.
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.
My understanding is that wikilambda wants to be easier than going through all the necessary knowledge to contribute to a software project. That is, wikilambda could be something better than git/github.
I get why such an architecture might be a choice for a prototype, for fast iteration and because the people involved are familiar with wikis. But what core contributors are familiar with and what can be used for a fast prototype is rarely a suitable and scalable architecture for the final product.
My understanding is that the prototype wanted to demonstrate that it is possible to i18n the identifiers, docstrings, etc... of a programming language. Something that nobody tried or succeed at doing so far.
There is also a notion of how dynamic the content is to take into account. There is a difference between the needs of ever-changing encyclopedic information, which a wiki is obviously good at handling, and an iterative software project where the definition of a function to pluralize some text in a language is highly unlikely to be edited on a daily basis, but where interdependencies are much more likely to be an important feature. Something that code version control is designed for.
The problem with git is that if you change the definition of function in a file, every other place where you call that function, you need to update the code. That is different from a content-addressable code where you reference the content of the function, if you change the function, it creates a new function (possibly with the same name) but old code keeps pointing to the old definition. That much more scalable than the current git/github approach (even if you might keep calling old code).
On Wed, Jul 15, 2020 at 4:42 PM Arthur Smith arthurpsmith@gmail.com wrote:
On Wed, Jul 15, 2020 at 8:15 AM Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
I keep being confused about this point: What are the "functions" on AW/Wikilambda, and in which language will they be written?
I think everybody has a slightly different perspective on this. I've been working closely with Denny's prototype project (which included the javascript version of 'eneyj' that Lucas was inspired by) at https://github.com/google/abstracttext/ (I assume this will move somewhere under wikimedia now?). The prototype does to an extent define its own "language" - specifically it defines (human) language-independent "Z Objects" (implemented as a subset of json) which encapsulate all kinds of computing objects: functions, tests, numeric values, strings, languages (human and programming), etc.
I think right now this may be a little more complex than is actually necessary (are strict types necessary? maybe a 'validator' and a 'test' should be the same thing?); on the other hand something like this is needed to be able to have a wiki-style community editable library of functions, renderers, etc. and I really like the underlying approach (similar to Wikidata) to take all the human-language components off into label structures that are not the fundamental identifiers.
ZObjects for "implementations" of functions contain the actual code, along with a key indicating the programming language of the code. Another ZObject can call the function in some context which chooses an implementation to run it. At a basic level this is working, but there's a lot more to do to get where we want and be actually useful...
Arthur _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia