1. Куча / Говнокод #10331

    +124

    1. 1
    f = (((.) flip) . (((flip (.)) flip) . ((.) . (.))))

    Для тех кто не смог догадаться это {spoiler} f x1 x2 x3 x4 = x1 (x2 x3 x4) {/spoiler}

    Запостил: HaskellGovno, 20 Мая 2012

    Комментарии (112) RSS

    • Хотя лично мне нравится вот такой код больше:
      f=(.).(.)
      Ответить
    • HaskellGovno доказал что он может в point-free?
      Ответить
      • Немного поразмял моск:
        f = (((.) flip) . (((flip (.)) flip) . ((.) . (.))))
        
        (.) f g = \x -> f (g x)
        ((.) . (.)) = (\f g x -> f (g x)) (\f1 g1 x1 -> f1 (g1 x1)) (\f2 g2 x2 -> f2 (g2 x2)) =
            \x -> (\f1 g1 x1 -> f1 (g1 x1)) ((\f2 g2 x2 -> f2 (g2 x2)) x) =
            \x -> (\f1 g1 x1 -> f1 (g1 x1)) (\g2 x2 -> x (g2 x2)) =
            \x -> (\g1 x1 -> (\g2 x2 -> x (g2 x2)) (g1 x1)) =
            \x -> (\g1 x1 -> (\x2 -> x (g1 x1 x2))) =
            \x g1 x1 x2 -> x (g1 x1 x2)
        
        flip f = \x y -> f y x
        flip (.) = \x y -> (.) y x = \x y -> (\x1 -> y (x x1)) = \x y x1 -> y (x x1)
        (flip (.)) flip = \y x1 -> y (flip x1) = \y x1 -> y (\x y -> x1 y x)
        
        ((flip (.)) flip) . ((.) . (.)) = \x -> ((flip (.)) flip) (((.) . (.)) x) =
            \x -> (\y x1 -> y (\x2 y -> x1 y x2)) ((\x3 g1 x4 x5 -> x3 (g1 x4 x5)) x) =
            \x -> (\y x1 -> y (\x y -> x1 y x)) (\g1 x4 x5 -> x (g1 x4 x5)) =
            \x x1 -> (\g1 x4 x5 -> x (g1 x4 x5)) (\x y -> x1 y x) =
            \x x1 x4 x5 -> x ((\x y -> x1 y x) x4 x5) =
            \x x1 x4 x5 -> x (x1 x5 x4)
        
        (.) flip = \g x -> flip (g x) = \g x -> (\x1 y1 -> (g x) y1 x1) =
            \g x x1 y1 -> g x y1 x1
        
        f = \x -> (\g x6 x1 y1 -> g x6 y1 x1) ((\x2 x3 x4 x5 -> x2 (x3 x5 x4)) x) =
            \x -> (\g x6 x1 y1 -> g x6 y1 x1) (\x3 x4 x5 -> x (x3 x5 x4)) =
            \x -> (\x6 x1 y1 -> (\x3 x4 x5 -> x (x3 x5 x4)) x6 y1 x1)
            \x -> (\x6 x1 y1 -> x (x6 x1 y1)) =
            \x x6 x1 y1 -> x (x6 x1 y1)


        f a b c d = a (b c d) ч.т.д.
        Ответить
        • > (.) f g = \x -> f (g x)

          А нахуй тут в синтаксис воткнули обратный слэш?
          Ответить
          • так лямбды обозначают
            Ответить
          • Эм, ну можно и (.) f g x = f (g x) если \ не нравится.
            Ответить
          • Похоже на λ из лямбда-исчисления.
            Ответить
            • Ага. Ну и не писать же в языке, который состоит из лямбд чуть более, чем полностью, function или lambda.
              Ответить
            • А что изменится, если написать просто
              (.) f g = x -> f (g x)
              Ответить
              • Будет синтаксическая ошибка.
                Ответить
                • Если из синтаксиса убрать слэш, то что изменится?
                  Ответить
                  • Будет не так удобно.
                    Ответить
                  • подозреваю, сложно будет визуально отличить частичное применение от нескольких аргументов функции:
                    f ... =   x y z -> g x y z -- применение x к аргументам... ой, лямбда
                    f ... = \ x y z -> g x y z -- лямбда
                    Возможно, там ещё какие-то конфликты в синтаксисе могли бы возникнуть
                    Ответить
                    • Короче понятно, захотели выебнуться и убрать скобочки и вот
                      Ответить
                  • Парсить же сложно становится: не понятно выражение ли надо кушать или сопоставление по образцу. В тяжелом случае - нужно откатываться далеко назад.
                    Ответить
                    • Но использовать \ в таком контексте у меня тоже вызывает идиосинказию, ocaml-ый fun x -> ... больше по душе.
                      Ответить
                      • тьфу, s/нка/нкра
                        Ответить
                      • Мне люто доставляет слово fun в ocaml, erlang, а теперь ещё и в kotlin (правда там они используются как defun, а не для анонимных функций)
                        Да, функции - это очень весело
                        Ответить
                        • Да, а defun звучит печально.
                          Ответить
                          • да, я тоже об этом думал :)
                            в clojure решили не играть на чувствах, и используют defn и fn
                            Ответить
                            • Для тех, кому пендосский неродной - важнее чтобы запоминалось и звучало проще.
                              Стал сей недоязык стандартом, печально, но "культуру" лишний раз можно и не принимать.
                              Ответить
                              • Недоязык это clojure чтоли
                                Ответить
                                • английский же
                                  Ответить
                                  • Туплю, спасибо
                                    Английский - не торт, но деваться некуда.
                                    Меня почему-то всегда тянуло к немецкому, а мой друг (сейчас он атташе в ЮАР o_0) в восторге от французского
                                    Ответить
                              • Что вы имеете в виду под принятием культуры? В чём это выражается?
                                Ответить
        • $ pointful "(((.) flip) . (((flip (.)) flip) . ((.) . (.))))"
          (\ x c e f -> x (c e f))
          
          $ pointfree "(\ x c e f -> x (c e f))"
          (.) . (.)

          // а тс уже приелся
          Ответить
    • Как ты заебал.
      Ответить
      • Я Хаскел популяризую и рекламирую.
        Ответить
        • Вероятно, своим ником? Потому что пока не сильно заметно, чтобы кодом.
          Ответить
          • Это черный маркетинг. Люди смотрят на Хаскел - можно писать всякую изотерическую поебень. Но люди думают, что наверное можно писать и что-то полезное. Начинают говорить о нем, обсуждать, язык висит на слуху, подтягиваются защитники и говорят какой он пушистый и вот уже пиар сделал своё дело.
            Ответить
            • > изотерическую
              Не понял изотермическую или изометрическую?
              Создавай ник "РусскийЯзыкГумно".
              Впрочем согласен с тезисами что Хацкель эзотеричен (для меня - человека, который вообще его не знает) и что есть граждане излишне форсящие его - ты например.
              Ответить
              • > Впрочем согласен с тезисами что Хацкель эзотеричен (для меня - человека, который вообще его не знает)
                Хаскел не эзотеричен.

                Это очень годный язык с краткой, читабильной и понятной формой записи программ.

                Он крайне безопасен и все программы что компилируются - почти всегда работают сразу после компиляции без ошибок.

                Более того он хорошо оптимизируется. Может спорить по производительности с сишечкой. И тем более очень хорошо подходит для многопоточных вычислений.

                А то что ты его не осилил - не делает тебе чести. Мне твой батхерт понятен. Ниасиляторы всегда завидовали осиляторам.
                Ответить
                • Ну это ваще пушка.
                  Ответить
                • > почти всегда работают сразу после компиляции без ошибок
                  Легко можно стек свалить или кучу отложить, помнится md5 пробовал наговнокодить - потом половину времени боролся с излишней ленивость.
                  Ответить
                  • Эм, а как ленивость могла испортить md5? Там же сплошные битовые операции, а они строгие.

                    Вот с загрузкой файлов это да... сервак может вылететь через день после старта сказав что "can't parse config header". А все потому, что лень было его читать.
                    Ответить
                    • >Вот с загрузкой файлов это да... сервак может вылететь через день после старта сказав что "can't parse config header". А все потому, что лень было его читать.

                      С чем связано? При каких обстоятельствах? Из-за переполнения стека? Как бороться?
                      Ответить
                      • Да почему. Из-за ленивости. Если не заставлять его вычислять выражения, он может отложить парсинг файла на потом. Ну и вылететь не сразу когда положено, а уже когда понадобится значение.
                        Ответить
                        • А, то есть файл загрузил и все хорошо, но из-за лени он его не загрузил, а потом как значения из него потребовались - так сразу начал падать. Ясно.
                          Ответить
                        • Это юмор?
                          Если одна функция зависит от результата другой, то никакой хаскелл не сможет поменять им порядок вычислений.
                          Ответить
                          • Не знаю к чему вы, но порядок вычисления аргументов функции можно менять в хаскеле.

                            И с чего вы взяли, что тут ваш случай? Просто файл был загружен, но не весь распарсен. Хаскел это может. Если до этого момента были нужны только первых 5 элементов из файла, то оставшийся файл вполне может оказаться недопарсеным.
                            Ответить
                          • Это не юмор. Есть такое понятие WHNF (Weak Head Normal Form). Т.е. вычисляется первый конструктор и все. Его параметры хаскелю раскрывать лень.

                            И многим функциям для работы достаточно этого самого WHNF. Например если у нас есть список, и мы пишем что-то в духе x = head list, хаскель только проверяет что в списке есть элемент и ложит thunk для его вычисления в x. Этот thunk запустится уже только при какой-то операции над x, а это может быть в совершенно другой части программы...
                            Ответить
                          • Это один из катастрофических недостатков ленивых языков - дебажить в принципе нет возможности, т.как значения нельзя увидеть до того, как они используются, а если форсировать это дело, то программа в отладчике будет работать принципиально не так, как без него.
                            Ответить
                            • Вот эту статью я считаю просто замечательной
                              http://blog.jgc.org/2007/01/tao-of-debugging.html
                              Ответить
                              • Как будто для написания юнит тестов дебаггер не нужен... автор статьи не в себе, ущемленный чем-то в детстве мудак. Не нравится использовать отладчик - ну так и не используй, и отлаживай каждую функцию по дню юнит тестами. Так и крестики нолики можно всю жизнь писать.
                                Ответить
                                • А ведь это Пол Грэм, легендарный лиспер (мне кстати очень нравится его "On Lisp"), который ещё одним из первых нехило срубил бабла на интернете. Читал, как они вдвоём с другом имплементили фичи, о выходе которых через пару дней заявляли конкуренты, раньше самих конкурентов.
                                  Ответить
                                  • Ну и что? Любой кто скажет, что отладчик не нужен - мудак, вне зависимости от заслуг перед человечеством.
                                    Это все равно, что пойти за авиабилетом в турагенство, а агент предложит санки или роликовые коньки взамен. На основании того, что он и на этом может до гастронома доехать.
                                    Ну, молодец, у него есть достаточно времени printfами отлаживать код - у других людей таких привилегий нет.
                                    Ответить
                                    • Отладчик не нужен... в 90% случаев, когда хочется его использовать.

                                      Отладчик опасен... потому что индусы, благодаря ему, исправляют последствия бага (например добавляют +1 к результату), а не его истинную причину.

                                      Отладчик ничего не может сделать в ситуациях с запоротой памятью, т.к. ошибка будет вылетать в невинном коде. И тут помогут только инструменты вроде valgrind.

                                      Отладчик нельзя использовать при отладке сервера, который, например, считает клиента неактивным после молчания в 30 секунд (не предлагайте мне править конфиги на время отладки).

                                      Случаи когда реально нужна пошаговая отладка - это отладка доставшегося в наследство треша, который нельзя понять логически, но нужно срочно пофиксить.
                                      Ответить
                                      • Вот, слышу здравые мысли )
                                        Сам использую отладчик крайне редко и с неохотой. Я умею им пользоваться (даже раньше читал курс "Introdution to GDB" на работе), но делают это с БОЛЬШОЙ неохотой. Лучше уж написать юнит-тест, автоматизировав процесс, чем заниматься обезьяньей работой.

                                        Когда я работал над проектом ericsson, не было абсолютно никакой возможности пользоваться отладчиком.

                                        Тем, кто не постиг ТАО, отладчик не нужен...
                                        Ответить
                                        • > Тем, кто не постиг ТАО, отладчик не нужен
                                          очевидный фикс
                                          Ответить
                                        • Да-да-да, особенно понравился маразм про Лисп в этом контексте. Лиспа без отладчика не бывает в принципе.
                                          Хочу посмотреть на программиста на Яве, у которого бы забрали возможность видеть стек трейсы, ассерты и сообщения об ошибках. Вот просто если в программе случается ошибка - она либо продолжает работать как-нибудь, ничего об этом никому не сообщая, либо крашится. И потому, что все эти возможности - это элементы отладчика. Кто-то тут собирался писать юнит тесты без ассертов? Или натыкать логов после каждого объявления функции, чтобы потом найти откуда же ошибка? Вот это блин уверенность... и желание оправдать любое говно этой самой самоуверенностью.
                                          Ответить
                                          • > Хочу посмотреть на программиста на Яве, у которого бы забрали возможность видеть стек трейсы, ассерты и сообщения об ошибках.
                                            Да Вы же садист. Еще исключения отберите т.к. они "часть отладчика".

                                            Когда я говорю об отладчике - я имею в виду gdb или его GUI'шный аналог, в котором есть возможность смотреть переменные и пошагово выполнять функции.

                                            А то что вы перечислили - это отладочные средства, которые действительно необходимы, в отличие от пошагового исполнения.
                                            Ответить
                                            • А какое вообще отношение gdb имеет к Лиспу или Яве и в том числе Хаскеллю? Мне c/c++ код отлаживать практически не приходилось, но попадались плохие отзывы о gdb. Но тут же не про конкретный отладчик идет речь - тут про отладчик как таковой, да еще и применительно к другому языку, в котором не то, что отладчик не работает, так и даже printf на столько затруднен, что даже трогать не хочется.
                                              Ответить
                                              • лол, вы уже договорились того, что отладчики не нужны?
                                                Ответить
                                              • Давайте определимся в том, что Вы понимаете под отладчиком. Свое представление об отладчике я написал выше - средство, позволяющее пошагово исполнять код, просматривать переменные и память и устанавливать контрольные точки, и именно его я считаю ненужным.

                                                Теперь по лиспу и хаскелю:
                                                Против REPL я ничего не имею, это действительно удобный и полезный инструмент, которого мне очень не хватает в С\С++, с которыми мне приходится работать.

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

                                                > так и даже printf на столько затруднен, что даже трогать не хочется
                                                show выводит все стандартые типы, все типы у которых написано deriving Show, и те у которых вручную описан instance Show. Сложностей с выводом не вижу.

                                                Если Вы о том, что нельзя вызвать print из произвольного места - то опять же не вижу проблемы: чистые функции удобней отлаживать по данным, с помощью вызова из REPL и юнит тестов. А в IO функциях print вполне себе работает.
                                                Ответить
                                                • Ну только show / print и им подобные не используешь там, где значение еще не вычислилось. А там где их "можно" использовать - уже как правило поздно, так что смысла от них - только лабы писать.

                                                  Отладчик: http://en.wikipedia.org/wiki/Debugger как написано во втором параграфе: программа, которая помимо того, что написано в других параграфах, показывающая где произошла ошибка. Кроме того, желательно бы, чтобы показывала содержание переменных, стека; позволяла на минимальном уровне управлять ею (остановить выполнение / продолжить); вызвать по желанию.

                                                  Я где-то спорил про полезность тестов? Какое это вообще имеет отношение к тому, что я говорю? Юнит тесты не заменяют отлачик уже хотя бы потому, что его используют.

                                                  Практика показывает, что чистая функция или нет - на столько незначительно сказывается на количестве ошибок в программе, что выставлять это в качестве аргумента за отсутствие отладчика - просто глупо. Ошибки связанные с тем, что кто-то не предвидел какие-то изменения в свойствах объекта с которым работают, составляют совсем незначительный процент от общего количества ошибок, что даже смешно об этом говорить. В том же Лиспе, например, из 10 ошибок, 8 - это когда скобки не там закрылись. В Яве, судя по моему скромному опыту - булевая алгебра (законы де Моргана и т.п.). Яваскрипт - приведение типов, и т.д.

                                                  Чистые функции или нет - роли не играет, я говорил изначально и повторюсь, что роль играет ленивость вычислений. А вот тут как раз все очень плохо т.как в отладчике информацию нужно увидеть как правило до того, как она используется, а в ленивом языке это не получится, т.как ее по-сути и нет. В Лиспе для того, чтобы можно было увидеть что происходит с аргументами, которые лениво вычисляются есть специальные функции (группы macroexpand*) которые дают какое-то представление о том, что происходит с "недовычисленными" аргументами, в Хаскелле об этом можно только гадать.
                                                  Ответить
                                                  • > В Яве, судя по моему скромному опыту - булевая алгебра
                                                    80% NPE
                                                    Ответить
                                                  • > Чистые функции или нет - роли не играет.
                                                    Играет. Для чистой функции даже юнит-тест написать гораздо проще. Я и на с\с++ стараюсь, по возможности, делать функции "почище" - их проще читать и переделывать.

                                                    > Ошибки связанные с тем, что кто-то не предвидел какие-то изменения в свойствах объекта с которым работают, составляют совсем незначительный процент от общего количества ошибок
                                                    После первого рефакторинга того самого объекта эта цифра внезапно может измениться. И, скорее всего, не в меньшую сторону.

                                                    > Юнит тесты не заменяют отладчик уже хотя бы потому, что его используют.
                                                    Омг, а если я писал юнит-тест на С, в виде обычного сяшного модуля, который проверяет корректность разбора всех пакетов, входящих в протокол, то он тоже использует отладчик ? :) А я и не знал...

                                                    Особых проблем в отладке чистых функций я не вижу. Код на Хаскеле не зря советуют разбивать на небольшие независимые функции. Так их можно проверить и изучить по отдельности, не вникая в сложности их взаимодействия друг с другом (собственно отладку). Ленивость здесь никакой роли не играет.

                                                    Но вот в коде, работающем с IO, ленивость играет роль, и, зачастую, очень неудобна. Например она позволяет исключениям "плавать" из одной части программы в другую. Здесь я не буду защищать хаскель - это действительно проблема. И неприятности она доставляет не при отладке (т.к. при выполнении из REPL и просмотре результатов, они все-таки вычисляются), а скорее при работе программы в боевых условиях. А решать ее, наверное, нужно одним из способов

                                                    1) Форсировать вычисления, вызвав evaluate $ deepseq. Тогда мы получим исключение в правильный момент, и сможем его обработать (ну или хотя бы упасть вовремя).

                                                    2) Писать чистую часть кода так, чтобы она не могла выдавать исключений - не юзаем fromMaybe, не передаем head'у и tail'у пустых списков, всегда указываем все возможные варианты в паттернах и т.п. Тогда на ленивость можно просто забить, ничего плохого из-за нее не произойдет.
                                                    Ответить
                                                    • Да, играет, я же не говорю, что нет. Один процент, ну может быть два вы выиграите, поимев несколько недель головной боли просто пытаясь разобрать этот бред. Это та же самая преждевременная оптимизация, только пальцы еще глубже в двери, по самые локти.

                                                      Код на Хаскелле советуют разбивать на маленькие функции не потому что, а потому что функция в 10 строк разжижает мозг даже самому саоуверенному идиоту, который свято верит в то, что может понять то, что на Хаскелле написано.
                                                      Ответить
                                                      • > потому что функция в 10 строк разжижает мозг даже самому самоуверенному идиоту
                                                        Что правда, то правда.
                                                        Ответить
                                                      • > Один процент, ну может быть два вы выиграите, поимев несколько недель головной боли просто пытаясь разобрать этот бред.
                                                        Ок, спасибо за ценное указание. Завтра на работе, в сяшном проекте, перенесу все переменные в глоб, и буду писать функции как можно большего размера, работающие с максимальным числом побочных эффектов. Чистые функции ведь бред, особенно в императивных языках.

                                                        > функция в 10 строк разжижает мозг
                                                        10 строк для хаскеля это очень много. Если там используются всякие high-order функции, это может быть эквивалентно 50-100 строкам на С. А функции на 50-100 строк на С тоже неплохо съедают мозг читающего.

                                                        Мелкие функции на любом языке легче писать, легче изучать, легче поддерживать, легче отлаживать. Вы же не будете это опровергать?
                                                        Ответить
                                                        • Да-да, конечно, только в нормальных языках есть устоявшиеся традиции не писать функций, например, не влезающиe в экран. Можно еще поискать чего там Филлипс в кодстайле пишут по этому поводу да и всякие разные остальные. Всякo не 10 строк максимум.
                                                          Проблема не в том, что, а в том что в любом нормальном языке функция в 10 строк не вызывает преждевременной утраты волос в интимных местах тела.
                                                          Ответить
                                                          • 10 строк на хаскеле: http://govnokod.ru/10361#comment139127

                                                            Предположим что некий индус переписал данный код на си, в одну функцию. Влезет ли она в экран? Сколько минут уйдет на ее разбор и понимание?

                                                            Поэтому нам нужно смотреть на сложность алгоритма, который реализует функция, а не на число строк в ней.

                                                            Для С есть хорошая эвристика этой сложности - функцию, которая не вошла в экран будет трудно разобрать.

                                                            Для хаскеля эта эвристика тоже есть - в районе 4-5 строк.

                                                            В том, что она меньше я ничего плохого не вижу, т.к. алгоритм, реализованный в этих 4-5 строках, на С уже не влез бы в экран.
                                                            Ответить
                                                            • 1. функция isPrime
                                                              int isPrime(int n){
                                                                  if (i==2) return 0;
                                                                  if (n % 2==0) return 1;
                                                                 for (int j=3;j<round(sqrt(n));j+=2)
                                                                           if (n % j==0) return 1;
                                                                  return 0;
                                                              }

                                                              too obvious, too trivial
                                                              2. Берем из листа/массива цифры, удоляем/метят уже используемыми (permutation)
                                                              3. Объединить 1 и 2, проверять в цикле.
                                                              ???
                                                              Хацкель не нужен.
                                                              Ответить
                                                              • Да, Вы правы, хаскель не нужен.
                                                                Ответить
                                                                • 2. permutation trivial too
                                                                  void permCheck(int base,int n) {
                                                                      if ( n==0 ) 
                                                                         if isPrime(base) && (base>max)
                                                                                 max=base;
                                                                      else
                                                                        for (int i = 9; i-->=0;) {
                                                                            permCheck(base*10+i,n-1);
                                                                  }
                                                                  call
                                                                  permCheck(0,n)
                                                                  or
                                                                  permCheck(9,n-1)
                                                                  fine too :)

                                                                  Простите я ленив - рекурсивный вариант проще, чем циклы/список/массив.
                                                                  Ответить
                                                                  • Не, тут все подряд числа выводятся, а в задаче рассмотрены только состоящие из разных цифр от 1 до n. Т.е. для n=3 => 123 132 231 213 321 312
                                                                    Ответить
                                                                    • А ну да, тупанул.
                                                                      С 9-ками тоже.
                                                                      Но я в целом подтверждение того, что кода на С - совсем чуть-чуть. Там только в цикле int i = 9 на n поменять.
                                                                      Ответить
                                                                      • Да понятно, там массив поюзанности цифр добавить, да проверку в цикл, и все будет норм. Так что хаскель действительно не нужен :)
                                                                        Ответить
                                                              • > for (int j=3;j<round(sqrt(n));j+=2)

                                                                Вы специально так, чтобы мы этим обмазывались?
                                                                Ответить
                                                                • GCC надо отдать должное, оно додумалось вынести round(sqrt(n)) за цикл.

                                                                  Но вот < вместо <= это фейл. 9 - простое число, 25 тоже.
                                                                  Ответить
                                                                  • И да, round возвращает плавучку. Поэтому сравнение j с ним будет в плавучке.
                                                                    Ответить
                                                                  • Гэцэцэ гэцэцой, а на компилятор надейся, а сам не плошай. Напишет он такое под микроконтроллер, где нет такой оптимизации, и что делать?
                                                                    Ответить
                                                                • >j<round(sqrt(n))
                                                                  >Вы специально так, чтобы мы этим обмазывались?
                                                                  Oh shi~. Вчера вечером я был немного не в себе. За 5 минут на автомате набросал - proof of concept.

                                                                  >там массив поюзанности цифр добавить
                                                                  No C way! Только биты, только хардкор!!!
                                                                  Под рукой консоль с JS потому так.
                                                                  var n=5;
                                                                  var perm=function (base,mask){
                                                                     if (mask+1==1<<n) {
                                                                          console.log(base);
                                                                          return;
                                                                     }
                                                                     for (var j=n;j-->0;)
                                                                         if ((mask & 1<<j)==0)
                                                                             perm(base*10+j+1,mask | 1<<j);
                                                                  }
                                                                  perm(0,0);
                                                                  Ответить
                                                                  • Ну да, битов в этом случае вполне достаточно.
                                                                    Ответить
                                      • Билет на самолет хуже санок для того, чтобы долететь из Москвы до Нью-Йорка потому что:
                                        - возможно вы полетите летом, а летом в Нью-Йорке жарче, чем в Москве, а вы могли это не предвидеть и одется очень тепло. На санках нельзя ездить летом - это предохранит вас от теплового удара.
                                        - летать самолетами небезопасно, а на санках вы все-равно дальше пары километров не уедете, тем более, вы не станете ездить по проезжой части или людным местам.
                                        - Иногда вылеты задерживаются, и даже на несколько суток - если авиакомпания продавшая вам билет поскупится, то вам прийдется ночевать на лавочке в аэропорту, а не в комнате в отеле. А после чего, еще и судится с авиакомпанией изза нарушение пользовательского соглашения.
                                        - В самолете вам может попастся пара с младенцем, который будет орать всю дорогу благим матом и не даст вам поспать. Кроме того, в самолете не разрешается курить, может попастся попутчик, который нажрется как свинья и заснет не давая вам пройти к туалету.

                                        Естественно, напрашивается однозначный вывод - если вы хотите добраться из Москвы до Нью-Йорка - ни в коем случае не покупайте авиабилеты. Санки (такие детские, с алюминиевыми полозьями и деревянным сидением) - это самое то!
                                        Ответить
                                        • Согласен, только вот санки это отладчик, а самолет это правильное проектирование, юнит-тесты, качественное логирование, valgrind и, по возможности, стектрейсы исключений.

                                          Можете продолжать пошагово катать санки :)
                                          Ответить
                                          • Я как раз вижу, как кто-то другой пытается игнорировать явные преимущества и выставляет напоказ наполовину вымышленные недостатки выгораживая идиотскую технологию, просто потому что она ему чем-то другим нравится.
                                            Ответить
                                            • Могу сказать то же самое о кое-ком другом, но не буду.
                                              Ответить
                                  • >как они вдвоём с другом имплементили фичи, о выходе которых через пару дней заявляли конкуренты, раньше самих конкурентов
                                    Щито?
                                    Ответить
                                    • Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release.
                                      http://www.paulgraham.com/avg.html
                                      Ответить
                                      • Lol.
                                        >о выходе которых за пару дней до этого

                                        PS. Подтверждаю - отладчики не нужны. Вернее нужны только когда написал эзотерическое говно - вот там они очень полезны.
                                        Ответить
                                        • Читал давно, писал по памяти, запомнилось именно так. В принципе, анонс конкурента в пресс-релизе не означает, что этого самого конкурента всё уже работает...
                                          Ответить
                                  • Кстати, если уж речь зашла о Лиспе, то, стандартный ANSI Лисп обязывает, вернее не допускает выполнение кода в отсутсвие отладчика.

                                    И уж если речь зашла об истории - когда-то на заре моей программерской карьеры писал я на АS1/AS2 и отладчик там был, ну прямо скажем, никакой, да и по большому счету не было его там. Т.е. я себе вполне представляю разницу между поиском ошибки без стек-трейса и с ним, например. А ведь это тоже составляющая отладчика. Или всякие ошибки приведения типов, когда распечатка показывает, что значение переменной, как будто там число, а на самом деле - строка и т.п.
                                    Ответить
                                    • А вот стек-трейсы исключений, согласен, нужны.

                                      > А ведь это тоже составляющая отладчика.
                                      Нет, хотя для качественного трейса действительно требуется отладочная инфа.
                                      Ответить
                                      • Просто GDB говно, которым невозможно пользоваться. Когда я писал на Аде, то тоже старался не использовать отладчик.
                                        А на Дельфях - самое то.
                                        Ответить
                                        • Ну Ада ориентирована на написание корректного кода, там отладчик использовать ИМХО некошерно :)
                                          GDB в чистом виде действительно неюзабелен. А вот в качестве бекенда для гуишного отладчика - например в составе QtCreator или CodeBlocks - вполне приятен.
                                          Ответить
                                          • Ну в Аде ГДБ тоже был не в чистом виде, а под обёрткой, но всё равно его скорость работы и глючность убивали.
                                            Ответить
                                            • Ну в с\с++ таких проблем за ним не замечал.
                                              Ответить
                                              • Ну я бы тоже не замечал, если бы не сравнивал с дельфями, которые заводятся моментально.
                                                Ответить
                                                • Делфи и компилит быстрее чем с\с++ :) За счет вменяемой системы модулей.
                                                  Ответить
                        • А вы участвовали в реальных разработках на Хаскеле? Какие проекты делали? :)
                          Ответить
                          • В реальных - к сожалению нет. Пытался запилить клиента к одной онлайн игрушке - но дело загнулось на недопиленной SDL либе (нельзя грузить рисунки через RWops, только через файлы) и на раскуривании полиморфных коллекций. Ну и на отсуствии времени.

                            P.S. за что чела минусуете, вроде нормальный вопрос.
                            Ответить
                    • 1) Строгим пришлось сделать применение нового чанка
                      2) Кроме того строгую структуру, содержающую квартет Word32.
                      В самой итерации осталось как было.
                      Ответить
                      • Ясно, т.е. проблема была в том, что ему было лень считать MD5 и он откладывал это на потом вместе со всем содержимым файла?
                        Ответить
                        • Ага, где-то так: нестрогий foldl1 (+) [1..n], но на уровне 64-байтных блоков.
                          Для эффективности выбрал ByteString.Lazy, поэтому готовый foldl' тоже подходил.
                          Ответить
                • Я не пойму - ты вообще на чьей стороне?
                  >Мне твой батхерт понятен. Ниасиляторы всегда завидовали осиляторам.
                  Или ты просто идиот? Учитывая твои прошлые посты в стиле: "посоны у миня хацкель на компилицо. чяднт?"
                  Ответить
                  • /me thinks он пытается троллить всех
                    Ответить
                    • Вот это как раз понятно.
                      Другое меня терзает - зачем ты, Роман вообще реагируешь на каждый тред этой жирноты, отвечая ему, попусту разбрасываешь бисер.
                      Ответить
                      • Вот такая я святая простота Опять же забавно смотреть на фриков
                        Ответить
                      • показать все, что скрытоНе можешь в Хаскель - биореактор там ===>
                        Скоро и на говнокод не заёдешь из-за Хаскел-Капчи.
                        Ответить
                        • Языки нужны для того чтобы кодить и получать за это бабки и/или удовольствие, а не для того чтобы "осиливать" (если ты конечно не малолетний долбоеб который учит Хацкель ради понтов).
                          Ответить
                      • А Роман - нормальный умный пацан в теме, так что не гони.
                        Ответить
                • кого-то ты мне напоминаешь...
                  Ответить
                  • Ты мне кого-то тоже...
                    Ответить
                    • Виртуалы Zefick срутся на гк.
                      Скучный гейдев-тролль.
                      Ответить
                      • Поциент просто завел себе в интернете воображаемых друзей и теперь они начали разговаривать друг с другом.
                        Ответить
                        • Вот до чего хаскелл доводит
                          Ответить
                          • Его мозг функционально чист. Поэтому одновременно может выполняться любое количество его экземпляров, не знающих друг о друге. К сожалению он пока не ленив...
                            Ответить
                            • То оно и видно - говна паралелялтся тут как грибы после дождя.
                              >К сожалению он пока не ленив...
                              Ленив. Все его т.н. вбросы - чужой код.
                              Ответить
                    • Я тебя уже где-то видел...
                      Ответить
                    • Разлученные в детстве братья нашли друг друга. Играет индийская музыка и все танцуют и поют.
                      Ответить

    Добавить комментарий