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(a)lists.wikimedia.org> de la part
de Gilles Dubuc <gilles(a)wikimedia.org>
Envoyé : mercredi 15 juillet 2020 15:00
À : General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)
<abstract-wikipedia(a)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.com<mailto:arthurpsmith@gmail.com>> wrote:
On Wed, Jul 15, 2020 at 8:15 AM Amir E. Aharoni
<amir.aharoni@mail.huji.ac.il<mailto: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<mailto:Abstract-Wikipedia@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia