Два неправильных пункта.
Приведу пункты полностью: Во-первых, не секрет, что императивные языки гораздо богаче оснащены библиотеками и всяким вспомогательным инструментарием. С учётом того, что в нынешнем программировании в среднем примерно 10% кода уходит на оригинальный алгоритм, а 90% - на возню с различными API и преобразование структур данных, эти преимущества являются весьма существенными. Если бы я перешёл на ФП - это бы снизило мою продуктивность. Да, у ФП есть существенные достоинства, типа математической верифицируемости кода - но ради этого придётся отказываться от слишком многих удобств.
Во-вторых, императивное программирование кажется мне гораздо более доступным интуитивно. Человеческий мозг, как я понимаю, уже сам по себе натренирован разворачивать постановку задачи в виде некоторой цели в последовательность простых шагов. Мыслить в терминах ФП - значит плыть против течения, анализировать структуру задачи самому, а не пользоваться для этого врождёнными навыками мозга.
Это был ответ на вопрос, почему yk4ever разынтересовался в ФП.
Мне в этих пунктах не нравится практически ничего.
Начну с соотношения 10/90. Как известно, 90% кода программы требует для своего написания 90% времени. А оставшиеся 10% кода требуют оставшихся 90% процентов времени. Эти 10% процентов нового кода и есть то самое сложное, ради чего и пишут новые программы. Хорошо бы потратить на эту одну десятую поменьше времени, не 90, а хотя бы 45 процентов. Поскольку при этом мы вторгаемся в неизученную область (скорее всего, либо автор никогда не делал ничего похожего, либо никто в мире такого не делал), то надо пользоваться чем только можно для сокращения своего собственного труда.
Я достаточно давно заметил, что современные API предоставляют кучу возможностей для прикладных программ. Например, с помощью API именованных каналов (named pipes) OS/2 можно было запустить шаттл с навигационным спутником. Когда я внимательно и достаточно полно изучил это API, я понял, что для моей работы оно 1) избыточно и 2) сложно в использовании. Плюс, непереносимо. После чего урезал до невозможности и сформулировал для себя правило, что практически любое API вне POSIX libc я должен вложить в обертку, за которой можно скрыть пару-троечку аналогичных по функциональности реализаций из разных систем. Большая часть любого API не представляет важности для цели прикладной программы. Её просто необходимо скрыть, чтобы не думать о ней вообще. Сделать что-то применимое точно по мерке программы, не более, но и не менее.
После чего наслаждаться жизнью со своим собственным, удобным (например, с удобно скрытым состоянием), небольшим и понимаемым API.
Если это не сделать, будет беда. Чуть раньше, чуть позже, чуть больше, чуть меньше, но будет.
Теперь про мышление.
Мышление человека заточено под решение простых проблем. Чем меньше зависящих друг от друга сущностей, тем лучше, тем больше проблем в единицу времени мы сможем решить, разбив их на более мелкие. Поэтому желательно сокращать количество сущностей и зависимостей между ними. В принципе, неважно, как это сделать, вышеприведенное соображение насчет своего собственного API как раз направлено на это сокращение.
Вот теперь можно и про ФП.
Как известно, машина Тьюринга, предтеча всех современных компьютеров, моделирует вычисления человека с карандашиком, бумагой и ластиком. А лямбда-исчисление моделирует вычисления человека с карандашиком и бумагой. Сущностей ровно на одну меньше.
Ну, и резюмируя: любая хорошая практика в программировании направлена на экономию сущностей. ФП в этом смысле ничем не отличается от любой другой практики.
Во-вторых, императивное программирование кажется мне гораздо более доступным интуитивно. Человеческий мозг, как я понимаю, уже сам по себе натренирован разворачивать постановку задачи в виде некоторой цели в последовательность простых шагов. Мыслить в терминах ФП - значит плыть против течения, анализировать структуру задачи самому, а не пользоваться для этого врождёнными навыками мозга.
Это был ответ на вопрос, почему yk4ever разынтересовался в ФП.
Мне в этих пунктах не нравится практически ничего.
Начну с соотношения 10/90. Как известно, 90% кода программы требует для своего написания 90% времени. А оставшиеся 10% кода требуют оставшихся 90% процентов времени. Эти 10% процентов нового кода и есть то самое сложное, ради чего и пишут новые программы. Хорошо бы потратить на эту одну десятую поменьше времени, не 90, а хотя бы 45 процентов. Поскольку при этом мы вторгаемся в неизученную область (скорее всего, либо автор никогда не делал ничего похожего, либо никто в мире такого не делал), то надо пользоваться чем только можно для сокращения своего собственного труда.
Я достаточно давно заметил, что современные API предоставляют кучу возможностей для прикладных программ. Например, с помощью API именованных каналов (named pipes) OS/2 можно было запустить шаттл с навигационным спутником. Когда я внимательно и достаточно полно изучил это API, я понял, что для моей работы оно 1) избыточно и 2) сложно в использовании. Плюс, непереносимо. После чего урезал до невозможности и сформулировал для себя правило, что практически любое API вне POSIX libc я должен вложить в обертку, за которой можно скрыть пару-троечку аналогичных по функциональности реализаций из разных систем. Большая часть любого API не представляет важности для цели прикладной программы. Её просто необходимо скрыть, чтобы не думать о ней вообще. Сделать что-то применимое точно по мерке программы, не более, но и не менее.
После чего наслаждаться жизнью со своим собственным, удобным (например, с удобно скрытым состоянием), небольшим и понимаемым API.
Если это не сделать, будет беда. Чуть раньше, чуть позже, чуть больше, чуть меньше, но будет.
Теперь про мышление.
Мышление человека заточено под решение простых проблем. Чем меньше зависящих друг от друга сущностей, тем лучше, тем больше проблем в единицу времени мы сможем решить, разбив их на более мелкие. Поэтому желательно сокращать количество сущностей и зависимостей между ними. В принципе, неважно, как это сделать, вышеприведенное соображение насчет своего собственного API как раз направлено на это сокращение.
Вот теперь можно и про ФП.
Как известно, машина Тьюринга, предтеча всех современных компьютеров, моделирует вычисления человека с карандашиком, бумагой и ластиком. А лямбда-исчисление моделирует вычисления человека с карандашиком и бумагой. Сущностей ровно на одну меньше.
Ну, и резюмируя: любая хорошая практика в программировании направлена на экономию сущностей. ФП в этом смысле ничем не отличается от любой другой практики.