Jump to content

Abstract Wikipedia/Updates/2021-08-27/uk

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Abstract Wikipedia/Updates/2021-08-27 and the translation is 19% complete.
Оновлення Абстрактної Вікіпедії Translate

Абстрактна Вікіпедія (список розсилки) Абстрактна Вікіпедія в ICR Абстрактна Вікіпедія в Телеграм Wikifunctions on Mastodon Абстрактна Вікіпедія у Твіттері Абстрактна Вікіпедія у Фейсбуці Абстрактна Вікіпедія на Ютубі Сторінка проекту Абстрактні Вікіпедії Translate

Фаза ζ завершена

Коли ми розпочали розробку сайту Вікіфункцій, ми поділили роботу з запуску Вікіфункцій на одинадцять фаз, названих першими одинадцятьма буквами грецького алфавіту.

  • Після завершення фази α (альфа) появилась можливість створювати екземпляри системних Типів у вікі.
  • Після фази β (бета) стало можливим створювати Типи на вікі та створювати екземпляри цих Типів.
  • Після фази γ (гамма) стали доступними всі основні Типи загальної моделі функції.
  • With Phase δ (delta), it became possible to evaluate built-in implementations.
  • With Phase ε (epsilon), it became possible to evaluate contributor-written implementations in any of our supported programming languages.
  • Цього тижня ми завершили Фазу ζ (дзета).

Метою Фази ζ було забезпечити можливість оцінки реалізацій, що складаються з інших функцій.

Що це означає? Кожна Функція у Вікіфункціях може мати кілька Реалізацій. Існують три різні способи вираження Реалізації:

  1. As a built-in Function, written in the code of Wikilambda: this means that the Implementation is handled by the evaluator natively using code written by the team.
  2. As code in a programming language, created by the contributors of Wikifunctions: the Implementation of a Function can be given in any programming language that Wikifunctions supports. Eventually we aim to support a large number of programming languages; for now we support JavaScript and Python.
  3. As a composition of other Functions: this means that contributors can use existing Functions as building blocks in order to implement new capabilities.

With Phase ζ we close the trilogy of Phases dealing with the different ways to create Implementations.

Besides making composition work, we also spent some time on other areas.

We worked to reduce technical debt that we accumulated in development during the last two phases which we rushed in order to be ready for the security and performance reviews. We improved how the error system works, re-worked the data model for Testers and Errors, refactored the common library to be more extensible, moved the content of the wiki to the main namespace, and changed Python function definitions to align with the style we use for JavaScript ones.

We started with some work to make the current bare-bones user experience better. This included displaying Testers' results and meta-data on their own page as well as related Function and Implementation pages. Functions and Implementations can be easily called right from their page. We made it much easier to create and connect Implementations and Testers with their functions, started on the designs for Function definition and implementation, and implemented aliases that sit alongside labels, much like in Wikidata. Plenty done!

We are now moving on to Phase η (eta). The three main goals of phase η is to finish the re-work of the Error system, to revisit user-defined types and integrate them better with validators, and to allow for generic types.

What are generic types?

We have a type for a list of elements. But instead of saying “this is a list of elements”, we can often be more specific, and for example say “this is a list of strings”. Why is that useful? Because now, if, for example, we have a function to get the first element of a list, we know that this function will return a string when given this kind of list. This allows us to then offer a better user experience by making more specific suggestions, because now the system knows that it can suggest functions that work with strings. We can also check whether an implementation makes sense by ensuring that the types fit. We won’t be able to do that in all cases, but having generics will allow us to increase the number of cases where we can do that by a lot. For more background you can refer to the Wikipedia article on generic programming.

In this example case, instead of a special type representing a list of strings, we will have a function that takes a type and returns a typed list. If you then call this function with the string type as the argument, the result of the function will be the concept of a list of strings. And you can easily use that for any other type, including user-defined types.

My thanks to the team! My thanks to the volunteers! Some of us are starting to have fun using the prototype, playing with implementations across different programming languages interacting with each other in non-trivial ways, and starting to build a small basic library of functions. This will also be the phase where we move from the pre-generic data model to the full function model. To give due warning: this probably means that almost everything will need to be re-written by the end of this phase, in order to take advantage of the generic system that we are introducing.

Thank you for accompanying us on our journey!