Как стать автором
Обновить

Комментарии 15

А еще, может быть, рекурсию вместо циклов и рекурсивные декларации типов данных? Ранние Cobol, Fortran, PL / I такое ведь вовсе не умели))

Да, согласен рекурсию можно было включить в этот список. То что функции могут вызывать сами себя все давно уже воспринимают как данность, поэтому о ней не подумали при написании.

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

Мне это видится довольно неудачным примером (когда я столкнулся с этим - начав изучать FP с решения задачек на Haskell).

Вот сценарий: обычный вложенный цикл (с общей головой), который неудобно сократить в виде map / fold / ....

При переписывании через рекурсию превращается вот в такое:

f args = if something then f (prepare_args args) else g args

Не знаю как людям давно с FP знакомым, но мне это представляется крайне "синтаксически контринтуитивным". Нет понимания того, что функция g() - вложенная относительно f(), т.к. из f() вызывается как она сама, так и g()

обычный вложенный цикл (с общей головой), который неудобно сократить в виде map / fold / ...

Можете привести код?

Да здравствует FORTH!

гослинг изначально собирал команду для создания жавы из фортеров

потом подключили сишников, просто потому что внутреннее устройство и внешний вид кода никак не связано

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

пришлось нивелировать идею контекстов до классов а кодеров - до программистов

Спасибо за статью!

Пользуясь случаем, спрошу у более знающих коллег: а как вообще определить что такое ФП-стиль? Не через признаки, а через суть?

Я для себя некоторое время назад некое подобие определения сформулировал, но я всё же совсем не специалист в этом всём, поэтому буду рад, если кто-нибудь скажет, прав ли я.

По мне так императивное программирование основано на машине Тьюринга: мы всё равно мыслим некоего исполнителя и некую ленту-память, и исполнитель исполняет некоторый набор команд, меняя состояние памяти.

Функциональное же программирование основывается на лямбда-исчислении. У нас уже нет ни исполнителя, ни памяти, ни состояний, ни команд, а есть некоторый текст (программа) и правила его редукции. И "выполнение" есть просто редуцирование текста в нормальную форму. В идеале (если я правильно помню, если наше исчисление (язык) сильно нормализуемо) порядок редукций не влияет на результат, так что слово "выполнение" лучше писать в кавычках.

Меня смущает то, что, как мне кажется, моё понимание этой всей терминологии противоречит тому, как она обычно применяется, поэтому мне кажется, что я ошибаюсь.

императивное программирование основано на машине Тьюринга

...

Функциональное же программирование основывается на лямбда-исчислении.

https://ko.com.ua/-ischislenie_33286

Лямбда-исчисление - это тоже абстрактная машина Тьюринга.

Прокомментирую.

"[...]Лямбда-исчисление — это не язык программирования, а формальный аппарат, способный определить в своих терминах любую языковую конструкцию или алгоритм. В этом смысле оно созвучно машине Тьюринга, только соответствует функциональной парадигме, а не императивной."

https://habr.com/ru/post/215807/

Вы сами очень хорошо описали суть функционального и императивного программирования, я использую такое же интуитивное представление об этих стилях при разработке. Вы также правильно заметили что на практике применение ФП слабо напоминает выражения λ-исчисления. Главная причина в необходимости функциональной программы как-то взаимодействовать с окружением (устройствами ввода/ввывода, сетью, базой данных) которые требуют исполнения императивных команд в программе, поэтому в реальных программах присутствуют оба эти стиля (причем в типичном веб-сервере написанном на Haskell императивный код может занимать значительную часть). Большое количество императивного кода все-же не считается хорошим признаком, общепринятое мнение в ФП-коммьюнити то что чистый функциональный код имеет множество преимуществ поэтому более предпочтителен и необходимо иметь абсолютный минимум императивного кода.

Еще одна возможная причина почему реальные функциональные программы не похожи на выражения λ-исчисления, потомучто λ-исчисление — очень плохой язык программирования, он имеет минимум конструкций что удобно для индуктивных доказательств каких-нибудь свойств но в реальной программе хорошо иметь язык с синтаксическим сахаром, конструкциями вроде (let, where, case и т.д.) чтобы иметь шанс прочитать и понять программу написанную другими программистами.

чистый функциональный код

А под "чистым" подразумевается "с контролем побочных эффектов".

Скорее без побочных еффектов, только вычисление какого-то значение без мутаций

"Функция f является чистой если выражение f(x) является ссылочно прозрачным для всех ссылочно прозрачных x"

https://habr.com/ru/post/479238/

нас обучали писать на Вольфраме

это язык символьных вычислений, почти чистое фп

для детей которые в лучшем случае что-то понимали в басике или паскале это был ад

как это - ленивые вычисления? почему эта фигня не делает что я прошу немедленно?

циклы, ифы, циклы, ифы.. и незачеты.. семестр только половина группы закончила.. им так и не удалось усвоить

Зарегистрируйтесь на Хабре, чтобы оставить комментарий