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:_JavaScript-based_implementations

[2] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-based_implementations

[3] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-based_implementations

[4] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementations_in_other_languages

[5] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate_into_IDEs

[6] http://cohmetrix.com/

 

From: Amirouche Boubekki
Sent: Friday, July 3, 2020 2:19 PM
To: General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)
Subject: Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia

 

Le ven. 3 juil. 2020 ŕ 18:50, Adam Sobieski <adamsobieski@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.md.

> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia