That is very true, Louis!
But remember, the goal is not to write arbitrary applications. In order to
write an actual full-fledged application there is still a lot of packaging
to do: UX, state, persistence, etc. -- all things we will not look at.
Does this limit us in what we can achieve? Yes, absolutely. But our primary
goal is not to provide an application building and hosting platform. Our
primary goal is to provide a system to extend the coverage in the
Wikipedias. For this, we will also provide the missing pieces of product
development. But for using the functions of Wikilambda in other contexts,
well, for that there will still be more needed.
Wikilambda won't replace apps, and does not intend to. But having a
collaborative repository of functions will still provide a lot of
interesting use cases, even with this restriction.
But thanks for clarifying the limits of the current plan, this is
super helpful!
Denny
On Sat, Jul 18, 2020 at 8:31 AM Louis Lecailliez <
louis.lecailliez(a)outlook.fr> wrote:
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>:
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.
_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia