Здравствуйте, deniok, Вы писали:
PM>>на самих SKI-комбинаторах почти никто писать не пытается.
D>Вот тут я не то чтобы несогласен, а слегка сомневаюсь. Я думаю, что если (чисто в рамках комбинаторной логики) подсахарить Unlambda, то тоже можно получить симпатичный язычок.
Я с трудом представляю себе симпатичную анлямбду, но было бы любопытно взглянуть. Мне кажется, что для борьбы со сложностью в больших программах необходимо давать имена промежуточным объектам, и насколько я понимаю, в комбинаторной логике средств для этого нет.
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, deniok, Вы писали:
PM>>>на самих SKI-комбинаторах почти никто писать не пытается.
D>>Вот тут я не то чтобы несогласен, а слегка сомневаюсь. Я думаю, что если (чисто в рамках комбинаторной логики) подсахарить Unlambda, то тоже можно получить симпатичный язычок.
PM>Я с трудом представляю себе симпатичную анлямбду, но было бы любопытно взглянуть. Мне кажется, что для борьбы со сложностью в больших программах необходимо давать имена промежуточным объектам, и насколько я понимаю, в комбинаторной логике средств для этого нет.
Добавить B, W, C, Y (возможно) и ещё пяток (главный вопрос каких?). И с песнями вперёд.
Здравствуйте, sharcUs, Вы писали:
U>Здравствуйте, palm mute, Вы писали:
PM>>Я предлагаю четко разделить следующие аспекты: 1) какие выгоды получает программист от применения ФП 2) какие у ФП математические корни PM>>Пункт 2 требует значительно более аккуратного к себе отношения. U>Это и без того понятно, что того что есть особенно по второму вопросу не хватит даже самому нелюбознательному.
Курилка высказался по поводу "относительной" чистоты того же Haskell, которого Вы называете "чистыми абсолютно". Я так же склонен полагать, что кристальной чистоты даже у самых чистых языков, коим является Haskell не может быть.
Понятие чистоты формализовано. Градаций нет. Функция print в Хаскель чистая? Чистая! Она всегда возвращает IO () и не имеет побочных эффектов.
Ну, а так, разумеется, программе надо что-то выводить, что-то откуда то получать, так что механизмы для этого имеются. Но от этого Хаскель не становится "нечистым" ;-)
Здравствуйте, sharcUs, Вы писали:
К>>Было бы здорово, если бы ты смог одной-двумя фразами выразить фундаментальную мысль статьи?
Э... То, что ты сейчас сказал — это либретто: сжатие с потерями, так сказать (или без потерь).
А интересно, что из всего этого ты открыл для себя, в чём субъективная новизна и глубина. В чём, может быть, личный интерес и блеск в глазах?
Если это удастся выразить, то статья перестанет выглядеть компиляцией. (Ну ты понял мою основную претензию, да?)
U>Для ФП характерна математическая семантика выражений, абстрактность по отношению к ВТ, U>выводимость типов выражений,
Выводимость типов не есть принадлежность ФП. Просто в императивных языках традиционно используются вещи, ломающие систему вывода типа Хиндли-Милнера: перегрузка операторов (арифметика, присваивание) и неявное приведение (опять же арифметика, классы). Но пример того же Nemerle или OCaML показывает, что можно сохранить и императивность, и ХМ-типизацию в одном флаконе.
А с другой стороны, существуют и ИЯ, и ФЯ с утиной типизацией.
Особенно забавен в этом плане С++, у которого статическая типизация конкретных типов (где правит бал императивность) и утиная — шаблонов (декларативность).
U>Это основные мысли описанные с статье. Не знаю как должна выглядеть систематизация, но я этот термин использую именно для подобных целей
Для чего бы ты воспользовался систематизацией, помимо написания статьи? Ну например, для выбора языка под решение конкретной задачи, или для написания нового языка, закрывающего белые пятна в мире существующих языков, и т.п.?
Здравствуйте, sharcUs, Вы писали:
PM>>Пункт 2 требует значительно более аккуратного к себе отношения. U>Это и без того понятно, что того что есть особенно по второму вопросу не хватит даже самому нелюбознательному.
Я не говорил, что написано мало. Имелось в виду, что если упоминается некоторая теория или математический факт, упоминание должно быть а) точным и б) к месту. Т.к. статья ненаучная, наукообразие ей только вредит. Это относится и к другим фрагментам — например, вместо "семантики математических выражений" можно было сказать, что значение выражение не зависит от порядка вычислений.
>>>аличие механизма отложенного вычисления PM>>Только в чистых ленивых языках. U>а какие ФЯ являются чистыми ленивыми а какие нет?
Те же Хаскелл с Клином. U>И что значит понятие чистый ленивый язык?
Насчет чистоты lomeo уже ответил, а ленивые вычисления ты сам упоминаешь в статье. Просто отложить вычисление какого-то выражения, а потом его форсировать можно на любом языке, и только в чистых языках вроде Хаскелла ленивость сидит глубоко в виртуальной машине, если можно так выразиться. Между этими двумя подходами к ленивости — настоящая пропасть.
PM>>Относительно чистые — это как рыба второй свежести. U>Тут
Курилка высказался по поводу "относительной" чистоты того же Haskell, которого Вы называете "чистыми абсолютно". Я так же склонен полагать, что кристальной чистоты даже у самых чистых языков, коим является Haskell не может быть.
См. комментарий lomeo.
Здравствуйте, Кодт, Вы писали:
К>А интересно, что из всего этого ты открыл для себя, в чём субъективная новизна и глубина. В чём, может быть, личный интерес и блеск в глазах? К>Если это удастся выразить, то статья перестанет выглядеть компиляцией. (Ну ты понял мою основную претензию, да?)
...
К>Для чего бы ты воспользовался систематизацией, помимо написания статьи? Ну например, для выбора языка под решение конкретной задачи, или для написания нового языка, закрывающего белые пятна в мире существующих языков, и т.п.?
В статье нет чего-то революционного, или чего-то уникального все что здесь отражено, описано уже много раз многими людьми вдоль и поперек. Да и вряд ли за вечер можно было раскрыть с нуля для себя функциональное программирование все, какое оно есть, с исчерпывающими выводами и заключениями. Для меня же целью этого рисерча, как я писал в первом сообщении темы не было написание статьи. Главной задачей было прежде всего для себя самого расставить все по местам, что такое ФП, какие основные особенности ему характерны, в чем отличие от привычных мне, и возможно большинству других программистов, императивных подходов, чем ФП может быть полезен, в каких языках и в какой мере нашел отражение он, существуют ли абсолютно функциональные языки, интересно ли это мне, хотел бы ли я еще что-нибудь узнать из этой области.
Я ответил практически на все свои вопросы, определился с тем, что мне интересно больше всего, и чем я при наличии желания и свободного времени буду интерсоваться — Haskell. Кроме этого, с помощью статьи, в которой нашли свое отражение большинство ответов на интересовавшие меня в данный момент вопросы я научился лучше формулировать свои мысли, знания, то что я знаю, и то чего хочу. Не помню кто и где как-то сказал, что если хочешь что-то изучить — напиши об этом. Я придерживаюсь этой мысли, так как в этом случае помимо накопления и приобретения знаний по существующей теме необходимо еще их корректно сформулировать и доходчиво объяснить, прежде всего для себя. Для меня все то, что я узнал, формулируя, не без помощи отдельных личностей данного форума, за что им огромное спасибо, свои мысли в виде статьи, не исчезнет бесследно и станет первым кирпичиком знаний в области функционального программирования. За ним появятся и другие, более трудоемкие и глубинные. Выразятся ли они подобно этому в виде статьи — покажет время. А пока, отвечая на Ваш вопрос по поводу результата — я думаю я все-таки поставил точки над "i" в интересовавших меня вопросах, по крайней мере для себя
Кодт,
К>А с другой стороны, существуют и ИЯ, и ФЯ с утиной типизацией.
Ты про окамл? Там это просто выглядит как duck typing, но внутренняя механика совсем другая, всё строго и безопасно. Поэтому там чаще используется (корректный) термин structural typing.
Здравствуйте, sharcUs, Вы писали:
U>В статье нет чего-то революционного, или чего-то уникального все что здесь отражено, описано уже много раз многими людьми вдоль и поперек
Не воспринимай, плиз, нашу критику негативно. Мы пытаемся быть конструктивными. Документировать свое понимание интересующей области — отличный подход, решпект. U>Редакция 2, исправленная и доработанная
Можно опять попридираться? Спасибо. >Дальнейшим развитием функционального программирования стало появление семейства языков ML (Meta Language). Этот язык был задуман как инструмент для >научных и образовательных учреждений
Насколько мне известно, вовсе не для каких-то учреждений. Вспомогательный язык, разработанный специально для теорем прувера LCF. >спровоцировало пересмотр его концепции, что явилось причиной появления различных диалектов, таких как Standard ML, CaML Light и Objective CaML
Standard ML — это скорее основная ветвь развития. CAML — прорыв в эффективной реализации. "Пересмотра концепции", что бы это ни значило, не было.
>Первым чистым функциональным языком стал язык Miranda,
SASL был раньше
>Главное отличие этих языков заключается в способе вычислений.
Однако непонятно.
Здравствуйте, Курилка, Вы писали: К>>>насчёт Питона тож сомнения U>>Ну а как же тогда с наличием кортежей и средств функционального программирования: filter(), map(), zip() и reduce() U>>к тому же в книге Г.Россум, Ф.Л.Дж.Дрейк, Д.С.Откидач "Язык программирования Python" — авторы недвусмысленно намекают на то, что в питоне есть немного от функционального программирования. К>Если так подходить, то и в ассемблере ФП можно найти К>Вообще во многих языках есть разные черты, просто определяющий момент — насколько они "родные", т.е. насколько востребованы и используются подобные "фичи", мапы и фильтры — это хорошо, но вот как часто "питонисты" пишут при помощи ФВП, т.е. сами эти ФВП, а не просто исопльзуют штатные.
Для Python-а все эти фичи вполне родные. Функции — "первокласные" объекты. Есть лямбды и замыкания, списковые включения. Есть итераторы и генераторы — на них можно строить "ленивые" вычисления.
Так что можно писать практически в функциональном стиле.
Ну и используется всё это довольно активно.
Здравствуйте, Tonal-, Вы писали:
T>Для Python-а все эти фичи вполне родные. Функции — "первокласные" объекты. Есть лямбды и замыкания, списковые включения. Есть итераторы и генераторы — на них можно строить "ленивые" вычисления. T>Так что можно писать практически в функциональном стиле. T>Ну и используется всё это довольно активно.
Главного чего в нем нет — это паттерн-матчинга. Так что писть то на нем конечно можно в фунциональном стиле, но делать это намного менее удобно по сравнению с языками в которых хорошо поддерживается паттерн-матчинг.
Ну, а писать в функциональном стиле можно и на C# 2.0. На C# 3.0 это будет делать даже пожалуй удобно. Но вот однажды написав 100 кил с паттерн-матчингом потом уже без него писать не хочется.
Вообще, я никак не могу понять почему гражданские (как их называет Гапертон) языки не рассмотрели этой очень удобной фишки. Как показал опыт Скалы и Немерла она прекрасно интегрируется во вполне себе ООЯ. То есть по сути фича к ФП отношения не имеет. Просто удачное решение родившееся в среде ФП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вообще, я никак не могу понять почему гражданские (как их называет Гапертон) языки не рассмотрели этой очень удобной фишки. Как показал опыт Скалы и Немерла она прекрасно интегрируется во вполне себе ООЯ. То есть по сути фича к ФП отношения не имеет. Просто удачное решение родившееся в среде ФП.
Потому что "гражданские" исходно были ориентированы на максимально "чистое" ООП. Паттерн матчинг хорош, когда внутренняя (алгебраическая) структура типа максимально открыта, тогда по ней тип легко разбирать. А в ООП, наоборот, стремились к унификации всего и вся, в том смысле, что всё есть объект, работа с которым идет через набор методов и свойств, а структурные детали инкапсулированы.
Здравствуйте, VladD2, Вы писали:
T>>Для Python-а все эти фичи вполне родные. Функции — "первокласные" объекты. Есть лямбды и замыкания, списковые включения. Есть итераторы и генераторы — на них можно строить "ленивые" вычисления. T>>Так что можно писать практически в функциональном стиле. T>>Ну и используется всё это довольно активно.
VD>Главного чего в нем нет — это паттерн-матчинга. Так что писть то на нем конечно можно в фунциональном стиле, но делать это намного менее удобно по сравнению с языками в которых хорошо поддерживается паттерн-матчинг.
Вопрос был про мультипарадигменность. На него я и ответил. Все необходимые для ФП парадигмы элементы присутствуют.
То что нет паттерн-матчинг-а — жалко конечно, но он как бы не является основорологающим.
VD>Ну, а писать в функциональном стиле можно и на C# 2.0. На C# 3.0 это будет делать даже пожалуй удобно. Но вот однажды написав 100 кил с паттерн-матчингом потом уже без него писать не хочется.
Давно не интересовался.
А там уже есть лямбды, картежи и замыкания?
И можно не писать класс на каждый чих?
VD>Вообще, я никак не могу понять почему гражданские (как их называет Гапертон) языки не рассмотрели этой очень удобной фишки. Как показал опыт Скалы и Немерла она прекрасно интегрируется во вполне себе ООЯ. То есть по сути фича к ФП отношения не имеет. Просто удачное решение родившееся в среде ФП.
Надеюсь, что в Python-е оно появиться.
Здравствуйте, deniok, Вы писали:
D>Потому что "гражданские" исходно были ориентированы на максимально "чистое" ООП. Паттерн матчинг хорош, когда внутренняя (алгебраическая) структура типа максимально открыта, тогда по ней тип легко разбирать. А в ООП, наоборот, стремились к унификации всего и вся, в том смысле, что всё есть объект, работа с которым идет через набор методов и свойств, а структурные детали инкапсулированы.
вспомнил :) palm_mute на это мне напомнил о views patterns и прочих радостях, не ломающих инкапсуляцию.
Здравствуйте, deniok, Вы писали:
L>>вспомнил :) palm_mute на это мне напомнил о views patterns и прочих радостях, не ломающих инкапсуляцию.
D>То-то я пишу и думаю, где-то недавно чуть ли не те же слова были :)) Что, слово в слово процитировал?
Перекуём баги на фичи!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
