Рассмотрим пример на C#, демонстрирующий преимущества функционального программирования для качества кода:
Вижу обычный, стандартный шарповый код.
А есть какой-то пример, который являлся бы, по-вашему, не функциональным, но выполнял бы все те же самые действия? Лишенный, так сказать, "всех преимуществ".
Тестирование на товары с отрицательными ценами. Ожидаемый результат: игнорировать такие товары и вернуть сумму только положительных цен.
Но ведь проверять отрицательность цены должны другие тесты (валидаторы?), а не все подряд, кто имеет хоть какую-то возможность эту цену прочитать. Наличие отрицательных цен - это совершенно отдельный вопрос к бизнесу (возможно/не возможно), и его постоянное "учитывание", как в тестах, так и в остальной логике, лишь усложняет разработку.
Сделать как в Slay the Spire не сложно, если потратить некоторое время на пристальное разглядывание КАК ИМЕННО сделано в этой игре, разбить наблюдаемый функционал на отдельные блоки (декомпозиция), их реализация уже будет сильно проще. Например, поводить мышкой неспеша влево-вправо по руке, отметить, в какие моменты фокус переключается с одной карты на другую. Отметить, насколько именно карта вылезает из руки при фокусе, можно засечь время анимации (запись экрана, подсчёт кадров), можно даже примерно определить easing function, используемую при каждой конкретной анимации.
Если тебя на работе уважают, ценят и даже - нихрена себе! - хвалят, то выгореть гораздо сложнее, чем когда исподтишка травят, постоянно давят собственными дедлайнами, грозя лишением премий, а любую полезную самовольную инициативность полностью игнорируют (как максимум считая её за должное).
Я как-то мечтал о подобном, но юнити еще тогда не знал, и хотел на WPF. Ведь в игре много интерфейсов! Такая классная технология и так жаль, что не кроссплатформенная.
Ну, с одной стороны, вывод казалось бы очевидный, а с другой - без конкретных данных по "просадке" производительности это мало что полезного показывает. Да, много строчек в табличек, но что если они все особо ни на что не влияют?
Да что тут доказывать, все сильно проще. Берём, копируем вставляем текст задачи Эйнштейна боту. Бот её незамедлительно решает (конечно же). Берём абсолютно то же описание, но заменяем немца на русского. Всё, бот сломался. Пытается и думать, и спекулировать, и сразу ответ говорить, но он ни разу даже не угадал. Сразу видно, что да, думать он не умеет, причем, как это очевидно, задача изменена минимально.
Мне кажется, не должно быть сложно придумать способ, работающий без Reflection.Emit.
IDE-шка ведь имеет представление о нашем коде без какой-либо компиляции, прямо в процессе написания кода. Значит, у неё в памяти уже есть модельки, представляющие собой описание юзеровых типов и их членов. Осталось только прикрутить генерацию именно этих самых моделек (вынеся их в public api) в output инструмента "source" generators.
А тел методов можно и через делегаты реализовывать.
Вижу обычный, стандартный шарповый код.
А есть какой-то пример, который являлся бы, по-вашему, не функциональным, но выполнял бы все те же самые действия? Лишенный, так сказать, "всех преимуществ".
Просто "concurrent" даже в топ-6 гуглопереводов не переводится как "конкуретный" :)
мне уже кажется, что джуна-мидла натаскивать на неё будет проще и быстрее
Но ведь проверять отрицательность цены должны другие тесты (валидаторы?), а не все подряд, кто имеет хоть какую-то возможность эту цену прочитать. Наличие отрицательных цен - это совершенно отдельный вопрос к бизнесу (возможно/не возможно), и его постоянное "учитывание", как в тестах, так и в остальной логике, лишь усложняет разработку.
А если ваш Васян за свои деньги купил себе УльтраГайковёрт3000 и крутит их в 3 раза быстрее, вы ему тоже побольше работы накидаете?
Сделать как в Slay the Spire не сложно, если потратить некоторое время на пристальное разглядывание КАК ИМЕННО сделано в этой игре, разбить наблюдаемый функционал на отдельные блоки (декомпозиция), их реализация уже будет сильно проще. Например, поводить мышкой неспеша влево-вправо по руке, отметить, в какие моменты фокус переключается с одной карты на другую. Отметить, насколько именно карта вылезает из руки при фокусе, можно засечь время анимации (запись экрана, подсчёт кадров), можно даже примерно определить easing function, используемую при каждой конкретной анимации.
Столько воды и эпитетов... но ни слова конкретики. Чем он лучше то?
Можно отсекать людей с рейтингом меньше X.
Почему лимит сразу убьёт частные приложения? У каждого юзера вводится личный лимит, и он физически не сможет больше 2-3х запросов в секунду посылать.
Unnecessary tag detected.
Если тебя на работе уважают, ценят и даже - нихрена себе! - хвалят, то выгореть гораздо сложнее, чем когда исподтишка травят, постоянно давят собственными дедлайнами, грозя лишением премий, а любую полезную самовольную инициативность полностью игнорируют (как максимум считая её за должное).
тут компилятор, к счастью, умеет так:
Интересно, что они этим экономят.
А это не тоже ли самое? Только еще и с машиной времени.
Я как-то мечтал о подобном, но юнити еще тогда не знал, и хотел на WPF. Ведь в игре много интерфейсов! Такая классная технология и так жаль, что не кроссплатформенная.
Ну, с одной стороны, вывод казалось бы очевидный, а с другой - без конкретных данных по "просадке" производительности это мало что полезного показывает. Да, много строчек в табличек, но что если они все особо ни на что не влияют?
Для обоснования совмещения используйте
Distinct. Его тупо нет в query синтаксе.Да что тут доказывать, все сильно проще. Берём, копируем вставляем текст задачи Эйнштейна боту. Бот её незамедлительно решает (конечно же). Берём абсолютно то же описание, но заменяем немца на русского. Всё, бот сломался. Пытается и думать, и спекулировать, и сразу ответ говорить, но он ни разу даже не угадал. Сразу видно, что да, думать он не умеет, причем, как это очевидно, задача изменена минимально.
Мне кажется, не должно быть сложно придумать способ, работающий без Reflection.Emit.
IDE-шка ведь имеет представление о нашем коде без какой-либо компиляции, прямо в процессе написания кода. Значит, у неё в памяти уже есть модельки, представляющие собой описание юзеровых типов и их членов. Осталось только прикрутить генерацию именно этих самых моделек (вынеся их в public api) в output инструмента "source" generators.
А тел методов можно и через делегаты реализовывать.