Стоп. Сначала «ломаем мозги» переменными и циклами, а потом «функциональщину сложнее понять». Если человек хотел просто удвоить каждый элемент в списке, может быть дать ему написать list |> map x => x *2, а не засирать мозги ненужной для задачи ерундой?)
Договора и счета и описывают как раз состояние :-)
Дистанция между реальностью и формализированной математикой больше, чем между реальностью и импреативщиной, значит человеку надо проделать больше работы.
Многие инженерные (да и не только) задачи отлично описываются и решаются формализованной математикой. И совершенно логично реализовывать модель близко к тому, как она описывается. Введение же более сильных ограничений иногда полезно для того, чтобы увеличить предсказуемость алгоритма (он просто будет отбрасывать некорректные исходные данные). Я предпочитаю иметь такую возможность когда она требуется, вместе того, чтобы мучаться, имитируя эти ограничения на языке «попроще»
Я бы согласился, если бы не одно но: никакой статистики, из которой можно заключить, что большинству людей удобнее парадигма Х нет: если изначально учат парадигме Х, в индустрии используется в основном Х, то человеку будет «удобнее» Х. В кавычках только потому, что человек ничего кроме этого не знает. А если преподавать и «Х» и «Y», а затем (для начала пусть в сферической вселенной в вакууме) предоставить выбор, что использовать для задачи — далеко не факт, что человек выберет X.
Человек живёт в императивном мире, мыслит императивно и действует императивно.
В это утверждении фактическая ошибка. Не все процессы в мире императивны и не всегда мы думаем «берём каждую бумагу, проверяем дату и подписываем». Иногда нужно просто «подписать все бумаги». Для большого количества задач ФП не уложняет работу, а упрощает её за счёт более высоких абстракций. И возможность не усложнять эти задачи деталями реализации — это и есть KISS.
Железо императивно по своей природе, да. Но это ли повод делать языки императивными? Мне всегда кажется, что такой подход и есть ни что иное, как «человек для компьютера». Когда мне нужно проверить, что два документа равны, меня, чёрт возьми, интересует, что эквивалентны все его составляющие. В реальных задачах нет регистров, указателей и другой мутотени, связанной сугубо с реализацией. И если без этих деталей можно обойтись — то стоит их опустить, ибо к задаче они никакого отношения не имеют.
Возражение только одно — кроме SQL для БД ничего нет, ну разве что Industrial-D, который реализован в 1,5 базах
SQL это DSL в той же степени, что и ассемблер — DSL для процессоров
<troll_area>
Знание императивного программирования без функционального не имеет ценности. Нужно понимать принципы моделирования процессов, когда можно использовать разделяемое состояние, когда нет. В ином случае реализация модели превращается в бесструктурный фарш, в котором невозможно разобраться. Зачем плодить быдлокодеров?
</troll_area>
Не пойму, где вы нашли у автора «закапывание смысла»? Язык статьи предельно прозрачен и ясен, вы бы ещё у Лейбница шизофазию диагностировали после прочтения монадологии :)
Всегда удивляло, почему для создания ресурса используют POST, а для обновления — PUT, семантически логичнее использовать PUT для создания, PATCH — для обновления…
Внедрение аспекта ещё быстрее и удобнее) Что касается гибкости: если — тьфу-тьфу-тьфу — в коде нотификации обнаружиться какая либо проблема, то её можно будет исправить лишь изменив код аспекта, а не удаляя/пересоздавая массу портянок. Как писали ниже — INPC лишь пример проблемы, которую можно таким образом решить.
В общем случае любой компилируемый язык без макросов имеет максимальный предел абстракции, аспекты как раз позволяют подняться на уровень выше. Аспект INPC это тоже самое, что event, встроенный в язык — события можно реализовать и без него, но с event удобнее)
P.S. во многих функциональных языках есть mapi и это нормально)
Но не все функциональные языки заставляют так делать)
Многие инженерные (да и не только) задачи отлично описываются и решаются формализованной математикой. И совершенно логично реализовывать модель близко к тому, как она описывается. Введение же более сильных ограничений иногда полезно для того, чтобы увеличить предсказуемость алгоритма (он просто будет отбрасывать некорректные исходные данные). Я предпочитаю иметь такую возможность когда она требуется, вместе того, чтобы мучаться, имитируя эти ограничения на языке «попроще»
Если ФП удобно для решения задачи — почему его не использовать для этого?
Это я к тому, что удобство в случаях чуть менее тривиальных, чем приготовление бутерброда, начинает быть более или менее субъективной величиной.
Запросить бумаги >> подписать бумаги >> отослать бумаги
Давайте ещё матан выкинем и оставим только выч.методы.
В это утверждении фактическая ошибка. Не все процессы в мире императивны и не всегда мы думаем «берём каждую бумагу, проверяем дату и подписываем». Иногда нужно просто «подписать все бумаги». Для большого количества задач ФП не уложняет работу, а упрощает её за счёт более высоких абстракций. И возможность не усложнять эти задачи деталями реализации — это и есть KISS.
Железо императивно по своей природе, да. Но это ли повод делать языки императивными? Мне всегда кажется, что такой подход и есть ни что иное, как «человек для компьютера». Когда мне нужно проверить, что два документа равны, меня, чёрт возьми, интересует, что эквивалентны все его составляющие. В реальных задачах нет регистров, указателей и другой мутотени, связанной сугубо с реализацией. И если без этих деталей можно обойтись — то стоит их опустить, ибо к задаче они никакого отношения не имеют.
SQL это DSL в той же степени, что и ассемблер — DSL для процессоров
Знание императивного программирования без функционального не имеет ценности. Нужно понимать принципы моделирования процессов, когда можно использовать разделяемое состояние, когда нет. В ином случае реализация модели превращается в бесструктурный фарш, в котором невозможно разобраться. Зачем плодить быдлокодеров?
</troll_area>
Большое спасибо за ссылку на книжку!
В общем случае любой компилируемый язык без макросов имеет максимальный предел абстракции, аспекты как раз позволяют подняться на уровень выше. Аспект INPC это тоже самое, что event, встроенный в язык — события можно реализовать и без него, но с event удобнее)
P.S. во многих функциональных языках есть mapi и это нормально)