Вышел 2-й выпуск журнала «Практика функционального программирования»

> Почему? В смысле что не так описано в Википедии?

Там пишется, что оператор вроде как не возвращает значения, в отличие от выражения, однако в тех же сях functions и assignment, запятая таки возвращают значение, и присваивание я, например, могу засунуть в математическое выражение. Кроме того, про лисп пишется, что там дескать нет операторов, хотя там есть те же самые if, do, prog*, setq которые являются специальными формами и по всем статьям должны быть операторами. И к тому же есть в сях есть гнутое расширение, которое из блока кода делает выражение [1], чем оно принципиально отличается от progn, мне вообще непонятно.

Вообще говоря, сама статья мне показалась не очень вразумительной.

[1] http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs

> Lisp — это вообще отдельная тема :) Языки лисп-семейства не императивны по сути (равно как и не строго функциональны).

Лисп (CL) - он императивный по сути, но там ему много чего осталось в наследство от старых функциональных лиспов, да.

> Ну так дай ты определение императивного подхода. А то пока не видно ни одного.

Это прямое использование фреймовой (не подстановочной, referentialy opaque) модели вычислений в программе, т.е. если где-то в программе используется деструктивное присваивание, а значит там есть identity и состояния. Это не значит, что программа вся целиком состоит "присваиваний", это не значит, что она не модульная, это не значит, что она должна быть похожа на сишный boilerplate, это не значит, что в ней не могут использоваться pattern matching, high-order functions, anonymous functions и все остальное. (Я эти слова уже пишу раз десятый, но я терпеливый, когда-нибудь ты поймешь:))

> В каком месте ты здесь дал определение?

Число́ — абстракция, используемая для количественной характеристики объектов, я думал это и так понятно.

> Дай определение почему A -> B а С -> !B.

"Этому" нельзя дать определение, как бы я не старался.

>>Объект - это то, что обладает identity и состоянием. Яйцо - это реальный предмет, а число - это абстракция (просто по определению).

> Ты сказал. А -> B потому что A -> B, а С -> !B по определению. Я ничего такого не говорил, я сказал, что такое A, B и С, где ты там увидел какие-то выводы, я не в курсе.

> - потому что в микроволновке котоов нельзя сушить не потому что их сушить нельзя в принципе - а потому что их сушат изх неверных предпосылок думая что микроволновка это "фен". Я действую из понимания что там происходит. От того что я понимаю что там происходит не проистекает что это хороший способ писать программы.

Тогда ты, наверное, понимаешь, что атрибуты класса, начинающиеся с _ - не следует трогать, только если не знаешь, к чему это приведет.

> Твоя рекомендация - это рекомендация вида "чтобы стружка от токарного станка не попала в глаз - не подставляй глаз". Моя - вида "надень очки" (создай систему типов где такое не возможно).

Отличный пример, то, что сделал ты - снял очки и подставил глаз. Хошь я тебе на CL напишу - там есть возмножность скрыть реализацию, или ты мне на слово поверишь?

> Поделиться - в данном случае было фактически - а не "информацией".

Получается, что мой счет реален, а вот число, которое его описывает - абстрактно.

> Твоя линейка для меня не абстрактна? Серьезно?!?

Нет конечно, можешь подъехать ко мне, я тебе дам ее потрогать и повертеть в руках, чтобы ты полностью убедился в ее реальности. А вот представление о ней вполне может быть абстрактным. Вот мне интересно, для тебя путин с медведевым абстрактны или нет?

> При чем тут кто? Дай характеристику свойств абстрактных объектов и реальных в кеоторых они различаются и по чем ты их разделил.

Ну тут мы с тобой далеко зайдем :), туда куда я заходить не хочу. Ты лучше напиши, что ты хотел этим вопросом показать, ведь ты же куда-то ведешь. Хотя я предположу, возможно даже неправильно, но ты если что поправь меня.

Ты, наверное, хочешь показать, что яйцо - это абстракция, по крайней мере в нашей программе и нам без разницы взяли мы какое-то конкретное или нет, главное, чтобы оно было "правильного" типа RawEgg, и получили бы на выходе Omlet - не какой-то конкретный, а совершенно абстрактный омлет. А если бы мы хотели поработать с более "конкретными" (и посему менее абстрактными) яйцами, мы бы в описание типа добавили существенные для нас характеристики - вес, цвет, конкретное место в холодильнике, возможно даже номер и прочее, а на выходе из функции получили бы более конкретный омлет - с определенным весом, консистенцией и тд. Я прав?

