О функциональных и императивных языках. О функциональном и императивном подходах

Скажем так "вводная" была тут - http://18delphi.blogspot.com/2013/11/blog-post_4093.html

Сегодня вышел спор с одним из коллег по цеху.

О том, кто и как понимает функциональное и императивное программирование и их принципы. И "что чем является".

Дискуссия местами велась в стиле "Ленин vs Мартов", ну или "Маркс vs Каутский". Ну или "уроки Октября" и "об уроках Октября".

И ОБЕ стороны - "были хороши".

В итоге наговорили друг другу некоторое количество "не очень приятных вещей".

Ну и разошлись - "каждый довольный собой".

Если бы была возможность "расстрелять оппонента", то "расстреляли бы". Ну или на худой конец - "сослали бы в Алма-Ату".

Что хочу сказать?

Ну я ЛИЧНО собой-то не очень "остался доволен".

И видимо заслуженно получил упрёки в том, что "я не слушаю", да и вообще - "никто не просил помогать".

Наверное.

Посему - хочу всё же - "прояснить ситуацию".

И ОБЪЯСНИТЬ - "своё виденье" вопроса. И ЧТО ИМЕННО я пытался донести.

НЕ ПОТОМУ, что "я прав".

В данном вопросе - "правых нет". По-моему.

Есть лишь - "личные трактовки".

Хотя может быть "моя личная трактовка" - ДЕЙСТВИТЕЛЬНО - "ЛИЧНАЯ" и сторонников у меня нет.

ДОПУСКАЮ.

Мне это - НЕ НОВО.

Теперь - к делу.

Суть вопроса была примерно в следующем - "какие языки считать функциональными и почему, а какие не считать".

Мой оппонент приводил следующее определение:
"Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).

Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательное изменение состояний (в значении, подобном таковому в теории автоматов). При необходимости, в функциональном программировании вся совокупность последовательных состояний вычислительного процесса представляется явным образом, например как список.

Функциональное программирование предполагает обходиться вычислением результатов функций от исходных данных и результатов других функций, и не предполагает явного хранения состояния программы. Соответственно, не предполагает оно и изменяемость этого состояния (в отличие от императивного, где одной из базовых концепций является переменная, хранящая своё значение и позволяющая менять его по мере выполнения алгоритма)."

взято отсюда - http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

И он НАСТАИВАЛ на своей точке зрения, что мол "раз нет состояний" - значит ФУНКЦИОНАЛЬНОЕ программирование.

Ну и с эти не поспоришь в общем-то. Да я с ЭТИМ И НЕ СПОРИЛ.

Наверное просто был НЕ ТАК ПОНЯТ.

Но!

Я НЕ ЗРЯ написал про "теорию и ПРАКТИКУ ПРИМЕНЕНИЯ".

Собственно какую мысль я пытался донести до своего оппонента?

А вот какую:

"нет состояний" и "нет императивных конструкций" - это конечно - ХОРОШО.

Но! ЗАЧЕМ ЭТО? Суть вопроса в чём?

Зачем отказываться от "состояний" и "императивных конструкций".

Зачем "усложнять себе жизнь". Спрашивал я.

Только ради "чистоты арийской расы"? Только ради "применения чистого функционального программирования"?

Я не спорю, что ЛЮБОЙ язык без состояний и императивных конструкций является ФУНКЦИОНАЛЬНЫМ. (Хотя - как же "монады"? Это разве не "императивная надстройка? Сейчас меня побьют ногами...)

Но! Вот давайте возьмём Паскаль. На нём можно программировать в ФУНКЦИОНАЛЬНОМ СТИЛЕ (согласно ПРИВЕДЁННОМУ ВЫШЕ ОПРЕДЕЛЕНИЮ)?

Можно?

Ну в общем - в большинстве случаев - МОЖНО.
НУЖНО ЛИ? Ну наверное - В БОЛЬШИНСТВЕ случаев - НУЖНО.

Зачем?

Для того чтобы повысить стабильность кода.

Согласен.

Является ли Паскаль после этого "функциональным языком"?

Я - НЕ ЗНАЮ.

Хотелось бы услышать мнение моего оппонента.

Что же говорил я?
 В чём СУТЬ разногласий?

Я говорил примерно следующее - "ТЕОРИЯ - это ХОРОШО. Отсутствие состояний и "императивных конструкций" - ЗДОРОВО. НО ЗАЧЕМ?

Давайте "погрузимся в байты". Говорил я.

Давайте прочитаем СЛЕДУЮЩИЙ АБЗАЦ.

Вот он:
"На практике отличие математической функции от понятия «функции» в императивном программировании заключается в том, что императивные функции могут опираться не только на аргументы, но и на состояние внешних по отношению к функции переменных, а также иметь побочные эффекты и менять состояние внешних переменных. Таким образом, в императивном программировании при вызове одной и той же функции с одинаковыми параметрами, но на разных этапах выполнения алгоритма, можно получить разные данные на выходе из-за влияния на функцию состояния переменных. А в функциональном языке при вызове функции с одними и теми же аргументами мы всегда получим одинаковый результат: выходные данные зависят только от входных. Это позволяет средам выполнения программ на функциональных языках кешировать результаты функций и вызывать их в порядке, не определяемом алгоритмом и распараллеливать их без каких-либо дополнительных действий со стороны программиста (см.ниже Чистые функции)"

Отсутствие СОСТОЯНИЙ, т.е. ДЕТЕРМИНИРОВАННОСТЬ - она КОНЕЧНО ВЕДЁТ к стабильности кода "самого по себе".

Представим язык "без глобальных переменных" и всё - СТАНЕТ ЯСНО.

И ТУТ - мой оппонент - ПРАВ!

БЕЗ глобальных переменных - СТАБИЛЬНОСТЬ повышается.

Но! Спрашивал я.

Не МНОГИМ ли мы жертвуем ОТКАЗЫВАЯСЬ от "состояний" и "императивных конструкций"?

ЗАРАДИ ЧЕГО такие жертвы?

Не РАДИ ли - кешируемости, параллелизма и оптимизации порядка выполнения?

Не ЭТО ли должно быть ПОСТАВЛЕНО ВО ГЛАВУ УГЛА?

Т.е. "отсутствие состояний" и "императивных конструкций" - это ОПРЕДЕЛЕНИЕ. Но! ОПРЕДЕЛЕНИЕ - определят ли ПАРАДИГМУ и СУТЬ функциональных языков.

По-моему - НЕТ.

По-моему - ГЛАВНОЕ как раз, что "мы жертвуем состояниями и императиивностью" ВО ИМЯ "кешируемости, параллелизма и оптимизации порядка выполнения (в частности хвостовой рекурсии").

