WH>На первом. И с огромным отрывом. WH>goto пакостит только внутри функции, а глобальные переменные по всей программе. WH>Что называется почувствуйте разницу.
так это потому что Дейкстра критиковал вовсе не то goto, которое сейчас в C. goto в C действительно локальное и безобидное.
Дейстра критиковал goto по всей программе, типа longjmp.
Здравствуйте, minorlogic, Вы писали:
M>А тут кто то доказательства доказывает ? Я думал просто на примере пытаются продемонстрировать мысль ?и
Для иллюстрации мысли сначала высказывают саму мысль, и лишь затем иллюстрируют ее аналогией. В обсуждаемом же сообщении ничего кроме аналогии нет. Классика жанра.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая.
И эта новая функция неразрывно связана с данными. ЧТД.
ВВ> В этом плане каррирование не сильно отличается от дефолт параметров.
Ну и что?
ВВ> В ООП у тебя функции привязаны к структурам данных всегда.
Статические функции в классе без статических полей — почти не привязаны.
AVK>>Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции.
ВВ>Слушай, давай ты не будешь уходить в ту же степь
Э нет, эта степь как раз та самая. Это ты все увильнуть пытаешься.
ВВ>, что и товарищ tripol в этой теме, который уже практически доказал, что функциональное программирование невозможно, т.к. состояние на стеке — это тоже "скрытое" состояние
Товарищь tripol как раз и споткнулся об твое вольное обращение с термином "состояние". Потому что, если не принимать во внимания твои умолчания, ты написал конкретный бред — что состояние противоречит ФП.
ВВ>И в отличие от каррирования, для которого существует обратная процедура под названием декаррирование
В теории. На практике далеко не всегда.
ВВ>У всего есть какие-то границы на самом деле. Да на самом деле любая функция инкапсулирует свое состояния, и это состояние увидеть снаружи нельзя.
Молодец.
ВВ>Возникает только вопрос — на фига?
Не знаю. Речь то не о проведении параллелей, а о твоем доказательстве несовместимости ФП и ООП. Так вот, твои заявления об отсутствии инкапсуляции в ФП — полная фигня.
ВВ>А приводить примеры всякой хрени, вроде генераторов, мне нужно. Потому что, во-первых, чистых ФЯ не существует, кроме совсем уж эзотерических. А во-вторых — ФЯ все же довольно старые языки, и в них дебютировали многие концепции, которые, собственно, развитием идей ФП ни в каком смысле не являются, а являются скорее попыткой примирить ФЯ с реальными практическими задачами.
Угу, если факты не подходят под теорию — тем хуже для фактов. Знакомо.
ВВ>Ты меня просто не понял и начал заниматься софистикой. И ООП, и ФП строятся на процедурном программировании. Понятно, что между ними можно найти немало общего.
Куда интереснее найти то, что делает их несовместимыми. У тебя пока не вышло.
ВВ> Только вот это совершенно не говорит о том, что их общие подходы должны быть совместимы.
Ты чего то путаешь. Это тебе надо доказывать свое утверждение, что они несовместимы. Я обратного, между прочим, в этом топике не утверждал.
ВВ>>>Все правильно, только это уже не ООП. AVK>>Самому не смешно?
ВВ>Нет, мне грустно. ООП предоставляет механизм полиморфизма классов
И много чего другого.
ВВ>, который ты нарушаешь с помощью композиции
Нет, не нарушаю.
ВВ>Ты тут мои "пседоаксиомы" критикуешь, а сам же ты вообще ничего пытаешься обосновать.
Верно. Потому что я и утверждений не делаю. В отличие от тебя.
AVK>>Ты не переключай тему. Ты доказывай, почему ФП противоречит ООП и с ним не совместимо.
ВВ>Я уже говорил.
О, говорить то ты много чего говорил. Только не обосновал.
ВВ>Практика ООП
Как интересно. Уже не сам ООП, а чья то практика. Смешно. Давай дальше.
ВВ>- Структуры данных и функции слепливаются воедино и именуются "классами".
Не всегда. ООП позволяет это удобно делать, но не навязывает.
ВВ>- В качестве одного из следствий этого мы получаем не просто инкапсуляцию состояния, а инкапсуляцию побочных эффектов.
Неопределенный термин "инкапсуляция побочных эффектов".
ВВ>И первое, и второе весьма затрудняют программирование в ФП-стиле.
Ну то есть некий практик зачем то городит несовместимый с ФП дизайн, а затем оказывается, что виноват в этом не этот практик, а ООП. Сильно, ничего не скажешь. Но неубедительно. Логическая ошибка очень простая — из того что конкретный ОО-дизайн может быть несовместим с ФП никак не следует что все ОО-дизайны несовместимы с ФП.
ВВ>Они не дружат, потому что они не дружат.
Во-во. Я о том и говорю. Аргументация доставляет.
ВВ> В ООП удобнее скрыть изменение состояния, в ФП — удобнее не скрывать.
Удобнее — понятие субъективное.
ВВ> Если попытаться их скомбинировать, то получится или очень хреновое ООП, или очень хреновое ФП.
У кого как.
ВВ>Если у тебя есть пример приложения, где они удачно сочетаются — опиши архитектуру, обсудим.
LINQ подойдет?
AVK>>Есть в ФП и более интересные конструкции в эту тему. Например классы типов в хаскеле.
ВВ>О, боже, ну причем тут классы типов?
Полиморфизьм, которого, якобы, в ФП нет.
ВВ> Кто тут из нас с темы соскальзывает? Классы типов в том же хаскеле были придуманы, чтобы обойти ограничения, придуманные в хаскеле.
Да нет, они были придуманы для полиморфизма.
ВВ>>>Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах. AVK>>Вася, не надо выделять никакие сущности, тебя об этом никто не просит.
ВВ>Т.е. ты просишь меня объяснить, почему ФП на мой взгляд не сочетается с ООП, но при этом слушать о том, что я понимаю под ФП ты не хочешь?
Мне не интересно что ты персонально понимаешь под ФП, бо это спор о терминах, бессмысленный и беспощадный. Определение ФП есть в вики, можешь им воспользоваться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.
Классы ООП тоже можно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие. Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников".
Не так быстро, если можно. По каждому паттерну дано не только условие, то бишь зачем он, но и его схема в сугубо ООП-стиле. Более того, эти схемы даны в стиле ООП-языков со строгой статической типизацией, что не просто уже ООП, а ООП с весьма серьезными ограничениями. Так что, извини, но это не "просто паттерны", ибо для "просто ООП" (без подобных ограничений), и тем более не-ООП, многие из указанных паттернов вовсе не нужны. Приглядись, добрая их половина служит как раз для борьбы с указанным ограничением, по-сути, являясь не более чем "трюком" в рассматриваемой системе координат.
Здравствуйте, mrTwister, Вы писали:
T>Не согласен, моя практика показывает, что при понимании того, что immutable объекты — это круто, со временем остается очень мало mutable кода.
Ну да, ничего удивительного. Глупо не пользовать GC, если он под рукою... Другое дело когда его нет, тогда весь этот пафос выглядит слегка надуманным.
Здравствуйте, mrTwister, Вы писали:
S>>А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко. T>Мировая тенденция как раз движется сейчас в этом направлении с распространением многоядерных процессоров.
А какие проблемы с локальными состояниями в ООП в случае многопоточности? И насколько локальное состояние отличается от АТД? Или, переформулирую: где вообще проходит граница м/у АТД и локальными состояниями?
ООП несомненно неплох в том, что практически не навязывает парадигму, ибо является инструментом очень низкого уровня. Просто не все это понимают. Ты, находясь в рамках одного и того же ООП-ЯВУ, запросто можешь на нем реализовать такую систему прикладных типов, которые могут представлять из себя и абстракции ФП, и логического и реактивного программирования.
ИМХО, проблемы с ООП примерно такие же как с MFC в свое время, от непонимания позиционирования технологии. Ну низкого уровня эта технология, "гибкий кирпич", не наделенный никакой магией сам по себе.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Воронков Василий, Вы писали: ВВ>>ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая. AVK>И эта новая функция неразрывно связана с данными. ЧТД.
И никакого отличия между ней и классом нет, да?
ВВ>> В ООП у тебя функции привязаны к структурам данных всегда. AVK>Статические функции в классе без статических полей — почти не привязаны.
Да, и подобные функции как раз и нарушают чистоту ООП в языках. Это чистое процедурное программирование.
AVK>>>Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции. ВВ>>Слушай, давай ты не будешь уходить в ту же степь AVK>Э нет, эта степь как раз та самая. Это ты все увильнуть пытаешься.
"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать? Люди диссертации пишут о том, что такое ФП, а ты смотришь определение в википедии? Если нет желания думать об этом — какой смысл вообще что-то обсуждать. Спорить с оппонентом, позиция которого основана на аксиомах, невозможна.
Твоя позиция, видимо, сводится к тому, что программирование в "функциональном стиле" ООП никак не противоречит. Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП. Полноценно писать в ФП на Шарпе практически невозможно. Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
А если ты там где-то сбоку прикрутил Линк и вставил несколько функций высшего порядка, полагаешь у тебя от этого программа сильно функциональной становится?
ВВ>>, что и товарищ tripol в этой теме, который уже практически доказал, что функциональное программирование невозможно, т.к. состояние на стеке — это тоже "скрытое" состояние AVK>Товарищь tripol как раз и споткнулся об твое вольное обращение с термином "состояние". Потому что, если не принимать во внимания твои умолчания, ты написал конкретный бред — что состояние противоречит ФП.
Хорошо, ну теперь-то мы разобрались что я имел в виду?
Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
ВВ>>Возникает только вопрос — на фига? AVK>Не знаю. Речь то не о проведении параллелей, а о твоем доказательстве несовместимости ФП и ООП. Так вот, твои заявления об отсутствии инкапсуляции в ФП — полная фигня.
Я таких заявлений не делал. Я делал простое заявление — ООП стремится к инкапсуляции побочных эффектов, ФП — к избавлению от оных.
ВВ>>А приводить примеры всякой хрени, вроде генераторов, мне нужно. Потому что, во-первых, чистых ФЯ не существует, кроме совсем уж эзотерических. А во-вторых — ФЯ все же довольно старые языки, и в них дебютировали многие концепции, которые, собственно, развитием идей ФП ни в каком смысле не являются, а являются скорее попыткой примирить ФЯ с реальными практическими задачами. AVK>Угу, если факты не подходят под теорию — тем хуже для фактов. Знакомо.
О каких фактах речь? Ты считаешь генераторы основополагающей концепцией ФП? От того, что ты ответишь "да", они таковыми не станут.
ВВ>>Ты меня просто не понял и начал заниматься софистикой. И ООП, и ФП строятся на процедурном программировании. Понятно, что между ними можно найти немало общего. AVK>Куда интереснее найти то, что делает их несовместимыми. У тебя пока не вышло.
Ты понимаешь, когда действительно хотят что-то найти, то сначала очерчивают рамки — где, собственно, искать-то будут. Для того, чтобы показать несовместимость двух концепций, надо сделать редукцию этих концепций, оставив лишь самое основное, то, что определяет их сущность. И вот тут-то как раз и начинается — композиция для тебя основопологающий паттерн ООП, а ФП без генераторов даже помыслить нельзя.
А *что* делает их несовместимыми я уже писал и повторял раз надцать — ООП приводит к тому, что программирование строится на инкапсуляции побочных эффектов, ФП напротив стремится избежать этого. Побочные эффекты есть, конечно, и там, и там. Но последовательный дизайн программы в ООП стиле противоречит ФП стилю — они идут в разные стороны. Программа не может быть одновременно ООП и ФП. А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
AVK>Ну то есть некий практик зачем то городит несовместимый с ФП дизайн, а затем оказывается, что виноват в этом не этот практик, а ООП. Сильно, ничего не скажешь. Но неубедительно. Логическая ошибка очень простая — из того что конкретный ОО-дизайн может быть несовместим с ФП никак не следует что все ОО-дизайны несовместимы с ФП.
Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq?
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава. AVK>Классы ООП тоже можно.
Можно. Об этом и речь. Собственно, вопрос, "а не является ли ХХХ лишь набором паттернов, а не отдельной парадигмой" применим к ним обоим.
Здравствуйте, AndrewVK, Вы писали: AVK>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе.
Ну вот в дотнете эвент — тоже first class citizen. А толку?
Здравствуйте, IT, Вы писали: IT>А что такое настоящая парадигма? ООП — это тоже несколько паттернов: инкапсуляция, наследование, полиморфизм.
Идеи ООП вытекают из наблюдения за объектами реального мира, которые существуют, могут изменяться и воздействовать на другие объекты независимо от сознания наблюдателя. Инкапсуляция, полиморфизм и наследование возникают в ходе попыток сабжевые объекты классифицировать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая. AVK>>И эта новая функция неразрывно связана с данными. ЧТД.
ВВ>И никакого отличия между ней и классом нет, да?
Практически нет. Функциональные объекты представляют из себя то же, что и ОО-объекты, это некие данные + обрабатывающие ф-ии. Отличие функционального объекта от ОО-объекта лишь в том, что функциональный объект имеет лишь единственную ф-ию в своём видимом АПИ.
AVK>>Статические функции в классе без статических полей — почти не привязаны. ВВ>Да, и подобные функции как раз и нарушают чистоту ООП в языках. Это чистое процедурное программирование.
Обычная инкапсуляция это.
ВВ>"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать? Люди диссертации пишут о том, что такое ФП, а ты смотришь определение в википедии?
ФП — это лишь подход к решению проблемы. И почему его нельзя использовать совместно с другими подходами?
ВВ>А если ты там где-то сбоку прикрутил Линк и вставил несколько функций высшего порядка, полагаешь у тебя от этого программа сильно функциональной становится?
Достаточно сильно.
ВВ>Хорошо, ну теперь-то мы разобрались что я имел в виду? ВВ>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
С классом нельзя. Как вообще можно сравнивать типы и экземпляры?
ВВ>Я таких заявлений не делал. Я делал простое заявление — ООП стремится к инкапсуляции побочных эффектов, ФП — к избавлению от оных.
Если учесть, что побочный эффект от непобочного отличается лишь тем, что в первом случае нам известна область памяти, которая изменяется в процессе работы программы, то по-прежнему это можно считать лишь разным взглядом на вещи.
Но отличия ООП от ФП, разумеется, не в этом. Отличие заключается в способе декомпозиции логики. А что касается "Чистого ФП", который без побочных эффектов — то это лишь некая практика, навроде паттерна в этой системе, с вполне разжеванными бенефитами. Само по себе ФП к избавлению от побочных эффектов не стремится, так же как не стремится программа на ООП к исопльзованию своих ООПэшных паттернов. Человек может стремится юзать паттерны.
Опять же, а как же монады в Хаскеле? Разве не являются монады способом "протащить" некое состояние в процессе вычислений? Просто рекурсии — они ведь глубиной стека ограничены, и нужен был механизм размещения состояний, не требующий все новых ячеек стека. Вот тебе монады. "Костыль"/инфраструктура для того, чтобы имеющиеся "чистые" ф-ии использовать для модификации заведомо известного набора данных.
ВВ>О каких фактах речь? Ты считаешь генераторы основополагающей концепцией ФП? От того, что ты ответишь "да", они таковыми не станут.
Я думаю, что собеседник считает основополагающим в ФП ф-ии высших порядков. Остальное — подробности ограничений различных реализаций и подходов, причем не всегда обязательные.
ВВ>Но последовательный дизайн программы в ООП стиле противоречит ФП стилю — они идут в разные стороны.
До чего же скучно читать подобные высказывания... Нуднее зубной боли...
Ты же изучал, например, схемотехнику в институте. И видел, что прекрасно в одной сложной схеме используются как "чистые ФП" — компоненты, то бишь логические схемы без памяти, так же как схемы с триггерами и прочими ячейками памяти. Почему в схемотехнике оба подхода уживаются, у тебя нет? Более того, преобразователи с памятью строятся как преобразователи без памяти + память. Считай, что императивный подход получается таким же образом из ф-ного.
Выдели отдельно состояние и модифицируй его путем путем присвоения результата работы "чистых" ф-ий. Хочу заметить, что это весьма удобный способ декомпозиции на низком уровне сам по себе, т.к. понижает общую связанность системы, и эти "чистые" ф-ии становятся легко повторно применимы, как кирпичи при реализации методов классов. Ну вот типа как библиотеки работы с коллекциями из LINQ, даже если юзать их без LINQ-синтаксиса.
ВВ>Программа не может быть одновременно ООП и ФП. А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
Может. Даже если прикрутить гораздо больше фишек, чем в C#. ФП-компоненты могут быть удобными кирпичиками для реализации кода методов ОО-иерархий.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, AndrewVK, Вы писали: AVK>>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе. MC>Ну вот в дотнете эвент — тоже first class citizen. А толку?
Только не event, а delegate, ибо первое — лишь спецификация пары ф-ий в метаинформации, поддержанная компилятором + синтаксисом. И толк очевиден, на этом ф-ом объекте, делегате, строятся заимствования и расширения языка в сторону ФП-стиля.
Здравствуйте, Воронков Василий, Вы писали:
AVK>>И эта новая функция неразрывно связана с данными. ЧТД.
ВВ>И никакого отличия между ней и классом нет, да?
С чего ты взял?
ВВ>Да, и подобные функции как раз и нарушают чистоту ООП в языках. Это чистое процедурное программирование.
Т.е. ООП еще и с процедурным программированием не совместимо?
ВВ>"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать?
Я тебе еще раз напоминаю, что утверждения здесь делаешь ты, а не я.
ВВ>Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП.
ВВ> Полноценно писать в ФП на Шарпе практически невозможно.
Опять неопределенный термин "полноценно писать".
ВВ> Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
Ужас просто.
ВВ>А если ты там где-то сбоку прикрутил Линк и вставил несколько функций высшего порядка, полагаешь у тебя от этого программа сильно функциональной становится?
Неопределенный термин "сильно функциональная".
ВВ>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
А я ее и не сравниваю. На прямое опровержение твоим словам, что данные и функции в ФП связать нельзя.
ВВ>Я таких заявлений не делал.
Очередная стадия — отказ от своих слов.
Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет.
В принципе, уже все понятно.
ВВ>О каких фактах речь? Ты считаешь генераторы основополагающей концепцией ФП?
Основополагающей концепцией не считаю. Считаю совместимой с ФП штукой.
AVK>>Куда интереснее найти то, что делает их несовместимыми. У тебя пока не вышло.
ВВ>Ты понимаешь, когда действительно хотят что-то найти, то сначала очерчивают рамки — где, собственно, искать-то будут.
Да пофик. Сколько рамки не очерчивай, надо все таки несовместимости показать. Ни для полиморфизма, ни инкапсуляции ты такого пока не показал, сколько рамки не очерчивал. Несовместимости, понимаешь? Не принадлежности, а несовместимости.
ВВ>А *что* делает их несовместимыми я уже писал
А я тебя опровергал.
ВВ> и повторял раз надцать — ООП приводит к тому, что программирование строится на инкапсуляции побочных эффектов
Не доказано.
ВВ>Побочные эффекты есть, конечно, и там, и там. Но последовательный дизайн программы в ООП стиле
Неопределенный термин "последовательный дизайн".
ВВ> противоречит ФП стилю — они идут в разные стороны.
Не доказано.
ВВ> Программа не может быть одновременно ООП и ФП.
Не доказано.
ВВ> А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
"Сбоку" это лирика. ФП и ООП либо можно использовать совместно, либо нельзя.
ВВ>Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq?
"Совместимый с ФП ООП дизайн"
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Mr.Cat, Вы писали:
AVK>>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе. MC>Ну вот в дотнете эвент — тоже first class citizen. А толку?
А какого толку ты ждешь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Mr.Cat, Вы писали:
MC>Идеи ООП вытекают из наблюдения за объектами реального мира, которые существуют, могут изменяться и воздействовать на другие объекты независимо от сознания наблюдателя.
Идеи могут вытекать откуда угодно, но современный ОО-дизайн не является зеркалом реального мира.
ООП удобен не тем, что моделирует реальный мир, а тем что мозг человека природой приспособлен мыслить сущностями, в том числе и абсолютно абстрактными. Объекты как раз и есть отражение абстрактных сущностей в мозгу человека.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Mr.Cat, Вы писали:
MC>Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
По-моему, парадигма — это базис, в котором другая парадигма может быть выражена как набор паттернов. Так что это отношение ФП-ООП и в обратную сторону работать будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Если нет желания думать об этом — какой смысл вообще что-то обсуждать. Спорить с оппонентом, позиция которого основана на аксиомах, невозможна.
