Здравствуйте, grosborn, Вы писали:
>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
G>Это общий механизм мышления.
Это общий механизм воссоздания образов, то есть воображения. Назвать это мышлением слишком сильно, нужно какое то подтверждение.
>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов.
Даже образное мышление трудно назвать набором образов, а есть еще понятийное, сиречь абстрактное мышление.
>Вообще добиться того, что бы следующий снимок не накладывался на предыдущий и не разрушал его, а это требуется для логического мышления,
Не совсем ясно откуда следует что какой то снимок накладывается на предыдущий ? Это имеется ввиду какая то конкретная модель мышления ? Честно, в книгах по когнитивной психологии такого не встречал.
>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
G>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов.
Так устроен разве что только внутренний диалог, или в других терминах — высший уровень сознания.
При этом большая часть мышления приходится на подсознание, где выполнее проще описать, как сеть из функциональных блоков. На этих уровнях последовательности снимков скорее нет, чем есть.
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Но вот, к примеру, для дизайна GUI фреймворков все что я в функциональном мире видел, это либо подточеный под ФП классический ОО подход, либо такие страшные чудовища, да еще и без дизайнера, что мама дорогая. С дизайном распределенных систем у функционального подходя я тоже каких то особых прорывов не видел. И т.д.
ВВ>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
Здравствуйте, Ikemefula, Вы писали:
ВВ>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет. I>А что ты видел в дизайне распределенных ?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну раз к линку попривыкли, наверное, и до монад не так много осталось.
Возможно. Но почему тогда ООП обвиняется в мозговыламывании, а ФП нет?
ВВ>Ну можешь считать это подпорками, если тебе так хочется. Странно еще, кстати, что ты ПМ не вспомнил.
Совсем не странно. Здесь речь про дизайн, а ПМ на уровне контрактов прямо не фигурирует.
ВВ>Это действительно неудобно.
Об этом и речь.
ВВ> Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым
Блин, ну что за любовь приписывать мне какие то странные мысли? Я не говорил, что ФП становится менее чистым. Речь о том, что в ФП королевстве все примерно так же, как и в ООП. Базовая концепция в какой то часто встречающейся ситуации приводит к неудобству. Для устранения этого мы вводим новую сущность, не являющуюся обязательной для соответствия парадигме, которая в этом сценарии жизнь упрощает. Только почему то в ФП это считается в порядке вещей, а в ООП расценивается как смертный грех, и нужно ООП непременно редуцировать до объектов, обменивающихся сообщениями и ничего сверх того.
AVK>>Все что я хотел, я уже сказал. Если тебе не нравится моя точка зрения, это вовсе не означает что я неправ или чего то не сказал.
ВВ>Точку зрения неплохо чем-либо аргументировать.
Все аргументы, что я посчитал нужным, я привел.
AVK>>А я нет. Дальше то что? Опять скатываемся в субъективно-экспертный подход? Да, если мы цепочку данных иммутабельно трансформируем, ФП скорее всего даст более короткий и понятный код.
ВВ>ФП это далеко не обязательно про иммутабельность.
Обязательно. По определению.
ВВ>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел.
ОО-RPC кто то отменил уже? Ну и по мне так SOA вполне себе в духе ООП, и прекрасно с ОО-языками уживается.
ВВ> UI будет.
Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?
AVK>>Нет, статические не выходят, потому что никаких проблем ООП не решают.
ВВ>Как же не решают. Решают стандартную проблему — "неудобно".
Что неудобно? Статические методы никаких проблем дизайна не решают.
ВВ>>>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП AVK>>Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.
ВВ>Что, тоже?
Постоянно упираются в неудобство и тяжеловесность чистого ФП.
ВВ> ФЯ упираются в тяжеловесность ООП? Что-то я вообще не понял, о чем ты.
Все ты понял, но опять занимаешься софистикой.
ВВ>Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП.
Ага, а армяне лучше чем грузины. Если повторить это 1000 раз, может что то и получится.
ВВ>А что происходит в ООЯ? Появляются мегамонстры вроде Скалы?
В Скале больше ФП чем ОО. Впрочем, топик на эту тему уже был, там кто то, хорошо в Скале разбирающийся, приводил численные оценки новых ОО и Ф конструкций. ООП в Скале совсем недалеко от джавы ушло.
ВВ>Причем ФЯ развиваются как раз именно как ФЯ, ООЯ же уносит черт знает куда, в какое-то монстроподобие
Вот, о чем я и говорил. Абсолютно аналогичные процессы в ФЯ и в ООП расцениваются по разному. А для доказательства придумываются специальные критерии чистоты концепции.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ikemefula, Вы писали:
I>Указатель на функцию это уже ФП, опаньки ! Процедурная парадигма не умеет никаких таких вещей.
Дудки, ФП — это где есть механизм ФВП. А если речь об адресе статической ф-ии, видимой в compile-time, то это не ФП, а банальный AddressOf из махровых императивных 70-х.
I>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.
Ниче не понял, перефразируй, плиз.
I>То есть, понять, что же будет сделано, можно только глядя в код конкретного метода. I>В моем случае все это по месту вызова.
Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))
I>>>Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает. V>>Мде? А qsort в чистом Си видел? I>А ты перестал опохмеляться ?
Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.
V>>Как эмулируется замыкание — я уже показал. С помощью указанной пары {ф-ия, контекст} можно делать в точности аналогичное на процедурном подходе. Достаточно умения вызывать обычную ф-ию по ссылке. I>А ты хорошо понимаешь, что такое эмуляция ? ты хорошо понимаешь, что код по месту вызова не то же самое что и код хрен знает где ? ты хорошо понимаешь, что привел пример фактически из ФП ?
Да, я привел основную концепцию ФП на не ФП. Именно это я и хотел тебе показать, см своё исходное утверждение:
I>Покажи на примере, как функциональная композиация несильно отличается от процедурной.
Потому что на "голых" сях тоже успел пошпилить в задачах поболе даже тысячи строк... и все эти приемчики, ес-но, очень даже в ходу. Даже можно на досуге полистать код ядра линухов и основные внутренние интерфейсы (не в смысле интерфемов дотнета или джавы). Код на чистом Си, но незамыленным глазом ты будешь натыкаться на IOC-подход постоянно.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну раз к линку попривыкли, наверное, и до монад не так много осталось. AVK>Возможно. Но почему тогда ООП обвиняется в мозговыламывании, а ФП нет?
Потому что ООП современное представляет собой варево из ООП и ФП, так что выламывание мозгов по крайней мере двойное, причем ФП чудовищным образом прогибается под системы типов на него не рассчитанные.
ВВ>>Ну можешь считать это подпорками, если тебе так хочется. Странно еще, кстати, что ты ПМ не вспомнил. AVK>Совсем не странно. Здесь речь про дизайн, а ПМ на уровне контрактов прямо не фигурирует.
Ну тогда и кортежи надо убрать, это же просто синтаксис.
ВВ>> Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым AVK>Блин, ну что за любовь приписывать мне какие то странные мысли? Я не говорил, что ФП становится менее чистым. Речь о том, что в ФП королевстве все примерно так же, как и в ООП. Базовая концепция в какой то часто встречающейся ситуации приводит к неудобству.
Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*. Так как то, что ты называешь костылями, это и не костыли вовсе. В ООП *совсем* не так. Базовая коцепция в ООП — это и есть само ООП. И расширяется оно вещами, которые вообще идеологически конфликтуют с ООП. Добавление первоклассных функций — это уже есть подобное расширение "базовой концепции". Ибо первоклассные функции добавляют средства, для которых есть аналоги в ООП, но менее выразительные. Код, который использует "лямбды", не является объектно-ориентированным.
С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница.
AVK>Для устранения этого мы вводим новую сущность, не являющуюся обязательной для соответствия парадигме, которая в этом сценарии жизнь упрощает. Только почему то в ФП это считается в порядке вещей, а в ООП расценивается как смертный грех, и нужно ООП непременно редуцировать до объектов, обменивающихся сообщениями и ничего сверх того.
Чистое ООП должно включать только то, что не вступает в противоречие с ООП. Алгебраические типы не вступают в противоречие с ФП. "Лямбды" и статические методы вступают в противоречии с ООП. Так что, извините, придется их редуцировать.
ВВ>>ФП это далеко не обязательно про иммутабельность. AVK>Обязательно. По определению.
У тебя какое-то неправильное определение. А из него происходит и неправильное понимание ФП. ФП — это не иммутабельность. ФП — это функции и детерминизм. Но ФП вообще не против состояния, ФП против только *нелокального* состояния. ФП — это про referential transparency. Локальное состояние не противоречит RT, а следовательно — и чистому ФП.
Поэтому в рамках чистого ФП не только возможны, но и вполне активно используются мутабельные структуры данных.
ВВ>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. AVK>ОО-RPC кто то отменил уже? Ну и по мне так SOA вполне себе в духе ООП, и прекрасно с ОО-языками уживается.
По-моему, да
Я его видел и даже сам писал в 2002-2003. Потом оно стало куда-то упорно исчезать. Проектов разных я вижу довольно много, так что статистика определенная есть.
А SOA может и уживается с ОО языками, но оно вообще-то не очень в духе ООП. Я бы даже сказал, что оно принципиально не в духе ООП, там ООП нет ни грамма.
В распределенных приложениях, я бы сказал, своя некая парадигма формируется, ООП и ФП там, мне кажется, не очень подходят, слишком много косвенности. А вот сервис в SOA имеет четкие границы, т.е. четкое различение между локальным и нелокальным вызовом, что в распределенке важно.
ВВ>> UI будет. AVK>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?
Я думаю, меньше. Но всему требуется время. ФП построено на основе очень выразительной системы исчисления, но ФП довольно сложен в плане реализации. Тот же Хаскелл — это такой большой исследовательский проект по разработке компилятора для ФЯ. Думаю, UI пока еще не стал главным приоритетом, но дойдет и до него. Вообще ФП должно, наверное, противопоставляться не ООП, а императивному программированию. И по сравнению с императивным программированием ФП меняет просто все. Но до серьезной работы над UI пока еще не дошло, да.
Вообще ФП — сравнительно молодая парадигма. Идеи — да, давно витают. А реализации стали появляться-то сравнительно недавно. Та же Миранда — это уже середина 80х. А Миранда практически исключительно варилась в академии.
AVK>>>Нет, статические не выходят, потому что никаких проблем ООП не решают. ВВ>>Как же не решают. Решают стандартную проблему — "неудобно". AVK>Что неудобно? Статические методы никаких проблем дизайна не решают.
Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают. Решают проблему с "неудобством". Причем способами, которые ФП не противоречат, в отличие от.
ВВ>>Причем ФЯ развиваются как раз именно как ФЯ, ООЯ же уносит черт знает куда, в какое-то монстроподобие AVK>Вот, о чем я и говорил. Абсолютно аналогичные процессы в ФЯ и в ООП расцениваются по разному. А для доказательства придумываются специальные критерии чистоты концепции.
Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными". Где здесь аналогия?
Здравствуйте, samius, Вы писали:
S>Мы уже выяснили, что у двери поведения нет.
Значит, так выясняли. Поведение ес-но есть. И уже раз 100 говорили, что дело в подробностях задачи, которые надо зафиксировать в ТЗ.
S>И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.
Где ты эту траву берешь?
V>>Объект — это не только термин из ООП. S>Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.
Ох... Было сказано "функциональный объект".
А почему так? — из-за природы ФВП, т.к. они прямо по определению хранят в замкнутом контексте некоторые данные.
V>>>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП. S>>>Объекты — замыкания для бедных
V>>Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь. S>а мне кажется что ты клоунадничаешь. И я не одинок в этом.
Ну да, вас 3-5. Как и во все времена. Просто самые плодовитые. Один из этой "группы" какой-то неактивный в последнее время, дык, смотрю, замена подоспела... ))
V>>Да что же за такое??? V>>3-й раз уже этот аргумент про несчастные классы типов скипают. V>>С вами каши не сваришь. ))) S>Ох, а ты сколько скипаешь... Не пробовал считать?
Я скипаю то, на что уже отвечал или несущественное по теме (на мой взгляд). Если же задают скипнутый вопрос повторно — обязательно отвечаю.
Скажем так, сам пинг-понг вопросов-ответов трекаю многократно тщательнее тебя и других популярных "писателей".
V>>============= V>>Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.
V>>Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... )) V>>Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.
S>Кэй писал что вдохновлялся атомами Лиспа.
Дык, а про что конкретно он так писал? Есть брать атомы в смысле атомов из Лиспа, то их можно натянуть разве что на объектную identity.
S>На самом деле от Лисп-атома до кортежа функций не так далеко.
Бесконечно далеко.
S>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.
А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Потому что ООП современное представляет собой варево из ООП и ФП
В практическом плане это совершенно пофигу, из чего варево. А обсуждать проблему с точки зрения истории программирования или CS мне здесь не интересно.
ВВ>, так что выламывание мозгов по крайней мере двойное
Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями.
ВВ>Ну тогда и кортежи надо убрать, это же просто синтаксис.
Да нет, кортежи вполне себе присутствуют в том числе и в спецификациях, что в ООП, что в ФП. Да и вообще, кортежи ортогональны базовым принципам и ФП и ООП.
ВВ>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*.
Для чего важно?
ВВ>С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница.
Какая разница в практическом плане?
ВВ>Чистое ООП должно включать только то, что не вступает в противоречие с ООП.
Вот только, поскольку что такое чистое ООП по большому счету никто не знает, то и вопрос твой больше теоретический. Мне же, если это еще непонятно, совершенно плевать на идеологическую чистоту, мне важно удобство. А теоретические вопросы генеалогии ФП и ООП обсуждай с Клапауцием, мне эта тема малоинтересна.
ВВ>А SOA может и уживается с ОО языками, но оно вообще-то не очень в духе ООП. ВВ> Я бы даже сказал, что оно принципиально не в духе ООП, там ООП нет ни грамма.
Опять неаргументированный субъективизм. Если ты такой сторонник чистоты ООП, то должен понимать, что кеевскому определению SOA не противоречит. Идентити у сервисов есть — эндпоинт, обмениваться сообщениями они могут, детали реализации изолированы контрактом. А то что полиморфизма на базе иерархий наследования нет (полиморфизм реализаций контрактов есть) — так это вовсе необязательный признак ООП. Не ты ли недавно доказывал, что наследование контрактов не нужно?
Ну и главное — в практическом разрезе все это бесполежный буллшит. Главное — SOA удобно реализуется ОО-языками, и интерфейс ОО-языка 1 в 1 без смены модели меппится на контракт. А вот чисто функциональными — интересный вопрос, я бы с удовольствием послушал, какая сущность ФП будет описывать SOA контракт, чтобы его компилятор понимал и контролировал, а не только RPC фреймворк.
ВВ>А вот сервис в SOA имеет четкие границы, т.е. четкое различение между локальным и нелокальным вызовом, что в распределенке важно.
Круто. А еще есть четкая граница между персистентными данными в БД и неперсистентными в памяти. Тоже будем новую парадигму придумывать?
AVK>>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?
ВВ>Я думаю, меньше.
Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.
ВВ> Но всему требуется время.
Сколько? И ФП и гуевым фреймворкам уже много десятков лет, не новые, мягко говоря, вещи? Что танцору мешает?
ВВ>ФП построено на основе очень выразительной системы исчисления, но ФП довольно сложен в плане реализации
Ну то есть ФП уровня C# не достаточен? Почему и в каком месте?
ВВ>. Тот же Хаскелл — это такой большой исследовательский проект по разработке компилятора для ФЯ.
А казалось бы, какая связь.
ВВ>Думаю, UI пока еще не стал главным приоритетом
Если за 30 лет UI не стал, не, не приоритетом, просто важной задачей ... Что то в датском королевстве ... Потому что ООП массово влез в мейнстрим как раз на волне GUI (текстово-псевдографического UI, если желаешь), и до сих пор это остается одной из важнейших задач промышленно применимых универсальных языков. И это, кстати, не только GUI касается, а вообще всех компонентных фреймворков. А в ФП с их идеологической правильностью вопрос компонентности, похоже, тоже пока неважен.
ВВ>Вообще ФП должно, наверное, противопоставляться не ООП, а императивному программированию
С какой целью? Я вот, честно говоря, вообще ничего ничему противопоставлять не хочу, мне как то вместо полета в стратосферах интереснее удобрения по полям распылять. И если ФП хорошо, лучше ООП, работает для решения определенного класса задач, его и надо применять. А вопросы идеологической чистоты пусть остаются теоретикам CS.
ВВ>. И по сравнению с императивным программированием ФП меняет просто все. Но до серьезной работы над UI пока еще не дошло, да.
Хуже то, что и направлений пока не очень то видно.
ВВ>Вообще ФП — сравнительно молодая парадигма.
Существенно старше ООП, что характерно.
AVK>>Что неудобно? Статические методы никаких проблем дизайна не решают.
ВВ>Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают.
Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом?
ВВ>Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными".
НУ И ЧТО?
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, samius, Вы писали:
V>>Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть) S>Тоже можно считать. Только результат if-а очень даже повторимый. Сколько не будешь вычислять с теми же аргументами, получишь то же самое.
"единственный и неповторимый" — это аллегория, результат будет только один.
V>>Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости. S>Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.
Речь не о самом побочном эффекте (я же уже всё раскрывал), а о таких замеченных св-вах происходящего, что:
— последовательность вычисления важна для побочных эффектов, но для чистого кода — не важна;
— то бишь все 3 аргумента if могут вычисляться в произвольном порядке.. теоретически;
— фактически же порядок их вычислений гарантируется, что позволяет писать программы навроде комбинаторных парсеров с бесконечными рекурсиями, которые, однако, вполне конечны на конечных данных, из-за ленивости вычислений вкупе с гарантированным порядком вычисления аргументов в ПМ и if-then-else.
S>Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.
О, блин, наконец-то.
Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка?
Ес-но, в случае аналога бинарного дешифратора на вложенных if сначала будут вычислены все предикаты, и только "когда-нибудь потом" выбранная, в ходе ветвления, ветка.
Здравствуйте, samius, Вы писали:
S>Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#.
Спорно. Как минимум вариант посетителя, пусть даже на базе ФВП, для большого количества значений дискриминанта был бы удобнее рукопашной проверки этого дискриминанта.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Мы уже выяснили, что у двери поведения нет.
V>Значит, так выясняли. Поведение ес-но есть. И уже раз 100 говорили, что дело в подробностях задачи, которые надо зафиксировать в ТЗ.
Нет никакого поведения у двери кроме как подчиняться законам природы. А то что ты совокупность действующих на дверь сил заменяешь методом Откройся() — так это не двери забота. Это особенности твоей модели, а не двери вовсе.
S>>И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.
V>Где ты эту траву берешь?
У Кэя взял.
V>>>Объект — это не только термин из ООП. S>>Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.
V>Ох... Было сказано "функциональный объект". V>А почему так? — из-за природы ФВП, т.к. они прямо по определению хранят в замкнутом контексте некоторые данные.
хранят, но с ООП-шностью этих данных в чистом языке напряг. Так что в топике об ООП лучше не называть эти данные объектом.
S>>а мне кажется что ты клоунадничаешь. И я не одинок в этом.
V>Ну да, вас 3-5. Как и во все времена. Просто самые плодовитые. Один из этой "группы" какой-то неактивный в последнее время, дык, смотрю, замена подоспела... ))
Самый плодовитый тут однозначно ты.
S>>Ох, а ты сколько скипаешь... Не пробовал считать?
V>Я скипаю то, на что уже отвечал или несущественное по теме (на мой взгляд). Если же задают скипнутый вопрос повторно — обязательно отвечаю. V>Скажем так, сам пинг-понг вопросов-ответов трекаю многократно тщательнее тебя и других популярных "писателей".
конечно, ты скипаешь несущественное. Для тебя.
S>>Кэй писал что вдохновлялся атомами Лиспа.
V>Дык, а про что конкретно он так писал? Есть брать атомы в смысле атомов из Лиспа, то их можно натянуть разве что на объектную identity.
да, об identity items речь была.
S>>На самом деле от Лисп-атома до кортежа функций не так далеко.
V>Бесконечно далеко.
ну-ну
S>>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.
V>А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле?
Конечно. Примерно как между статикой и динамикой.
V>Принципиальное отличие я уже объяснял: http://www.rsdn.ru/forum/decl/4691158.1.aspx
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.
V>Я уже все показал, опять? http://www.rsdn.ru/forum/philosophy/4837590.1.aspx
Ты не показал побочный эффект. А то что ты показал — это не про Хаскель во всяком случае.
V>Речь не о самом побочном эффекте (я же уже всё раскрывал), а о таких замеченных св-вах происходящего, что:
Ты говорил о самом побочном эффекте, если чо. V>- последовательность вычисления важна для побочных эффектов, но для чистого кода — не важна; V>- то бишь все 3 аргумента if могут вычисляться в произвольном порядке.. теоретически; V>- фактически же порядок их вычислений гарантируется, что позволяет писать программы навроде комбинаторных парсеров с бесконечными рекурсиями, которые, однако, вполне конечны на конечных данных, из-за ленивости вычислений вкупе с гарантированным порядком вычисления аргументов в ПМ и if-then-else.
Ну и где побочный эффект-то?
S>>Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.
V>О, блин, наконец-то. V>Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка?
Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет. V>Ес-но, в случае аналога бинарного дешифратора на вложенных if сначала будут вычислены все предикаты, и только "когда-нибудь потом" выбранная, в ходе ветвления, ветка.
Ага, и чо?
Здравствуйте, AndrewVK, Вы писали:
V>>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. AVK>Нет, не начинает.
Начинает для заведомо рекурсивных и бесконечных программ, будучи исполненными в энергичной манере.
V>> Некие выражения вычисляются заведомо РАНЬШЕ других AVK>Ну и что? Это не приводит к ни к каким сайд-эффектам.
Приводит к тому, что заведомо неудачные ветки не вычисляются. Вроде бы и не сайд-эффект, если представить вычислитель с бесконечным быстродейтсвием и бесконечной памятью... А в конечных характеристиках этот момент — разминка для воображения.
AVK>>>А логические ветвления присутствуют, наверное, в любой парадигме. V>>Предположу, что только у наследованных от структурной. V>>Например, в логическом программировании никакого ветвления нет.
AVK>Есть. Предикаты как раз ветвление для тел правил и задают.
Ну дык, это в процессе работы вычислителя происходит ветвление. Просто в ФП-языке можно глазами пробежаться по коду и сэмулировать поток исполнения в любой единице программы. В императивном ПО и подавно. То бишь ветвление будет прямо перед глазами. А в Прологе так не пробежишься, бо правила могут быть объявлены в произвольном порядке, затрудняющем восстановить ход работы (поток исполнения) вычислителя.
V>>>>Про последовательное исполнение в Хаскеле — do-стрелки. AVK>>>А при чем тут Хаскелл? V>>А чтобы сферических коней не гонять туда-сюда.
AVK>Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию.
Дык, если брать OCaml — то там перечисление последовательности операций тоже изкаробки. Nemerle — тоже. Лисп, Схема — тоже. Про Хаскель сказал. Другие функциональные достаточно подробно не смотрел, чтобы делать какие-то утверждения. ИМХО, другие ФП-языки еще более экзотичные, чем перечисленные.
V>>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл. AVK>Нет, не дает. Кури определение чистоты.
Дык, уже год как бросил...
V>>
V>>* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
AVK>А теперь включаем моск и осмысливаем написанное.
Коллега, я привел три составляющие. Они или работают все вместе, раскрываясь в одно общее определение, или вообще ничего не работают. Достаточно было оставить всего любые два компонента и уже было бы неубедительно... А ты решил ткнуть мне всего одним. ))
AVK>Если при последовательном исполнении можно придумать условие, которое изменится на очередной итерации внутри одной функции — налицо сайд-эффект, которого в чистом ФП быть не может по определению.
* Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы.
Сайд-эффект маскируется созданием нового значения из старого и ростом стека. Но в координатах очередного фрейма стека на каждом новом витке рекурсии мы имеем абсолютно такую же диспозицию данных, как на предыдущем витке. Наложи один идентичный фрейм локальных переменных на другой и ты увидишь такие же точно отличия, как если бы это был всё тот же самый фрейм стека + сайд-эффект.
Именно на этом важном принципе работает раскрутка рекурсии в цикл, даже если на каждом шаге изменяется более одной переменной-параметров ф-ии.
AVK>В то же время при чистой рекурсии любое условие всегда будет давать один и тот же результат для заданных аргументов, и каждая последующая итерация вызывает функцию с другими аргументами, так что условие чистоты на 100% соблюдается. AVK>Меня совершенно потрясает, что ты местами забираешься глубоко в хитрые детали, а местами демонстрируешь зияющие пробелы в базовых знаниях.
А меня всегда потрясает, как можно предполагать второе из первого...
Всего-то требовалось немного воображения относительно аргументов оппонентов и хотя бы на минуту перестать считать окружающих дураками.
V>>И да, изначально далеко не все языки позволяли рекурсивные вызовы. Вот как раз в ф-ых языках она и появилась в кач-ве способа организации цикла.
AVK>Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?
Фортран, ес-но.
В первых стандартах не было RECURSIVE и я даже успел пройти на таком диалекте нем выч-практику на первом курсе на старой EC-1025.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#.
AVK>Спорно. Как минимум вариант посетителя, пусть даже на базе ФВП, для большого количества значений дискриминанта был бы удобнее рукопашной проверки этого дискриминанта.
Соглашусь, посетитель был бы кстати. Но ничто не мешает прикрутить внешнюю диспетчеризацию (фактически таже рукопашка) или dynamic-ах.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Потому что ООП современное представляет собой варево из ООП и ФП AVK>В практическом плане это совершенно пофигу, из чего варево. А обсуждать проблему с точки зрения истории программирования или CS мне здесь не интересно.
"Практический план" у тебя только что подключился. До этого вроде бы как о парадигмах говорили.
В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает. ФП нормальное можно построить либо вообще без системы типов, либо на основе чего-то вроде System F. В ООП-ные системы типов — ну не пролезает оно, один ПМ с кортежами и достается.
Получается ровно та же ерунда, что была раньше, но только "с кортежами".
ВВ>>, так что выламывание мозгов по крайней мере двойное AVK>Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями.
Смотря, где. В Скале, по-моему, уже скоро тройное будет — как раз благодаря этим "существенным изменениям".
ВВ>>Ну тогда и кортежи надо убрать, это же просто синтаксис. AVK>Да нет, кортежи вполне себе присутствуют в том числе и в спецификациях, что в ООП, что в ФП. Да и вообще, кортежи ортогональны базовым принципам и ФП и ООП.
В спецификациях — алгебраические типы. Кортеж просто синтаксис для конструкторов (в т.ч. и типов). Не более и не менее.
ВВ>>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*. AVK>Для чего важно?
Для того, чтобы наконец понять — утверждение, что ФП является более самодостаточной парадигмой, чем ООП — не голословно. Здесь как раз и приводятся причины, почему это так.
ВВ>>С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница. AVK>Какая разница в практическом плане?
У ФП есть будущее и почва для развития. У ООП — нет.
А больше никакой разницы.
Кстати, у меня почему-то возникает упорное чувство, что ты резко переключил дискуссию в какое-то совершенно другое русло.
ВВ>>Чистое ООП должно включать только то, что не вступает в противоречие с ООП. AVK>Вот только, поскольку что такое чистое ООП по большому счету никто не знает, то и вопрос твой больше теоретический.
Ну ты вот любишь Синклера по этому поводу цитировать; я вот тут тоже по соседству пытаюсь у него выудить, что же такое "поведение". И что-то все идет к тому, что вот это самое "ООП — это про поведение" настолько это самое ООП сужает, что оно вообще в какую-то экзотическую концепцию превращается.
Вообще с "чистым ООП" должно быть все достаточно просто. Мы ведь можем определить, что такое ООП, я полагаю? Чистым, очевидно, будет такое ООП, в котором нет каких-либо "посторонних" концепций, с помощью которых задачи решаются не в ОО-стиле.
Вот только реальные языки обычно не такие.
AVK>Мне же, если это еще непонятно, совершенно плевать на идеологическую чистоту, мне важно удобство. А теоретические вопросы генеалогии ФП и ООП обсуждай с Клапауцием, мне эта тема малоинтересна.
А какая тебе тема интересна? Вроде как второй день говорим про ФП и ООП — теперь оказывается, что неинтересно А чего говорил тогда?
ВВ>>А SOA может и уживается с ОО языками, но оно вообще-то не очень в духе ООП. ВВ>> Я бы даже сказал, что оно принципиально не в духе ООП, там ООП нет ни грамма. AVK>Опять неаргументированный субъективизм. Если ты такой сторонник чистоты ООП, то должен понимать, что кеевскому определению SOA не противоречит. Идентити у сервисов есть — эндпоинт, обмениваться сообщениями они могут, детали реализации изолированы контрактом. А то что полиморфизма на базе иерархий наследования нет (полиморфизм реализаций контрактов есть) — так это вовсе необязательный признак ООП.
Все, что ты тут перечислил, есть и в том же ФП. Но ФП от этого ООП не становится. У ООП есть еще одна такая маленькая деталь, которую вы постоянно упоминаете — поведение.
AVK>Не ты ли недавно доказывал, что наследование контрактов не нужно?
Я не доказывал, я спрашивал. Кстати, вопрос был не про ООП.
AVK>Ну и главное — в практическом разрезе все это бесполежный буллшит. Главное — SOA удобно реализуется ОО-языками, и интерфейс ОО-языка 1 в 1 без смены модели меппится на контракт. А вот чисто функциональными — интересный вопрос, я бы с удовольствием послушал, какая сущность ФП будет описывать SOA контракт, чтобы его компилятор понимал и контролировал, а не только RPC фреймворк.
Ага, знаю. Это трюк из области — формулируем задачу в терминах ООП, потом просим один-в-один перевести это в ФП. Влад одно время так развлекался — типа покажите мне абстракцию для последовательности в ФП типа IEnumerable.
И ты, Брут?
ВВ>>А вот сервис в SOA имеет четкие границы, т.е. четкое различение между локальным и нелокальным вызовом, что в распределенке важно. AVK>Круто. А еще есть четкая граница между персистентными данными в БД и неперсистентными в памяти. Тоже будем новую парадигму придумывать?
Зачем? Она уже выдумана. Анемичная модель называется. И не ООП, и не... В общем неведома зверушка.
Кстати, хороший пример. Я сам хотел его привести. Тоже тот случай, когда ООП-ная косвенность как бы не сильно популярностью пользуется, и Фаулера с его репозитариями народ что-то не шибко не любит в общей-то массе своей.
AVK>>>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана? ВВ>>Я думаю, меньше. AVK>Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.
Примерчик чего?
Я вижу, что, скажем, за последние 10 лет в ФП неплохо прогрессирует. Так что 30 лет ждать, может, и не придется.
ВВ>> Но всему требуется время. AVK>Сколько? И ФП и гуевым фреймворкам уже много десятков лет, не новые, мягко говоря, вещи? Что танцору мешает?
ФП настоящему не так много лет как тебе кажется. И танцор пока танцевать учится. Но у него есть преимущество перед остальными — обе ноги на месте.
ВВ>>ФП построено на основе очень выразительной системы исчисления, но ФП довольно сложен в плане реализации AVK>Ну то есть ФП уровня C# не достаточен? Почему и в каком месте?
Что такое ФП на уровне C#? Какой еще ФП в C#?
AVK>Если за 30 лет UI не стал, не, не приоритетом, просто важной задачей ... Что то в датском королевстве ... Потому что ООП массово влез в мейнстрим как раз на волне GUI (текстово-псевдографического UI, если желаешь), и до сих пор это остается одной из важнейших задач промышленно применимых универсальных языков. И это, кстати, не только GUI касается, а вообще всех компонентных фреймворков. А в ФП с их идеологической правильностью вопрос компонентности, похоже, тоже пока неважен.
А что не так с компонентностью?
ВВ>>Вообще ФП должно, наверное, противопоставляться не ООП, а императивному программированию AVK>С какой целью? Я вот, честно говоря, вообще ничего ничему противопоставлять не хочу, мне как то вместо полета в стратосферах интереснее удобрения по полям распылять. И если ФП хорошо, лучше ООП, работает для решения определенного класса задач, его и надо применять. А вопросы идеологической чистоты пусть остаются теоретикам CS.
Мне казалось, что с целью разобраться в том, что же такое *в действительности* ФП. Если такой цели нет, то ничего противопоставлять действительно не нужно.
ВВ>>Вообще ФП — сравнительно молодая парадигма. AVK>Существенно старше ООП, что характерно.
Симула появилась в конце 60х, Лисп — в конце 50х.
Вот только симула фактически заложила весь фундамент современного ООП, которое не шибко-то и поменялось с тех пор. А Лиспе от ФП — две чайных ложки и вообще это язык не функциональный.
Что-то более или менее похожее — это уже скорее Хоуп. И в большей степени Миранда.
AVK>>>Что неудобно? Статические методы никаких проблем дизайна не решают. ВВ>>Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают. AVK>Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом?
Написал бы пару АлгТД типа Pair и Triple.
Оно и сейчас примерно так и сделано.
А можно просто вернуть вот такое:
\f -> f a b
a и b это как раз те значения, которые ты хотел передать через кортеж.
А можно сразу описать все это через CPS.
А можно еще лучше — сразу описать это через монаду.
Оставаясь при этом в рамках чистого ФП и не имея ничего кроме лямбд под рукой. Вариантов много.
ВВ>>Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными". AVK>НУ И ЧТО?
ВВ>Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП.
Ага, а армяне лучше чем грузины. Если повторить это 1000 раз, может что то и получится.
Могу лишь повторить — ФП более самодостаточная концепция. Но тебе, похоже, это уже неинтересно.
Здравствуйте, samius, Вы писали:
V>>Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка? S>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.
Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.
V>Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?
В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.
А чего говорил тогда?
