Lex Kravetski (lex_kravetski) wrote,
Lex Kravetski
lex_kravetski

Categories:

Полуфункциональность

Сколь прекрасны некоторые решения в функциональном стиле, столь же чудовищны некоторые другие.

Сто пудов, возможность написать что-то типа

myList.view.map(f1).map(f2).sum


это прекрасно. Вместо десяти строк — одна, она легко читается, всё сразу понятно, легко чего-то добавить или поменять и так далее.

Но в других случаях попытки написать то же самое оборачиваются каким-то трындецом.

Встретилась мне, например, надобность. Есть экселевская таблица. Точнее, две таблицы, но на одном листе. Которые разные.

Надо собрать данные из обеих таблиц, преобразовать их и записать в файлы. Причём в один файл должны попасть данные из обеих таблиц — определённым образом сгруппированные и преобразованные. А в другой файл — из одной из них, но преобразованные другим способом.

Всё это вычисляется за один проход, вообще говоря, но нормальных выразительных средств для этого в функциональной парадигме нет. То есть можно оформить это в совершенно адскую свёртку, где на каждой итерации как-то там возвращаются три списка — два для одного файла, а третий — для другого. Но выглядит всё это вырвиглазно, а думать, как это записать, надо необоснованно много.

Чего-то не хватает. Должны быть для этого какие-то встроенные методы. Но их нет.

Другой пример. Неизменяемые структуры данных. В оптимистическом варианте это прекрасно: такие можно слать в трэды, не напрягаясь и не синхронизируя. И при поддержке языка это выглядит столь же коротко, сколь было бы с изменяемыми. А с учётом ненадобности синхронизаций — даже короче.

Однако структуры ведь можно вложить друг в друга. Например, в структуре «студент» может храниться тестовое задание, которое он сделал. Положим, мы завели эти структуры до экзамена. А после экзамена хотим вписать оценку за тестовое задание. С изменяемыми объектами всё очевидно

student.testWork.mark = 5


Но у нас неизменяемые структуры, поэтому хрен там.

student.copy(testWork = student.testWork.copy(mark = 5))


Если вложенность глубже, то всё будет ещё хреновее.

Для борьбы с этим есть всякие интересные объекты, называемые «линзами». Это — как бы обёртка над вот этой операцией, возвращающая всё взад — к столь же короткому стилю. И даже лучше, поскольку эти «обёртки» можно комбинировать между собой, как функции.

Однако снова чего-то не хватает: их можно реализовать, но поштучно. Хотите проставлять оценку — делаете «линзу». Хотите менять имя студента — ещё одну. Хотите дату работы — третью. И так далее.

Внутренний голос подсказывает, что это должно быть встроено в язык, но оно не встроено. Типа, ой.

В своё время, обработка исключений была столь многословной, что дело кончилось тем, что на обработку исключений все просто стали забивать. Аналогичное происходит и с «безопасными» неизменяемыми структурами: все знают, что надо бы вот так, но оно многословно, а потому ну его нахер. Сделаем с изменяемыми, а в бесконечном потом пофиксим.

С функциями — так же. Чего-то не хватает, а потому половина задач решается в «полуфункциональном» стиле. Просто потому, что людям хочется той самой простоты и понятности, которую им обещали.



doc-файл

Tags: программирование, философия
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 40 comments