LINUX.ORG.RU

История изменений

Исправление slackwarrior, (текущая версия) :

Ну банально. Облегчение труда разраба требует инвестиций, которые могут не отбиться и... зафиксируют выбор возможностей, т.е. ограничат возможности развития API: делая выбор, проектировщик все время отсекает другие возможности. Пример из «несвязанной» области (но связанной по проектированию API, только более простого): были раньше (где-то примерно в 10-х) в моде «humanfriendly» API обмена данными для распределенных сервисов на XML и JSON с авторазбором в DOM и объекты(ORM, сериализация-десериализация), которые подавались как «более лудшая» альтернатива «ужасной» бинарной СORBA... Это все в итоге оказалось небыстро, нефрендли и переусложнено (многие из-за этого бросали изучать XML где-то на неймспейсах, XPATH и XSLT («циклы for в разметке? ЧЗХ...»). Генереный роботами JSON тоже оказался нисколько не читабельнее генереного роботами XML. Поэтому история сделала круг через rest к гуглобуферам — и вернулись к бинарным форматам, а API текстовых парсеров упростили до функций, возвращающих следующий токен, с маркетингом «зато быстро!» В развитии графических API происходит такая же «спиральная диалектика». От недружелюбных буферов с арифметикой указателей и прерываниями к «дружелюбным» фиксированным API, от фиксированных API к шейдерам с буферами за «семантику» которых отвечает программист и далее к «кроссAPIйности» вулканиума + «ситуация, есть N конкурирующих стандартов... Это плохо. Нужно взять все лучше... Ситуация, есть N+1 конкурирующий стандарт».

Исправление slackwarrior, :

Ну банально. Облегчение труда разраба требует инвестиций, которые могут не отбиться и... зафиксируют выбор возможностей, т.е. ограничат возможности развития API: делая выбор, проектировщик все время отсекает другие возможности. Пример из «несвязанной» области (но связанной по проектированию API, только более простого): были раньше (где-то примерно в 10-х) в моде «humanfriendly» API обмена данными для распределенных сервисов на XML и JSON с авторазбором в DOM и объекты(ORM, сериализация-десериализация), которые подавались как «более лудшая» альтернатива «ужасной» бинарной СORBA... Это все в итоге оказалось небыстро, нефрендли и переусложнено (многие из-за этого бросали изучать XML где-то на неймспейсах, XPATH и XSLT («циклы for в разметке? ЧЗХ...»). Генереный роботами JSON тоже оказался нисколько не читабельнее генереного роботами XML. Поэтому история сделала круг через rest к гуглобуферам — и вернулись к бинарным форматам, а API текстовых парсеров упростили до функций, возвращающих следующий токен, с маркетингом «зато быстро!» В развитии графических API происходит такая же «спиральная диалектика». От буферов к фиксированным API, от фиксированных API к шейдерам с буферами за «семантику» которых отвечает программист и далее к «кроссAPIйности» вулканиума + «ситуация, есть N конкурирующих стандартов... Это плохо. Нужно взять все лучше... Ситуация, есть N+1 конкурирующий стандарт».

Исходная версия slackwarrior, :

Ну банально. Облегчение труда разраба требует инвестиций, которые могут не отбиться и... зафиксируют выбор возможностей, т.е. ограничат возможности развития API: делая выбор, проектировщик все время отсекает другие возможности. Пример из «несвязанной» области (но связанной по проектированию API, только более простого): были раньше (где-то примерно в 10-х) в моде «humanfriendly» API обмена данными для распределенных сервисов на XML и JSON с авторазбором в DOM и объекты(ORM, сериализация-десериализация), которые подавались как «более лудшая» альтернатива «ужасной» бинарной СORBA... Это все в итоге оказалось небыстро, нефрендли и переусложнено (многие из-за этого бросали изучать XML где-то на неймспейсах, XPATH и XSLT («циклы for в разметке? ЧЗХ...»). Генереный роботами JSON тоже оказался нисколько не читабельнее генереного роботами XML. Поэтому история сделала круг через rest к гуглобуферам — и вернулись к бинарным форматам, а API текстовых парсеров упростили до функций, возвращающих следующий токен, с маркетингом «зато быстро!» В развитии графических API происходит такая же «спиральная диалектика». От фиксированных API к шейдерам с буферами за «семантику» которых отвечает программист и далее к «кроссAPIйности» вулканиума + «ситуация, есть N конкурирующих стандартов... Это плохо. Нужно взять все лучше... Ситуация, есть N+1 конкурирующий стандарт».