>Это прямое использование фреймовой (не подстановочной, referentialy opaque) модели вычислений в программе

Ты можешь привести чью нить ссылку которая определяет императивную модель через фреймы или типа претьендуешь на оригинальность?

И еще - ассемблер - самый яркий представитель императивщины - нука впиши его в фреймовую модель хоть чем нибудь.

>Число́ — абстракция, используемая для количественной характеристики объектов, я думал это и так понятно.

Ага - "сабо собой разумеется" - идеальный аргумент или обоснование в технических или научных вопросах. Что - проя яйцо не нашел? Или тоже само собой разумеется?


> "Этому" нельзя дать определение, как бы я не старался.

А - то есть ты поделил объекты по категориям а обосновать почему так - не можешь - для тебя это "само собой разумеется" - правильно?

>Тогда ты, наверное, понимаешь, что атрибуты класса, начинающиеся с _ - не следует трогать, только если не знаешь, к чему это приведет.

Ты прикинь - ошибки связанные с типизщацией в динамических языках возникают чаще чем в статически типизированых совсем не потому что те кто на них пишет не знают что делают. А потому что в двух разных местах одлин и тот же или разные люди руководствовались разными соображениями. Но оба знали что делали.

>Хошь я тебе на CL напишу - там есть возмножность скрыть реализацию, или ты мне на слово поверишь?

Что поверю? Что ты будешь сидеть и превращать систему в набор чистых ...ммм "модулей" в неудобной форме исходя из "само собой разумеется" - оснований, без малейшей продемонстрированной пользы от такого подхода? Еще как поверю.

>Получается, что мой счет реален, а вот число, которое его описывает - абстрактно.

Счет твой никуда не делется - там абстракции станет меньше. К стати! Банкомат вообще мистическая машина - превращает абстракции в реальность нажатием простых кнопок - прямо шутки Калиостро какие-то:)

>Вот мне интересно, для тебя путин с медведевым абстрактны или нет?

Для меня слово "абстракция" соответствует тому что понимал под ним аристотель, а не ССР. Так что два вопроса - 1) почему програмное яйцо для тебя реально, 2) что вообще кому-нибудь кодга-нибудь давало представление объектов реального мира с "проецированием" их свойств конкретно в программировании (конкретно - что ты выиграл представив яйцо объектом с состоянием) - остаются открытыми.

>Ну тут мы с тобой далеко зайдем :), туда куда я заходить не хочу.

Фига се. Это принципиальный вопрос. Ты разделил объекты на 2 категории, отстаиваешь правоту своего деления, но даже обосновать его не хочешь.

>Ты лучше напиши, что ты хотел этим вопросом показать, ведь ты же куда-то ведешь.

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

Ну и по поводу верности восприятия стейтфульных вещей об этом задумывались даже древние греки. Поэтому задаваясь вопросом о том как мыслит человек - можно обратить внимание на классика, и его "учение о познании" - потому что даже в те временя он понимал разницу между реальностью и восприятием реальности посредством органов чувств и принципиальную между ними разницу.


В следствие чего:

Действительная реальность - не имеет никакого значения - мы ее воспринять не в состоянии.

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

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


>Я прав?

Частично. См. выше.

> http://hackage.haskell.org/packages/archive/pkg-list.html

А почему среди сего списка всякого полезно-бесполезного барахла нет Fudgets, от которого многие писают кипятком, когда речь заходит о GUI на Haskell???

> Действительная реальность - не имеет никакого значения - мы ее воспринять не в состоянии.

Такой подход не очень полезен в программировании. Вон Страуструп постоянно пишет о моделировании реальности.

________________________________________________

Попытки наехать на state для меня выглядят... ну мягко скажем бесперспективными.

Состояние существует... эээ... почти что объективно (ну насколько можно говорить об объективности в данном контексте).

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

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

2 anonymous

Любой алгоритм оперирует абстрактными понятиями. Рецепт приготовления омлета из конкретных яиц не нафиг нужен никому - он одноразовый. Даже если мы учитываем вес и цвет яиц, они всё равно в алгоритме будут абстрактные.

