Зачем так критично? А как же бинарное дерево обойти иначе? Есть конечно способы обойти его без стека, но их осмысленность, как мне кажется, сомнительна.
Так я нигде и не писал: «долой циклы, давайте одной рекурсией пользоваться». Это было бы по меньшей мере глупо, для большинства языков.
Но в тоже время, если посмотреть на такой язык как smalltalk, то все циклические конструкции там реализованы через рекурсию, и результат на голову обходит Java. В случае с Python по мощности и удобству использования не мне судить, но то что реализация больше соответствует принципу бритвы Окама — уверен.
(говорить о рекурсии в smalltalk не совсем корректно, если не ошибаюсь использованный там приём называется fractal duck, когда объект при обработке сообщения (метода), посылает себе тоже сообщение)
Ещё Дейкстра писал в своей работе о структурном программирование, что рекурсии достаточно для того, что бы описать любой алгоритм, а использование циклов является избыточным (слишком много лишних сущностей). Хотя стоит заметить, что в своём Алголе, он широко применял конструкции именно для циклов, но то было начало языкостроения…
А у меня тут всё несколько печальнее. Мне практически любая задача надоедает очень быстро, даже интересная. И если она надоедает, но работать через силу, то в скоре она на перестаёт быть интересной. Но для такой ситуации есть грязный хак, надо держать рядом с собой 1-2 открытые книги в процессе чтения, и в случае скуки, отвлекаться на чтени нескольких страниц из той, к оторой рука сама потянится. После этого, как правило, к задаче подходишь как с новыми силами, так и с новыми идеями.
Скажите, а применимо ли GTD для творческих задач? Которые требуют, к примеру, час на вхождение в тему, делаются часа два-три-четыре и после этого их надо обсудить и снова доробатывать.
Именно так. Но широкий (физический) канал, даёт больше возможностей сигналу «разбредаться» по его ширине. Из-за этого растут шумы, и, как следствие, появляется нужда понижать частоту, а следовательно и скорость.
Если не секрет, по каким соображениям была выбрана связка c+lex+yacc? Чем не понравились такие инструменты как Ocaml или Haskell на пример? К тому же они вроде как получили некое распространение на поприще компилятора-строения.
habrahabr.ru/blogs/htranslations/95063/
Вот тут, пункт 7. Меньше сущностей — меньше мест напортачить. А если есть возможность напортачить — напортачишь. Хотя, это в основном вопрос умения и предрасположенностей разработчика.
> Не согласен :)
Там не просто так было написано «временами», говорят раз в год и палка стреляет. Вообще, прирост может быть в случае если очень активно создаются и разрушаются мелкие объекты (современные сборщики с поколениями работают очень неплохо). И в случае если сборщик мусора будет бежать на отдельном ядре процессора.
> То за такое надо отрывать руки, потому что во-первых есть STL.
С этим нельзя не согласиться.
Вполне себе логичным для двусвязанного списка хранить как указатель на голову, так и на хвост…
А в целом, посмотрите какие вы логические рассуждения сделали для выбора типа указателей. И это с учётом того, что задача простая. Разве оно того стоит?
Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение может происходить в другом процессе и системные вызовы дёргаются более кучно.
Но в тоже время, если посмотреть на такой язык как smalltalk, то все циклические конструкции там реализованы через рекурсию, и результат на голову обходит Java. В случае с Python по мощности и удобству использования не мне судить, но то что реализация больше соответствует принципу бритвы Окама — уверен.
(говорить о рекурсии в smalltalk не совсем корректно, если не ошибаюсь использованный там приём называется fractal duck, когда объект при обработке сообщения (метода), посылает себе тоже сообщение)
(могу и ошибаться, но вроде бы так)
Вот тут, пункт 7. Меньше сущностей — меньше мест напортачить. А если есть возможность напортачить — напортачишь. Хотя, это в основном вопрос умения и предрасположенностей разработчика.
> Не согласен :)
Там не просто так было написано «временами», говорят раз в год и палка стреляет. Вообще, прирост может быть в случае если очень активно создаются и разрушаются мелкие объекты (современные сборщики с поколениями работают очень неплохо). И в случае если сборщик мусора будет бежать на отдельном ядре процессора.
С этим нельзя не согласиться.
Вполне себе логичным для двусвязанного списка хранить как указатель на голову, так и на хвост…
А в целом, посмотрите какие вы логические рассуждения сделали для выбора типа указателей. И это с учётом того, что задача простая. Разве оно того стоит?
Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение может происходить в другом процессе и системные вызовы дёргаются более кучно.