С недавних пор появилась толика свободного времени, и дабы не заскучать решил несколько утолить свой интерес к функциональному программированию, благо во многих неспециализированных, в отличие от этого, топиках как например ФП или некоторые другие упоминаний об нем и/или его приемах предостаточно, а я, признаться, имею только крайне абстарктное представление о нем и всех немайнстримовых языках фигурирующих на RSDN, имющих отношение к функциональной парадигме, таких как Nemerle, Erlang, Haskell, Scala и пр. В связи с этим пришлось систематизировать доступную мне информацию в данной области с целью раставить все точки на "i" в вопросе что есть что, и зачем оно надо. Сам не заметил как в процессе систематизации полуилось что-то путное (по моему, сугубо личному мнению). Решил оформить это в виде небольшой статьи.
К общественности большая просьба указать мне на те неточности и/или некорректные факты, которые имеют место быть в сем манускрипте с целью личного личного удовлетворения и избавления от в корне неправильного понимания предметной области в самом начале интересования ею. Так же буду благодарен за информацию которая по каким-то причинам была мною упущена из вида. Ну и конечно, может кому то, это как и мне будет полезно и/или интересно, такое просвещение
Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный. Он динамический, типобезопасный и функциональный. ВМ только заточена на параллелизм.
Вот Скала и Немерле много логичней тут, насчёт Питона тож сомнения
Здравствуйте, Курилка, Вы писали:
К>Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный.
в доступных мне источниках про Erlang говорят:
...concurrent, functional, distributed...
причем все это рассматривают в роли парадигм... вроде. В одних источниках он фигурирует как мультипарадигменный, в других просто как функциональный, в третьих еще как то... Но поскольку наличием только лишь функционального подхода он не ограничивается, то почему же его нельзя назвать мультипарадигменным?
К>насчёт Питона тож сомнения
Ну а как же тогда с наличием кортежей и средств функционального программирования: filter(), map(), zip() и reduce()
к тому же в книге Г.Россум, Ф.Л.Дж.Дрейк, Д.С.Откидач "Язык программирования Python" — авторы недвусмысленно намекают на то, что в питоне есть немного от функционального программирования.
Здравствуйте, sharcUs, Вы писали:
U>в доступных мне источниках про Erlang говорят: U>
U>...concurrent, functional, distributed...
U>причем все это рассматривают в роли парадигм... вроде. В одних источниках он фигурирует как мультипарадигменный, в других просто как функциональный, в третьих еще как то... Но поскольку наличием только лишь функционального подхода он не ограничивается, то почему же его нельзя назвать мультипарадигменным?
Сам язык является довольно простым динамически типизированным функциональным.
Просто у его ВМ "заточка" под параллелизм и распределённость, т.е. область применения у него такая. Он, конечно, универсальный язык, но вот довольно тупо использовать его для несвойственных ему областей применения.
Имхо оснавная парадигма там функциональная, т.к. она больше всего подходит для такого рода приложений.
Так что не вижу откуда тут "мульти" взяться.
К>>насчёт Питона тож сомнения U>Ну а как же тогда с наличием кортежей и средств функционального программирования: filter(), map(), zip() и reduce() U>к тому же в книге Г.Россум, Ф.Л.Дж.Дрейк, Д.С.Откидач "Язык программирования Python" — авторы недвусмысленно намекают на то, что в питоне есть немного от функционального программирования.
Если так подходить, то и в ассемблере ФП можно найти
Вообще во многих языках есть разные черты, просто определяющий момент — насколько они "родные", т.е. насколько востребованы и используются подобные "фичи", мапы и фильтры — это хорошо, но вот как часто "питонисты" пишут при помощи ФВП, т.е. сами эти ФВП, а не просто исопльзуют штатные.
Ещё по тексту:
Суть подхода состоит в том, что программа представляет собой не набор команд, а описание действий, которые необходимо осуществить.
одно и то же противопоставляешь? При декларативном подходе описывается по сути результат, который хочется получить, скажем в селекте сиквельном условия пишутся — ну скажи где там "описание действий"? Это описание было бы империтивом.
Ещё — с какого вдруг любая функция есть ФВП?
Про лямбда-исчисление и комбинаторную логику как-то очень мутно написано, я не понял, что ты хотел сказать — что за анализ вычислимости? Ты о чём?
Про "обычную" короткость функциональных программ — это далеко не обязательно. Бывают ситуации когда это так, но бывает и наоборот.
Сборщик мусора к ФП прямого отношения не имеет. Суть в том, что при функциональном подходе по идее нет изменяемых ячеек памяти, поэтому нельзя делать new/delete.
Про обязательность строгой типизации не совсем понял. Может имелась в виду статическая типизация? Если ты уж про вывод типов говоришь.
Если так, то дофигищи языков функциональных без оной — тот же эрланг, все лиспы и др.
Про адаптированность функций без побочных эффектов — странная формулировка, никто там ничего не адаптирует, просто функциии могут выполняться независимо.
Про медленность и меньшие трудозатраты — очень большой вопрос. Про медленность — смотря с чем сравнивать и как. А трудозатраты порой ой какие нехилые, скажем посмотри сколько компилированный хэллоуворлд на хаскеле весит.
Дальше надоело смотреть — слишком много спорных и странных предложений да и спать пора.
U>К общественности большая просьба указать мне на те неточности и/или некорректные факты, которые имеют место быть в сем манускрипте с целью личного личного удовлетворения и избавления от в корне неправильного понимания предметной области в самом начале интересования ею.
Императивный подход имеет много общего с естественными языками, поэтому он достаточно понятен для понимания, и языки программирования базирующиеся на нем легче поддаются изучению.
Ну, это голословное утверждение, т.е. это Ваше мнение об этих языках и о возможностях других людей что-то изучать.
Суть подхода состоит в том, что программа представляет собой не набор команд, а описание действий, которые необходимо осуществить.
Курилка уже отметил некоторую неточность высказанной выше мысли, добавлю, что в декларативном программировании мы описываем цель, которую хотим достигнуть, но не способ её достижения.
Такой подход существенно проще и прозрачнее формализуется математическими средствами и, как следствие требует для понимания гораздо более высокую математическую подготовку.
см. выше.
Одним из путей развития декларативной парадигмы стал функциональный подход к программированию.
+1, ибо иногда декларативность и функциональность объединяют в нечто единое целое, что, судя по общепринятой классификации, не правильно.
О сборщике мусора и строгой типизированности, о "любая функция есть суть ФВП" Курилка уже сказал.
. Я не в коей мере не хочу сказать, что Вы не читали этих работ (даже если это и так ), просто считается "хорошим тоном" ссылаться на имеющиеся работы в рассматриваемой области.
Здравствуйте, Курилка, Вы писали:
К>Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный. К> насчёт Питона тож сомнения
По поводу Erlang очевидно Вы правы и мультипарадигменность это громко сказано, просто главной мыслью было то, что в нем сочетаются различные подходы, в том числе и функциональный, а Python без сомнение далек от функционального, и упомянув его по причине того, что хотел сказать, что функциональноый подход также оказал на него некоторое влияние, что и было воплощено в некоторых его особенностях. А то что это не используется, это уже другое дело, ведь я и сам отдаю себе отчет в том, что он далек от функционального.
К>одно и то же противопоставляешь?
Хм, по тексту практически так и получается Мысль которую я хотел выразить заключалась в том, что в отличие команд в императивном подходе, последовательность которых строго определена и по сути описывает перечень инструкци процессору, описание декларативной операции(-ий) не предполагает такой строгой последовательности и носит больше математическую семантику
К>Ещё — с какого вдруг любая функция есть ФВП?
При написании этого я исходил из того, что по сути в ФП любая сущность является функцией, поэтому функция, имющая аргументы может называтся ФВП.
К>Про лямбда-исчисление и комбинаторную логику как-то очень мутно написано, я не понял, что ты хотел сказать — что за анализ вычислимости? Ты о чём?
с математической точки зрения основой лямбда-исчисления является понятие конверсии, то есть преобразование объектов исчисления к более компактному или более детальному виду, применительно к ФП насколько я понимаю это стало базисом для выведения функций и их формализации, комбинаторная логика — по природе своей теория функций без переменных, в ФП она используется для вывода типа результата в выражения, как я и написал в своей статье. Повторюсь, с ФП знаком только поверхностно, на уровне данного манускрипта, практики использования языков не имею, поэтому если я тут что-то не то говорю, прошу меня поправить
К>Про "обычную" короткость функциональных программ — это далеко не обязательно. Бывают ситуации когда это так, но бывает и наоборот.
Ну так то оно так, но приближенность ФП к математический семантике во многих случая делают его более лаконичным. Есстественно все зависит от решаемой задачи.
К>Про обязательность строгой типизации не совсем понял. Может имелась в виду статическая типизация? Если ты уж про вывод типов говоришь.
По правде говоря не нашел в статье ничего о обязательности строгой типизации. Если вы о "Большинство функциональных языков являются строго типизированными..." то как я понимаю, это и является синонимом статической типизации, поскольку в ФП все переменные являются неизменяемыми и динамической типизацией обладать не могут. Строгой типизацией называют одно из свойств ФП Душкин и здесь
(а когда вторая будет? Форумы RSDN (генератор интереса к ФП) Википедия (с очень большой опаской, в основном только для правильного формулирования мыслей)
Изучив весь этот материал, думаю можно будет и с VladD2'ом спорить в ФП
Здравствуйте, sharcUs, Вы писали:
U>По поводу Erlang очевидно Вы правы и мультипарадигменность это громко сказано, просто главной мыслью было то, что в нем сочетаются различные подходы
Можно конкретнее?
Где там подход "различный" по отношению к ФП?
Просто чистофункциональные языки как-то должны общаться с реальным миром, поэтому там появляются "нечистые" вещи, но это же не делает хаскел объектно-ориентированным
К>>Ещё — с какого вдруг любая функция есть ФВП? U>При написании этого я исходил из того, что по сути в ФП любая сущность является функцией, поэтому функция, имющая аргументы может называтся ФВП.
С теоретической точки зрения, конечно, можно числа функциями представить, но с практической нафиг это не упало. А если так, то как функция сложения у тебя получается ФВП?
К>>Про лямбда-исчисление и комбинаторную логику как-то очень мутно написано, я не понял, что ты хотел сказать — что за анализ вычислимости? Ты о чём? U>с математической точки зрения основой лямбда-исчисления является понятие конверсии, то есть преобразование объектов исчисления к более компактному или более детальному виду, применительно к ФП насколько я понимаю это стало базисом для выведения функций и их формализации, комбинаторная логика — по природе своей теория функций без переменных, в ФП она используется для вывода типа результата в выражения, как я и написал в своей статье. Повторюсь, с ФП знаком только поверхностно, на уровне данного манускрипта, практики использования языков не имею, поэтому если я тут что-то не то говорю, прошу меня поправить
Практику нарабатывать надо — очень помогает с практической стороны понять о чём говоришь. Про конверсию и более компактный (и как-то при этом более детальный) вид опять не понял — как ты объеденяешь необъединимое? Может я тупой, но что-то я не улавливаю мысль опять же.
К>>Про "обычную" короткость функциональных программ — это далеко не обязательно. Бывают ситуации когда это так, но бывает и наоборот. U>Ну так то оно так, но приближенность ФП к математический семантике во многих случая делают его более лаконичным. Есстественно все зависит от решаемой задачи.
Тогда не приводи квантор всеобщности
А то так фанатичностью веет, любой язык имеет свою нишу, свои плюсы и минусы. Также и функциональный подход — иногда полезный, иногда нет. Серебряной пули не бывает.
К>>Про обязательность строгой типизации не совсем понял. Может имелась в виду статическая типизация? Если ты уж про вывод типов говоришь. U>По правде говоря не нашел в статье ничего о обязательности строгой типизации. Если вы о "Большинство функциональных языков являются строго типизированными..." то как я понимаю, это и является синонимом статической типизации, поскольку в ФП все переменные являются неизменяемыми и динамической типизацией обладать не могут. Строгой типизацией называют одно из свойств ФП Душкин и здесь
Не путай понятия — строкая и статическая типизация — вещи разные. Скажем есть тот же Эрланг, типизация строгая, но динамическая.
скажем функция элеметная идентити
id(X) -> X.
Какой тип имеет X? Строковый? Числовой?
Он будет определяться в момент вызова функции, скажем если id(2) — числовой, id("a") — строковый.
Есть конечно вывод типов в MLях, хаскеле и не только. Вот там именно статическая типизация.
Но это иной подход, а у тебя как-то слишком обще получается и поэтому непонятно и спорно, имхо
К>>Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный. U>в доступных мне источниках про Erlang говорят: U>
U>...concurrent, functional, distributed...
Насколько понимаю, "мультипарадигменный" означает что можно использовать по своему выбору одну из нескольких парадигм.
Т.е. например как "желтый или синий", понятия одного типа между которыми надо выбирать.
А в твоей цитате "желтый, сладкий и квадратный" — понятия ортогональные, они все одновременно присутствуют и определают одну "парадигму" — конкурентную и функциональную и распределённую одновременно.
К>>насчёт Питона тож сомнения U>Ну а как же тогда с наличием кортежей и средств функционального программирования: filter(), map(), zip() и reduce()
Тогда не забывай JavaScript
Замыкания, создание функция на лету.... http://dklab.ru/chicken/nablas/39.html#cont0
Здравствуйте, sharcUs, Вы писали:
К>>Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный. U>в доступных мне источниках про Erlang говорят: U>
U>...concurrent, functional, distributed...
Термины concurrent и distributed из одной оперы и к парадигме не относятся. Это сокорее специализация зыка. Паралелизм можно встроить и в императивный язык (например, в АДА встроен механизм рандеву).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, sharcUs, Вы писали:
U>Хм, по тексту практически так и получается Мысль которую я хотел выразить заключалась в том, что в отличие команд в императивном подходе, последовательность которых строго определена и по сути описывает перечень инструкци процессору, описание декларативной операции(-ий) не предполагает такой строгой последовательности и носит больше математическую семантику
Вот и учти замечание. Замени "описание действий" (или как там у тебя?) "на описание желаемого результата".
Кстати по большому счету это обман. Функциональные языки так же в основном описывают вычисления которые нужно произвести. Просто в них есть возможности которые деустивительно декларативны. Одна из них — это паттерн-мачинг. Вот он действительно описывает то что мы хотим получить в виде паттерна. В остальном ФЯ довольно императивны . Скажем я не вижу разницы между фиклом записанным с помощь конструкций wile/for или рекурсивной функции.
Реальную краткость функциональному коду придают манипуляции с функциями (в том числе массовое использование ФВП и замыканий) и паттерн-матчинг. Остальное все от лукавого.
К>>Ещё — с какого вдруг любая функция есть ФВП? U>При написании этого я исходил из того, что по сути в ФП любая сущность является функцией, поэтому функция, имющая аргументы может называтся ФВП.
Это математический булшит. В ЯП все не может быть функцией иначе вообще нет смысла в вычислениях. Функцию на хлеб не намажешь .
К тому же даже если дойти до такого маразма и начать думать о числах как о функциях, то все равно будут примитивные фукнции которые не являются ФВП. ФВП обазана принимать или возвращать другие функции. А скажем функция "1" ничего не делает. Она является литералом.
В общем, оставь абстрактные рассуждения для математиков. Не отнимай у них их горбушку.
К>>Про обязательность строгой типизации не совсем понял. Может имелась в виду статическая типизация? Если ты уж про вывод типов говоришь. U>По правде говоря не нашел в статье ничего о обязательности строгой типизации. Если вы о "Большинство функциональных языков являются строго типизированными..." то как я понимаю, это и является синонимом статической типизации, поскольку в ФП все переменные являются неизменяемыми и динамической типизацией обладать не могут. Строгой типизацией называют одно из свойств ФП Душкин и здесь
Значич так... Этот вопрос уже много раз обсуждался у нас в философии. Термин "строгая типизация" нужно выбросить на помойку, так как он неопределенный. Вместо него нужно использоват два определенных термина "статически типизировванный" и "типобезопасный". Так вот ФЯ не обязан быть ни тем, ни другим, хотя большинство ФЯ типобезопасны. Со статической типизацией все еще проще. Есть ФЯ статически типизированные, а есть динамически. Никаой зависимости тут нет. Эрлэнг динамический, а скажем ОКамл статический (даже черезчур). Причем есть и промежуточные решения. Так есть языки которые если что позволяют и переключаться на динамику. Например в Немерле есть макрос late позволющий написать динамический кусок. А в Boo по умолчанию типы выводятс, но если они не могут вывестись, то код автоматически становится динамически типизированным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
К>>Сильно не вчитывался, но довольно странно видеть строку о том, что Эрланг мультипарадигменный. К>> насчёт Питона тож сомнения
M>Вполне себе мультипарадигменный. А чего бы нет ?
Согласен. Одинаково плохо поддерживает много парадигм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
U>>По поводу Erlang очевидно Вы правы и мультипарадигменность это громко сказано, просто главной мыслью было то, что в нем сочетаются различные подходы К>Можно конкретнее? К>Где там подход "различный" по отношению к ФП?
Ну если concurrent и distributed не воспрепятствуют природе ФП и являются лишь ортогональным дополнением, то ко всему прочему можно отметить, что Erlang появился в результате попыток расширить возможности языка Prolog, с целью реализации в нем параллелизма. А сам Prolog является языком использующим логическую семантику, и основан на исчислении предикатов. В связи с чем я так предполагаю, что в Erlang много чего осталось от Prolog. источник
U>>При написании этого я исходил из того, что по сути в ФП любая сущность является функцией, поэтому функция, имющая аргументы может называтся ФВП. К>С теоретической точки зрения, конечно, можно числа функциями представить, но с практической нафиг это не упало. А если так, то как функция сложения у тебя получается ФВП?
К сожалению я сейчас могу вести дискуссию только с точки зрения теории, поэтому возможно не совсем отдаю себе отчет в разнице между теоретической ФВП и той которая имеет место на практике.
К>Про конверсию и более компактный (и как-то при этом более детальный) вид опять не понял — как ты объеденяешь необъединимое? Может я тупой, но что-то я не улавливаю мысль опять же.
Мои доводы основаны на сугубо математическом понятии лямбды. То что есть в ФП наверняка отличается от этого, что и сеет Ваше недопонимание
Думаю, если бы я и сам пересмотрел свою статью скажем через месяц, после некоторго практичекого использования ФП, то многие вещи стали бы понятнее и Вам(то есть читателю) в плане того, что и как там было бы написано. Поэтому очевидно так и стоит поступить а там глядишь и новая редакция с дополнением практической части появится — систематизирвать то все равно придеться
К сожалению данное семейство также не является чисто функциональным.
А>В заключении: А>
Поэтому нет смысла сравнивать эти подходы или противопоставлять, гораздо лучше их совместить
Просто при беглом обзоре языков, акцентировалось внимание на том является ли язык чисто фунциональным, возможно с целью поиска максимально близкого к эталонному ФЯ, инетерес был вызван чисто академическими соображениями. В конце статьи делаются выводы относительно того, что наиболее рациональным использованием ФП является его совмещение с ИЯ, что и нашло отражение во многих существующих языках. Поэтому никакого противоречия я не вижу.
Здравствуйте, sharcUs, Вы писали:
U>Ну а как же в С# все является объектом: U>
U> "string".ToCharArray()
U>
Кто сказал все? Попробуй сделать что нибудь с конструкцией, скажем, class.
U>почему в ФЯ нестоит рассматривать все как функции? Я понимаю, крайности это всегда чревато... но все же.
Потому что крайности... ну ты понял .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>К тому же даже если дойти до такого маразма и начать думать о числах как о функциях, то все равно будут примитивные фукнции которые не являются ФВП. ФВП обазана принимать или возвращать другие функции. А скажем функция "1" ничего не делает. Она является литералом.
Она принимает функцию и аргумент и применяет эту функцию 1 раз к аргументу. Функция 2 — применяет два раза; функция 0 — 0 раз (возвращает аргумент).
VD>В общем, оставь абстрактные рассуждения для математиков. Не отнимай у них их горбушку. :)
Кстати, давно хотел задать вопрос. Если я буду писать на чистом Си без использования любых глобальных и статических переменных — будет ли это функциональным подходом или нет? Если нет, то почему не является?
