Внимание! возможно, очень глупый вопрос
Не работает ли функциональное программирование больше памяти, чем процедурное программирование? Я имею в виду... если ваши объекты (структуры данных вообще) все можно вывести. В конечном итоге вы не получите больше объекта в памяти в данный момент времени.
Разве это не поглощает больше памяти?
Это зависит от того, что вы делаете. С функциональным программированием вам не нужно создавать защитные копии, поэтому для некоторых проблем это может привести к уменьшению объема памяти.
Многие языки функционального программирования также хорошо поддерживают ленивость, что может еще больше сократить использование памяти, поскольку вы не создаете объекты, пока не используете их. Однако это, возможно, связано только с функциональным программированием, а не с прямой причиной.
Постоянные ценности, которые поощряют функциональные языки, но которые могут быть реализованы на императивном языке, делают обмен информацией без проблем.
Хотя общепринятая идея заключается в том, что с сборщиком мусора в любой момент времени (уже недостижимые, но еще не собранные блоки) есть некоторое количество потерянного пространства, в этом случае без сборщика мусора вы оказываетесь очень часто копировать значения, которые являются неизменяемыми и могут быть разделены, только потому, что слишком много беспорядка, чтобы решить, кто несет ответственность за освобождение памяти после использования.
Эти идеи немного расширены в этом отчете об опыте, который не претендует на объективное исследование, но только анекдотические доказательства.
Помимо исключения защитных копий программистом, очень умная реализация чистых языков функционального программирования, таких как Haskell или Standard ML (которые не имеют физического равенства указателей), может активно восстанавливать совместное использование структурно равных значений в памяти, например. как часть управления памятью и сбора мусора.
Таким образом, вы можете иметь автоматическую хэш-консоль, предоставляемую вашей системой времени исполнения на языке программирования.
Сравните это с объектами в Java: идентификатор объекта является неотъемлемой частью определения языка. Даже просто обмен одним неизменным String для другого создает семантические проблемы.
Существует, по крайней мере, тенденция рассматривать память как богатый ресурс (что на самом деле это действительно в большинстве случаев), но это относится к современному программированию в целом.
С несколькими ядрами, параллельными сборщиками мусора и доступной оперативной памятью в гигабайтах, один из них концентрировался на разных аспектах программы, чем в более ранние времена, когда каждый байт можно было сэкономить. Помните, когда Билл Гейтс сказал, что "640K должно быть достаточно для каждой программы"?