ВО ИМЯ возможности БОЛЕЕ ЭФФЕКТИВНЫХ вычислений.

А ИНАЧЕ - ЗАЧЕМ ВСЯ эта функциональная парадигма? Чем она ЛУЧШЕ ИМПЕРАТИВНОЙ?

Глобальные переменные - ОТЛОЖИМ В СТОРОНУ. Тут - Я СОГЛАСИЛСЯ. Они - УХУДШАЮТ СТАБИЛЬНОСТЬ.

Если следовать "чистой теории", то "кастрированный" Паскаль - ведь является функциональным языком?

ЯВЛЯЕТСЯ? Я - не знаю. Вопрос к моему оппоненту. Мне кажется, что - ЯВЛЯЕТСЯ.

Могу ошибаться.

Многие ли люди согласятся программировать на подобном языке? Получат ли они выгоду?

Мне кажется, что - нет.

Могу ошибаться.

Так "функциональность языка" это ли лишь "отсутствие состояний и императивных конструкций". Или всё же функциональность "подразумевает" - "кешируемость, параллелизм и оптимизацию вычислений"?

Не знаю.

Для меня - ВОПРОС ОТКРЫТ.

За данный вопрос я получил "ярлык" - "ты придумываешь свои определения".

Может быть.

Только - НЕ ПРИДУМЫВАЮ, а ПЫТАЮСЬ ПОНЯТЬ.

Ну и ещё я получил упрёк - "ты всюду пихаешь свой Форт и форт-машину".

Опять же - НЕ "пихаю". А ПЫТАЮСЬ поделиться.

Я - НЕ НАВЯЗЫВАЮ НИЧЕГО.

Я лишь пишу - О ЧЁМ ЗНАЮ.

Когда мне говорят - "никто не просил помогать" - ну грустно, чего уж...

НЕ просил - простите. Больше не буду.

Я может быть только "неправильно выражаюсь". Форт и форт-машина - всё же РАЗНЫЕ вещи, хотя и связанные.

Точнее даже - "стековая-машина".

Ну практически все компиляторы - ПОСТРОЕНЫ на ней. Ну читаем например статью Болье - "методы построения компиляторов".

И когда я писал про форт-машину - я НИКОИМ ОБРАЗОМ не имел в виду - "разбор токенов по пробелам" или "обратную польскую запись". Эти ЧАСТНОСТИ - УЖЕ сильно выше. В реализации. Я имел в виду лишь стековую-машину и "словарь".

То и другое, так или иначе - присутствует во всех современных компиляторах.

Иногда словарь называется "деревом разбора".

(Или я опять "придумываю собственные определения"?)

Пи-код, байт-код и прочее и прочее - всё из одной и той же области.

И если я ПРЕДЛАГАЛ, для РЕАЛИЗАЦИИ функционального языка использовать форт-машину (стековую-машину) это НЕ ЗНАЧИТ, что я предлагал ОТКАЗАТЬСЯ от ФУНКЦИОНАЛЬНОСТИ. Просто мне КАЗАЛОСЬ, что для КОНКРЕТНОЙ реализации - она очень даже МОЖЕТ ПОДОЙТИ.

http://ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%80%D1%82_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

Испытал влияние:	АПЛ, Лисп

http://ru.wikipedia.org/wiki/Erlang
"Erlang [ˈɜːlæŋ] — Э́рланг — функциональный язык программирования с динамической типизацией, предназначенный для создания распределённых вычислительных систем. Разработан и поддерживается компанией Ericsson. Язык включает в себя средства порождения параллельных процессов и их коммуникации с помощью асинхронных сообщений и в соответствии с моделью акторов. Программа транслируется в байт-код, исполняемый виртуальной машиной, что обеспечивает переносимость. Кратко формулу языка можно выразить как Erlang = функциональный язык + процессы."

http://ru.wikipedia.org/wiki/Haskell
"

• YHC (York Haskell Compiler) — форк nhc98, ставящий целью быть более переносимым и эффективным, поддерживает отладчик Hat; генерирует промежуточный байт-код, который можно использовать для генерации кода на других языках программирования"

Всё - взаимосвязано..

Посему резюме:
1. ДОСТАТОЧНЫМ ли условием ЯВЛЯЕТСЯ для "функциональности" языка - ОТСУТСТВИЕ "состояний и императивных конструкций".
2. Можно ли строить "функциональные" языки - на стековой-машине.

-- эти вопросы я оставляю ОТКРЫТЫМИ.

Для своего оппонент скажу лишь. ИМЕННО это я и имел в виду, когда всё писал.
НИ БОЛЬШЕ, НИ меньше.

И никого "поучать" и в мыслях - НЕ БЫЛО.