Le mer. 15 juil. 2020 à 17:00, Gilles Dubuc <gilles(a)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(a)gmail.com> wrote:
On Wed, Jul 15, 2020 at 8:15 AM Amir E. Aharoni <amir.aharoni(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
--
Amirouche ~
https://hyper.dev