Сто пудов, возможность написать что-то типа
myList.view.map(f1).map(f2).sumэто прекрасно. Вместо десяти строк — одна, она легко читается, всё сразу понятно, легко чего-то добавить или поменять и так далее.
Но в других случаях попытки написать то же самое оборачиваются каким-то трындецом.
Встретилась мне, например, надобность. Есть экселевская таблица. Точнее, две таблицы, но на одном листе. Которые разные.
Надо собрать данные из обеих таблиц, преобразовать их и записать в файлы. Причём в один файл должны попасть данные из обеих таблиц — определённым образом сгруппированные и преобразованные. А в другой файл — из одной из них, но преобразованные другим способом.
Всё это вычисляется за один проход, вообще говоря, но нормальных выразительных средств для этого в функциональной парадигме нет. То есть можно оформить это в совершенно адскую свёртку, где на каждой итерации как-то там возвращаются три списка — два для одного файла, а третий — для другого. Но выглядит всё это вырвиглазно, а думать, как это записать, надо необоснованно много.
Чего-то не хватает. Должны быть для этого какие-то встроенные методы. Но их нет.
Другой пример. Неизменяемые структуры данных. В оптимистическом варианте это прекрасно: такие можно слать в трэды, не напрягаясь и не синхронизируя. И при поддержке языка это выглядит столь же коротко, сколь было бы с изменяемыми. А с учётом ненадобности синхронизаций — даже короче.
Однако структуры ведь можно вложить друг в друга. Например, в структуре «студент» может храниться тестовое задание, которое он сделал. Положим, мы завели эти структуры до экзамена. А после экзамена хотим вписать оценку за тестовое задание. С изменяемыми объектами всё очевидно
student.testWork.mark = 5
Но у нас неизменяемые структуры, поэтому хрен там.
student.copy(testWork = student.testWork.copy(mark = 5))
Если вложенность глубже, то всё будет ещё хреновее.
Для борьбы с этим есть всякие интересные объекты, называемые «линзами». Это — как бы обёртка над вот этой операцией, возвращающая всё взад — к столь же короткому стилю. И даже лучше, поскольку эти «обёртки» можно комбинировать между собой, как функции.
Однако снова чего-то не хватает: их можно реализовать, но поштучно. Хотите проставлять оценку — делаете «линзу». Хотите менять имя студента — ещё одну. Хотите дату работы — третью. И так далее.
Внутренний голос подсказывает, что это должно быть встроено в язык, но оно не встроено. Типа, ой.
В своё время, обработка исключений была столь многословной, что дело кончилось тем, что на обработку исключений все просто стали забивать. Аналогичное происходит и с «безопасными» неизменяемыми структурами: все знают, что надо бы вот так, но оно многословно, а потому ну его нахер. Сделаем с изменяемыми, а в бесконечном потом пофиксим.
С функциями — так же. Чего-то не хватает, а потому половина задач решается в «полуфункциональном» стиле. Просто потому, что людям хочется той самой простоты и понятности, которую им обещали.
doc-файл