Hi all,
The largest issue I see with Wikilambda is conceptual: sure a Wiki of functions would be
nice. However, a real code base is not made of pure, generic functions such as
"addition" or "concatenation". Let's have a look at a function I
just picked from one of my open text editors. Its signature (C#) is:
void WriteSignedJsonFile(string path, string content, string publicKey, string
signature)
This create a JSON file on the filesystem with a very specific format and values. This
function is 100% useless in any other project. The thing is, most code is glue between
functions, and most have quite specialized use. In this regard, a Wiki a functions
doesn't sound super useful because:
1. For a generic task (say parsing XML) a specialized library in the language one is
programming in will be more easy to use
2. The core code as well as glue code of a project is not transferable to other projects
Abstract Wikipedia will need very specialized data structures. I will need very
specialized code too. The reusability of this code in unrelated projects will tend towards
zero.
Best regards,
Louis Lecailliez
________________________________
De : Abstract-Wikipedia <abstract-wikipedia-bounces(a)lists.wikimedia.org> de la part
de Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il>
Envoyé : jeudi 16 juillet 2020 12:17
À : General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)
<abstract-wikipedia(a)lists.wikimedia.org>
Objet : Re: [Abstract-wikipedia] Wiki of functions (was Re: Runtime considerations:
Introducing GraalEneyj)
בתאריך יום ה׳, 16 ביולי 2020 ב-6:23 מאת Denny Vrandečić
<dvrandecic@wikimedia.org<mailto:dvrandecic@wikimedia.org>>:
Amir, when I say function I mean a computation that accepts an input and returns an
output. That differs, for example, from Lua modules, which are basically a small library
of functions and helpers. We're also starting with no side-effects and referential
transparency, because we're boring, and leave that for a bit later.
But you see, that's exactly the problem: This may be clear to people who learned about
side effects, composition, and referential transparency in the university for their
Computer Science or Mathematics degrees, but I strongly suspect that most editors of
Wikimedia projects didn't learn about these things.
If the project only wants contributors with CS degrees or comparable knowledge, then
it's fine to do it completely differently from a wiki, and more like a software
development project: with Git, with rigorous code review, and so on. Maybe the eventual
result will be better if it's done this way. But don't expect the size and the
diversity of the Wikimedia community, and don't expect that it will be easy to
integrate the functions' output into Wikipedia. Maybe it will _possible_, but it
won't be easy.
But if the intention is to let the large and diverse Wikimedia community edit it, then
from the outset, this project needs to speak in terms that this large community
understands.
This community understands the following things:
* what is an encyclopedia, and what are notability, reliability, original research, etc.
* wiki pages and wikitext (links, headings, categories, references, files)
* a relatively large part of this community understands structured data in the form of
Wikidata
* a relatively large part of this community understands templates (at least how to add
them to pages, though not necessarily how to create them)
* a smaller, but still relatively large and multi-lingual group understands Scribunto
modules
It's totally fine to introduce new concepts or to upgrade existing ones, but it has to
start from something familiar. Jumping straight into composition, side effects, and Z
objects is too cryptic.
So, there will be wikipages that represent such a function. So on one page we would say,
"so, there's this function, in English it is called concatenate, it takes two
strings and returns one, and it does this". Admittedly, not a very complicated
function, but quite useful.
Sorry, but I still don't understand how is this different from making the following
Scribunto module:
local p = {}
function p.concat(frame)
return frame.args[1] .. frame.args[2]
end
return p
I've read through the walkthrough at
https://github.com/google/abstracttext/blob/master/eneyj/docs/walkthrough.md , and at
most, I can see that the Z objects are a programming-language-independent abstract
representation of the code's interface. But _eventually_, there is code at the bottom,
isn't there? And is that code fundamentally different from a Scribunto module?
Then we might have several implementations for this function, for example in different
programming languages, we also might have tests for this function. All implementations
should always behave exactly the same. An evaluation engine decides which implementations
it wants to use (and, for the result it shouldn't matter because they all should
behave the same), but some engines might prefer to run the JavaScript implementations,
others might run Python, others might decide "oh, wait, I am composing two different
functions together in order to get to a result, maybe it is smarter if I pick two
implementations with the same language, as I actually can compile that into a single call
beforehand", etc. There are plenty of possibilities to improve and optimize
evaluation engines, and if you were asking me to dream I'd say I am seeing a vibrant
ecosystem of evaluation engines from different providers, running in vastly different
contexts, from the local browser to an open source peer-to-peer distributed computing
project.
But Scribunto can also support multiple programming languages. In practice it supports
only Lua at the moment, but in theory more languages like JavaScript and Python could be
added. (It's an old and pretty popular community wish.)
So, is a conceptually new infrastructure really needed, and are functions really different
from modules? "Scribunto is not scalable for such an ambitious project" would be
an acceptable answer, but I'd love to know whether this was at least considered.