Статья, на мой взгляд—в первую очередь попытка рефлексии на тему того, почему же ФП непопулярно. Потому что по объективным критериям функциональные языки, действительно, совсем не популярны. Хотя, как и написано во вступлении, считается, что у них куча преимуществ. Действительно, и следить за состоянием легко, и параллелить как бы легко, и математически красивые и т.п. Но на них никто не пишет. Взять, к примеру, TIOBE index (конечно, он не совершенен, но хоть какой-то). В первой двадцатке нет ни одного функционального языка. И идея автора показалась мне очень хорошей, и пример с пирогом метким. Да, действительно, судя по всему, функциональные языки просто слишком далеки (i) от моделей реального мира, (ii) от моделей задач, что появляются в головах программистов, и (iii) от того, как работает компьютер. Что изменяемое состояние—это то, что близко реальному миру, человеку, компьютеру.
У таких статей есть непосредственная польза. Они могут помочь честнее взглянуть на ФП. Потому что многие функциональные языки описывают себя как очень хорошие и даже популярные, а на самом деле писать на них в итоге почему-то неудобно (и никто не пишет). Вот, к примеру, очень хорошая и глубокая критика языка и «маркетинговой кампании» Haskell. В этом же блоге есть свежая предметная статья с критикой чистого ФП. Такая критика и понимание проблем могут помочь сэкономить много денег компаниям, потому что они не начнут проекты на Хаскеле, к примеру. Помогут исследователям сконцентрироваться на важных аспектах этих языков и т.п. Помогут лучше учить программирование в университатах, опять же.
Вот наглядный пример. Оказалось, что в одном немецком университете есть специальная программа (типа магистерской) на факультете информатики для людей с не-ИТ образованием, где их учат программированию и информатике. И вот знакомая биолог начала по ней учиться (как раз месяц назад). И что бы вы думали? Их начинают учить с диалекта Lisp (ну, то есть, самый базовый вводный курс—на диалекте лисп). И на мой взгляд, это совершенно лишняя трата времени преподавателей и студентов (и трата налогов).
Так что я с вашим комментарием не согласен. Попытки понять, есть ли что-то неестественное в ФП и почему, имеют большой смысл. Точнее, понять, почему ФП неествественное (ведь оно совсем непопулярно) и предупредить об этом тех, кто сомневается или в неведении.
P.S. Я не спорю с тем, что какие-то общие и частные идеи из ФП, безусловно, полезны. Стараться писать чистые фунции, не изменять лишний раз состояние. Pattern matching, опять же. Но _иногда_ нарушить правила ФП намного удобнее и лучше, чем пытаться не нарушать. Стандартный пример—циклы. Писать их через рекурсию—мука. Как только у вас будет массив (список!) NumberState, с которыми надо что-то сделать в чистом ФП—все, пиши пропало. А если еще и операций будет несколько, тоже в списке…
P.P.S. Наконец, в статье не сравнивается ФП и ООП, а скорее ФП и императивное программирование.
Ну, я перевел ее скорее из-за примера с пирогом, потому что он показался мне очень точным (и веселым, и доступным). В том смысле, что функциональные языки, действительно, пожалуй, далеки и от тех моделей задач и реального мира, что в голове у программиста при написании программы, и от того, как работает компьютер.
На суперкомпьютерах обычно поддерживаются только три компилятора: С, С++ и Fortran. Параллельность—за счет Message Passing Interface плюс OpenMP. Так что там, по крайней мере, функциональное программирование точно не цветет.
Так надо же с C++ сравнивать, а не с C++ .Net. Конечно, с другим—таким же медленным— .Net языком сравнение будет хорошим. Там была, скорее всего, та же самая garbage collection, в первую очередь.
Нужно заметить, что начиная со страницы 411 идет описание стандартной библиотеки, а потом аппендикс. Так что стандарт для синтаксиса—410 страниц. Для сравнения: у C# образца 2006 года, например, и того больше—443 страницы до аппендиксов (классы .Net в документе не описываются, разумеется—это только Language specification).
Справедливости ради, гугол купил компанию, которая этим занималась задолго до покупки. Так что гугол к этому достижению отношения, в общем, не имеет. Кроме того, авторы ж не сами все алгоритмы с нуля придумали. Они, безусловно, молодцы, но это (как обычно) последний шаг долгого пути. Вот у них и научная статья есть, и там много ссылок на предшественников. Вот ее бесплатная версия.
Ну вот мне, например, не нравится исходный и ваш комментарии. Раст пока не очень производительный по сравнению с С, если посмотреть на бенчмарки. И, мне начинает казаться, никогда таким не станет. Хотя бы из-за проверок на выход за границы массива, которые никак не отключить (если я не ошибаюсь). И, например, в числодробилках (а ля научных приложениях), где таких проверок будет очень много, я предпочту все еще С/С++, хотя раст мне поначалу даже нравился. Плюс язык не выглядит уже намного проще С++. Писать на нем, как оказалось, не настолько и удобно. Как оказалось, опять же, иногда unsafe code может быть необходим (да, связный список), хотя вначале разработчиками как бы заявлялось, что любую программу в принципе можно написать без unsafe.
Сразу по градиентам, мне кажется, можно это сделать. Начинаем watershed из локального минимума длин градиентов, потом расползаемся до линии локальных максимумов градиента. Картинка наверху вот этой страницы намекает, что так работает (как минимум одна) библиотека для ImageJ.
Ну как минимум у вас есть возможность подставлять в шаблонные параметры (класса или пусть и функции) не функцию за функцией, а группы функций (классы), что уменьшает число шаблонных параметров на порядок. Ну и в целом это метод борьбы со сложностью. Можно сгруппировать функции семантически; данные, интересные нескольким функциям, можно добавить в класс. Какие-то поля сделать приватными, чтоб никто их больше не видел и вы точно знали, что за пределами класса о них думать не надо. Делегировать что-то другому классу (конечно, можно делегировать просто разным функциям, но так у вас близкие функции уже сгруппированы, и понять делегирование намного проще). Или, к примеру, если у вас даже с классами шаблонных параметров функции или класса много, вы можете группировать какие-то из них в классы дальше. Приватные поля для кеширования сразу легко вводить и т.п. Короче, все, что пишут в книжках по ООП.
О, это просто. Вот посмотрите, к примеру, на диаграмму классов уже упомянутого проекта с lattice-boltzmann method. Дело в возможности включать разную физику и численные методы. Можно обходить 15 ближайших узлов, можно 19, можно 27. Можно использовать разные разностные схемы. Можно моделировать однофазный поток, можно многофазный. Если многофазный, то с есть разные методы его моделирования (даже в рамках этого численного метода). Можно включать турбулентность, можно выключать. Можно использовать разные геометрии и граничные условия. В параллельном случае можно использовать разные топологии связей. И т.п. И так у вас набегает 2986 классов, хотя программа все еще, по сути, это вложенные четыре цикла с парой сложений и умножений внутри. К счастью, все комбинации классов обычно можно разрешать статически, поэтому можно обойтись статическим полиморфизмом.
Ну вот в числодробилках всяких типа моделирования гидродинамики ООП до сих пор считается медленным. Я видел проект, в котором все было сделано через шаблоны, не было ни одной виртуальной функции. Легко прикинуть. К примеру, у вас система из дискретной равномерной сетки, N*M*L узлов, на каждой итерации надо обработать каждый узел, всего I итераций. В простейшем случае состояние узла на следующей итерации зависит от состояния его ближайших соседей (и его самого) на предыдущей итерации, положим 27 штук соседей ( включая сам узел). Итого получается вложенный цикл из 27*N*M*L*I итераций. Каждое из этих чисел N,M,L,I легко может быть порядка 1000 или 10000 (и это еще очень скромно). Итого 10^13-10^17 итераций. Если у вас в цикле будут вызовы виртуальных функций, то, скорее всего, вы это заметите. Конечно, зависит от того, что еще считается в цикле. В алгоритме, который я пробовал и имею в виду, добавление модного слоя абстракции в этом вложенном цикле на некоторые сущности через динамический полиморфизм сразу стоило 20% времени выполнения.
Занимательный факт. Изначально планировалось, что телескоп Джеймса Уэбба будет запущен в 2007 году и будет стоить 0,5 млрд долларов, теперь планируют, что он будет запущен в 2018 и окончательная цена окажется 8,8 млрд долларов.
Но в любом случае, после фразы «В Visual Studio выдает «not null» при запуске вне студии выдает «null».» я ожидал самого интересного, а вы уже закончили статью. Даже если бы TestWeakRef был правильным, хотелось бы прочитать больше, с документацией GC, Unity, с объяснением, почему в Visual Studio не падает и т.п.
У вас либо опечатка в TestWeakRef, либо, в общем-то, он и должен падать: вы пишете «var wa = new WeakReference(new A());», а должно было бы быть, по логике, «var wa = new WeakReference(sa);». То, что после GC удаляется объект «new A()», на который есть только слабая ссылка, вполне нормально, как я понимаю. Не уверен, как это соотносится с вашей исходной проблемой. [Edit: а мне надо обновлять комментарии перед отправкой своего]
У таких статей есть непосредственная польза. Они могут помочь честнее взглянуть на ФП. Потому что многие функциональные языки описывают себя как очень хорошие и даже популярные, а на самом деле писать на них в итоге почему-то неудобно (и никто не пишет). Вот, к примеру, очень хорошая и глубокая критика языка и «маркетинговой кампании» Haskell. В этом же блоге есть свежая предметная статья с критикой чистого ФП. Такая критика и понимание проблем могут помочь сэкономить много денег компаниям, потому что они не начнут проекты на Хаскеле, к примеру. Помогут исследователям сконцентрироваться на важных аспектах этих языков и т.п. Помогут лучше учить программирование в университатах, опять же.
Вот наглядный пример. Оказалось, что в одном немецком университете есть специальная программа (типа магистерской) на факультете информатики для людей с не-ИТ образованием, где их учат программированию и информатике. И вот знакомая биолог начала по ней учиться (как раз месяц назад). И что бы вы думали? Их начинают учить с диалекта Lisp (ну, то есть, самый базовый вводный курс—на диалекте лисп). И на мой взгляд, это совершенно лишняя трата времени преподавателей и студентов (и трата налогов).
Так что я с вашим комментарием не согласен. Попытки понять, есть ли что-то неестественное в ФП и почему, имеют большой смысл. Точнее, понять, почему ФП неествественное (ведь оно совсем непопулярно) и предупредить об этом тех, кто сомневается или в неведении.
P.S. Я не спорю с тем, что какие-то общие и частные идеи из ФП, безусловно, полезны. Стараться писать чистые фунции, не изменять лишний раз состояние. Pattern matching, опять же. Но _иногда_ нарушить правила ФП намного удобнее и лучше, чем пытаться не нарушать. Стандартный пример—циклы. Писать их через рекурсию—мука. Как только у вас будет массив (список!) NumberState, с которыми надо что-то сделать в чистом ФП—все, пиши пропало. А если еще и операций будет несколько, тоже в списке…
P.P.S. Наконец, в статье не сравнивается ФП и ООП, а скорее ФП и императивное программирование.