Еще раз на счет конструктивности и дискуссий. Мы все вместе знаем намного больше, чем каждый по отдельности и какой бы дискуссия не была, она всегда полезнее, чем ее бы вообще не было. Например, я сказал что-то неправильно, кто-то написал почему это неправильно и опа -- совместное использования знаний в человеко-распределенной системе :)
На счет тимтоуди -- то это не имеет ничего общего с парадигмам и подходами в программировании, а касается только синтаксиса языка. Да и в общем-то это оказалось фэйлом и все пишут в строгих стилях, но разных. И чтобы читать чужой код, нужно знать те чужие способы написания тоже. Типа, не скажешь же боссу, что ты не умеешь писать с if, а только с unless. В p5p это регулярно вспоминают и перл 5 уже давно не просто тимтоуди, а еще и but sometimes consistency is not a bad thing either. > Тут под сложностью наверное понимается количество сущностей. То есть > кроме корутин еще есть каналы, локи, семафоры. Больше сущностей - > меньше надежность. Со сложностью конечно сложно объяснить, но не так сложно, если подумать. Думать -- вот это сложно :) Быстренько аргумент написать легче. И так, первое, корутины вводят целую систему с планировщиком и пачкой функций для управления этой системой. Тут как не крутить, а вы будете делать предположения о работе этой системы и ее планировщика с каждым cede. Всегда придется с ней считаться. Второе: implicit vs explicit, эта проблема старая, как мир. В корутинах все функции, которые как-то трогают систему с планировщиком замаскированы под обычные функции и при любом желании повлиять на систему вам нужно как-то с ними считаться. А раз они прячутся, то это легко может привести к неправильным предположениям о том, что они делают и, соответственно, ошибкам. Третье да, куча дополнительных сущностей из параллельного программирования, чтобы хоть как-то с этим всем работать, что довольно странно. Никто бы в жизни не хотел пользоваться синхронизацией и в параллельном программировании она не от легкой жизни, но марку она показалась "удобной". Получается, что корутины вводят просто редчайшую сложность, но не дают нам никакой реальной параллельности. Теперь сравним это с continuation passing style: все что у нас есть - это функция, которую нужно вызвать, когда мы закончили в текущей и все дела. Куда тут проще. На счет дебагить легче -- у нас же вроде уже TDD популярно, о каком дебагить речь? :) На счет оптимизаций, отсутствие такой для tail call - вообще не проблема, у нас императивный язык и есть обычные циклы, их не надо через рекурсию запускать, как в эрланге. А на IO событиях там даже не получится уйти в рекурсию. В общем такое случайное происхождение корутин и не могло привести ни к чему хорошему. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
