SG
и в понимании того, как это отработает
Size: a a a
2016 September 22
AL
Давай сравним алгоритм выполнения обычного for лупа и рекурсии
AL
Теоретический минимум
Ю
да, я согласен, что там большинство задач там решаются без tco, но вот задачи, требующие взаимной рекурсии, решаются большими усилиями
SG
что это за магический список такой
SG
т.е. я не знаю, если есть конкретная задача, я могу оценить какие данные пришли, их объем, затем понять за какое время мне надо это выполнить, определить оценки сложности по времени/памяти, написать соответствующий алгоритм
SG
т.е. итерация подобна человеку, рекурсия можественна
SG
это все мы знае
SG
но я против каких-то полумер
SG
если хотите описать мат. модель и пользоватся этими инструментами, то можно писать на idris
Ю
задачи обхода графов, разбора сложных структур удобнее (в плане трудозатрат программиста) решать использованием взаимной рекурсии, нежели явного манипулирования состояниями
AL
Самая простую задачу я уже озвучивал - ленивый цикл с условием выхода
AL
Это реально частая штука
SG
любой программист должен с закрытыми глазами писать любой обход графа и прочее
SG
короче это такая же сомнительна штука как - "в крутых функциональных языках в 100 строк кода умещяется 1000 строк из плохих других языков"
SG
тут вопрос общей компетенции
SG
кому-то в принципе сложно написать может быть поиск в ширину или глубину, или там a* или что угодно, там максимальный поток..
SG
это все относительно и необъективно.
Ю
в SICP, кстати, если память не изменяет, были примеры задач, которые нужно было решать продолжениями. вот один из примеров. конечно, можно такую задачу решить средствами ООП, но кода будет действительно порядок больше и он будет представлять собой эталон боли (конечный автомат). либо требовать наличия многопоточности (реальной или зелёной)