[Moscow.pm] HTTPD на короутинах

[Alexandr Gomoliako]

Еще раз на счет конструктивности и дискуссий.
Мы все вместе знаем намного больше, чем каждый по отдельности и какой
бы дискуссия не была, она всегда полезнее, чем ее бы вообще не было.
Например, я сказал что-то неправильно, кто-то написал почему это
неправильно и опа -- совместное использования знаний в
человеко-распределенной системе :)

На счет тимтоуди -- то это не имеет ничего общего с парадигмам и
подходами в программировании, а касается только синтаксиса языка. Да и
в общем-то это оказалось фэйлом и все пишут в строгих стилях, но
разных. И чтобы читать чужой код, нужно знать те чужие способы
написания тоже. Типа, не скажешь же боссу, что ты не умеешь писать с
if, а только с unless. В p5p это регулярно вспоминают и перл 5 уже
давно не просто тимтоуди, а еще и but sometimes consistency is not a
bad thing either.

> Тут под сложностью наверное понимается количество сущностей. То есть
> кроме корутин еще есть каналы, локи, семафоры. Больше сущностей -
> меньше надежность.

Со сложностью конечно сложно объяснить, но не так сложно, если
подумать. Думать -- вот это сложно :) Быстренько аргумент написать
легче.

И так, первое, корутины вводят целую систему с планировщиком и пачкой
функций для управления этой системой. Тут как не крутить, а вы будете
делать предположения о работе этой системы и ее планировщика с каждым
cede. Всегда придется с ней считаться.
Второе: implicit vs explicit, эта проблема старая, как мир. В
корутинах все функции, которые как-то трогают систему с планировщиком
замаскированы под обычные функции и при любом желании повлиять на
систему вам нужно как-то с ними считаться. А раз они прячутся, то это
легко может привести к неправильным предположениям о том, что они
делают и, соответственно, ошибкам.
Третье да, куча дополнительных сущностей из параллельного
программирования, чтобы хоть как-то с этим всем работать, что довольно
странно. Никто бы в жизни не хотел пользоваться синхронизацией и в
параллельном программировании она не от легкой жизни, но марку она
показалась "удобной".

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

Теперь сравним это с continuation passing style: все что у нас есть -
это функция, которую нужно вызвать, когда мы закончили в текущей и все
дела. Куда тут проще.

На счет дебагить легче -- у нас же вроде уже TDD популярно, о каком
дебагить речь? :)

На счет оптимизаций, отсутствие такой для tail call - вообще не
проблема, у нас императивный язык и есть обычные циклы, их не надо
через рекурсию запускать, как в эрланге. А на IO событиях там даже не
получится уйти в рекурсию.

В общем такое случайное происхождение корутин и не могло привести ни к
чему хорошему.