Вы сами очень хорошо описали суть функционального и императивного программирования, я использую такое же интуитивное представление об этих стилях при разработке. Вы также правильно заметили что на практике применение ФП слабо напоминает выражения λ-исчисления. Главная причина в необходимости функциональной программы как-то взаимодействовать с окружением (устройствами ввода/ввывода, сетью, базой данных) которые требуют исполнения императивных команд в программе, поэтому в реальных программах присутствуют оба эти стиля (причем в типичном веб-сервере написанном на Haskell императивный код может занимать значительную часть). Большое количество императивного кода все-же не считается хорошим признаком, общепринятое мнение в ФП-коммьюнити то что чистый функциональный код имеет множество преимуществ поэтому более предпочтителен и необходимо иметь абсолютный минимум императивного кода.
Еще одна возможная причина почему реальные функциональные программы не похожи на выражения λ-исчисления, потомучто λ-исчисление — очень плохой язык программирования, он имеет минимум конструкций что удобно для индуктивных доказательств каких-нибудь свойств но в реальной программе хорошо иметь язык с синтаксическим сахаром, конструкциями вроде (let, where, case и т.д.) чтобы иметь шанс прочитать и понять программу написанную другими программистами.
Да, согласен рекурсию можно было включить в этот список. То что функции могут вызывать сами себя все давно уже воспринимают как данность, поэтому о ней не подумали при написании.
О, круть будем ждать релиза, в ФП кстаки есть функция которая выполняет роль NeverError называется absurd: <A>(x: never) => A. Вот мой вариант этого ts хелпера
Может это просто плохая идея если уже в 1000 раз повторяете а они все не могут вашу молитву выучить?
Скорее без побочных еффектов, только вычисление какого-то значение без мутаций
Вы сами очень хорошо описали суть функционального и императивного программирования, я использую такое же интуитивное представление об этих стилях при разработке. Вы также правильно заметили что на практике применение ФП слабо напоминает выражения λ-исчисления. Главная причина в необходимости функциональной программы как-то взаимодействовать с окружением (устройствами ввода/ввывода, сетью, базой данных) которые требуют исполнения императивных команд в программе, поэтому в реальных программах присутствуют оба эти стиля (причем в типичном веб-сервере написанном на Haskell императивный код может занимать значительную часть). Большое количество императивного кода все-же не считается хорошим признаком, общепринятое мнение в ФП-коммьюнити то что чистый функциональный код имеет множество преимуществ поэтому более предпочтителен и необходимо иметь абсолютный минимум императивного кода.
Еще одна возможная причина почему реальные функциональные программы не похожи на выражения λ-исчисления, потомучто λ-исчисление — очень плохой язык программирования, он имеет минимум конструкций что удобно для индуктивных доказательств каких-нибудь свойств но в реальной программе хорошо иметь язык с синтаксическим сахаром, конструкциями вроде (
let
,where
,case
и т.д.) чтобы иметь шанс прочитать и понять программу написанную другими программистами.Да, согласен рекурсию можно было включить в этот список. То что функции могут вызывать сами себя все давно уже воспринимают как данность, поэтому о ней не подумали при написании.
О, круть будем ждать релиза, в ФП кстаки есть функция которая выполняет роль
NeverError
называетсяabsurd: <A>(x: never) => A
. Вот мой вариант этого ts хелпера