Абстрактное мышление, насколько я знаю, врождённым для человека не является. Но его развитию способствует язык - мы все думаем на каком-то языке, называя конкретные вещи абстрактными именами. И именно абстрактное мышление сделало из обезьяны человека. :)

>Попытки наехать на state для меня выглядят... ну мягко скажем бесперспективными.

Я пока не увидел ни одной успешной попытки обосновать _необходимость_ стейта в этой задаче. Все попытки сведены к "а вы реальности оно вот такое". А это "как обоснование" даже Платон бы разнес в клочья.

>Состояние существует... эээ... почти что объективно

Ну как это так. Люой предмет который ты наблюдаешь вокруг тебя трудно даже идентифицировать в терминах состояния - потому что неизвестно где кончается этот предмет и где начинается что-то другое в этом состоянии. Можно только выстроить некоторую искуственную точку отсчета, назвать ее 0лем, и сказать - это карандаш. Потому что в точке < нуля - это была деревяшка, а еще дальше - вообще дерево. То есть уже одно это - ограниченная абстрактная модель.

>Если ты где-то заметишь, что можно (объективно) обойтись без состояния, то весьма верояно, получишь нехилую оптимизацию и получившийся алгоритм назовут твоим имененем.

Вон яишницу без состояния заделали раньше на сковороде без состояния.

>И опять же соглашусь с анонимусом о наличии двух типов объектов -- реальных с состоянием и "идеальных" (чисел, ...)

Угу - в программах реальных яиц просто немеряно.

>> Если ты где-то заметишь, что можно (объективно) обойтись без состояния, то весьма верояно, получишь нехилую оптимизацию и получившийся алгоритм назовут твоим имененем.

> Вон яишницу без состояния заделали раньше на сковороде без состояния.

И тебе не скучно такой *бред* писать? (К слову, некоторые твои мысли бывают очень интересны).

1. Я, когда предложил написать программу яишницы, подумал, что надо самому бы написать императивный вариант, но при моей температуре меня хватило только на треп. Я кстати и сейчас соображаю на 30% от номинала.

2. "Если ... именем." -- это и есть обоснование полезности рассмотрения состояния. Я понимаю, что тему тут можно раскрыть глубже, но это скучно, и вероятность, что ты найдешь у меня существенную ошибку я оцениваю на уровне 5%. А так как для меня имеет смысл в основном то, когда у меня находят ошибку... короче, будем продолжать дискуссию? тебе интересно?

3. Задача про яишницу сформулирована слишком неточно, чтобы тут точно что-то доказать.

В треде я сделал 1-2 наезда на ФП, вот в них-то вероятность меня поймать чуть ли не 50%, так что там гораздо интереснее. Правда, мне еще нужно время, чтобы выйти на номинальную мощность и как следует их сформулировать.

>3. Задача про яишницу сформулирована слишком неточно, чтобы тут точно что-то доказать.

Не имеет значения. Тут вопрос стоит вот таким ребром: насколько далеко ты готов зайти в описании свей модели и с какой точки зрения ты ее будешь описывать.

Вариант А: смотрим о чем предметная область и создаем "объекты предметной области" отвечающие на вопрос "is a" и их свойства "has a". Из этого проистекает ООПшная модель с состояниями.

Вариант Б: представить с какими данными предметной области мы будем иметь дело, категоризировать их и описать как абстрактные данные - это было сделано выше на хаскеле - такая себе штука вроде "алгебры".

Последний вариант предполагает составление абстрактной модели, установления ее ограничений и инвариантов. Первый - проще. У меня человек рядом на работе сидит который не колеблясь выберет первый - седня у нас вышел спор на тему "все люди как люди пишут антовские скрипты для каждого проекта и ничего vs моего "в котором надо разбираться" мегаскрипта (который получился очень маленьким( но построен вокруг определенной модели, а не "надо скопировать файл пишем команду копи", и один скрипт собирает штук 50 разных многомодульных проектов". Спор кончился в момент когда я ему показал проект из 25 модулей и спросил - "ты предлагаешь 25 одинаковых скриптов написать?"

Так вот я выбираю второй. Одна из основных причин - первый для меня скучен и не интересен - хотя тоже работает. В совоем варианте я постоянно натыкаюсь на различные интересные свойства и возможности, которые мне помогают в работе физически раз, и делают ее для меня интересной два. Мне интероесно решать задачу DSLями, составлять обощенную модель вместо частного решения, разрабатывать абстрактную либу вместо решения задачи в лоб на месте.

