Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
Z>http://pobox.com/~oleg/ftp/Scheme/pure-oo-system.scm
Не понятно, как такое может работать. Ну допустим, у них глобальные map-ы из identity в объект, через этот identity и идут ссылки. Ну допустим, они протаскивают этот контейнер через все вызовы параметром (кошмар неюзабельный). Ну, так конечно делать можно. Только работать все равно по человечески не должно, оно стопудов работает как-то не так.
Вот тебе простейший пример — электронная таблица, рекурсивно вычисляющая формулы, и использующая член класса для отметки, что "мы это уже считали" — выявление кольцевых ссылок. Хотя бы это у них сработает? А там можно и более сложные примеры найти. Давай разберемся.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, FR, Вы писали:
FR>>Да и еще это у тебя в хаскеле несколько функций(хотя логически она тоже одна) а ML и Nemerle будет одна, тут уже в философии прошлись по поводу размеров таких функций
L>Это общая проблема switch'ей — они имеет тенденцию распухать.
Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.
Здравствуйте, Андрей Хропов, Вы писали:
L>>Это общая проблема switch'ей — они имеет тенденцию распухать.
АХ>Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.
Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.
Re[9]: Purely-functional Object-Oriented System in Scheme
Здравствуйте, Gaperton, Вы писали:
G>Не понятно, как такое может работать. Ну допустим, у них глобальные map-ы из identity в объект, через этот identity и идут ссылки. Ну допустим, они протаскивают этот контейнер через все вызовы параметром (кошмар неюзабельный).
Конечно кошмар, и чтобы от него избавится все давно используют монады
Смотрите "State monad" и "O'Haskell" заодно. Монады на Scheme у Олега тоже есть — посмотрите там на сайте.
G>Вот тебе простейший пример — электронная таблица, рекурсивно вычисляющая формулы, и использующая член класса для отметки, что "мы это уже считали" — выявление кольцевых ссылок. Хотя бы это у них сработает? А там можно и более сложные примеры найти. Давай разберемся.
Давайте остановимся на кольцевых ссылках — вот чисто функциональный предикат 'cycle-list?'
Работает он так, давайте запистим по списку двух "пешеходов" — медленного и быстрого. Если они встретятся — список кольцевой — если кто-то дошел до конца — нет. Их состояние мы храним в двух аргументах внутренней функции 'helper':
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Андрей Хропов, Вы писали:
L>>>Это общая проблема switch'ей — они имеет тенденцию распухать.
АХ>>Именно поэтому в таких случаях рулит расширение через добавление классов реализующих общий интерфейс.
L>Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.
Не согласен. Паттерн-матчинг — это свитч на стероидах. Но тем не менее свитч.
Если ты захочешь расширить вариант, то тебе скорее всего придется добавлять код
там где делается паттерн-матчинг по этому варианту.
Таким образом получается размазывание добавления новой функциональности по коду.
А если просто отнаследовать класс, то код обработки, вызывающий виртуальные функции менять не придется.
Всему свое место. Для не слишком сложных структур данных — варианты и паттерт-матчинг.
Для более навороченных — классы, интерфейсы и полиморфизм.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Не согласен. Паттерн-матчинг — это свитч на стероидах.
Свитчу до него как до луны. Так что я бы тогда уж сказал что это свитч с могзгами. Там нехилые алгоритмы вывода используются все же.
АХ>Если ты захочешь расширить вариант, то тебе скорее всего придется добавлять код там где делается паттерн-матчинг по этому варианту.
Вариант на то и вариант, что он закрытый тип. Его нельзя расширить извне. И сделано это не случайно. При появлении нового значения, в тех местах коде по варианту делается паттерн-матчинг будет выдано сообщение, что такого-то значения не обработано. И ты легко внесешь изменения во все нужные места. То есть на лицо контроль и помощь компилятора.
АХ>Таким образом получается размазывание добавления новой функциональности по коду.
Вывод совершенно некорректый. На оборот. Функциональность собирается в тех местах где она нужна. На самом деле функциональность не привязана к варианту или его опциям. В прочем если вдруг захочется привязать функциональность к объектам, то виртуальных функций и вообще ООП никто не запрещал. Так что каждый выбирает дизайн который ему нравится.
АХ>А если просто отнаследовать класс, то код обработки, вызывающий виртуальные функции менять не придется.
Читайте коментарии к паттерну Посетитель так хорошо обясняется почему зачастую бывает плохо пихать операции в классы.
К тому же у подходов с классами есть одна огромная проблема — отсутсвие контроля. В отличии от закрытых вариантов наследование никем не контроливется и никто не подскажет что нужно что-то там переоределять.
АХ>Всему свое место. Для не слишком сложных структур данных — варианты и паттерт-матчинг.
Полностью несогласен. Нет зависимости между сложностью данных и применением варинатов (ака алгебороический типов). Если уж вырабатывать правла, то они должны быть совершенно другими. Выбор между вариантом и классом делается в зависимости от того что требется получить. Если нужно описать данные, то варинаты почти наверняка будут подходить. А вот если нужно эмулировать некую иерархию имеющуюся в жизни или нужно создать объекты обладающие богатым состоянием и функциональность, то лучше предпочесть классы.
АХ>Для более навороченных — классы, интерфейсы и полиморфизм.
Такое ощущение, что варианты это не полимофизм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Оверхед получается из-за того, что о действиях думают как об объектах.
Серьезно? Ну, тогда ты и обращайся к тем кто так думает. Я конечно знаю паттерн Команда, но что-то не видел чтобы его применяли вместо методов.
L> Отсюда все эти генераторы, треды, различные менеджеры чего-то там.
Генераторы это что? Метапрограммирование? Дык оно совсем от другого. Это автоматизация кодирования вещей которые можно сделать по контексту. Это и в любом ФЯ лишним не будет.
Кто такие "треды" я вообще не знаю.
Менеджеры? В моем понимании менеджер — это объект владеющий чем-то и позволяющий этим чем-то распоряжаться. Вариация на тему инкапсуляции.
В общем, не вижу ничего рационального в этих рассуждениях.
VD>>Так вот его то сахар и убирает. Во многих ООЯ сахара просто недостаточно. От того и выражение мыслей бывает более длинным и запутанным.
L>Не согласен. Паттерн матчинг и АТД — не сахар — это подход, другой способ взглянуть на вещи.
Это лирика. Другой способ взглянуть на вещь которой в данном случае является ветвление управления и есть сахар.
, что сахар понятие относительное и что зачастую то что является сахаром в одно языке является основной кострукцией в другом, и что эти конструкции могут выражаться друг через друга.
Другими словами кострукции решающие одну и ту же проблему и которые можно заменить без потери функциональности (но не выразительности) являются сахаром друг для друга.
Просто пример. Казалось бы конструкция match в Немерле более выразительна и мощьна, но ее всегда можно выразить тем или иным количеством if-ов. И иногда она оказвается более громоздкой. Так если нам нужно всего лишь выполнить действие если некое условие верно, то конструкция when или if окажется более выразительной:
when (isOK)
DoSomething();
sv.
match (isOK)
{
| true => DoSomething();
| _ => () // Do nothing
}
Но в более сложных случаях уже бесспорное лидерство match-а.
Это четкое доказательство того, что "сахар" понятие отностиельное.
L> А уж ФВП сахаром назвать язык не повернётся.
И тем не менее это так. А не поворачивается он тольк потому что лень подумать, а голва забита молитвами от ФП-проповедников которые превратили ФП в религию.
C# 2.0 и выше, Немерле и многие другие реализуют замыкания захватывающие контекст метода как классы. И ничто не мешает создать подобный код в языке не поддреживающих замыканий.
Ну, а ссылка на метод которая и делает функцию величиной высшего порядка есть почти в любом языке, так что тут и обсуждать нечего.
Так что как не прискорбно но функциональный стиль является всего лишь сахаром котрый можно привнести в любой язык. Собственно это и делается сейчас. Тот же C# в следующей вресии обзаведется лямбдами которые выглядят не хуже чем в самиом из языков. А ведь никаких идеологических изменений в C# нет.
L> А ведь они, может быть, самая важная вещь для обсуждаемого вопроса.
Вряд ли именно они, но бесспорно что функции высшего порядка, замыкания, локальные фукнкции, паттерн-матчинг, алгеброические типы и возможно что-то еще делает ФЯ столь привлекательными. Вот только к идее запрета на модификацию переменных все это отношения не имеет. А ведь именно она вроде как тут признается главной идеей ФЯ. Так что готовьтесь. Рано или поздно весь этот сахар (или его часть) попадут в те языки которые до сих пор принято было считать императивными. Ну, да лично я считаю это положительным моментом.
L>Воспрос не о императивный vs функциональный, а об объектно-ориентированный vs функциональный и о том, насколько больше приходится держать в голове в случае ОО.
Да без разницы. ООП это тоже сахар. Я писал ОО-программы на С в 1993-ем году. Да было менее удобно чем на С++, но жить было можно. Когда появился сахар в виде классов, виртуальных методов и т.п. я с удовольствием им воспользовался.
L>Я с ним согласен. Отсутствие сайд-эффекта — одна из очень важных черт ФП, которая даёт ему большие преимущества, их уже не раз перечисляли.
Ну, тогда тебе остается согласиться и с тем, что почти все достижения ФЯ не имеют к ФЯ никакого отношения. Они появлись в ФЯ, но могут быть успешно использованы в императивном (модифицирующем переменные языки). И эти языки как не странно окажутся только гибче и удобнее чем "чистые". Ведь писать "чистый" фукнциональный код в них можно без проблем, но если что не будет проблемой и написать более эффективный или простой императивный код. В конце концов глупо же отказываться от тех же хэш-таблиц только потмому, что они императивны по сути?
VD>>Так вот можно без проблем писать очень компактный и выразительный код во всю используя модификацию переменных. И программа от этого сложнее не или непонятнее не станет. Так что если определять ФП как это делает Гапертон, то ФП вообще мало чего дает.
L>Не понял, почему?
Что тут не понятного? ФЯ по Гапертону (и тебе, в общем-то) это запрет на модификацию переменных. А это деградация функциональности и больше ничто. Этот запрет не даст никаких приемущество с точки зрения реализации алгоритмов. Никакие паттерн-матчинги от этого не зависят. Никакие функции высшего порядка тоже. Это просто запрет ради запрета. Он яко бы должен привести к гипотетическому упрощению программирования. Но по жизни, как говорится рулят, ковровые бомбордировки и танковые клинья и еще этот, как его? А, гриб Сарумяна. То есть рулят отладчики, IDE, визуальные дизайнеры и т.п.
Если же кому-то хочется полной immutability, то это можно организовать просто добавление некоторого атрибута.
L>Отсутствие сайд-эффекта + функции высшего порядка, по моему, гораздо важнее.
Чем что? Чем они лучше чем "функции высшего порядка" + возможность по желанию сделать "сайд-эффект"?
Вот наличие такой возможности дает возможность более гибкого дизайна. А отсуствие дает только ощущение причястности к религии.
L> Без них код на ФЯ не будет таким выразительным и лаконичным.
Аагащазблин. Это алогичное рассуждение хотя бы потому, что в языке поддерживающем изменение переменных можно без проблем их не изменять.
И вообще как выразительность может зависить от отсуствия некой возможности? Это же нонсенс!
L>Ну так, а в ФП для этого даже не надо выполнять эти правила! Из-за этих правил опять таки в мыслях оверхед.
В ФП из-за этого порой приходится долго трахаться и использовать совершенно не эффективные и/или многословные решения.
Так что если о простоте отладки еще можно можно по рассуждать, то уж выразительнсть ну ни каким боком к неизменности переменных отношения не имеет. Это миф настойчиво навязываемый религией ФЯ.
VD>>Меж тем модификация переменных иногда может быть очень полезна даже если используется весь перечисленный выше сахар. Ни один из приведенных аспектов не противоречит императивному программированию. Не мудренно что из ФЯ в таких условиях пытаются сделать религию.
L>Я сейчас не об императивном говорил,
Да, ну? А как называется модификация переменных? ООП?
L> а об объектно-ориентированном.
И какое отношение к нему имеет немодифицируемость переменных? ООП возможен и в этих условяих. Это неразумно и неудобно, но возможно.
L> А так — да, понятно, что все эти подходы могут существовать вместе. Важно выделить преимущества и недостатки их друг перед другом. Например, при использовании ОО получается больший оверхед, чем при использовании функциональщины
Важно убрать религию из областей IT. Вот когда люди будут использовать логику и научные методы для изучения предметов, то не будет и религии. А пока что ФЯ — это религия которая рассказывая все вокруг о своей крутости использует совершенно некорректные методы. Результат маргинальный мир полусумашедших ученых работающих над языками котрые использует немногочисленная групка фанатов и они сами.
Думаю, что со временем все замечательные инновации мира ФЯ войдут и в мир промышленной разработки ПО. И тога они будут просто удобными возможностями языка без фанатизма. А неизменяемость переменных будет использоваться для автоматического распараллеливания и т.п., а не для создания ореола божественного превосходства.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
L>> А уж ФВП сахаром назвать язык не повернётся.
VD>И тем не менее это так. А не поворачивается он тольк потому что лень подумать, а голва забита молитвами от ФП-проповедников которые превратили ФП в религию.
VD>C# 2.0 и выше, Немерле и многие другие реализуют замыкания захватывающие контекст метода как классы. И ничто не мешает создать подобный код в языке не поддреживающих замыканий.
VD>Ну, а ссылка на метод которая и делает функцию величиной высшего порядка есть почти в любом языке, так что тут и обсуждать нечего.
VD>Так что как не прискорбно но функциональный стиль является всего лишь сахаром котрый можно привнести в любой язык. Собственно это и делается сейчас. Тот же C# в следующей вресии обзаведется лямбдами которые выглядят не хуже чем в самиом из языков. А ведь никаких идеологических изменений в C# нет.
Во-первых, ФВП — это другая абстракция, нежели классы. Если выражать руками одно через другое, то придётся бороться с оверхедом, который неминуемо возникает при такой эмуляции и необходимость отбивать его ручками, если это не делает компилятор (плюс для N и C, они это делают).
Во-вторых, код, который решает какую-нибудь задачу выглядит и работает совершенно по-разному, в зависимости от того, от чего отталкивается создатель — от функций или от классов. Пример? Те же парсеры.
VD>Вот только к идее запрета на модификацию переменных все это отношения не имеет.
В-третьих, передача и возвращение функций с побочными эффектами — это опасная конструкция. А именно: поскольку любой мало-мальски сложный метод модифицирует приватное состояние, то передавать этот метод куда-то наружу — это вносить хаос в состояние объекта. И чем шире будет использоваться эта возможность, тем более непредсказуемым будет поведение программы. И этой возможностью будут пользоваться как можно реже, только когда по-другому совсем никак. В случае же отсутствия побочных эффектов ФВП можно будет использовать повсеместно (и это только добавит кайфа разработчикам).
В-четвёртых, прозрачность ссылок и ООП — вещи почти несовместимые — при модификации состояния любого объекта рвутся ссылки, что мешает нормальному моделированию. Хотя в соседней ветке Z00N привёл пример жестокой (иного слова подобрать не могу) реализации такого const-OOP через гхм... ну ты понял
В-пятых, в чистом функциональном мире все параметризованные типы могут быть ковариантны (то есть для любого параметризованного типа T: B < D => T[B] < T[D]), что невозможно в случае модифицируемого состояния (необходимость рантайм-проверок для того, чтобы не сломать систему типов).
В-шестых, ООП-шный полиморфизм не самым гладким образом сочетается с выводом типов. Это конечно мелочь, но всё равно неприятно.
Дальше можно вспомнить и непревзойдённую крутость системы типов Хаскеля по сравнению с системой типов любого ОО языка, и тому подобное.
В двух словах: те абстракции, которые отлично работают в случае ФП не факт что будут работать в общем случае. В идеале надо, чтобы компилятор позволял создавать такие чистые островки безопасности, а потом их использовать для реализации крупных объектов. Причём не надо никакого наследования, просто интерфейс — реализация.
VD>Да без разницы. ООП это тоже сахар. Я писал ОО-программы на С в 1993-ем году. Да было менее удобно чем на С++, но жить было можно. Когда появился сахар в виде классов, виртуальных методов и т.п. я с удовольствием им воспользовался.
Твоё понятие сахара что-то слишком широко.
Приведу пример: в чистом функциональном окружении можно ввод-вывод реализовать на стримах, континуэйшнах и монадах. Но значит ли отсюда то, что два пункта из этой тройки являются сахаром для третьего?
VD>Ну, тогда тебе остается согласиться и с тем, что почти все достижения ФЯ не имеют к ФЯ никакого отношения. Они появлись в ФЯ, но могут быть успешно использованы в императивном (модифицирующем переменные языки). И эти языки как не странно окажутся только гибче и удобнее чем "чистые". Ведь писать "чистый" фукнциональный код в них можно без проблем, но если что не будет проблемой и написать более эффективный или простой императивный код. В конце концов глупо же отказываться от тех же хэш-таблиц только потмому, что они императивны по сути?
Бывают, что ограничения позволяют сделать консервативные предположения, которые в свою очередь открывают дорогу к новым абстракциям, невозможным в общем случае. И ограничение побочных эффектов — как раз тот случай.
PS1: Никто не отказывается от хэш-таблиц, а их просто прячут внутрь языка, библиотек или ещё чего-нибудь.
PS2: Остальное (в частности то, как "рулят" отладчики) требует отдельных священных войн... Потом повоюем
PS3: VD>> ковровые бомбардировки и танковые клинья и еще этот, как его? А, гриб Сарумяна.
^ это понравилось, но про гриб не понял
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Не понятно, как такое может работать. Ну допустим, у них глобальные map-ы из identity в объект, через этот identity и идут ссылки. Ну допустим, они протаскивают этот контейнер через все вызовы параметром (кошмар неюзабельный).
Z>Конечно кошмар, и чтобы от него избавится все давно используют монады Z>Смотрите "State monad" и "O'Haskell" заодно. Монады на Scheme у Олега тоже есть — посмотрите там на сайте.
Монады — это кошмарный кошмар. Это то, чего в мире быть не должно. Монадная программа выглядит как императивная, и монады имеют тенденцию расползаться по коду, поражая всю программу. А если нечто выглядит как собака, жрет как собака, и, простите, какает, как собака, но сделано через задницу, то зачем платить больше? Можете найти хоть одно реальное преимущество такого ООП? По моему, оно гениальным образом объединяет в себе худшие черты императивного и функционального стиля. Проще не парить мозг, и воспользоваться честным, благородным, и всем понятным императивным расширением.
G>>Вот тебе простейший пример — электронная таблица, рекурсивно вычисляющая формулы, и использующая член класса для отметки, что "мы это уже считали" — выявление кольцевых ссылок. Хотя бы это у них сработает? А там можно и более сложные примеры найти. Давай разберемся.
Z>Давайте остановимся на кольцевых ссылках — вот чисто функциональный предикат 'cycle-list?' Z>Работает он так, давайте запистим по списку двух "пешеходов" — медленного и быстрого. Если они встретятся — список кольцевой — если кто-то дошел до конца — нет. Их состояние мы храним в двух аргументах внутренней функции 'helper':
Круто. Только чо-то я тут классов не вижу совсем. Не понимаю, к чему пример — он никак не относится к обсуждаемой теме. Какое отношение задачка с микрософтского интервью имеет к ООП? Она даже к проблеме кольцевых ссылок отношения не имеет — список в задаче не меняется.
Влад у меня создаётся впечатление, что ты очень неуважительно относишься к своим оппонентам. Фиг с ним, что ты назвал меня человеком, которому лень подумать, проинформировал меня чем у меня забита голова, яростно приобщил к фанатикам. Ну спроецировал ты разницу в наших взлядах на своё отношение ко мне — с кем не бывает. Но вот то, что ты просто напросто не читаешь то, что тебе пишут, а начинаешь додумывать, выглядит неприятно. Я попробую написать еще раз, а ты, пожалуйста, перед тем как отвечать прочитай до конца.
Напомню для начала о чём мы спорим, — спор был вызван тезисом о том, что ООП даёт больший оверхед, чем ФП.
Поэтому не скатывайся каждый раз к императивному программированию. Речь именно об ООП. О том, что в ИЯ что то есть или чего то нет для этого тезиса совершенно не интересно.
Дальше моё мнение о том, почему я считаю этот тезис справедливым.
За счёт чего создаётся оверхед в ООП? За счёт того, что "о действиях думают как об объектах".
О действиях, о которых думают как об объектах. Распишу ещё раз. Подробнее.
Различные классы Listener-ов, которые по сути представляют собой функцию. Есть такое? Есть. Приходиться думать о том, что слушатель событий это некий объект, которому передаются события и на которые он должен реагировать, вместо того, чтобы думать о том, что по приходу какого то события выполняется некое действие — всё, без дополнительных наворотов. Поэтому насчёт того, что ты не видел применения паттерна Команда я даже не знаю, что сказать. Кстати, не понял, как ты собираешься использовать вместо этого паттерна методы, покажи пожалуйста, хоть это и оффтоп.
Треды — это потоки (Thread), которые почему то представляют опять же объектами, чем не оверхед?
Генераторы — это то, что порождает (генерирует) некоторые данные. Однозначно действие, однако, представляется объектом. К метапрограммированию отношения не имеет.
Недостаточно примеров?
Повторю — всё это действия, однако, работая в ОО режиме мы вполне естественно создаём для них объекты. По крайней мере в стандартных библиотеках явы и си-шарпа мы найдём этому много подтверждений.
Теперь, что нам даёт взамен ФП (для выразительности, т.е. полного и ясного представления мысли — я верно понимаю слово "выразительность"?).
Это ФВП+отсутствие сайд эффектов. ФВП позволяет не представлять действия в виде объектов, а сайд-эффект вносит дополнительный вклад в ясность представления. Насколько я понимаю разногласия у нас именно в сайд-эффекте. Ты считаешь, что сайд эффект (отсутствие) нужен для автоматического распараллеливания, может быть для лучшей тестируемости код (в силу того, что функции получаются чистыми). Для меня же не только это.
Распараллеливание и прочие вещи, ПРОСТО получающиеся автоматически, берутся не спроста. Это связано с большой ясностью что происходит при отсутсвии сайд-эффектов. Большой ясностью не только для машины, но и для человека. Но ты так не считаешь. В этом, насколько я понимаю, и есть разница в нашем отношении к оспариваемому тезису "ООП vs ФП". Всё остальное — в частности твои разговоры о паттерн матчинге, о том, что всё в этом мире есть сахар, о том, что функциональный стиль может быть в любом языке, а в императивном можно вот так, и твоё постоянное смешивание понятий "функионального программирования" и "функциональных языков" — отношения к разговору не имеют, потому что не доказывают и не опровергают этот тезис.
Здравствуйте, Андрей Хропов, Вы писали:
L>>Всё относительно. По сравнению со свитчами — рулит, а по сравнению с ФВП+паттерн-матчинг — сосёт.
АХ>Не согласен. Паттерн-матчинг — это свитч на стероидах. Но тем не менее свитч. АХ>Если ты захочешь расширить вариант, то тебе скорее всего придется добавлять код АХ> там где делается паттерн-матчинг по этому варианту. АХ>Таким образом получается размазывание добавления новой функциональности по коду.
АХ>А если просто отнаследовать класс, то код обработки, вызывающий виртуальные функции менять не придется.
АХ>Всему свое место. Для не слишком сложных структур данных — варианты и паттерт-матчинг. АХ>Для более навороченных — классы, интерфейсы и полиморфизм.
Не согласен ;-) Ты (можно?) забыл про функции высшего порядка, которые куда как проще наследования с виртуальными функциями.
Для не слишком сложных структур данных — варианты и паттерт-матчинг.
Для более навороченных — + функции высшего порядка.
Тут уже обсуждали паттерн Посетитель на ФП, погляди — по моему то, о чём мы говорим. По крайней мере, решения именно такие, которые предлагаешь ты для ОО подхода, и я для функционального.
Здравствуйте, lomeo, Вы писали:
L>Влад у меня создаётся впечатление, что ты очень неуважительно относишься к своим оппонентам. Фиг с ним, что ты назвал меня человеком, которому лень подумать, проинформировал меня чем у меня забита голова, яростно приобщил к фанатикам. Ну спроецировал ты разницу в наших взлядах на своё отношение ко мне — с кем не бывает. Но вот то, что ты просто напросто не читаешь то, что тебе пишут, а начинаешь додумывать, выглядит неприятно. Я попробую написать еще раз, а ты, пожалуйста, перед тем как отвечать прочитай до конца.
L>Треды — это потоки (Thread), которые почему то представляют опять же объектами, чем не оверхед?
Оверхед это когда затраты есть, а выгод нету. А это не оверхед, а плата за доп.удобства. Например, процесс в ST можно сериализовать-десериализовать и запустить. О полезности/бесполезности такого сейчас не нужно говорить — я так никогда не делал, но в форуме по Squeak видел, что люди справшивали можно ли такое сделать и делали.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Оверхед это когда затраты есть, а выгод нету. А это не оверхед, а плата за доп.удобства. ;) Например, процесс в ST можно сериализовать-десериализовать и запустить. О полезности/бесполезности такого сейчас не нужно говорить — я так никогда не делал, но в форуме по Squeak видел, что люди справшивали можно ли такое сделать и делали.
Ну почти. В данном случае оверхед — это разница в затратах для одних и тех же задач. Может быть для этой задачи — сериализация процесса, это не оверхед. Хотя и можно предложить функциональные решения, но тогда мы скатимся в частности.
Вообще, мне не очень нравится это слово — оверхед.
А насчёт ST — так он использует очень много из функционального подхода, и при работе с ним легко думать о блоках как о фунциях, а не объектах. Собственно, чем он мне и нравится.
Re[11]: Purely-functional Object-Oriented System in Scheme
Здравствуйте, Gaperton, Вы писали:
G>Монады — это кошмарный кошмар. Это то, чего в мире быть не должно. Монадная программа выглядит как императивная, и монады имеют тенденцию расползаться по коду, поражая всю программу. А если нечто выглядит как собака, жрет как собака, и, простите, какает, как собака, но сделано через задницу, то зачем платить больше? Можете найти хоть одно реальное преимущество такого ООП? По моему, оно гениальным образом объединяет в себе худшие черты императивного и функционального стиля. Проще не парить мозг, и воспользоваться честным, благородным, и всем понятным императивным расширением.
Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.)
Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами. Те же list comprehensions, например. Выглядят искусственно в любом языке, кроме Хаскелла. (имхо)
Здравствуйте, VladD2, Вы писали:
VD>Вариант на то и вариант, что он закрытый тип. Его нельзя расширить извне. И сделано это не случайно. При появлении нового значения, в тех местах коде по варианту делается паттерн-матчинг будет выдано сообщение, что такого-то значения не обработано. И ты легко внесешь изменения во все нужные места. То есть на лицо контроль и помощь компилятора.
Это смотря как написать.
type Var = Foo | Bar | Buz {- добавьте сюда ещё Err -}
f :: a -> Var -> a
f x Foo = x+1
f x Bar = x*2
f x _ = x*x -- как бы сэкономили на последней проверке
g :: a -> Var -> a
g x Foo = x-1
g x Bar = x/2
g x _ = sqrt x
Опять же, что быстрее — один раз построить функцию и передавать/вызывать её, или же каждый раз выполнять сопоставление.
type Var' a = Vars { there :: a->a, back :: a->a }
foo = Vars (\x -> x+1) (\x -> x-1)
bar = Vars (\x -> x*2) (\x -> x/2)
buz = Vars (\x -> x*x) (\x -> sqrt x)
f x var = (there var) x
g x var = (back var) x
(этот пример, конечно, утрирован).
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[12]: Purely-functional Object-Oriented System in Scheme
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Монады — это кошмарный кошмар. Это то, чего в мире быть не должно. Монадная программа выглядит как императивная, и монады имеют тенденцию расползаться по коду, поражая всю программу. А если нечто выглядит как собака, жрет как собака, и, простите, какает, как собака, но сделано через задницу, то зачем платить больше? Можете найти хоть одно реальное преимущество такого ООП? По моему, оно гениальным образом объединяет в себе худшие черты императивного и функционального стиля. Проще не парить мозг, и воспользоваться честным, благородным, и всем понятным императивным расширением.
К>Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.)
Я вообще говорю об ООП и моделировании состояния.
К>Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами. Те же list comprehensions, например. Выглядят искусственно в любом языке, кроме Хаскелла. (имхо)
Какая нам разница, в контексте данного разговора.
Re[13]: Purely-functional Object-Oriented System in Scheme
К>Это ты говоришь о монадах, реализующих последовательный конвеер (IO, State и т.п.) К>Но есть ещё и монады-множества — список, Maybe, Either и т.д., позволяющие компактно выражать функции над множеством через функции над элементами.
Это просто категорийская ересь. Все прекрасно выражается и без всяких монад.
Re[13]: Purely-functional Object-Oriented System in Scheme
Трурль wrote: > Это просто категорийская ересь. Все прекрасно выражается и без всяких монад.
Я что-то, видимо, пропустил. Если монады — это ересь, то какая религия
нынче самая правильная?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Только чо-то я тут классов не вижу совсем. Не понимаю, к чему пример — он никак не относится к обсуждаемой теме. Какое отношение задачка с микрософтского интервью имеет к ООП? Она даже к проблеме кольцевых ссылок отношения не имеет — список в задаче не меняется. 
Перекуём баги на фичи!
