Вот ссылка. В принципе там нет ничего, что опровергало бы мои доводы, изложенные чуть ниже.
Показаны сообщения с ярлыком Функциональное программирование. Показать все сообщения
Показаны сообщения с ярлыком Функциональное программирование. Показать все сообщения
Функциональное программирование, свежий взгляд на вещи (часть 2)
2-ая часть обсуждения. Обратимся к Википедии. Избранные цитаты из нее:
"Функциональное программирование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании). Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательность изменения состояний (в значении, подобном таковому в теории автоматов). Функциональное программирование не предполагает изменяемость данных (в отличие от императивного, где одной из базовых концепций является переменная)."
"Многие нефункциональные языки, такие как C, C++ и C# могут вести себя как функциональные при использовании указателей на функцию"
"Основной особенностью функционального программирования, определяющей как преимущества, так и недостатки данной парадигмы, является то, что в ней реализуется модель вычислений без состояний. Если императивная программа на любом этапе исполнения имеет состояние, то есть совокупность значений всех переменных, и производит побочные эффекты, то чисто функциональная программа ни целиком, ни частями состояния не имеет и побочных эффектов не производит. То, что в императивных языках делается путём присваивания значений переменным, в функциональных достигается путём передачи выражений в параметры функций. Непосредственным следствием становится то, что чисто функциональная программа не может изменять уже имеющиеся у неё данные, а может лишь порождать новые путём копирования и/или расширения старых. Следствием того же является отказ от циклов в пользу рекурсии."
"Привлекательная сторона вычислений без состояний — повышение надёжности кода за счёт чёткой структуризации и отсутствия необходимости отслеживания побочных эффектов. Любая функция работает только с локальными данными"
Какие отсюда следуют выводы?
1) Очевидно, что ФП и ООП - мягко говоря, слабо совместимы.
2) Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.
3) Давайте уберем из ФП - функции, оставим одни переменные, и тогда получим не 2D-программирование, а 1D-программирование. Вот вам и та часть Ассемблера, в которой мы присваиваем переменные в регистрах (другие возможности Ассемблера сейчас опустим).
4) Можно и не использовать процедурный подход при программировании в ФП. В таком случае "весь поток выполнения программы" - будет представлять собой постоянное присваивание и рекурсивные вызовы там, где нужно обработать циклом.
Это уже вообще НЕЧТО. - Если не заботиться о том, чтобы некоторые фрагменты кода можно было использовать несколько раз (а тогда получается процедурное программирование).
И это "круто"?! :)
"Функциональное программирование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании). Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательность изменения состояний (в значении, подобном таковому в теории автоматов). Функциональное программирование не предполагает изменяемость данных (в отличие от императивного, где одной из базовых концепций является переменная)."
"Многие нефункциональные языки, такие как C, C++ и C# могут вести себя как функциональные при использовании указателей на функцию"
"Основной особенностью функционального программирования, определяющей как преимущества, так и недостатки данной парадигмы, является то, что в ней реализуется модель вычислений без состояний. Если императивная программа на любом этапе исполнения имеет состояние, то есть совокупность значений всех переменных, и производит побочные эффекты, то чисто функциональная программа ни целиком, ни частями состояния не имеет и побочных эффектов не производит. То, что в императивных языках делается путём присваивания значений переменным, в функциональных достигается путём передачи выражений в параметры функций. Непосредственным следствием становится то, что чисто функциональная программа не может изменять уже имеющиеся у неё данные, а может лишь порождать новые путём копирования и/или расширения старых. Следствием того же является отказ от циклов в пользу рекурсии."
"Привлекательная сторона вычислений без состояний — повышение надёжности кода за счёт чёткой структуризации и отсутствия необходимости отслеживания побочных эффектов. Любая функция работает только с локальными данными"
Какие отсюда следуют выводы?
1) Очевидно, что ФП и ООП - мягко говоря, слабо совместимы.
2) Очевидно, что ФП подразумевает, на практике, процедурный подход в программировании. Нюанс, о чем не указано в Википедии - что вы передаете не объекты, а функции, в теле программы, что вы ВЫНУЖДЕНЫ будете использовать подпрограммы.
3) Давайте уберем из ФП - функции, оставим одни переменные, и тогда получим не 2D-программирование, а 1D-программирование. Вот вам и та часть Ассемблера, в которой мы присваиваем переменные в регистрах (другие возможности Ассемблера сейчас опустим).
4) Можно и не использовать процедурный подход при программировании в ФП. В таком случае "весь поток выполнения программы" - будет представлять собой постоянное присваивание и рекурсивные вызовы там, где нужно обработать циклом.
Это уже вообще НЕЧТО. - Если не заботиться о том, чтобы некоторые фрагменты кода можно было использовать несколько раз (а тогда получается процедурное программирование).
И это "круто"?! :)
Функциональное программирование, свежий взгляд на вещи (часть 1)
По моему скромному убеждению, функциональное программирование, это, своего рода - 2D-программирование. В программировании, с использованием ООП, у нас есть не только функции (методы), но и классы. Это дополнительное измерение (классы) - и дает 3D.
Это в контексте самого стиля программирования.
Бывают и функциональные языки, например в MS Visual Studio 2010 был введен фунциональный язык программирования F#.
Кратко его можно охарактеризовать так - "write once" (написал один раз, потом фиг разберешь что написал).
Из функции стараются сделать объект, которым и пытаются оперировать, поелику это представляется возможным. Со всеми вытекающими.
Здесь можно выделить 2 следующих момента:
1) Функциональные языки программирования зародились ранее, чем ООП-подход. Устаревшее, успело развиться, и раз уцелело до наших дней, значит там не только "попытки разными путями придать функции 3D-измерение", некоторые вещи там могут показаться любопытными.
2) Попытки же сейчас возрождать функциональное программирование - продиктовано кажущимся многим низким порогом вхождения в такое программирование. Т.к. потом такой код разобрать бывает невероятно сложно, то программисты этих языков - неизбежно должны упираться, что более пару тысяч строк в программе - они не могут написать и эффективно их поддерживать. Как раз, чтобы поднять планку сложности гораздо выше для программистов - и была придумана ООП-парадигма.
Забавный материал прилагается
P.S. В древние времена были популярны шаманы, пытающиеся толковать те или иные природные явления, что они означают. Позднее некоторые наблюдения вошли в обиход - "Солнце красно с вечера - моряку бояться нечего", "Солнце красно по утру - моряку не по нутру", "Если чайка села в воду - жди хорошую погоду", "Чайка ходит по песку - моряку сулит тоску". Почувствуй себя шаманом - интерпретируй результат Google.
Это в контексте самого стиля программирования.
Бывают и функциональные языки, например в MS Visual Studio 2010 был введен фунциональный язык программирования F#.
Кратко его можно охарактеризовать так - "write once" (написал один раз, потом фиг разберешь что написал).
Из функции стараются сделать объект, которым и пытаются оперировать, поелику это представляется возможным. Со всеми вытекающими.
Здесь можно выделить 2 следующих момента:
1) Функциональные языки программирования зародились ранее, чем ООП-подход. Устаревшее, успело развиться, и раз уцелело до наших дней, значит там не только "попытки разными путями придать функции 3D-измерение", некоторые вещи там могут показаться любопытными.
2) Попытки же сейчас возрождать функциональное программирование - продиктовано кажущимся многим низким порогом вхождения в такое программирование. Т.к. потом такой код разобрать бывает невероятно сложно, то программисты этих языков - неизбежно должны упираться, что более пару тысяч строк в программе - они не могут написать и эффективно их поддерживать. Как раз, чтобы поднять планку сложности гораздо выше для программистов - и была придумана ООП-парадигма.
Забавный материал прилагается
P.S. В древние времена были популярны шаманы, пытающиеся толковать те или иные природные явления, что они означают. Позднее некоторые наблюдения вошли в обиход - "Солнце красно с вечера - моряку бояться нечего", "Солнце красно по утру - моряку не по нутру", "Если чайка села в воду - жди хорошую погоду", "Чайка ходит по песку - моряку сулит тоску". Почувствуй себя шаманом - интерпретируй результат Google.
Подписаться на:
Сообщения (Atom)