Re: Стабильная система?
Vladimir Zhbanov writes: > И в нашем комьюнити (не смог подобрать здесь слова лучше) постоянно > висят крики типа "ну вас с вашим дурацким ским/лиспом, си форевер, или > накрайняк хотим питону". Есть два типа языков программирования. На которые все ругаются -- раз, которыми никто не пользуется -- два. :) Это у Вас ещё слабое противостояние. Си против лиспов не тянет совершенно: если постараетесь, заткнёте оппонентов за пояс. Дело плохо, когда какие-нибудь фанатики начинают дебаты типа "Racket vs Clojure" или "Ocaml vs Scala". В таких случаях лучше отойти в сторонку, ибо разговор неизбежно сведётся к плюсам и минусам JVM. :) > Повторюсь, я недавно начал знакомиться с Scheme. И вот, когда смотришь > "этот статический C-код"... Не, плакать не хочется... Хочется > плюнуть, и бросить всё это безнадёжное дело. Да, первое впечатление от Лиспов, оно такое. Но Вы не обольщайтесь. У нас есть куча своих проблем. Как говорил Ф. Брукс: "серебряной пули нет". signature.asc Description: PGP signature
Re: Стабильная система?
Vladimir Zhbanov -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 23:29:10 +0300: >> >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что >> >> это пережиток языков с duck typing. На практике, учитывая, что язык >> >> компилируемый, всегда можно либо добавить пару параметров и поменять все >> >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные >> >> значения, либо, что чаще, одновременно со вводом дополнительных >> >> параметров переименовать функцию, а старое имя определить как >> >> каррирование нового. >> VZ> А что если параметров десяток-два? >> >> Тогда кто-то что-то делает не так. VZ> Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в VZ> документации guile, он про графическое иксовое окошко, написанное хз на VZ> чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых. VZ> Или, например, взять тот же xrandr. Что если кто-то захочет сделать его VZ> функцией для использования в модуле для какой-то графической хрени. Я не VZ> буду приводить свои более спицфицкие примеры, но вот это -- такое VZ> использование -- неправильно? Ты считаешь, правильно делать кучу функций VZ> для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной VZ> столько-то и высотой столько-то, со всеми остальными параметрами по VZ> умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни VZ> разу не хочу спорить о том, кто должен решать размер окна, юзер или wm, VZ> это о другом, есличо.) Ну, такое я на хаскеле делаю регулярно. Это один _комплект_ параметров, под него заводится тип записи, у нее есть дефолтное значение, и ему при необходимости модифицируются поля. >> VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по >> VZ> сравнению с языками со статической типизацией, если не считать размер >> VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за >> VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь >> VZ> начать осваивать в последние пару лет) вопрос размера объектного кода >> VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно >> понял >> VZ> одного из авторов), причём работа в этом направлении идёт масштабная. >> >> Основная проблема заключается в том, что почти любая проблема выявляется >> только в рантайме. Как раз размер объектного кода чем дальше, тем >> меньше важен. А вот время на разработку... VZ> Ага, понял, спасибо. Таки ты считаешь си++ лучше лиспов в отношении VZ> времени на разработку (из-за статической типизации; не говорю про VZ> обычный си, искал, но не нашёл его в списках языков ни с динамической, VZ> ни со статической типизацией; каюсь, ленивый, смотрел только в VZ> "авторитетной" википедии)? Или сие касается только Haskel vs 'все VZ> остальные'? Говоря "почти любая", я имею в виду все-таки высокоуровневый язык с богатой системой типов. C++ слишком низкоуровневый, чтобы сравнивать его с лиспом. То есть в смысле статической проверки типов он да, лучше, но его оверхед на выражение мысли возвращает его обратно к ассемблерам :)
Re: Стабильная система?
Artem Chuprina writes: > Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 15 Oct 2015 > 21:49:30 +0300: > > >> DK> За время работы с ним меня приятно удивило после Haskell: > >> > >> DK> 1) Позволяет более просто комбинировать функциональное и императивное > >> DK> программирование: не надо изворачиваться монадами, чтобы добиться > >> DK> последовательного выполнения команд. > >> > >> ... > >> > >> а зачем, собственно, добиваться последовательного выполнения никак не > >> связанных между собой команд? > > DK> Я думаю, тут есть недоразумение. Требование последовательного выполнения > DK> определённых команд как раз и определяет связь между ними. Если конечно > DK> не считать, что связь -- это "результат А нужен для вычисления B". Тут > DK> важно понять, что императивное программирование -- это именно > DK> программирование с изменением состояния системы. > > Тогда это, натурально, связанные между собой команды. Для вычисления B > требуется состояние системы, полученное после вычисления A. > > Хаскельный компилятор просто более аккуратно подходит к вопросу > зависимости (он машина, ему внимания не жалко), и может обнаружить > независимость там, где программист ее не обнаружил, и по умолчанию > полагает, что зависимость есть. Теоретически это наверное плюс. Но мне бы реальных ситуаций. У меня такое чувство, что вполне себе может случится обратное: зависимость есть, а компилятор её не обнаружил, и решил что-нибудь соптимизировать. В этом случае мне кажется, чем тупее система -- тем лучше. > DK> Зачем это нужно? Ну, бывают разные случаи. > > DK> Бывает, что это повышает производительность. В случае большого словаря > DK> создание его дубликата при изменении значения одного ключа создаёт очень > DK> большие накладные расходы. > > Это, как я уже писал, вопрос не императивности, а мутабельности. Нам, > вообще говоря, совершенно незачем выполнять строго последовательно > изменения значений у двух разных ключей. Извините, у меня в мозгу императивность и мутабельность неразрывно связаны. Объясните, почему Вы разделяете их? Мутабельность -- это возможность объекта менять состояние. Императивность -- стиль программирования, при котором программа проходит через последовательность состояний. > Хаскель, кстати, будет делать дубликат не всего словаря, а только той > ветки, в которой поменяли значение. Для, допустим, Map это O(log n). Ну и таки да, Хаскель не будет делать дубликат словаря, ибо эти "разницы между исходной версией и данной" для него суть thunk-и, и это одно из полезных следствий ленивости. Но тут мы вроде бы занимались выяснением вопроса "почему иногда императив всё-таки нужен". > DK> Бывает, что это упрощает описание алгоритма. Например, если Вы > DK> реализуете программу, алгоритм которой описан в императивном стиле в > DK> некоторой статье, то логично пользоваться тем же представлением, что и > DK> автор. > > Ну, тут да. Тут, действительно, может выясниться, что один в один > перевести сложнонавороченный цикл на монадную схему... не то чтобы > сложно, но получается менее удобочитаемо. С другой стороны, ну, пишем > наскоро EDSL под псевдокод из статьи, и вперед. Зефиров рассказывал, > что для какой-то довольно серьезной задачи он делал императивный даже не > EDSL, а просто DSL, и транслировал его в хаскель. Ну, в принципе, создание EDSL -- это метод. Но это, как я понимаю, в основном прерогатива Lisp-ов. Там они органичны более-менее. (Хотя это смотря где ещё. Вот гигиенические макросы из Scheme на меня тоску наводят). А как в Haskell с расширением синтаксиса? > DK> Бывает, что без этого обойтись невозможно. Такое случается, когда Ваша > DK> программа должна некоторым образом взаимодействовать со внешней > DK> средой. Вот пишете Вы, допустим, сборочную систему, и Вам принципиально > DK> важно, чтобы были выполнены последовательно сначала git clone, а потом > DK> git checkout. > > Это система с изменением состояния - "не склонировано", "склонировано", > "извлечено". git checkout можно делать из состояния "склонировано", а > откуда и когда оно взялось, в этом месте неважно. А берется оно из > завершения git clone (это состояние RealWorld)... > > Система зависимостей тут как раз может гарантировать консистентность > вытащенного, потому что, если копать дальше, для выполнения git clone > надо, чтобы место было чистое - и вызывается команда приведения места в > чистое состояние... Ну, значит тут надо изменить подход к процедуре описания данных алгоритмов. Начать оперировать состояниями внешней среды. Я должен их разумеется детектировать, описывать, задать правила их вычисления, задать правила их изменения. Что ж, возможно, тут есть свои подходы. Вот об этом-то и надо бы писать в книжках. > DK> Но вот сейчас я вспомнил, чего я действительно не видел в Haskell, и что > DK> очень облегчает мне жизнь сейчас. Это опциональные аргументы при > DK> сопутствующих полноценных возможностях каррирования. > > DK> ... > > Я иногда тоже хочу параметров по умолч
Re: Стабильная система?
On Fri, Oct 16, 2015 at 10:14:10PM +0300, Dmitrii Kashin wrote: ... > > Не знаю за другие языки (и даже за другие лиспы), дюже не пробовал, но > > в guile scheme (который я пытаюсь начать осваивать в последние пару > > лет) вопрос размера объектного кода сейчас во многом решается на этапе > > прекомпиляции (если я правильно понял одного из авторов), причём > > работа в этом направлении идёт масштабная. > > Какая бы там работа не шла, проблема не в размере кода, и даже не в > производительности. Вопрос лишь в том, когда выявляются ошибки. И это > важно, если Вы намерены отдавать программу в продакшн. Ну, как говорит одна русская пословица, продакшн продакшну рознь. Я, к примеру, работаю (не смог подобрать здесь слова лучше) над одним FOSS-проектом. И в нашем комьюнити (не смог подобрать здесь слова лучше) постоянно висят крики типа "ну вас с вашим дурацким ским/лиспом, си форевер, или накрайняк хотим питону". Повторюсь, я недавно начал знакомиться с Scheme. И вот, когда смотришь "этот статический C-код"... Не, плакать не хочется... Хочется плюнуть, и бросить всё это безнадёжное дело. Но совесть не позволяет :) И да, ошибки стараемся ловить тестами, несмотря на (кашу в головах и коде). И как всё это превратить в систему, где ошибки выявляются на этапе компиляции..., я просто представить не могу. > > > ... > >> DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и > >> DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без > >> DK> ленивости. Синтаксис выразительный, но логика вычислений проще > >> поддаётся > >> DK> осмыслению, и дебаг также не вызывает трудностей. > >> > >> Мозги разные? Для меня логика вычислений на хаскеле на порядок (по > >> основанию явно больше 2, но не 10) проще для осмысления. Именно в силу > >> функциональности. Ведь императивный алгоритм - это инструкции для > > > > Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?) > > функциональные? > > Они мультипарадигменные. Позволяют писать в обоих Хорошее слово, запишу в свою книжечку... > стилях. Функциональный, само собой, поощряется.
Re: Стабильная система?
On Fri, Oct 16, 2015 at 09:43:25PM +0300, Artem Chuprina wrote: > Vladimir Zhbanov -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 > 18:51:37 +0300: > > >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что > >> это пережиток языков с duck typing. На практике, учитывая, что язык > >> компилируемый, всегда можно либо добавить пару параметров и поменять все > >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные > >> значения, либо, что чаще, одновременно со вводом дополнительных > >> параметров переименовать функцию, а старое имя определить как > >> каррирование нового. > VZ> А что если параметров десяток-два? > > Тогда кто-то что-то делает не так. Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в документации guile, он про графическое иксовое окошко, написанное хз на чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых. Или, например, взять тот же xrandr. Что если кто-то захочет сделать его функцией для использования в модуле для какой-то графической хрени. Я не буду приводить свои более спицфицкие примеры, но вот это -- такое использование -- неправильно? Ты считаешь, правильно делать кучу функций для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной столько-то и высотой столько-то, со всеми остальными параметрами по умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни разу не хочу спорить о том, кто должен решать размер окна, юзер или wm, это о другом, есличо.) > > VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по > VZ> сравнению с языками со статической типизацией, если не считать размер > VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за > VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь > VZ> начать осваивать в последние пару лет) вопрос размера объектного кода > VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял > VZ> одного из авторов), причём работа в этом направлении идёт масштабная. > > Основная проблема заключается в том, что почти любая проблема выявляется > только в рантайме. Как раз размер объектного кода чем дальше, тем > меньше важен. А вот время на разработку... Ага, понял, спасибо. Таки ты считаешь си++ лучше лиспов в отношении времени на разработку (из-за статической типизации; не говорю про обычный си, искал, но не нашёл его в списках языков ни с динамической, ни со статической типизацией; каюсь, ленивый, смотрел только в "авторитетной" википедии)? Или сие касается только Haskel vs 'все остальные'?
Re: Криптовечеринка в Москве
Dmitrii Kashin -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 22:29:09 +0300: >>> Может быть, есть желающие присоединиться, познакомиться, пообщаться? >>> Давайте обсудим! :) >> >> Я подписываюсь! DK> О, пошло дело. >> Вечер текущей пятницы уже упущен. Как насчет следующей? DK> Окей, значит, в следующую пятницу. В 19:30 удобно? Я, пожалуй, тоже подпишусь.
Re: Криптовечеринка в Москве
zhukov writes: > 15.10.2015 22:01, Dmitrii Kashin пишет: >> Может быть, есть желающие присоединиться, познакомиться, пообщаться? >> Давайте обсудим! :) > > Я подписываюсь! О, пошло дело. > Вечер текущей пятницы уже упущен. Как насчет следующей? Окей, значит, в следующую пятницу. В 19:30 удобно? > Дмитрий, давай как организатор (зачинщик) Первой Московской Бутырской > KSP, заводи мероприятие на biglumber.com. Вау, какие оказывается ресурсы существуют. Сейчас сделаю. :) signature.asc Description: PGP signature
Re: Стабильная система?
Vladimir Zhbanov writes: > On Fri, Oct 16, 2015 at 01:33:51AM +0300, Artem Chuprina wrote: > > И, прошу прощения за невежество, что в языках с duck typing хуже по > сравнению с языками со статической типизацией, если не считать размер > объектного кода из-за проверок типа? Ну, тут есть много мнений, но самое существенное -- возможность выявить проблему во время компиляции, а не в рантайме. Это, кстати, палка о двух концах. Для прототипирования удобнее использовать языки не строго типизированные, потому что Вы потратите меньше времени на то, чтобы "договориться" с компилятором о том, какие типы уместны при вызове данной функции. Но тогда надо иметь в виду, что всякие граничные случаи могут давать ошибки. И тогда на сцену выходит статическая типизация, которая просто не даст проекту скомпилироваться, если Вы в каком-то месте пытаетесь подсунуть в функцию значение несоответствующего типа. > Не знаю за другие языки (и даже за другие лиспы), дюже не пробовал, но > в guile scheme (который я пытаюсь начать осваивать в последние пару > лет) вопрос размера объектного кода сейчас во многом решается на этапе > прекомпиляции (если я правильно понял одного из авторов), причём > работа в этом направлении идёт масштабная. Какая бы там работа не шла, проблема не в размере кода, и даже не в производительности. Вопрос лишь в том, когда выявляются ошибки. И это важно, если Вы намерены отдавать программу в продакшн. > ... >> DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и >> DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без >> DK> ленивости. Синтаксис выразительный, но логика вычислений проще поддаётся >> DK> осмыслению, и дебаг также не вызывает трудностей. >> >> Мозги разные? Для меня логика вычислений на хаскеле на порядок (по >> основанию явно больше 2, но не 10) проще для осмысления. Именно в силу >> функциональности. Ведь императивный алгоритм - это инструкции для > > Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?) > функциональные? Они мультипарадигменные. Позволяют писать в обоих стилях. Функциональный, само собой, поощряется. signature.asc Description: PGP signature
Re: Криптовечеринка в Москве
15.10.2015 22:01, Dmitrii Kashin пишет: > Может быть, есть желающие присоединиться, познакомиться, пообщаться? > Давайте обсудим! :) Я подписываюсь! Вечер текущей пятницы уже упущен. Как насчет следующей? Дмитрий, давай как организатор (зачинщик) Первой Московской Бутырской KSP, заводи мероприятие на biglumber.com. -- С уважением, Konstantin A Zhuravlev aka ZhuKoV
Re: Стабильная система?
Vladimir Zhbanov -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 18:51:37 +0300: >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что >> это пережиток языков с duck typing. На практике, учитывая, что язык >> компилируемый, всегда можно либо добавить пару параметров и поменять все >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные >> значения, либо, что чаще, одновременно со вводом дополнительных >> параметров переименовать функцию, а старое имя определить как >> каррирование нового. VZ> А что если параметров десяток-два? Тогда кто-то что-то делает не так. VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по VZ> сравнению с языками со статической типизацией, если не считать размер VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь VZ> начать осваивать в последние пару лет) вопрос размера объектного кода VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял VZ> одного из авторов), причём работа в этом направлении идёт масштабная. Основная проблема заключается в том, что почти любая проблема выявляется только в рантайме. Как раз размер объектного кода чем дальше, тем меньше важен. А вот время на разработку... >> DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и >> DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без >> DK> ленивости. Синтаксис выразительный, но логика вычислений проще >> поддаётся >> DK> осмыслению, и дебаг также не вызывает трудностей. >> >> Мозги разные? Для меня логика вычислений на хаскеле на порядок (по >> основанию явно больше 2, но не 10) проще для осмысления. Именно в силу >> функциональности. Ведь императивный алгоритм - это инструкции для VZ> Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?) VZ> функциональные? В контексте - нет. В смысле, контекст дискуссии - что они позволяют прямее, чем хаскель, выражать императивный стиль, и в таковом качестве DK их использует.
Re: Стабильная система?
On Fri, Oct 16, 2015 at 01:33:51AM +0300, Artem Chuprina wrote: ... > Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что > это пережиток языков с duck typing. На практике, учитывая, что язык > компилируемый, всегда можно либо добавить пару параметров и поменять все > (найденные компилятором) вхождения вызовов, добавив туда дефолтные > значения, либо, что чаще, одновременно со вводом дополнительных > параметров переименовать функцию, а старое имя определить как > каррирование нового. А что если параметров десяток-два? И, прошу прощения за невежество, что в языках с duck typing хуже по сравнению с языками со статической типизацией, если не считать размер объектного кода из-за проверок типа? Не знаю за другие языки (и даже за другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь начать осваивать в последние пару лет) вопрос размера объектного кода сейчас во многом решается на этапе прекомпиляции (если я правильно понял одного из авторов), причём работа в этом направлении идёт масштабная. ... > DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и > DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без > DK> ленивости. Синтаксис выразительный, но логика вычислений проще поддаётся > DK> осмыслению, и дебаг также не вызывает трудностей. > > Мозги разные? Для меня логика вычислений на хаскеле на порядок (по > основанию явно больше 2, но не 10) проще для осмысления. Именно в силу > функциональности. Ведь императивный алгоритм - это инструкции для Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?) функциональные?
Re: Стабильная система?
Артём Н. -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 16:04:15 +0300: АН> Хосспади, OCaml... o.O АН> Может, когда требуется "большой кусок в императивном стиле", АН> следует отказаться от использования функционального языка в сторону императивного? АН> Или религия не позволяет? ;-) А смысл, если есть язык, который это позволяет прямо тут? Ocaml, насколько я понимаю, ничем не плох. 1) Позволяет более просто комбинировать функциональное и императивное программирование: не надо изворачиваться монадами, чтобы добиться последовательного выполнения команд. >>> Но зачем? >> >> "This is no matter of religion or esthetics; a priori neither style is >> prettier or holier than the other. On the contrary, one style may be >> more adequate than the other depending on the problem to be solved. >> >> The first rule to apply is the rule of simplicity. Whether the algorithm >> to use implemented is written in a book, or whether its seed is in the >> mind of the programmer, the algorithm is itself described in a certain >> style. It is natural to use the same style when implementing it. >> >> The second criterion of choice is the efficiency of the program. One may >> say that an imperative program (if well written) is more efficient that >> its functional analogue, but in very many cases the difference is not >> enough to justify complicating the code to adopt an imperative style >> where the functional style would be natural". [1] >> >> Бывает, что императивное программирование разумнее. Большинство >> алгоритмов можно писать в функциональном стиле, но бывает и так, что это >> порождает большой оверхед в производительности. При столкновении с >> подобным "узким горлом" приходится реализовывать часть функционала в >> императивном стиле. Например, управление большими словарями много >> выгоднее, если они мутабельны. >> >> [1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html >>
Re: Криптовечеринка в Москве
On 15.10.2015 22:01, Dmitrii Kashin wrote: Собственно, а почему бы нам не организовать небольшое мероприятие? Я бы предложил посидеть в Брудере на Бутырской (ст. м. Савёловская)[1], можно хорошо покушать, выпить пива/чаю, ну и конечно же, подписать друг другу ключи. В Москве сейчас живу и работаю. Короче, всегда готов. Думаю, вечер пятницы -- очень хорошее время. Какой именно, сейчас и разберёмся. Может быть, есть желающие присоединиться, познакомиться, пообщаться? Давайте обсудим! :) [1] http://butirskaya.beerbruder.ru/gallery/ Ключа нет и вроде не особо нужен, пока что. Но пожрать я не против. :-) В Москву переезжаю через неделю-две. P.S.: Подписать ключи "на Бутырской", навевает интересные ассоциации. ;-)
Re: Стабильная система?
Хосспади, OCaml... o.O Может, когда требуется "большой кусок в императивном стиле", следует отказаться от использования функционального языка в сторону императивного? Или религия не позволяет? ;-) On 15.10.2015 21:02, Dmitrii Kashin wrote: 1) Позволяет более просто комбинировать функциональное и императивное программирование: не надо изворачиваться монадами, чтобы добиться последовательного выполнения команд. Но зачем? "This is no matter of religion or esthetics; a priori neither style is prettier or holier than the other. On the contrary, one style may be more adequate than the other depending on the problem to be solved. The first rule to apply is the rule of simplicity. Whether the algorithm to use implemented is written in a book, or whether its seed is in the mind of the programmer, the algorithm is itself described in a certain style. It is natural to use the same style when implementing it. The second criterion of choice is the efficiency of the program. One may say that an imperative program (if well written) is more efficient that its functional analogue, but in very many cases the difference is not enough to justify complicating the code to adopt an imperative style where the functional style would be natural". [1] Бывает, что императивное программирование разумнее. Большинство алгоритмов можно писать в функциональном стиле, но бывает и так, что это порождает большой оверхед в производительности. При столкновении с подобным "узким горлом" приходится реализовывать часть функционала в императивном стиле. Например, управление большими словарями много выгоднее, если они мутабельны. [1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html