Мне не интересно решение вида "о чем? о яйцах? так class Яйцо.. разбитое? так поле разбитое метод разбить". Ну извините.

PS: "абстрактные числа" появились когда людям надоело перекладывать "реальные камушки" для счета. Подумайте об этом.

> Спор кончился в момент когда я ему показал проект из 25 модулей и спросил - "ты предлагаешь 25 одинаковых скриптов написать?"

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

Впрочем, иногда бывают такие принеприятные ситуации, когда вроде бы уровень возможен, но он получается настолько не меньше того, что было, что от него приходится отказаться.

> Мне не интересно решение вида "о чем? о яйцах? так class Яйцо.. разбитое? так поле разбитое метод разбить". Ну извините.

А здесь именно такая ситуация. "так class Яйцо"

> PS: "абстрактные числа" появились когда людям надоело перекладывать "реальные камушки" для счета. Подумайте об этом.

Мне достаточно близки идеальные объекты (да, кивок в сторону Платона, а слово "абстрактные" не так удачно, ибо несколько занято) и нравятся функциональные структуры данных (сохраняющие всю старую историю).

Но в данном случае как раз уместно обсудить когда нужны реальные, а когда идеальные объекты.

И подумать можно не о числах, а о более интересных вещах. В частности, о *мутабельных* классе Прямоугольник и его подклассе Квадрат. Если мы сделаем объект Прямоугольник мутабельным, но запретим иметь на него несколько ссылок (точно так же, как число 1 мутабельно, но на него несколько ссылок быть не может) то вроде бы решим известную проблему. Так?

>Лучше сходи на http://migmit.vox.com где Miguel Mitrofanov приводит простенький код на хаскеле

А где конкретно?

>Вот ты исписал много букаф -- а где профит?

Это еще мало букв. Да и как справедливо замечают, все описано http://en.wikibooks.org/wiki/Haskell/Category_theory

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

Плюс все упирается в теорию типов, плюс все упирается в представление типов с несколькими параметрами с помощью чего-то похожего на карринг, только для функторов, хотя в книжках по ТК обычно рассматривают декартово произведение функторов...

