Amirouche,
I see your points about a new programming language potentially causing friction and
reducing ease of adoption.
I found this useful document:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan . It
appears that JavaScript [1] and Lua [2] are in a group of languages for initial
consideration for Wikilambda and that Python [3] as well as Web Assembler, PHP, Rust,
C/C++, R, Swift, Go, and others [4] are planned for later, eventual consideration.
We seem to agree that structured comments could be useful for providing features
including: extensible metadata for functions, ease the searching for functions in large
collections, and make possible the automatic generation of documentation.
I disagree that global objects are evil; after searching the Web for concerns, I do see
that they should be used with care. Without global variables, global objects or global
scripting environment API, many functions would have the same, arguably redundant,
parameters – for example the output natural language. We could broaden that set of
parameters which describe NLG output by adding reading level and verbosity. There could,
then, be a set of global parameters which describes desired NLG output which would,
otherwise, have to be passed to numerous functions as arguments.
I’m brainstorming on how to provide convenience for NLG developers. An envisioned
developer experience is having a means of toggling a developer mode or debugging mode when
viewing the hypertext NLG output on Abstract Wikipedia to then be able to hover over
content to view relevant diagnostic messages in hoverboxes. Another envisioned developer
experience is having a means of toggling a developer mode or debugging mode to view visual
indicators for diagnostic messages in a margin to the side of rendered natural language
hypertext output.
I wonder what you and others in the group envision in terms of developer experiences while
working on Wikilambda and inspecting natural language hypertext outputs on Abstract
Wikipedia?
I’m also starting to think about the many topics broached in the plan document:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan , e.g. IDE integration features
[5].
A topic that I didn’t see mentioned yet in the plan document is automatic natural language
measurement or evaluation. Software tools in the categories of automatic essay scoring,
grammar checking, readability measurement, or natural language evaluation, e.g. Coh-Metrix
[6], could be of use for automatically measuring articles in a number of ways. Perhaps
bots could measure articles as they are updated and report their data the developer
community.
Best regards,
Adam
[1]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.12:_JavaScr…
[2]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-bas…
[3]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-bas…
[4]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementa…
[5]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate…
[6]
http://cohmetrix.com/
From: Amirouche Boubekki<mailto:amirouche.boubekki@gmail.com>
Sent: Friday, July 3, 2020 2:19 PM
To: General public mailing list for the discussion of Abstract Wikipedia (aka
Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org>
Subject: Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia
Le ven. 3 juil. 2020 à 18:50, Adam Sobieski <adamsobieski(a)hotmail.com> a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract
Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it
intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract
Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase
friction and reduce the ease of adoption, also it will require to
rebuild the wealth of documentation that exists for existing
programming languages. It is sure that people do not love to learn new
languages. wikilambda should be a trampoline toward regular (?)
programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a
sweet spot (even if there is a lot of parentheses). Wikilambda will
probably not need call/cc (but might require exceptions) and macros.
So, it will make the implementation much much easier. I mentioned the
parentheses, well there are sugar syntaxes that allow you to work
around it. In particular, Racket is working on a wanna-be mainstream
language that will be the best of all worlds... See
https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals….
Might it be useful to transpile a new programming
language into an existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as
being comprised of signatures and bodies, might it be useful to consider models of
functions with more components? We could express such things with multiple, nested “{}”
brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and
effects.
Inspired by PDDL:
function foo(…)
{
guard { /* … */ }
preconditions { /* … */ }
body { /* … */ }
effects { /* … */ }
}
It seems to me it is similar to Racket contracts. I am not very
familiar with those. I will prefer that complexity to be opt-in,
unlike the previous generation of statically typed programming
language (C, C++, Java) and which is to some extent still the case
(Rust, in particular, is not very friendly to the newbie even seasoned
developer).
My idea about the subject of "specifying" the expected behavior of the
program inside the program is to rely on "asserts" which are opt-in
and can be disabled. The idea is to infer types from asserts. Remain
the question of who to specify exceptions (which is missing from
Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…)
{
requires { /* … */ }
body { /* … */ }
ensures { /* … */ }
}
Such models can be phrased as transformations or mappings from existing languages that
separate and organize varieties of content that frequently occur in function body
definitions.
I prefer to imagine a programing language as a sandbox. And document
patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular.
Structured comments can provide extensible metadata for functions, ease the searching for
functions in large collections, and make possible the automatic generation of
documentation.
I am not against the idea of comments. That said, I am not sure what
structured means in this contexte. XML to document functions?
Seriously? Again, I think I prefer complexity to be opt-in, and help
spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by
the Wikilambda project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have
the expressiveness of metadata attributes which can adorn methods and their parameters. A
useful attribute is [Obsolete] which supports the use of messages to make use of a newer
version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate
the syntax and increase the surface and required knowledge necessary
to play with the language. I imagine that simply having a function
that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With
namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a
crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be
provided by the runtime environment. An API could be specified for the runtime
environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be
convenient to be able to output to multiple streams, to log, or to raise typed events. It
would also be useful to be able to aggregate, organize and view these diagnostic outputs
with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of
toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view
rendered articles and hover over natural language output to view relevant diagnostic
messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of
toggling a developer mode or debugging mode on Abstract Wikipedia such that visual
indicators for diagnostic messages would be placed in a margin to the side of rendered
natural language output.
Best regards,
Adam Sobieski
_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia