Парадигма HumanSpeak

Здравствуйте!
Представляю вашему вниманию парадигму HumanSpeak — словесно свободную кроссплатформенную концепцию API.

Почему?

• Потому что надоело огромное количество языков и библиотек, которые реализуют одни и те же функции, но с разными наименованиями.
• Потому что надоело лезть в справочник по языку, который используешь не первый месяц, чтобы вспомнить как называется функция, назначение которой очевидно.

Смысл

Идея возникла в процессе знакомства с JQuery. Как известно, доступ к элементам разметки осуществляется, в JQuery, через функцию $(), например:
$("edit_field") — получение доступа к элементу с идентификатором edit_field.

Однако, доступ таким образом(через единую функцию-обсервер) можно получать(теоретически, не в JQuery) не только к структуре, но также и к функциям!

Т.о. введя например: $("string length"), можно получить доступ к функции нахождения длины строки.
Данный способ доступа можно представить как единый кросс-языковый API. Который поможет избавить программиста от необходимости изучения языко-специфических наименований при переходе с одного языка на другой.

Пример №1

Достаточно запомнить $("string length") независимо от языка.
Вот список наименований одной единственной функции:

OCaml:     string_length("string")  Python:     len("string")  C:     strlen("string")  Pascal:     length('string')  Lua:     string.length("string")  Tcl:     string length "string" 

Пример с длиной строки прост, т.к. меняться в названии там почти нечему. Но все равно есть разница.

Пример №2

Запомнить нужно только одно:

$("string find char","SAMPLE STRING!!!","T") 

Вместо:

OCaml:     string.index("STR","T")  Python:     "STR".index("T")  C:     strchr("STR",'T')  Pascal:     pos('STR','T')  Lua:     string.char("STR","T")  Tcl:     string index "STR" "T" 

Некоторые справочники по языкам(строковые функции)

TCL: tmml.sourceforge.net/doc/tcl/string.html
C: www.cplusplus.com/reference/cstring/
OCaml: caml.inria.fr/pub/docs/manual-ocaml/libref/String.html
Pascal: www.freepascal.org/docs-html/rtl/system/stringfunctions.html

Некоторые выводы

Т.о. функция-обсервер выполняет вспомогательную функцию(основная цель — упрощение вспоминания, обеспечение читаемости).

Это не панацея для языковых полиглотов. Потому, что от языка к языку, API иногда упрощается(синтаксический сахар), напр: извлечение подстроки в Python( s[5:] ) — гораздо проще и быстрее чем писать $("extract substring"). Однако упор на вспоминаемость и читаемость. Гиппотетически, не нужно помнить КАК извлечь подстроку. Наименования функций всегда есть в памяти, потому они выражатся в наиболее естественной для человека форме: $("извлечь подстроку").
Возможность использования локализованных наименований — отдельная тема.

Какие проблемы решает?

Проблема множества разных языков далеко не только в наименовании, но зачастую и в разном принципе работы функций(напр. сравнения строк(вспомните strcmp в Си и функцию сравнения строк в других языках)).

Что мы достигнем?

• Стандартные функции примут единое кросс-языковое наименование.
• Стандартные функции будут иметь единый принцип работы.

Т.о. порог вхождения для языков снизится, и на первый план выйдут именно особенности языков программирования в чистейшем их воплощении — скобки и апострофы станут не массовкой, а актерами с главной ролью — это обеспечит их эволюцию и конкуренцию. Если сравнить синтаксис с воздухом, то раньше им просто дышали, но теперь его можно будет жевать, синтаксические особенности языков станут по настоящему ощутимыми, т.к. набор функций одинаков.

Идея в том, что данный API должен быть реализован на всех общеизвестных языках.

Далее возможно рассмотрение способов реализации как в скриптовых, так и в системных(структурных) языках(через единую функцию с переменным числом аргументов и кучу подфункций через switch).

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