Я думаю, что подразумевалось написание кода, используемого в производстве, т. е. не для самообучения. Но даже если и для обучения, то все равно тупое использование копипасты бесполезно, все равно что зубрежка.
В функциональном мире все гораздо проще. Если функции не имеют побочных эффектов и при заданных аргументах всегда возвращают один и тот же результат, распараллелить их очень просто, ведь работа одной функции не повлияет на работу другой функции, поскольку они не разделяют глобально изменяемое состояние.
Имелось в виду глобальное состояние, а не глобальные переменные.
В глобальное состояние входит конкретное значение каждой переменной независимо от ее области видимости, будь она объявлена глобально, на уровне процедуры или в методе класса, если это ООП, а также стек вызовов функций (мы ведь говорим об обычных императивных языках).
Так вот, ограничивая, как вы думаете изменяемость переменных только посредством вызова методов объекта вы ничего не улучшаете в плане избавления от глобального состояния, Вы, как я уже сказал в другом комментарии, усугубляете ситуацию, спрятав эти переменные глубоко в объект.
Вы по-прежнему изменяете переменные, только теперь это делается посредством (взаимо)вызова методов объектов, т. е. побочные эффекты никуда не делись, они ушли на уровень ниже, в объекты.
А теперь представьте, что Вам необходимо писать параллельный или распределенный код. Отлаживать такое инкапсулированное состояние еще сложнее.
Вообще есть ООП парадигма и в функциональном мире — Common Lisp, OHaskell, OCaml. ООП, насколько мне известно, не означает изменение состояния; оно о другом.
Но то, о чем вы говорите, еще больше усложняет проблему анализа программ и поиска ошибок, потому что те изменяемые переменные и состояние вы прячете еще глубже, инкапсулируя.
Смотря что Вы подразумеваете под термином «промышленен».
Если «распространен в промышленности», то я согласен с Вами бесспорно, но в то же время и опечален.
Если «готов к использованию в промышленности наравне с другими популярными языками», то Хаскель имеет очень большое количество библиотек в Hackage.
Со Scheme все чуточку сложнее. Для Хаскеля всего пара-тройка реализаций, при том что полноценной считается GHC, а реализаций Схемы — за 70, в т. ч. от Microsoft. Последнее обстоятельство порождает несовместимость стандартов и самих реализаций, что не играет на пользу распространенности Scheme в производстве, хотя ее там вполне можно встретить.
Лисп, безусловно, распространен, Эрланг. В банковских системах, отказоустойчивых сервисах, метро и т. д.
Лисп использовали в космосе. Все эти языки промышленнопригодны.
Вы от него не избавитесь в императивных языках. Или сделаете это так, что код будет просто уродлив или не похож на все то, что обычно пишут на этих императивных языках.
Это примерно то же, что попытаться на чистом функциональном языке писать в императивном стиле.
Ну, вообще, как бы, одной только хвостовой рекурсии недостаточно, чтобы избавить язык от глобально изменяемого состояния (читай, сделать его чисто функциональным), но такие языки есть, да — Haskell.
Ну, в Lisp, во многих из 70 реализаций Scheme он, что называется, «из коробки», причем из лохматых годов прошлого века (см. выше), в OCaml, Haskell, да чего уж там — Erlang.
Я подразумевал глобально изменяемое состояние в императивных языках в противовес последовательного вызова чистых функций в функциональных языках с соответствующими аргументами без побочных эффектов, включая хвостовую рекурсию.
Вы не понимаете принципа функционального программирования, как программирования без побочных эффектов в идеале (Haskell, например, или Scheme). Итерация в C и C-подобных языках императивна, имеет побочные эффекты в форме изменения переменной-счетчика, например.
Программы без побочных эффектов очень легко анализировать формальными методами и сложнее допустить ошибку на почве глобально изменяющегося состояния.
1977 год, между прочим, Guy Steele. Вот вам и польза от знания Lisp'а налицо, что называется, а вы говорите СкрипачLisp не нужен. Рекурсия божественна, воистину!
В глобальное состояние входит конкретное значение каждой переменной независимо от ее области видимости, будь она объявлена глобально, на уровне процедуры или в методе класса, если это ООП, а также стек вызовов функций (мы ведь говорим об обычных императивных языках).
Так вот, ограничивая, как вы думаете изменяемость переменных только посредством вызова методов объекта вы ничего не улучшаете в плане избавления от глобального состояния, Вы, как я уже сказал в другом комментарии, усугубляете ситуацию, спрятав эти переменные глубоко в объект.
Вы по-прежнему изменяете переменные, только теперь это делается посредством (взаимо)вызова методов объектов, т. е. побочные эффекты никуда не делись, они ушли на уровень ниже, в объекты.
А теперь представьте, что Вам необходимо писать параллельный или распределенный код. Отлаживать такое инкапсулированное состояние еще сложнее.
Но то, о чем вы говорите, еще больше усложняет проблему анализа программ и поиска ошибок, потому что те изменяемые переменные и состояние вы прячете еще глубже, инкапсулируя.
Если «распространен в промышленности», то я согласен с Вами бесспорно, но в то же время и опечален.
Если «готов к использованию в промышленности наравне с другими популярными языками», то Хаскель имеет очень большое количество библиотек в Hackage.
Со Scheme все чуточку сложнее. Для Хаскеля всего пара-тройка реализаций, при том что полноценной считается GHC, а реализаций Схемы — за 70, в т. ч. от Microsoft. Последнее обстоятельство порождает несовместимость стандартов и самих реализаций, что не играет на пользу распространенности Scheme в производстве, хотя ее там вполне можно встретить.
Лисп, безусловно, распространен, Эрланг. В банковских системах, отказоустойчивых сервисах, метро и т. д.
Лисп использовали в космосе. Все эти языки промышленнопригодны.
Это если мы говорим о чистом функциональном программировании.
Хотя бы этот вопрос, Is anyone using Racket commercially? на Stackoverflow.
Это примерно то же, что попытаться на чистом функциональном языке писать в императивном стиле.
Мазохизм.
Вам недостаточно этих промышленных языков? ;-)
Программы без побочных эффектов очень легко анализировать формальными методами и сложнее допустить ошибку на почве глобально изменяющегося состояния.
СкрипачLisp не нужен. Рекурсия божественна, воистину!Видно комментатор кода несилен в языках, и не знает, что хвостовой рекурсии (Tail call optimization) сто лет в обед, и никакого стека, блджад.