понедельник, 13 июня 2016 г.

[prog.flame] Любопытная заметка "Disadvantages of purely functional programming"

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

Имхо, статейка Disadvantages of purely functional programming как раз в эту же тему. Суть -- чистое ФП классная штука, конечно. Но тормозит. И, в принципе, в определенных местах не может не тормозить.

Отдельно отметил бы ссылочку, которая есть в этой статье: Naive parallelism with HLVM. Особенно мне понравились пути повышения производительности HLVM-программы: Disabling bounds checking provides a substantial 20% performance improvement. Disabling the shadow stack (and, therefore, disabling GC) provides another 25% performance improvement. With these two changes, HLVM is only 24% slower than C++. Ну, т.е., берем язык более высокого уровня, чем C++, и гораздо более безопасный, чем C++, а потом отключаем нафиг те фичи, которые как раз и делают его более высокоуровневым и более безопасным. И все только для того, чтобы не тормозить так сильно.

Ну и вообще, как мне кажется, в последние год-полтора прослеживается интересная тенденция: если раньше во главу угла ставилась скорость разработки и на передний план выходили безопасные языки программирования (причем даже не Java, а всякие Python-ы, Ruby, Erlang-и, Scala, Clojure и прочие OCaml-ы с Haskell-ями), то теперь просто скорости разработки мало. Нужно еще, чтобы результат работал быстро и/или жрал мало. Отсюда и интерес к тому же Go, который позволяет писать что-то так же быстро, как и на Python-е, но работает затем это что-то намного эффективнее, чем на Python-е. И возродившийся интерес к старой ламповой сишечке (а так же вспыхивающие вновь споры C vs C++). И пристальное внимание к Rust-у и Nim-у...

Объяснение сей тенденции я вижу в том, что делать быстро на Python-е (Ruby, Erlang, Scala, Clojure,...) теперь могут практически все. И одним из важнейших факторов становится снижение издержек на эксплуатацию. Для чего нужны не только быстро выходящие на рынок решения, но еще и эффективно работающие. А вот это умеют делать пока не только лишь все :)

PS. Кстати говоря, то, что все стараются друг другу что-то продать (кто-то "продает" Haskell, кто-то "продает" Clojure, я, например, "продаю" SObjectizer) -- это нормально. Правильно сделанная "покупка" сильно облегчает жизнь. Однако, важно понимать, что в процессе "продажи" мало кто будет на 100% откровенен и будет честно и по собственной воле рассказывать не только о достоинствах, но и недостатках. Так что никому нельзя верить. Мне можно ;)

PPS. Прошу воспринимать написанный выше текст с изрядной долей юмора и иронии.

Комментариев нет: