Максим написал рекурсивный алгоритм, и столкнулся со Stack Overflow exception. Потому что он любит короткие и элегантные на его взгляд решения. Он не наслаждается, когда пишет так: Он хочет писать вот так: Но когда он запускает подобные этому рекурсивные алгоритмы, бывает так, что он видит это:  Потому что в Javascript есть ограничение на глубину стека вызовов. Каждый вложеный вызов функции factorial кладёт в стек запись о вызове функции. Когда размера стека не хватает — возникает эта ошибка. В случае на картинке — ошибка вылетела при 10700+ вложенных вызовах. Зависит от правильности алгоритма, размера задачи или стойкости его принципов. Сначала он должен проверить, может быть, он ошибся. Подобные ошибки могут появляться когда алгоритм написан не правильно. Необходимо проверить, приходит ли каждый вызов функции к базе рекурсии или нет. Если это не так, то нужно оценить размер задачи. Эта функция, может быть, никогда не будет вызвана на больших входных данных. В таких случаях пусть оставит рекурсивный алгоритм. Возможно, пометит границы применимости в комментарии к коду и достаточно. Если же Максим не ошибся в алгоритме и данных достаточно много, то Максиму нужно заменить рекурсивный алгоритм итеративным. Обычно рекурсивный алгоритм может быть заменён циклом и, если необходимо, вспомогательной структурой данных, чаще всего стеком. В случае расчёта факториала алгоритм лучше заменить на циклический, описанный выше. Но существуют более сложные рекурсивные алгоритмы, где нужно использовать дополнительную структуру данных. Я использую такую вспомогательную аналогию для того, чтобы представить рекурсивный алгоритм в форме цикла. Я представляю выполнение алгоритма как череду выполнения задач с одновременным планированием того, что необходимо сделать далее. Например расчёт факториала можно реализовать так: Сначала написали короткую документацию к этой функции. Потом на первой строке тела функции обработали «тривиальный» случай, когда n <= 1. Теперь решим эту задачу для не «тривиальных» случаев. Для этого определим стек команд и переменную для результата. Цикл while постепенно исчерпает список задач. Результат после этого будет храниться в переменной result. Теперь нам необходимо запланировать несколько задач, которые наш алгоритм должен выполнить. Первое что он должен сделать это вычислить факториал N - 1. Потом он должен умножить этот факториал N - 1 на N. Добавим эти задачи в todoStack. Так как задачи будут храниться в стеке, то задачи мы будем класть в обратном порядке. Теперь напишем реализацию этих команд в цикле, который исчерпывает стек задач. Это очень медленный алгоритм, по сравнению с циклом for. Но он демонстрирует основную идею, что есть стек «задач», и цикл, который этот стек опустошает, постепенно приходя к некоторому результату. Сергей решил занятся самообучением алгоритмам и решил написать нечто из раздела парсеров. Он решил, что парсером будет функция, которая принимает некоторый текст, и возвращает итератор по возможным результатам парсинга. Результатом парсинга является спарсеное значение и остаток строки, который не был использован при парсинге. Так вот он хочет написать такую функцию many1: Она должна применить этот парсер один или более раз и вернуть все возможные варианты последовательных применений этого парсера. Решим с помощью рекурсии. Задача парсинга текста действительно может вызывать большую глубину рекурсии. Поэтому Сергею необходимо переписать этот алгоритм через цикл. Вот как он это сделал: Схема точно такая как для факториала: стек задач, и цикл, который их исчерпывает. Здесь используется стек для хранения двух видов задач: Я поделился своими аналогиями, которые могли бы применить абстрактные «Максим» или «Сергей» для того чтобы превратить рекурсию в цикл. Расскажите, как вы превращаете рекурсию в циклы. Возможно, у вас есть свои аналогии? Или может вам они не нужны? Возможно вы бы решили задачу Сергея по-другому, расскажите как? Попадались ли вам рекурсивные алгоритмы в ваших проектах? Были ли случаи, где встречали Stack Overflow Error? Очень интересно узнать ваш опыт и ваше мнение, особенно по задаче парсинга. Можно ли её решить без рекурсии, но более просто? Frontend developer