А профита действительно мало :(

> А где конкретно?

Ссылка с русскими буквами :-(

http://migmit.vox.com/library/post/%D0%BE%D0%B1%D1%8A%D1%8F%D1%81%D0%BD%D0%B8...

сейчас она почти в начале страницы http://migmit.vox.com/library/posts/page/2/

> Плюс все упирается в теорию типов, плюс все упирается в представление типов с несколькими параметрами с помощью чего-то похожего на карринг, только для функторов, хотя в книжках по ТК обычно рассматривают декартово произведение функторов...

Думаешь так тебя кто-то поймет? Напиши подробнее: "Хотелось бы ...... но все упирается в теорию типов (именно ......)"

> В документах по хаскелю все почему-то крутится вокруг монад. Что совершенно неправильно.

Я так понимаю, что монады состояния используются как достаточно кривой способ учета побочных эффектов (почему кривой -- написано в http://www.haskell.org/haskellwiki/DDC/EffectSystem)

>достаточно кривой способ учета побочных эффектов

Да нет же! Причем здесь "монады"? Учет состояния, как и организация цепочек вычислений, к монадам никакого отношения не имеют.

Почему-то во многих документах монады выделяются как какой-то супер-пупер крутой объект. Причем - единственно возможный и почему-то только в "базисе" return/bind, хотя можно (и нужно) в "базисе" конструктор типа/fmap/join.

> Но в данном случае как раз уместно обсудить когда нужны реальные, а когда идеальные объекты.

Так ведь нет никаких реальных объектов в программе, в этом вся соль. Возвращаясь к пресловутым яйцам: "объектно-ориентированное яйцо" настолько же далеко (а может и дальше) от реальности, насколько и "функциональное яйцо". Это тоже идеальный объект, просто из другой парадигмы. Насколько удобно с его помощью ту самую реальность моделировать - вот главный вопрос. Выше был более тонкий пример с лампочкой, и я приводил своё видение того, как её смоделировать, не прибегая к состоянию. Так вот получается (по крайней мере для меня), что ограничение иммутабельности заставляет больше внимания уделять тонкостям типизации и жизненного цикла, а значит способствует построению более корректных моделей. Это не говоря уж о чисто технических преимуществах в реализации, вроде простоты распараллеливания. Философские вопросы о сути бытия здесь сугубо вторичны. А вопрос о двух категориях объектов (реальные vs идеальные) в программе вообще не стоит по-моему. Разве что только в тех, которые непосредственно работают с железом. Вот там действительно императивный подход более уместен пожалуй.

> И подумать можно не о числах, а о более интересных вещах. В частности, о *мутабельных* классе Прямоугольник и его подклассе Квадрат.

А зачем? Чтобы можно было делать аффинные преобразования, оставаясь в рамках одного типа и в итоге прийти к объекту "Квадрат" со свойствами ромба?

> точно так же, как число 1 мутабельно, но на него несколько ссылок быть не может

Не понял, как это число 1 мутабельно? Если мы его мутируем, у нас уже не будет больше числа 1 что ли? Это в каком языке так сделано?

> А зачем? Чтобы можно было делать аффинные преобразования, оставаясь в рамках одного типа и в итоге прийти к объекту "Квадрат" со свойствами ромба?

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

> Попытки наехать на state для меня выглядят... ну мягко скажем бесперспективными.

Это говорит о тебе гораздо больше, чем о реальности и механизмах её моделирования.

P.S. Яишница --- это состояние яйца, группы яиц или же новый объект?

> Ты можешь привести чью нить ссылку которая определяет императивную модель через фреймы или типа претьендуешь на оригинальность?

Я тебе еще н-постов, страниц назад давал ссылку на SICP. И это (referential transparancy) - единственный способ разграничить императивные и функциональные языки, потому что без нее (подстановочной модели) теряется основный смысл fp. В фп (с подстановочной моделью) мы получаем почти задарма возможность спокойно распараллеливать, автоматическую мемоизацию, высокую модульность, автоматическую оптимизация программы (по крайней мере в теории), меньшую ошибкоемкость, ленивые вычисления. Как только подстановочная модель вычислений хоть где-то нарушается - мы все это разом теряем (чтобы получить это все в ИЯ, нужно постараться), поэтому императивные языки принципиально отличаются от языков (чисто) функциональных.

Вся проблема в том, что фп плохо ложится на реальные задачи, т.к. компьютер - это не просто большой калькулятор, как это было 60-70ые года, и как хотелось бы фп-программистам, а "система управления", поэтому там важны не только вычисления, но и побочные эффекты - запись из файла/в файл, вывод на дисплей, работа с устройствами и прочее, кроме того иногда действительно нужны shared mutable data. Я тебе не раз говорил про rand - очень классический случай не функциональной функции, без скрытого состояния ее сложно реализовать, то же относится к вводу/выводу. Именно из-за необходимости работать с такими грязными функциями и желанием получить все плюшки фп (см выше), и пришлось придумать всякие ухищрения вроде передачи мира (universe) в качестве параметра в функцию, монады в конце концов. Кстати, надо сказать хаскелл в решении этой задачи,- создании чистого фп языка с возможностью работы с реальным миром, весьма преуспел.

> Ага - "сабо собой разумеется" - идеальный аргумент или обоснование в технических или научных вопросах.

Честно говоря, я не думал, что будут разногласия по поводу определения числа. Но, если тебе не нравится определения, иди правь википедию.

> Что - проя яйцо не нашел? Или тоже само собой разумеется?

А что яйцо? Яйцо - это предмет такой, класс объектов такого типа, можно назвать яйцо абстракцией - это ничего не меняет.

Яйцо можно описать как объект (который имеет состояние и identity), а можно как кортеж параметров, я не вижу причин, почему одно должно исключать другое. И то и другое - вычислительные абстракции, просто разные.

> Ты прикинь - ошибки связанные с типизщацией в динамических языках возникают чаще чем в статически типизированых совсем не потому что те кто на них пишет не знают что делают. А потому что в двух разных местах одлин и тот же или разные люди руководствовались разными соображениями. Но оба знали что делали.

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

> А потому что в двух разных местах одлин и тот же или разные люди руководствовались разными соображениями. Но оба знали что делали.

Тот код, которым ты ломал, говорит о том, что человек его писавший, все-таки не знал, что делал.

> Что поверю? Что ты будешь сидеть и превращать систему в набор чистых ...ммм "модулей" в неудобной форме исходя из "само собой разумеется" - оснований, без малейшей продемонстрированной пользы от такого подхода? Еще как поверю.

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

> Счет твой никуда не делется - там абстракции станет меньше. К стати! Банкомат вообще мистическая машина - превращает абстракции в реальность нажатием простых кнопок - прямо шутки Калиостро какие-то:)

Не, счет изменился, и поэтому он будет описываться уже другим числом. Мне кажется, ты путаешь причину и следствие.

> Фига се. Это принципиальный вопрос. Ты разделил объекты на 2 категории, отстаиваешь правоту своего деления, но даже обосновать его не хочешь.

Я что-то не припомню, что я где-то, что-то делил, напомни плиз. Я там вроде просто назвал вещи своими именами, и никому ничего не приписывал.

> Этим я хотел сказать механизм абстракции работает в любом случае, какое это яйцо тебе кажется в реальности - для програмирования значения не имеет никакого, абстракция - это механизм, который применяется для дальшейшего теоретического анализа,

> даже будь твоя теория насчет восприятия человеком мира как стейтфульных вещей верна - это не имеет никакого значения в теоретическом анализе - вариантом которого и является программирование.

Объекты* (это те, которые имеют identity и состояния) - это и есть абстракция для программирования (я думал это и так ясно, видимо, я действительно очень плохо выражаю свои мысли :( ) и не только, весьма удобная, кстати.

В фп кирпичик (из которого все строится) - это вычислительный объект (entity) без mutable внутреннего состояния - immutable data, functions and so on.

В ип добавляется еще один - это вычислительный объект (entity) с mutable внутренним состоянием. Простейший пример - это обычная mutable переменная, лексическое замыкание, объект в ооп-смысле. Он добавляет еще один уровень абстракции.

Почему я в своем "анализе" должен себя ограничивать только фп-образными объектами (entities) - immutable data, functions? Чтобы получить эфемерные плюсы подстановочной модели вычислений? Единственный существенный плюс - за который цепляются все фп-фанбои - это модульность, - но как писал господин хьюс в своей фп-агитке - она результат не столько самого фп, сколько HOF и lazy evaluation (хотя основной профит не в lazy evaluation, а в lazy sequences), а это я не считаю прерогативой исключительно фп.

Вспомни такие вещи как САПР (например, автокад), и человеку там, как это ни "парадоксально", естественнее работать с объектами* - передвинуть линию, нарисовать окружность, _поменять у этой окружности_ радиус и прочее, прочее, прочее, хотя человек там работает c абстракцией - чертежом.

Даже когда проводятся теоретические физические расчеты и анализ, мы мыслим (рассуждаем) более объектами* (в указанном смысле), чем функциями, у нас материальная точка (физическая абстракция) имеет состояние - скорость, ускорение, положение, и _она меняет свое состояние_ под воздействием импулься, приложенной силы или еще чего. Конечно, можно говорить, что под воздействием силы мы получаем новую точку с другими характеристиками, но я никогда о таком от учеников не слышал, им намного естественнее о ней думать, именно как об объекте (в указанном выше смысле), даже в абстрактных теоретических расчетах. Это уже потом, когда мы составляем уравнения, и нам приходится считать, - там больше функциональности, в самой математике, не в моделировании и рассуждениях о проблеме.

"Теоретический анализ" (вроде бы) дискретных систем привел создателей симулы к первому объектно-ориентированному языку.

Не зря, как я уже говорил, создатели *ml и scheme включили деструктивное присваивание в свои языки - хотя они были вполне академические, и создавались не для промышленного применения. Они как раз понимали, что не стоит ограничивать программиста только одним типом "кирпичей", ибо есть задачи, которые с помощь фп решаются намного хуже, чем в ип.

> Действительная реальность - не имеет никакого значения - мы ее воспринять не в состоянии.

Ну не хочу я залезать в эти дебри, что такое действительность, реальность, абстрактное, описательное, объективное, субъективное, истинное и ложное, мне не хочется обсуждать в этой ветке.

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

Да. Объекты* - это абстракция, и она помогает проводить теоретический анализ.

объекты* - это не те, которые ооп объекты, а те, которые имеют identity и мутабельное состояние; ооп объекты обычно мутабельны, но конечно, это не всегда так.

> Любой алгоритм оперирует абстрактными понятиями. Рецепт приготовления омлета из конкретных яиц не нафиг нужен никому - он одноразовый. Даже если мы учитываем вес и цвет яиц, они всё равно в алгоритме будут абстрактные.

да.

> Абстрактное мышление, насколько я знаю, врождённым для человека не является. Но его развитию способствует язык - мы все думаем на каком-то языке, называя конкретные вещи абстрактными именами. И именно абстрактное мышление сделало из обезьяны человека. :)

да.

> Я пока не увидел ни одной успешной попытки обосновать _необходимость_ стейта в этой задаче.

А никто тебе необходимость и не доказывает.

> Ну как это так. Люой предмет который ты наблюдаешь вокруг тебя трудно даже идентифицировать в терминах состояния - потому что неизвестно где кончается этот предмет и где начинается что-то другое в этом состоянии.

Ну это все философия и демагогия. Я смотрю на светофор и вижу, что горит зеленый. Я точно знаю в каком состоянии находится светофор.

> Можно только выстроить некоторую искуственную точку отсчета, назвать ее 0лем, и сказать - это карандаш. Потому что в точке < нуля - это была деревяшка, а еще дальше - вообще дерево. То есть уже одно это - ограниченная абстрактная модель.

Да. Это "абстрактная" модель. В чем проблема-то?

> Угу - в программах реальных яиц просто немеряно.

Не, там модели яиц.

> Вариант А: смотрим о чем предметная область и создаем "объекты предметной области" отвечающие на вопрос "is a" и их свойства "has a". Из этого проистекает ООПшная модель с состояниями.

> Вариант Б: представить с какими данными предметной области мы будем иметь дело, категоризировать их и описать как абстрактные данные - это было сделано выше на хаскеле - такая себе штука вроде "алгебры".

> Первый - проще.

почему ты так думаешь? Ведь все зависит от задачи.

> И подумать можно не о числах, а о более интересных вещах. В частности, о *мутабельных* классе Прямоугольник и его подклассе Квадрат. Если мы сделаем объект Прямоугольник мутабельным, но запретим иметь на него несколько ссылок (точно так же, как число 1 мутабельно, но на него несколько ссылок быть не может) то вроде бы решим известную проблему. Так?

Вроде как нет, тут[1] рассказывается, почему это не решает проблему.

[1] http://okmij.org/ftp/Computation/Subtyping/

> Так ведь нет никаких реальных объектов в программе, в этом вся соль.

да.

> Насколько удобно с его помощью ту самую реальность моделировать - вот главный вопрос.

да.

> Выше был более тонкий пример с лампочкой, и я приводил своё видение того, как её смоделировать, не прибегая к состоянию. Так вот получается (по крайней мере для меня), что ограничение иммутабельности заставляет больше внимания уделять тонкостям типизации и жизненного цикла, а значит способствует построению более корректных моделей.

Про лампочку я не читал, читал про яичницу (омлет). "Объектная*" (даже не в ооп смысле) модель не позволит тебе функцию unbreak (т.е. мы принципиально не можешь разбитое яйцо вернуть обратно), а функциональная позволит. И где тут более корректная модель?

Не смотря на иммутабельность, ты совершенно спокойно сможешь делать логические ошибки при программировании, которые напрямую противоречат твоей моделе - поведению твоего объекта.

Далее, сделай мне private mutable share data - например, у меня есть несколько потоков, которые добавляют, удаляют и читают слова из словаря. Как мне сделать эту вещь не через костыли в фп?

Как мне сделать probably cyclic list? Без костылей естественно. Только не надо приводить код из топика в developement - там не то. Т.е. это можно в хаскелле, например, сделать даже, не используя do нотацию, но это нельзя назвать красивым и идиоматическим решением.

> Это не говоря уж о чисто технических преимуществах в реализации, вроде простоты распараллеливания. Простота-то конечно, простота. Но как компилятор узнает, что ему параллелить? Ведь если он будет параллелить очень простые функции это может только замедлить работу, даже если это будут green threads внутрях настоящего треда. Поэтому параллелить все подряд не получится - значит, нужно оставлять аннотации - вот здесь параллель, а здесь - нет, что будет не сильно отличаться от ручного распараллеливания.

> P.S. Яишница --- это состояние яйца, группы яиц или же новый объект?

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

> Это как мы смоделируем

А как ты смоделируешь это здесь и почему?

> Яишница --- это состояние яйца, группы яиц или же новый объект?

В зависимости от задачи. Возможны, вроде бы, любые 7 комбинаций.

> Не понял, как это число 1 мутабельно? Если мы его мутируем, у нас уже не будет больше числа 1 что ли?

Возможны 3 уровня абстракции:

0. без абстракции: "вот к этий куче добавили те камушки -- куча стала больше"

1. средний "вот к этим 15 камушкам добавили 2 -- __именно это__ число 15 стало 17-ью"

2. полностью идеальный, годится для ФП: "15 всегда было, всегда есть и всегда останется таким и неизменным... add(15,2)=17"

> Возможны 3 уровня абстракции:

> 1. средний "вот к этим 15 камушкам добавили 2 -- __именно это__ число 15 стало 17-ью"

Числа с identity? Выглядит бредово... Даже если взять этот пример, здесь число - это скорее свойство кучи камушков (количество), но никак не самостоятельный объект. Хотя если скатываться к пуризму и допустить, что всё есть объект, то... Ещё дальше уйдём от реальности по-моему.

> 15 всегда было, всегда есть и всегда останется таким и неизменным

Ну это по-моему и пятикласснику очевидно :) А вот числа c identity вполне могут взорвать ему мозг.

Для какой задачи необходимо, чтобы яйцо целое, яйцо разбитое, яишница, кучка говна являлись одним и тем же объектом в разных состояниях?

> А как ты смоделируешь это здесь и почему?

А здесь нет задачи - тут нужно было записать один и тот же алгоритм в императивной и функциональной парадигме. Я собственно это и попытался сделать - записал один в один императивный вариант "псевдокода" r. У него используется представление о том, что разбитость, зажаренность, сырость являются свойствами яйца, а не разными типами - у меня тоже.

> Для какой задачи необходимо, чтобы яйцо целое, яйцо разбитое, яишница, кучка говна являлись одним и тем же объектом в разных состояниях?

Для той, в которой нам не нужны отдельные свойства для целого, разбитого яйца и яичницы - например, в задаче моделирования процесса приготовления яичницы для лора в разных парадигмах :) (прошу заметить у r - они тоже определены как состояния). Если тебе в принципе интересно, для каких задач легче использовать мутабельное состояние и identity - так я их перечислял где-то в недавних постах.

