Hello,
I totally agree with every concern raised in this email. In fact, I already stated my position that an Abstract Wikipedia doesn't need a new approach of programming in my first email. I also agree that anyone who has enough technical skills to write or edit code will be able to use git or any other version control software to contribute. I'll wait and see what going on on this front.
Besides, I also strongly hope that the Z-Object JSON subset will include the possibility to add comments otherwise this will be a nightmare to understand and maintain code.
@replying to sister email by Arthur:
Number of contributors is not an issue. The dotnet repository on Github for instance has 300+ contributors, and it probably can scale to a few more orders of magnitude. Language understanding is also not really an issue either as modules for a given linguistic community will likely be developped by the said community. In addition, code is generally written in English with comments in the local language (OpenOffice had comments in German for decade, for instance), in part because historically programming language didn't even support identifiers in other character sets than ASCII. For full "localized" programming one would need to also write filenames in their language, which will break things as Windows and macOS don't use the same Unicode canonicalization form; hence the industry practice write filenames in plain old ASCII.
Best regards, Louis Lecailliez
________________________________ De : Abstract-Wikipedia abstract-wikipedia-bounces@lists.wikimedia.org de la part de Gilles Dubuc gilles@wikimedia.org Envoyé : mercredi 15 juillet 2020 15:00 À : General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda) abstract-wikipedia@lists.wikimedia.org Objet : Re: [Abstract-wikipedia] Runtime considerations: Introducing GraalEneyj
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.
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.
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.
On Wed, Jul 15, 2020 at 4:42 PM Arthur Smith <arthurpsmith@gmail.commailto:arthurpsmith@gmail.com> wrote: On Wed, Jul 15, 2020 at 8:15 AM Amir E. Aharoni <amir.aharoni@mail.huji.ac.ilmailto: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.orgmailto:Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia