ИМХО за деревьями не видно леса. Для вызова функции нужно пропихнуть что-то в стек, а на возврате выпихнуть — переменные в неявном виде. Выше Вы справедливо отметили:
Сначала нужно будет строго определить понятие переменной.
Сможете доказать это утверждение строго математически: Теорема. Любую функцию можно реализовать без использования переменных?
И практически интересно: как спрограммировать в этом подходе решето Эратосфена?
Даже в императивном языке придется к нему [ГСЧ] обращаться явно.
ИМХО использование локальной переменной с неопределенным значением (в качестве случайного числа) — не явное обращение к ГСЧ. Такие обращения можно отследить в ходе исполнения, если во все переменые при запуске программы (и при вызове функции) будет записано уникальное значение, нпр., FFF… Так ловили баг в древних Паскалях. В некоторых ЯП всегда записано значение по умолчанию, нпр., ноль.
И ртуть и вода. Считать действительно лень, но в гугле много мнений, что летит. В лаборатории отработанную ртуть хранят под тягой в бутыле под слоем слабой азотки. Бутыль затыкают пробкой. Периодически сдают на переработку.
Но вопрос теоретический: сошлись на мнении, что в сифоне унитаза ртуть хранить не надо))
Ртуть практически не растворяется в воде. Т.е. почти совсем. Вода, в смысле универсальности, лучший растворитель, растворяет всё, но иногда очень мало — ну очень-очень мало)
Ok: никаких внешних переменных, видимых помимо аргументов, но в регистрах, стеке, где-то еще (зависит от железа и реализации) всегда есть мусор от предыдущих действий. Если мы будем читать этот мусор? М.б. не очень хороший ГСЧ, но одинаковых выходных не получим. Либо любой мусор признать аргументами (входными данными), но тогда список аргументов будет зависеть от устройства черного ящика — железа и реализации, т.е. никакой абстракции. Либо чистить весь мусор, что в общем виде м.б. проблематично. Либо везде прописывать уникальный код и тестировать все локальные переменные на неинициализированность. Как-то очень нечисто?
Все что влияет — это часть исходных данных, почему нет-то?
Данных, но не исходных, а текущих. Простейший пример: функция последовательными приближениями долго вычисляет результат, мне надоело ждать, нажал кнопочку, функция должна вернуть, что упела вычислить на этот момент.
Статьи на тему «ФП лучше» или «ООП лучше» напоминают дебаты, что же лучше для обеда, вилка или ложка.
Практика турпоходов показывает, что ложка лучше — все всегда берут ложки, но практически никто не берет с собой в поход вилку :)
Аналогично, ООП позволяет решать более широкий круг задач, если исходить из определения автора:
Функциональное программирование, в вольной трактовке, рассматривает программу как математическую формулу. Формулы хорошо формализуются и при одинаковых входных данных возвращают одинаковые выходные.
Добавим в код генерацию случайного числа или обработку события и при одинаковых входных данных не получим одинаковые выходных. Т.о., согласно данному определению, в ФП это недопустимо. А в ООП (и других парадигмах) допустимо. Или я не понял предложенного в статье определения?
М.б. олово не самая важная проблема, но проверять мне не хочется)))
О роли олова в живых организмах практически ничего не известно. Ежедневное поступление олова с пищей составляет 0,2—3,5 мг, при регулярном потреблении консервированной пищи — до 38 мг.
Я читал в учебнике химии для вузов (не помню в каком), что олово с органикой на воздухе дает неприятные соединения. Но, конечно, они будут копиться не один час и, м.б., не одни сутки. В кулинарных книгах, консервы из открытых банок советуют перекладывать, либо сразу после вскрытия, либо после застолья. Не советуют использовать пустую жестянку вместо чашки или миски.
Вы хотите сказать, что ФП — синтаксический сахар?
И практически интересно: как спрограммировать в этом подходе решето Эратосфена?
ИМХО использование локальной переменной с неопределенным значением (в качестве случайного числа) — не явное обращение к ГСЧ. Такие обращения можно отследить в ходе исполнения, если во все переменые при запуске программы (и при вызове функции) будет записано уникальное значение, нпр., FFF… Так ловили баг в древних Паскалях. В некоторых ЯП всегда записано значение по умолчанию, нпр., ноль.
И ртуть и вода. Считать действительно лень, но в гугле много мнений, что летит. В лаборатории отработанную ртуть хранят под тягой в бутыле под слоем слабой азотки. Бутыль затыкают пробкой. Периодически сдают на переработку.
Но вопрос теоретический: сошлись на мнении, что в сифоне унитаза ртуть хранить не надо))
повторятьсписок_аргументов := чистая_функция_очередное_приближение (список_аргументов);
до_той_поры_пока чистая_функция_точность_достигнута (список_аргументов)
или кнопочка_нажата;
Т.е. две чистых функции, но всю программу в виде читой функции не оформить.
ГСЧ может быть и аппаратным, частью CPU. Тут выделить не получится и ФП не применимо (в вольной трактовке).
Если событие происходит в ходе вычисления и влияет на него.
Аналогично, ООП позволяет решать более широкий круг задач, если исходить из определения автора:
Добавим в код генерацию случайного числа или обработку события и при одинаковых входных данных не получим одинаковые выходных. Т.о., согласно данному определению, в ФП это недопустимо. А в ООП (и других парадигмах) допустимо. Или я не понял предложенного в статье определения?