Напротив, Result "запихивает поглубже": в исключении, как правило, есть информация о стеке, а в результате, как правило, нет.
ошибка часто является частью логики
В этом случае она обрабатывается непосредственно в момент возникновения и сложностей не создает. Существенной разницы между try/catch и if/else при этом не возникает.
P.S. Такая ситуация возникает не "часто", а "редко" - потому исключения и прижились. Достаточно заглянуть в любой код на Go и посчитать, сколько раз ошибку вернули без обработки, а сколько - обработали.
Но ведь именно для устранения бойлерплейта, связанного с обслуживанием Result, исключения и используют. Никакой семантической разницы между явным возвратом результата и "невидимым" пролетом исключения вверх по стеку нет, и нет проблемы, которую исключения создают, а Result решает.
Что исключения, что результаты позволяют отделить бизнес-логику от логики обработки ошибок. Другое дело, что неопытные программисты часто не могут понять, где логика, а где ошибка - вот тогда и начинаются многоуровневые невидимые спагетти (причем использование Result их видимее не сделает). Я как-то столкнулся с полноценным конечным автоматом на разбросанных по всему коду исключениях - но проблема-то была не в механизме, а в его неуместном применении и в размазанности бизнес-логики.
Если подумать, ИИ мало что изменил в процессе. До него был класс работников, занимавшихся копипастом со stackoverflow, теперь эта работа автоматизирована. Риски подхода сохранились и масштабировались вместе с самим подходом. Раньше бизнес игрался с заменой дорогих сеньоров на дешевых джунов из развивающихся стран и терял контроль над кодом; теперь потерять контроль над кодом можно еще быстрее и дешевле.
С другой стороны, статья похожа на взаимное самоуспокоение сеньорствующих, которые несколько напуганы движухой. Если предыдущие серебряные пули в виде RAD, микросервисов, Scrum еще можно было принимать, закатив глаза, и ждать, пока труп очередной метододогии проплывет мимо, то в этот раз "оппонент" определенно силен.
ОКР неплохо работает в ситуации, когда эффект от деятельности непосредственный и мгновенный: разместили рекламу - прибежали клиенты, посчитали их, все хорошо. Но как быть с активностью, результат которой проявляется на долгих сроках? Например, создание некоего инструмента займет несколько кварталов - как тогда мерять прогресс в текущем квартале? Либо же действие имеет накопительный, отложенный эффект, который проявится через год. Померить-то мы результат сможем, но только потом. Как в рамках ОКР работать с такой активностью?
Вполне помогут. Несмотря на то, что основной вал хайпа по микросервисам прошел, все равно многие серьезные проекты дрейфуют в сторону развертывания отдельных сервисов в k8s, и вот там без асинхронного рантайма приходится очень туго: банально невозможно реализовать health checks, работающие адекватно.
Если асинхронный код на PHP уже никого не удивляет и активно используется в проде, то многопоточный — пока все еще большая экзотика, требующая немало потрудиться.
Ну и фреймворкам типа Symfony/Laravel/Laminas ничто не помешает подтянуться, выкатив скелет асинхронного сервиса.
Не, я согласен, что фишка удобная. Но опять-таки на данный момент статический контроль «генерикообразных» структур возможен через Psalm. Имхо, отсутствие генериков — не самая главная беда PHP. На мой взгляд, куда больше вредит отсутствие нормальной многопоточности. Судя по всему, мы рискуем увидеть fibers уже в 8.1, а там и многопоточные рантаймы подтянутся под Amp/ReactPHP. В интересное время живем, хе-хе.
Это вы приписываете разработчику мысль о том, что каждый потребитель должен окупить его расходы. В реальном мире такого нигде не наблюдается, кроме случаев, когда заказчик заказывает разработчику уникальную программу; в этом случае он платит упомянутые вами Y денег.
Во всех других случаях стоимость продукта Y/N денег, где N — некая оценка минимального числа пользователей, которые купят копию. По сути вы утверждаете: «почему вы считаете, что вам должны платить Y? Получите Y/N и расслабьтесь!»
Как-то вы странно Маркса прочитали. Дело в том, что очень мало кто может купить программу, оплатив труд программиста. Программа пишется иногда несколько лет, программист за это время заработал десятки тысяч долларов, но программа стоит, к примеру, всего сто долларов. Почему? Потому что продаётся множество её копий, за счёт этого каждую копию можно купить дешевле.
Именно поэтому, например, ваш мобильник, продукт сложнейших технологий, стоит сотни, а не миллионы долларов. Потому что в разработку технологии вложились один раз, а изготовление копий обходится намного дешевле, чем разработка.
И, кстати, лишнее доказательство того, что наличие шаблонизатора не отменяет необходимости думать. Ночной кошмар можно с равным успехом претворить в жизнь и на похапе, и на Смарти.
Ещё как нужны, причём именно наследуемые. Игра с внешним видом — это же основы маркетинга! В интернет-магазинах бывают различные акции и «сезоны скидок», бывают различные рекламные кампании — всё это требует оперативного переключения внешнего вида сайта (и, что ещё важнее — оперативной разработки оного!) Не следует понимать «скин» исключительно как возможность «поменять в личных настройках цвет форума с синенького на зелененький».
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
Жаль, в сравнении нету PHP - одного из основных конкурентов. А вот Rust туда пихать бессмысленно, на мой взгляд - отрыв слишком велик.
Напротив, Result "запихивает поглубже": в исключении, как правило, есть информация о стеке, а в результате, как правило, нет.
В этом случае она обрабатывается непосредственно в момент возникновения и сложностей не создает. Существенной разницы между try/catch и if/else при этом не возникает.
P.S. Такая ситуация возникает не "часто", а "редко" - потому исключения и прижились. Достаточно заглянуть в любой код на Go и посчитать, сколько раз ошибку вернули без обработки, а сколько - обработали.
Но ведь именно для устранения бойлерплейта, связанного с обслуживанием Result, исключения и используют. Никакой семантической разницы между явным возвратом результата и "невидимым" пролетом исключения вверх по стеку нет, и нет проблемы, которую исключения создают, а Result решает.
Что исключения, что результаты позволяют отделить бизнес-логику от логики обработки ошибок. Другое дело, что неопытные программисты часто не могут понять, где логика, а где ошибка - вот тогда и начинаются многоуровневые невидимые спагетти (причем использование Result их видимее не сделает). Я как-то столкнулся с полноценным конечным автоматом на разбросанных по всему коду исключениях - но проблема-то была не в механизме, а в его неуместном применении и в размазанности бизнес-логики.
Если подумать, ИИ мало что изменил в процессе. До него был класс работников, занимавшихся копипастом со stackoverflow, теперь эта работа автоматизирована. Риски подхода сохранились и масштабировались вместе с самим подходом. Раньше бизнес игрался с заменой дорогих сеньоров на дешевых джунов из развивающихся стран и терял контроль над кодом; теперь потерять контроль над кодом можно еще быстрее и дешевле.
С другой стороны, статья похожа на взаимное самоуспокоение сеньорствующих, которые несколько напуганы движухой. Если предыдущие серебряные пули в виде RAD, микросервисов, Scrum еще можно было принимать, закатив глаза, и ждать, пока труп очередной метододогии проплывет мимо, то в этот раз "оппонент" определенно силен.
А почему не бизнес? Термин feature начали применять к продуктам задолго до появления компьютеров.
https://en.m.wikipedia.org/wiki/Software_feature
А feature flag, например - это из какого словарного запаса?
ОКР неплохо работает в ситуации, когда эффект от деятельности непосредственный и мгновенный: разместили рекламу - прибежали клиенты, посчитали их, все хорошо. Но как быть с активностью, результат которой проявляется на долгих сроках? Например, создание некоего инструмента займет несколько кварталов - как тогда мерять прогресс в текущем квартале? Либо же действие имеет накопительный, отложенный эффект, который проявится через год. Померить-то мы результат сможем, но только потом. Как в рамках ОКР работать с такой активностью?
Если асинхронный код на PHP уже никого не удивляет и активно используется в проде, то многопоточный — пока все еще большая экзотика, требующая немало потрудиться.
Ну и фреймворкам типа Symfony/Laravel/Laminas ничто не помешает подтянуться, выкатив скелет асинхронного сервиса.
Во всех других случаях стоимость продукта Y/N денег, где N — некая оценка минимального числа пользователей, которые купят копию. По сути вы утверждаете: «почему вы считаете, что вам должны платить Y? Получите Y/N и расслабьтесь!»
Именно поэтому, например, ваш мобильник, продукт сложнейших технологий, стоит сотни, а не миллионы долларов. Потому что в разработку технологии вложились один раз, а изготовление копий обходится намного дешевле, чем разработка.
Имхо такой девайс имеет смысл только для тех, у кого действительно постоянный поток винтов под уничтожение.
Код есть код, его дублирование всегда порождало и будет порождать проблемы. Точно так же, как и тотальное наследование всего и вся, впрочем.
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…