> Ответ на: Re: Вышел 2-й выпуск журнала "Практика функционального программирования" от anonymous 10.10.2009 4:37:02

> anonymous (*) (10.10.2009 14:56:59)

Я думал, анонимус поумнел, а оказывается здесь их несколько.

Развели тут стейтлесс дискуссию (непонятно чьи посты можно воспринимать только по отдельности), а ещё стейт и идентити защищают. Позор! :)

> у r - они тоже определены как состояния

Тебе показалось.

> Тебе показалось.

[code] data EggState = Raw | Broken | Fryed deriving (Show) [/code]

> Развели тут стейтлесс дискуссию (непонятно чьи посты можно воспринимать только по отдельности), а ещё стейт и идентити защищают. Позор! :)

Ага, функциональненько так :) А теперь представь, что на всём ЛОРе остались только анонимусы, а регистрироваться низзя (ну ладно, в порядке исключения можно, но только тем, кто сдаст экзамен по теоркату). Удобно?

> Ага, функциональненько так :) А теперь представь, что на всём ЛОРе остались только анонимусы, а регистрироваться низзя (ну ладно, в порядке исключения можно, но только тем, кто сдаст экзамен по теоркату).

Лучше уже математическую капчу сделать. :)

> Удобно?

> Разве Карл Маркс запрещает держать на лестнице ковры? Разве где-нибудь у Карла Маркса сказано, что 2-й подьезд Калабуховского дома на Пречистенеке следует забить досками и ходить кругом через черный двор? (c) Булгаков

Разве Хаскелл Карри запрещает пользователям иметь имена?

Это не состояния.

>>Как это яйца иммутабельны? они ой как мутабельны.

> В каком месте?

На сковородке.

К.О.