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