Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики, после чего эфир был незаслуженно “закрыт” и отправлен в отставку, и вот уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра. “Ну и где мы теперь, с этой вашей красивой теорией относительности, кто-нибудь может мне назвать хоть какие-то реально-практические результаты её применения в вашей обыденной жизни после целого века её ковыряния и массового насаждения?” – как всегда язвительно вопрошает Гэбриел.
Авторов, использующих такую аргументацию, читать не стоит.
. При наличии языка с сильной поддержкой функциональной парадигмы места ООП почти не остается. На уровне методов его полностью заменяет ФП, а на уровне интерфейсов подсистем — SOA (которое далеко не ООП).
Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Воронков Василий, Вы писали: ВВ>>ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая. AVK>И эта новая функция неразрывно связана с данными. ЧТД.
И никакого отличия между ней и классом нет, да?
ВВ>> В ООП у тебя функции привязаны к структурам данных всегда. AVK>Статические функции в классе без статических полей — почти не привязаны.
Да, и подобные функции как раз и нарушают чистоту ООП в языках. Это чистое процедурное программирование.
AVK>>>Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции. ВВ>>Слушай, давай ты не будешь уходить в ту же степь AVK>Э нет, эта степь как раз та самая. Это ты все увильнуть пытаешься.
"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать? Люди диссертации пишут о том, что такое ФП, а ты смотришь определение в википедии? Если нет желания думать об этом — какой смысл вообще что-то обсуждать. Спорить с оппонентом, позиция которого основана на аксиомах, невозможна.
Твоя позиция, видимо, сводится к тому, что программирование в "функциональном стиле" ООП никак не противоречит. Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП. Полноценно писать в ФП на Шарпе практически невозможно. Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
А если ты там где-то сбоку прикрутил Линк и вставил несколько функций высшего порядка, полагаешь у тебя от этого программа сильно функциональной становится?
ВВ>>, что и товарищ tripol в этой теме, который уже практически доказал, что функциональное программирование невозможно, т.к. состояние на стеке — это тоже "скрытое" состояние AVK>Товарищь tripol как раз и споткнулся об твое вольное обращение с термином "состояние". Потому что, если не принимать во внимания твои умолчания, ты написал конкретный бред — что состояние противоречит ФП.
Хорошо, ну теперь-то мы разобрались что я имел в виду?
Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
ВВ>>Возникает только вопрос — на фига? AVK>Не знаю. Речь то не о проведении параллелей, а о твоем доказательстве несовместимости ФП и ООП. Так вот, твои заявления об отсутствии инкапсуляции в ФП — полная фигня.
Я таких заявлений не делал. Я делал простое заявление — ООП стремится к инкапсуляции побочных эффектов, ФП — к избавлению от оных.
ВВ>>А приводить примеры всякой хрени, вроде генераторов, мне нужно. Потому что, во-первых, чистых ФЯ не существует, кроме совсем уж эзотерических. А во-вторых — ФЯ все же довольно старые языки, и в них дебютировали многие концепции, которые, собственно, развитием идей ФП ни в каком смысле не являются, а являются скорее попыткой примирить ФЯ с реальными практическими задачами. AVK>Угу, если факты не подходят под теорию — тем хуже для фактов. Знакомо.
О каких фактах речь? Ты считаешь генераторы основополагающей концепцией ФП? От того, что ты ответишь "да", они таковыми не станут.
ВВ>>Ты меня просто не понял и начал заниматься софистикой. И ООП, и ФП строятся на процедурном программировании. Понятно, что между ними можно найти немало общего. AVK>Куда интереснее найти то, что делает их несовместимыми. У тебя пока не вышло.
Ты понимаешь, когда действительно хотят что-то найти, то сначала очерчивают рамки — где, собственно, искать-то будут. Для того, чтобы показать несовместимость двух концепций, надо сделать редукцию этих концепций, оставив лишь самое основное, то, что определяет их сущность. И вот тут-то как раз и начинается — композиция для тебя основопологающий паттерн ООП, а ФП без генераторов даже помыслить нельзя.
А *что* делает их несовместимыми я уже писал и повторял раз надцать — ООП приводит к тому, что программирование строится на инкапсуляции побочных эффектов, ФП напротив стремится избежать этого. Побочные эффекты есть, конечно, и там, и там. Но последовательный дизайн программы в ООП стиле противоречит ФП стилю — они идут в разные стороны. Программа не может быть одновременно ООП и ФП. А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
AVK>Ну то есть некий практик зачем то городит несовместимый с ФП дизайн, а затем оказывается, что виноват в этом не этот практик, а ООП. Сильно, ничего не скажешь. Но неубедительно. Логическая ошибка очень простая — из того что конкретный ОО-дизайн может быть несовместим с ФП никак не следует что все ОО-дизайны несовместимы с ФП.
Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq?
Здравствуйте, 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
Только время покажет, кто в итоге окажется правым, а кто в этой горячей методологической дискуссии искренне заблуждался.
...
не нужно бояться, если в очередной раз в истории вдруг окажется, что… “король-то голый”!
Именно что не нужно
Дайте наконец пощупать "провал ООП"
Или
Провалите в конце концов это чертово ООП.
Но там же: Томас Поток (Thomas Potok) из Oak Ridge National Laboratory даже провел масштабное прикладное исследование, которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами, работающими в стиле ООП и в обычном процедурном стиле программирования.
Дык не понял — какой именно король голый, если нет разницы? Обое тогда голые.
И самое важное, чего и в этой статье нет: Большую часть времени программисты сопровождают, модифицируют чужой код см "Факты и заблуждения профессионального программирования" Р. Гласса.
Поэтому все замеры производительности программиста по написанию нового кода такая же туфта, как измерять эффективность ЯП кодом:
for (int i=0, j=0; i < 1000000; ++i) j=i;
. При наличии языка с сильной поддержкой функциональной парадигмы места ООП почти не остается. На уровне методов его полностью заменяет ФП, а на уровне интерфейсов подсистем — SOA (которое далеко не ООП).
Хотя и ФП, и SOA представимы с помощью инструментария ООП, но этот факт зачастую только мешает грамотному проектированию, а не помогает ему.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, PC_2, Вы писали:
PC_>>Даа ... С++ еще тот фрухт под флагами ООП, напортачишь с сборкой муссора в большом проекте и будешь касперов, этих милых приведений, ловить до скончания веков. Опять таки, в функциональном подходе еще 50 лет сборка муссора ложится в архитектуру вычислителя что дети в школу
T>Собственно среда разработки показывает, если вдруг где то налажался...
неси зачотку
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Cadet, Вы писали:
C>>Да чтоб я так же провалился, как ООП.
Т>А ты уверен, что хочешь провалиться так же? По-моему, "провалиться как ООП" означает примерно следующее: Т>Ты приходишь на работу и объявляешь, насколько ты крут. Т>Тебе верят, дают умопомрачительную зарплату и ожидают решения всех проблем. Т>Некоторое время все от тебя в восхищении. Т>Затем наступает некоторое разочарование и устанавливается мнение, что ты просто хороший программист, не хуже, но и не лучше других, и что особых чудес ждать от тебя не приходиться.
Здравствуйте, VladD2, Вы писали:
VD>>>Думаю, что с ООП у него тоже все довольно не плохо. IB>>Не хорошо, я проверял.. =)) VD>Это субъективное мнение .
Не спорь с ним. Я как-то нелестно высказался об его статье, где он критиковал жирную модель Фаулера, причем весьма наивно, надо сказать, а Фаулер и Ко мне вообще нравится, его по крайней мере читать интересно, в отличие от, с тех пор он обожает ставить мне минусики со смайликами, обидчивый, видно, человек
IB>>Это все верно, но сомнения рождаются от недопонимания... VD>Не только.
Да не пытаюсь я ООП принизить в самом деле. Просто, увы, РСДН по-другому не работает. Как тут шутил кто-то — спросишь на форуме "Как сделать в С++ то-то", ну получишь в лучшем случае пару ленивых ответов в стиле "читай доки". А вот если написать — "Говно этот ваш С++, на нем даже нельзя нормально сделать то-то", то ответы будут подробнейшими и исчерпывающими
Во-первых, не только инкапсуляцию состояния, но и инкапсуляцию поведения. Ни то, ни другое не противоречит ФП. Проблемы будут только с изменением состояния. При этом ООП не заставляет тебя использование изменяемого состояния. Рассмотрим, например каталог ООП паттернов ГОФ:
Abstract Factory
1) Builder
2) Factory Method
3) Prototype
4) Singleton
5) Adapter
6) Bridge
7) Composite
8) Decorator
9) Facade
10) Flyweight
11) Proxy
12) Chain of responsibility
13) Command
14) Interpreter
15) Iterator
16) Mediator
17) Memento
18) Observer
19) State
20) Strategy
21) Template method
22) Visitor
Из всех этих паттернов только Builder, Iterator и State в классической реализации предполагают изменение состояния. При этом ничто не мешает сделать immutable реализацию даже этих трех паттернов.
Здравствуйте, tripol, Вы писали:
FR>>Нету абсолютно "чистых" ФП это бессмысленно. FR>>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
T>В каких областях?
Во всех, неизолированное изменяемое состояние — зло.
Я не решаю проблем, которых у меня нет. Никогда не страдал от побочных эффектов в ООП. Для того, что бы
решать не существующие проблемы, мне не зачем изучать новую парадигму, которая, якобы, исправляет
несуществующие проблемы.
Здравствуйте, rsdn2010, Вы писали:
T>>Как говорил не помню кто, что C или C++ это веревка достаточной длины, что бы выстрелить себе в голову... R>в ногу
Да ладно, пусть в голову себе стреляет. Мы не против...
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Фукерман, Вы писали:
Ф>>http://citforum.ru/gazeta/165/ V>Это надо занести в список капецов: V>1. Венде-капец. V>2. C-капец. V>3. C++-капец. V>4. Вот теперь ООП-капец.
V>ЗЫ: А мужики то не знали!
ООП не капец, поскольку его потихоньку пилят в нужном направлении.
Глобальные переменные подгребли,
талмуды по рефакторингу написали,
талмуды по паттернам — тоже написали,
сборку муссора ценой титанических усилий — сделали,
лямды и прочье — тоже потихоньку подмешивают с синтаксическим сахарком
Скоро будет мемоизация ( я вот в своем проекте хочу покрутить ).
Так что ООП жив и будет жить. То что многое из этого было еще 50 лет в ФП уже мало кого интересуют. Есть миллиард студентов и индусов, развернутая ИТ индустрия, тысячи библиотек без которых прожить уже нельзя.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Обе функции есть частный случай ФВП. Такая формулировка устроит? Sort, конечно же, не более общий случай, что-то я заговариваюсь последнее время.
Вполне устроит. Осталось показать, как реализовать второй частный случай в С.
ВВ>Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает. Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
Дело не в композиции. Дело в семантике.
ВВ>ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно.
Удобство — вопрос, в некотором смысле, второстепенный. Если есть подходящая семантика, то этого, в принципе, достаточно. Если нет — то придётся извращаться с эмуляцией.
ВВ>Твой пример с композицией — типичной операцией над функциональном типе в ФЯ — очень характерен (кстати, зачем там "new"? ). Попробуй изобразить композицию для трех функций, для четырех. Как все это будет выглядеть? Не очень-то декларативно. А еще и про каррирование не стоит забывать.
При чём тут "декларативность"? Композиция есть композиция.
ВВ>Поэтому мое личное ИМХО — джаваскрипт НЕ функциональный язык. Вроде и замыкания есть, но все равно чего-то не хватает.
А чего именно? Мы же не мону лизу обсуждаем, а язык программирования. ВВ>Все равно имитация. В этом смысле аналогичная имитация на Си будет ну просто несколько более уродлива, чем на ДжаваСкрипт и все. Но при этом будет такой же имитацией.
Ну, если разницы между С и JavaScript в плане ФП не видно, то не вижу смысла обсуждать столь тонкие материи, как сочетание ООП и ФП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Курилка, Вы писали:
К>Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
А дальше есть два пути — либо закрывать глаза на то, что изменяемое состояние существует объективно, как это делают некоторые апологеты чистого ФП, либо воспринимать его как неизбежное зло и работать в направлении по его минимизации. Например, вводя механизмы ограничений на состояния.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
К>>Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
AVK>А дальше есть два пути — либо закрывать глаза на то, что изменяемое состояние существует объективно, как это делают некоторые апологеты чистого ФП, либо воспринимать его как неизбежное зло и работать в направлении по его минимизации. Например, вводя механизмы ограничений на состояния.
Это какие-то апологеты в вакууме получаются. По-моему реально 2 других пути выходит: выносить ограничения в систему типов (монады и ун. типы) или "покласть" как в эрланге/мл/лиспах и др.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Речь была именно про изменяемое состояние. T>Изменяемое состояние допустимо в ООП, но необязательно.
Угу, риск для жизни присутствует, но это не значит, что вы обязательно сдохнете.
Это уже не важно, обязательно или необязательно. На практике — оно неизбежно. Но спорить не буду. Раз оно в принципе допустимо — то в корне меняет весь подход при разработке.
ВВ>>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие. T>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
Разве? Ну где тут необходимость в объектной декомпозиции на самом-то деле?
Попробуйте вот интереса ради реализовать эти паттерны, скажем, на F#. Без классов, разумеется.
ВВ>>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников". T>Вопросы к GoF, Фаулеру и пр.?
Фаулера не трожьте
А у ГОФа, да, не мешало бы спросить, из каких лиспов источников они свои паттерны позаимствовали.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>>>За многоточием вывод о невозможности ФП?
T>>>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>>>Можно сказать, что выполнение функции это то же состояние. S>>Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
T>И к регистру, и к кэшу и к памяти, и к винчестеру, ко всему, что может хранить состояние. T>В рамках ФП просто компьютер бы не смог работать.
Почитай для начала что-нибудь о состояниях. Ни один функциональщик не утверждал что ФП программа может работать без изменения памяти, регистров и т.п.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>>Вот и славно.
T>>>В ООП такой утопии нет. S>>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
T>Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>У кого выяснил-то? Проблемы возникают и часто. Возьмем хотя бы параллельное программирование. Или сложность отладки. Вернее, скажем так — жестую в ней необходимость.
Не знаю как в параллельном, но в мультипоточном, если проблемы, то это проблемы
архитектуры. Отладкой они не устранятся и могут не возникать долгое время, но при
определенном стечении обстоятельств могут возникнуть.
Здравствуйте, Фукерман, Вы писали:
Ф>http://citforum.ru/gazeta/165/
Это надо занести в список капецов:
1. Венде-капец.
2. C-капец.
3. C++-капец.
4. Вот теперь ООП-капец.
ЗЫ: А мужики то не знали!
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Брр, сейчас ты уже начинаешь спорить, т.к. тебе термин действие не понравился?
Дело не в термине, дело в сути.
ВВ>Рассуждения об активности/пассивности функций я, извини, не понял. Это о чем вообще?
Функция в ФП пассивна. Она не проявляет активности сама, ее можно только вызвать.
AVK>>А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?
ВВ>Про итераторы я же говорил — их в ФП нет
Ясно. Дальше, в принципе, можно уже не продолжать.
ВВ>Замыкания. А что, ты считаешь замыкания смешивают данные и функции?
Бе-з малейшего сомнения. В этом их смысл.
ВВ>Зачем нужны замыкания и на что они, собственно, замыкаются-то?
Не имеет отношения к обсуждаемому вопросу.
ВВ>>> Есть данные — отдельно. Есть операции — отдельно. AVK>>Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.
ВВ>Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом.
Не надо никакого буквализма. Сама суть процесса карринга — добавление данных к функции.
ВВ>Карринг — средство создания новой функции из имеющей.
Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции.
ВВ> Аналогичный композиции. Кстати, композиция тоже вполне "меня опровергает", чем функции не данные?
Без кавычек опровергает. Но карринг в качестве примера намного лучше — прицепиться тебе не удастся к деталям, приходится просто сползать с темы.
ВВ>А карринг, частичное применение
Карринг это и есть частичное применение.
ВВ> и прочие механизмы просто помогают тебе специфицировать обобщенные функции
Это все лирика, вода на киселе. По факту карринг как раз таки подмешивает состояние к функции и именно для этого он используется в реальных программах. Конечно, выглядит это не идентично инкапсуляции в ООП, но эффект в конечном итоге очень похож.
ВВ>, они от этого не становятся частью чьего-то поведения. Никаких "классов" у нас не появляется. И данные остаются просто данными, а не чьим-то "состоянием".
Это все пустые слова без аргументов и даже логических цепочек. Все твои тирады сводятся к простому — ФП противоречит ООП, потому что ФП противоречит ООП. Доказательная сила идентична.
AVK>>А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.
ВВ>Все правильно, только это уже не ООП.
Самому не смешно?
ВВ> Все вот эти сентенции в стиле "наследование" есть рут ов олл ивил, композиция хорошо, как раз и показывают некоторую усталость от традиционного ООП.
Это другой вопрос. Не отклоняйся от темы.
ВВ>Ты когда объекты комбинируешь, то с т.з. ООП делаешь, вообще говоря, полную хрень.
Это тебе только так кажется. Композиция применялась и применяется в ООП всегда и является неотъемлемой ее частью. И твои псевдоаксиомы не соответствуют действительности и ничего не доказывают.
ВВ> А именно нарушаешь тот самый "иерархический ОО полиморфизм", ибо объекты-то ты скомбинировал, а вот их контракты увы не скомбинируются.
А почему они должны комбинироваться? Для комбинирования контрактов существует наследование контрактов, совсем другой механизм.
ВВ>При этом ты, собственно, начинаешь писать в стиле, куда более близком к ФП, чем к ООП.
Извини, это полнейшая чушь. Никакого отношения к ФП композиция не имеет. Т.е. совсем.
ВВ> Если по каким-то идеологическим причинам, тебе больше нравится называть это по-прежнему ООП, то я-то абсолютно не против. Но сабжа это никак не отменяет.
Ты не переключай тему. Ты доказывай, почему ФП противоречит ООП и с ним не совместимо. Проблемы ООП это отдельная тема, и у ФП, кстати, проблем не меньше. Проповедники серебрянных пуль идут в лес.
AVK>>Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.
ВВ>Полиморфизм есть такая особенность, которая присуща чуть ли не всем парадигмам.
Отлично. Аргумент выкидываем.
ВВ> Речь не о полиморфизме вообще, а о том, какими именно средствами он достигается в ООП.
Тривиальными.
ВВ> И вот эти средства — а не сам абстрактный полиморфизм — не очень-то с ФП дружат.
Потому что ты так сказал? У меня, к примеру, дружат. Сколько бы ты не написал подобных утверждений, твое мнение от этого не станет обоснованнее ни на миллиметр. Нужны аргументы, а не спорные продукции твоего ИМХО в голом виде.
AVK>>Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.
ВВ>Не понял, честно говоря.
Ну так подумай.
ВВ> Функциональный тип — ну это просто функция.
Нет. Функциональный тип это не функция, а ее тип. Что интереснее, у функционального типа могут быть экземпляры, как и у объекта. Дальше догадаться, где там полиморфизм, совсем не сложно.
Есть в ФП и более интересные конструкции в эту тему. Например классы типов в хаскеле.
ВВ> О каком "динамическом полиморфизме" речь?
Полиморфизм в рантайме.
ВВ>Следствие отсюда еще проще — речь не о полиморфизме совсем.
Ты первый про полиморфизм вещать начал. Я тут не причем.
ВВ>Если ты с этим согласен, то непонятно, почему мое предыдущее утверждение показалось тебе спорным.
Потому что оно несколько отличалось от того, с чем я согласен.
ВВ>Странно. Ну начнем с того, что в ФП никаких объектов нет.
И что? Не надо доказывать, что ФП это не ООП, это и так понятно. Ты докажи, что ФП противоречит ООП.
ВВ>Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах.
Вася, не надо выделять никакие сущности, тебя об этом никто не просит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Mr.Cat, Вы писали:
FR>>>Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования" MC>>Тут вот хз, я пытаюсь сгенерировать мысль в ответ тебе и Василию, но она пока не генерируется.
FR>Все-таки Василий, как уже отметили выше любит сужать функциональщину.
Я это делаю вполне намеренно... Пытаюсь выделить некий базис. В который побочные эффекты не входят В противном случае, мы просто зайдем в тупик. И тогда действительно будет казаться, что никакого внутреннего противоречия между ООП и ФП нет, как это, собственно, и кажется некоторым.
Скажем, из того факта, что отложенное вычисление списка реализуется через некую хитрую структурку, которая скрывает в себе не менее хитрый спецэффект, никак ведь не следует того, что ФП лояльно относится к подобному программированию. Некоторые вещи сделаны так просто потому что по-другому их сделать нельзя Но это ИМХО не сближает ООП и ФП.
Более того, могу сказать, что как только люди перестают писать в модном ныне "ФП стиле", а начинает по-настоящему писать на каком-нибудь ФЯ, пусть хоть он и поддерживает ООП, то сразу понимают, что ООП-то им больше не нужен — и вопрос о сочетаемости вообще уже не стоит, т.к. потребности никакой в ней нет — и не нужен не потому, что он плохой или провальный, а потому что ФП просто совершенно другая концепция, позволяющая однако делать то же самое что и ООП.
Здравствуйте, PC_2, Вы писали:
PC_>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
На первом. И с огромным отрывом.
goto пакостит только внутри функции, а глобальные переменные по всей программе.
Что называется почувствуйте разницу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая. AVK>>И эта новая функция неразрывно связана с данными. ЧТД.
ВВ>И никакого отличия между ней и классом нет, да?
Практически нет. Функциональные объекты представляют из себя то же, что и ОО-объекты, это некие данные + обрабатывающие ф-ии. Отличие функционального объекта от ОО-объекта лишь в том, что функциональный объект имеет лишь единственную ф-ию в своём видимом АПИ.
AVK>>Статические функции в классе без статических полей — почти не привязаны. ВВ>Да, и подобные функции как раз и нарушают чистоту ООП в языках. Это чистое процедурное программирование.
Обычная инкапсуляция это.
ВВ>"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать? Люди диссертации пишут о том, что такое ФП, а ты смотришь определение в википедии?
ФП — это лишь подход к решению проблемы. И почему его нельзя использовать совместно с другими подходами?
ВВ>А если ты там где-то сбоку прикрутил Линк и вставил несколько функций высшего порядка, полагаешь у тебя от этого программа сильно функциональной становится?
Достаточно сильно.
ВВ>Хорошо, ну теперь-то мы разобрались что я имел в виду? ВВ>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
С классом нельзя. Как вообще можно сравнивать типы и экземпляры?
ВВ>Я таких заявлений не делал. Я делал простое заявление — ООП стремится к инкапсуляции побочных эффектов, ФП — к избавлению от оных.
Если учесть, что побочный эффект от непобочного отличается лишь тем, что в первом случае нам известна область памяти, которая изменяется в процессе работы программы, то по-прежнему это можно считать лишь разным взглядом на вещи.
Но отличия ООП от ФП, разумеется, не в этом. Отличие заключается в способе декомпозиции логики. А что касается "Чистого ФП", который без побочных эффектов — то это лишь некая практика, навроде паттерна в этой системе, с вполне разжеванными бенефитами. Само по себе ФП к избавлению от побочных эффектов не стремится, так же как не стремится программа на ООП к исопльзованию своих ООПэшных паттернов. Человек может стремится юзать паттерны.
Опять же, а как же монады в Хаскеле? Разве не являются монады способом "протащить" некое состояние в процессе вычислений? Просто рекурсии — они ведь глубиной стека ограничены, и нужен был механизм размещения состояний, не требующий все новых ячеек стека. Вот тебе монады. "Костыль"/инфраструктура для того, чтобы имеющиеся "чистые" ф-ии использовать для модификации заведомо известного набора данных.
ВВ>О каких фактах речь? Ты считаешь генераторы основополагающей концепцией ФП? От того, что ты ответишь "да", они таковыми не станут.
Я думаю, что собеседник считает основополагающим в ФП ф-ии высших порядков. Остальное — подробности ограничений различных реализаций и подходов, причем не всегда обязательные.
ВВ>Но последовательный дизайн программы в ООП стиле противоречит ФП стилю — они идут в разные стороны.
До чего же скучно читать подобные высказывания... Нуднее зубной боли...
Ты же изучал, например, схемотехнику в институте. И видел, что прекрасно в одной сложной схеме используются как "чистые ФП" — компоненты, то бишь логические схемы без памяти, так же как схемы с триггерами и прочими ячейками памяти. Почему в схемотехнике оба подхода уживаются, у тебя нет? Более того, преобразователи с памятью строятся как преобразователи без памяти + память. Считай, что императивный подход получается таким же образом из ф-ного.
Выдели отдельно состояние и модифицируй его путем путем присвоения результата работы "чистых" ф-ий. Хочу заметить, что это весьма удобный способ декомпозиции на низком уровне сам по себе, т.к. понижает общую связанность системы, и эти "чистые" ф-ии становятся легко повторно применимы, как кирпичи при реализации методов классов. Ну вот типа как библиотеки работы с коллекциями из LINQ, даже если юзать их без LINQ-синтаксиса.
ВВ>Программа не может быть одновременно ООП и ФП. А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
Может. Даже если прикрутить гораздо больше фишек, чем в C#. ФП-компоненты могут быть удобными кирпичиками для реализации кода методов ОО-иерархий.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В идеале функция в ФП не имеет внутреннего изменяемого состояния, не влияет на состояние других функций и пр. А это опять же означает, что все результаты ее жизнедеятельности мы получим сразу после вызова. В итоге функция возвращает и принимает некое состояние, не хранит его.
Угу. ВВ>Что в ООП? Да, действительно у нас нет такого требования, чтобы класс, извините, объект "инкапсулировал побочные эффекты". Требования — нету. Возможность - есть. ВВ>Но давай посмотрим в глаза реальности — как в действительности будет выглядеть ОО-приложение. В действительности во всех ОО программах, которые я видел, писал, переписывал и пр. у объектов есть внутренее *изменяемое* состояние. Причем поведение методов объекта будет зависеть от этого состояния. Все, бац, — у нас больше нет детерминированных функций.
А разве у нас не может быть объектов с состоянием, которые пользуются детерминированными функциями?
ВВ>По поводу б) все очень просто — да, допустимо в качестве этакого исключения из правил. Извините, статические методы в Шарпе тоже как-то слабо с ООП соотносятся. Но использование изменяемого внутреннего состояния не есть нормальный стиль программирования в ФП.
ВВ>С пунктом а) все интереснее. Интерес как раз в том, что если бы можно было привести строгие формальные причины, по которым изменяемое внутреннее состояния в ООП необходимо и неизбежно, то и спора, собственно, не было бы.
ВВ>Но если попробовать покопать. Класс в ООП — это изначально некая комплексная сущность, выделенная в процессе моделирования. Фактически мы берем некий набор действий и характеристик и объединяем их воедино. Вместо отдельного набора функций вроде "набирать скорость", "тормозить" и проч. у нас будет класс "Машина". ВВ>Ну хорошо — объединили мы несколько функций в один как бы "контейнер". Что нам это дало? Представим, что эти ф-ции ведут себя как 100% ФП функции, т.е. являются строго детерминированными. Возникает естественный вопрос — а на фига мы их в единую кучу слепили-то? Чтобы удобнее было в качестве единого параметра передавать? Ну ОК. А это точно ООП?
Нет, это точно не ООП. По очевидным причинам: не удовлетворяет критериям.
ВВ>Вот возникает такое серьезное подозрение — чего-то во всем этом не хватает. Мы же не просто контейнер для функций создали, у нас как бы класс, некоторая сущность, являющаяся проекцией объекта реального мира и т.д. и т.п. А помимо собственно действий, есть еще и такие штуки как характеристики. Ну вот например — у машины может быть такая отличная характеристика как количество бензина.
Нет, никаких проекций объекта реального мира у нас нету. Открой рефлектором любую из сборок FCL и попробуй подсчитать проекции объектов реального мира.
ВВ>Приведенная лишь в силу того, что я лично, со всеми подобающими ИМХО, не считаю опыт функционального программирования в Шарпе полноценным опытом, по которому можно судить о функциональном программировании.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
AVK>
Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, IB, Вы писали:
VD>> Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой. IB>Я бы не идеализировал этот факт. По крайней мере, что такое ООП он точно не очень уверенно понимает. =)
Думаю, что с ООП у него тоже все довольно не плохо.
Здесь другая причина. Он типичный представитель людей освоивших и оценивших ФП которые после этого начали сомневаться в том, что ООП — это такая уж классная вещь.
Во-первых, это обычно со временем проходит.
Во-вторых, в этом есть разумное зерно. Идеологи ООП действительно перегнули палку. В конце прошлого века ООП практически стал иконой. Его пихают везде и всегда. Меж тем — это способ решать проблемы со своими достоинствами и недостатками. И недостатков не мало. Плюс ООП — это набор концепций достижимых и без догм ООП. Инкапсуляция и полиморфизм не есть изобретения или достоинства только лишь ООП. Они достижимы где угодно. Наследование вообще спорная вещь. Тот же АВК не раз говорил о его вреде в ряде случаев. Вот и рождаются сомнения в умах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали: FR>Все-таки классическое процедурное на порядок "беднее". FR>Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн.
А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?
Здравствуйте, PC_2, Вы писали:
PC_>Глобальные переменные подгребли,
К ООП не имеет отношения.
PC_>лямды и прочье — тоже потихоньку подмешивают с синтаксическим сахарком
Лямбды это точно не ООП, а та самая функциональщина.
PC_>Скоро будет мемоизация ( я вот в своем проекте хочу покрутить ).
Мемоизация в ООП не нужна, там изменяемое состояние свободно доступно и прошивать в компилятор поддержку кеширования не нужно, библиотек вполне достаточно.
PC_>Так что ООП жив и будет жить. То что многое из этого было еще 50 лет в ФП уже мало кого интересуют.
Ты, судя по всему, путаешь ООП как концепцию и мейнстрим ЯВУ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Брр, сейчас ты уже начинаешь спорить, т.к. тебе термин действие не понравился? AVK>Дело не в термине, дело в сути.
И о какой же сути речь? Пока я лишь вижу, что ты выдумываешь какие-то понятия, которые видимо одному тебе и понятны.
Сначала функция не действия, теперь она "пассивна". Откуда ты набрался этого? Чистая функция в ФП не менее "активна", чем любая грязная функция. Ее можно вызвать, она может вызвать сама, ее можно передавать в качестве параметра, комбинировать с другими ф-циями и пр.
ВВ>>Замыкания. А что, ты считаешь замыкания смешивают данные и функции? AVK>Бе-з малейшего сомнения. В этом их смысл. ВВ>>Зачем нужны замыкания и на что они, собственно, замыкаются-то? AVK>Не имеет отношения к обсуждаемому вопросу.
Эээ, вот честно пытаюсь понять твою логику. Замыкания ты вспомнил сам, утверждая, с целью опровергнуть мою точку зрения, что они "смешивают данные и функции". Однако на что происходит замыкания ты считаешь не имеющим отношения к обсуждаемому вопросу. Я правильно понял?
ВВ>>Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом. AVK>Не надо никакого буквализма. Сама суть процесса карринга — добавление данных к функции.
ОК, я попробую еще раз объяснить. В ООП данные, структуры данных, существуют неразрывно с функциями. При каррировании же ты создаешь новую функцию для частного случая. В этом плане каррирование не сильно отличается от дефолт параметров. В ООП у тебя функции привязаны к структурам данных всегда.
ВВ>>Карринг — средство создания новой функции из имеющей. AVK>Верно. Но это не все. Новая функция создается путем добавления состояния к старой. И никакого способа увидеть это состояние снаружи нет — полная аналогия ООПной инкапсуляции.
Слушай, давай ты не будешь уходить в ту же степь, что и товарищ tripol в этой теме, который уже практически доказал, что функциональное программирование невозможно, т.к. состояние на стеке — это тоже "скрытое" состояние, которое при этом совершенно не видно снаружи. И в отличие от каррирования, для которого существует обратная процедура под названием декаррирование, ты уж тут точно снаружи ничего не увидишь.
Тебе вот реально до подобной демагогии остался один шаг.
У всего есть какие-то границы на самом деле. Да на самом деле любая функция инкапсулирует свое состояния, и это состояние увидеть снаружи нельзя. Тут карринг вообще не причем. Как и ФП прочем. По этой причине в свое время процедурное программирование изобрели. Как раз для того, чтобы функции/подпрограммы и проч. *инкапсулировали* свое состояние. Ясен перец, что инкапсуляции в ООП не на пустом месте выросла — а из того самого, старого доброго процедурного программирования. И, естественно, тут можно провести параллели. Возникает только вопрос — на фига?
В реальности же, в реальных ООП приложениях, это самое ООП начинает инкапсулировать самые настоящие побочные эффекты, чего ФП как раз не делает. А приводить примеры всякой хрени, вроде генераторов, мне нужно. Потому что, во-первых, чистых ФЯ не существует, кроме совсем уж эзотерических. А во-вторых — ФЯ все же довольно старые языки, и в них дебютировали многие концепции, которые, собственно, развитием идей ФП ни в каком смысле не являются, а являются скорее попыткой примирить ФЯ с реальными практическими задачами.
ВВ>> Аналогичный композиции. Кстати, композиция тоже вполне "меня опровергает", чем функции не данные? AVK>Без кавычек опровергает. Но карринг в качестве примера намного лучше — прицепиться тебе не удастся к деталям, приходится просто сползать с темы.
Где я сползаю с темы?
Ты меня просто не понял и начал заниматься софистикой. И ООП, и ФП строятся на процедурном программировании. Понятно, что между ними можно найти немало общего. Только вот это совершенно не говорит о том, что их общие подходы должны быть совместимы.
ВВ>>А карринг, частичное применение AVK>Карринг это и есть частичное применение.
Нет
ВВ>> и прочие механизмы просто помогают тебе специфицировать обобщенные функции AVK>Это все лирика, вода на киселе. По факту карринг как раз таки подмешивает состояние к функции и именно для этого он используется в реальных программах. Конечно, выглядит это не идентично инкапсуляции в ООП, но эффект в конечном итоге очень похож.
Опять масло масляное. У ф-ции и так есть состояние. Карринг — это именно специализация. Очень простая мысль, но ты ее понять не хочешь. Из-за того, что функция каррируется ничего катастрофического не происходит. Она не начинает ни с того ни с сего плодить побочные эффекты.
AVK>>>А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня. ВВ>>Все правильно, только это уже не ООП. AVK>Самому не смешно?
Нет, мне грустно. ООП предоставляет механизм полиморфизма классов, который ты нарушаешь с помощью композиции. Продолжая при этом утверждать, что сие есть традиционный прием ООП. Смеяться тут совершенно не над чем.
ВВ>> Все вот эти сентенции в стиле "наследование" есть рут ов олл ивил, композиция хорошо, как раз и показывают некоторую усталость от традиционного ООП. AVK>Это другой вопрос. Не отклоняйся от темы.
Это как раз тот же самый вопрос.
ВВ>>Ты когда объекты комбинируешь, то с т.з. ООП делаешь, вообще говоря, полную хрень. AVK>Это тебе только так кажется. Композиция применялась и применяется в ООП всегда и является неотъемлемой ее частью. И твои псевдоаксиомы не соответствуют действительности и ничего не доказывают.
Применялась всегда... и что? В ФП есть много вещей, которые "применялись всегда", но при этом к самой концепции ФП никакого отношения не имеют. А во многих ОО-языках "применяются всегда" и традиционные приемы процедурного программирования. Применяются, ага. Но частью ООП они от этого не становятся.
Ты тут мои "пседоаксиомы" критикуешь, а сам же ты вообще ничего пытаешься обосновать. И аксиомы я как раз вижу у тебя. Композиция. Всегда применялись. Неотъемлемая часть ООП. А если все же подумать немного? Почему это она часть ООП, каким местом она к нему относится? И второй, кстати, не менее интересный вопрос — а почему она всегда применялась-то?
ВВ>> А именно нарушаешь тот самый "иерархический ОО полиморфизм", ибо объекты-то ты скомбинировал, а вот их контракты увы не скомбинируются. AVK>А почему они должны комбинироваться? Для комбинирования контрактов существует наследование контрактов, совсем другой механизм.
Ну да, правильно. Существует другой механизм. ООП называется.
ВВ>>При этом ты, собственно, начинаешь писать в стиле, куда более близком к ФП, чем к ООП. AVK>Извини, это полнейшая чушь. Никакого отношения к ФП композиция не имеет. Т.е. совсем.
О, как. Т.е. композиция — один из столпов ООП, а к ФП уже ни сном ни духом. ООП на нее авторские права что ли зарегистрировал? Вот это уже правда смешно.
ВВ>> Если по каким-то идеологическим причинам, тебе больше нравится называть это по-прежнему ООП, то я-то абсолютно не против. Но сабжа это никак не отменяет. AVK>Ты не переключай тему. Ты доказывай, почему ФП противоречит ООП и с ним не совместимо.
Я уже говорил. Очень простые мысли. Практика ООП приводит к тому, что:
— Структуры данных и функции слепливаются воедино и именуются "классами".
— В качестве одного из следствий этого мы получаем не просто инкапсуляцию состояния, а инкапсуляцию побочных эффектов.
И первое, и второе весьма затрудняют программирование в ФП-стиле.
AVK>Проблемы ООП это отдельная тема, и у ФП, кстати, проблем не меньше. Проповедники серебрянных пуль идут в лес.
О проблемах тут речи вообще не было. Так что тему лучше действительно не переключать.
ВВ>> И вот эти средства — а не сам абстрактный полиморфизм — не очень-то с ФП дружат. AVK>Потому что ты так сказал? У меня, к примеру, дружат. Сколько бы ты не написал подобных утверждений, твое мнение от этого не станет обоснованнее ни на миллиметр. Нужны аргументы, а не спорные продукции твоего ИМХО в голом виде.
Они не дружат, потому что они не дружат. В ООП удобнее скрыть изменение состояния, в ФП — удобнее не скрывать. Если попытаться их скомбинировать, то получится или очень хреновое ООП, или очень хреновое ФП.
Если у тебя есть пример приложения, где они удачно сочетаются — опиши архитектуру, обсудим.
AVK>>>Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме. ВВ>>Не понял, честно говоря. AVK>Ну так подумай. ВВ>> Функциональный тип — ну это просто функция. AVK>Нет. Функциональный тип это не функция, а ее тип. Что интереснее, у функционального типа могут быть экземпляры, как и у объекта. Дальше догадаться, где там полиморфизм, совсем не сложно. AVK>Есть в ФП и более интересные конструкции в эту тему. Например классы типов в хаскеле.
О, боже, ну причем тут классы типов? Кто тут из нас с темы соскальзывает? Классы типов в том же хаскеле были придуманы, чтобы обойти ограничения, придуманные в хаскеле. Как тут это может помочь — я не понимаю.
ВВ>>Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах. AVK>Вася, не надо выделять никакие сущности, тебя об этом никто не просит.
Т.е. ты просишь меня объяснить, почему ФП на мой взгляд не сочетается с ООП, но при этом слушать о том, что я понимаю под ФП ты не хочешь?
Мы вроде не в "Священных войнах" пока
Здравствуйте, FR, Вы писали:
FR>Неоднократно писал и на C/C++ и недавно на OCaml. FR>Писать такое:
На С++ то зачем такое писать?
FR>
FR>module Dir : sig
FR> type handle
FR> val _open: utf8 -> handle
FR> val _close: handle -> unit
FR> val _read: handle -> DirData.t
FR>end
FR>
FR>Не сложнее чем класс.
Все же посложнее. Особенно если сравнивать с организацией классов с ява-подобных языках, где не надо отделять описание интерфейса от реализации.
Плюс проистекающие отсюда неудобства.
Так как сам модель объект не описывает, то мы вынуждены писать что-то вроде:
let h1 = Dir._open "путь"
...
Dir._read h1
"Dir." здесь совершенно лишний. Можно конечно "открыть тип", если язык это позволяет, но там уже не факт что не пойдут конфликты имен и т.п.
В ООЯ же все красиво и просто. Причем без дополнительных приседаний.
def dir = Dir("путь");
dir.Read().X().F
Конечно, можно и тут по приседать, но это паттерны которые нужно соблюдать. А ООЯ — это язык в которые эти паттерны уже зашиты.
В общем, я не утверждаю, что в не-ООЯ нельзя достичь того же, но все же придется делать много лишних приседаний. А зачем? Только от нелюбви к ООП?
FR>Паттерн, да, но в языках с нормальной модульностью элементарный.
Дык проблемы они имеют свойство накапливаться. Например, автокомплит в точечной нотации удобнее получается, связанное использование (x.y.z). По мелочи... там неудобно... тут надо последовательность действий соблюдать... в итоге получается довольно неудобно и это только от того, что мы просто из необъяснимых соображений неприемлем ООП.
VD>>Я не говорил "только". Я говорил, что объекты (точнее классы) хороши. Просто модули, даже очень хорошие все равно вынуждают применять паттерн так хорошо известный по С. А паттерн — это набор действий который нужно постоянно повторять, плюс возможность допустить ошибку. Класс же описывает АТД за один прием и без приседаний.
FR>Хорошие модули также за один прием.
Нет. Тебе нужно знать о наличии той самой концепции АТД и выдерживать ее каноны. В общем, я повторяюсь в сотый раз.
FR>Плюс в тех же модулях OCaml есть приватные и фантомные типы, плюс возможность параметризации, это с избытком покрывает АТД.
Это все кирпичи для их создания. Но не они сами.
Но в OCaml то как раз есть и классы, которые делаю там АТД, а за одно обеспечивают и другие прелести, в один присест.
FR>В ML семействе обеспечивают. Трудности появляются только когда нужен полиморфизм в рантайме.
Здравствуйте, Воронков Василий, Вы писали: ВВ>ООП все-таки предполагает инкапсуляцию состояния.
А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
Здравствуйте, tripol, Вы писали:
T>Можно, поинтересоваться, реально ли у Вас практически встречаются побочные эффекты из-за состояний ? T>Сколько программирую, внутренние состояния приносят только пользу .
Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
T>Я вообще не понимаю, саму суть такой идеологии. Возьмем объекты окружающего мира: человек, компьютер, машина, животное. T>Все они имеют внутренние состояния и память и в этом их преимущество. "выворачивать наизнанку" что бы видеть внутреннее T>состояние объекта это нормально? да и зачем?
Смотря что проектировать.
ООП по сути является средствами проектирования некоторого неживого автомата с фиксированой структурой. Чтобы хоть както сделать его полезным и модифицируемым для окружающих, придумали модное слово полиморфизм. Если не вдаваться в детали, если вы вытяните из своих старых жигулей карбюратор и вставите точно такой же но сделаный в китае и улучшеной конструкции, это и есть полиморфизм. Если выймите в салоне магнитолу и вставите точно такую же но с двд проигрывателем, то это тоже будет полиморфизм. Разработчик оставил вам "заглушки" для быстрой подмены модулей, но только тех которые он предусмотрел
С одной стороны это гибкость, но с другой где гарантия что вам не понадобится модифицировать в автомате то, что не предусмотрел разработчик ? Прийдется брать напильничек и выпиливать новый цилиндр в моторе жигулей старой модификации
Но в большинстве случаев ООП диагнозы неутешительны. Новый цилиндр нельзя поставить вместо старого, архитектор жигулей не предусмотрел. Проще собрать новое, свое жигули
Вообщем-то "живые" организмы работают несколько по другому и отличаются тем, что для их допила нужно гораздо меньше.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
T>>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции. S>Естетсвенно что в ФП аналогичные вещи основаны на функциональной декомпозиции.
Ну да.
S>Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется.
И опять да. Я, таким образом, лишь обратил внимание, что подавляющее большинство приемов объектно-ориентированной декомпозиции не предусматривают изменяемое состояние. Соответственно, утверждение, что ООП — это "один большой побочный эффект" является ложным.
Здравствуйте, Воронков Василий, Вы писали: ВВ>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
S>Почитай для начала что-нибудь о состояниях. Ни один функциональщик не утверждал что ФП программа может работать без изменения памяти, регистров и т.п.
S>Споришь со своими догадками.
Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило.
В ООП такой утопии нет.
Здравствуйте, Mr.Cat, Вы писали:
FR>>Все-таки классическое процедурное на порядок "беднее". FR>>Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн. MC>А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли?
Не напомнишь?
Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования"
Здравствуйте, tripol, Вы писали:
FR>>Вот тут http://www.digitalmars.com/d/2.0/accu-functional.pdf есть неплохое объяснение функциональной чистоты для императивщиков.
T>Я не решаю проблем, которых у меня нет. Никогда не страдал от побочных эффектов в ООП. Для того, что бы T>решать не существующие проблемы, мне не зачем изучать новую парадигму, которая, якобы, исправляет T>несуществующие проблемы.
Хуже чем фанат только догматик.
Давай лучше поговорим про улиток. Я вот никогда ни ел эту отвратительную гадость, и считаю их очень невкусными и несъедобными.
Здравствуйте, PC_2, Вы писали:
PC_>Программа достигает своего идеала в момент краха (с)
Это распространенное заблуждение.
PC_>Разведите рассадник глобальных переменных, ООП это позволяет, в своей программе и окунитесь в дебаг с особыми извращениями. Конечно на ООП можно писать и по другому, о многом пишут в книжках по рефакторингу, по патернам и прочье. Но одни подходы дисциплинирует и как говорил ВВП "душат гадину на корню"(с), а другие только "рекомендуют" разными книжками по рефакторингу и патернам проектирования.
Как говорил не помню кто, что C или C++ это веревка достаточной длины, что бы выстрелить себе в голову...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Воронков Василий, Вы писали:
IT>>>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
ВВ>>Честно говоря, непротиворечивость ООП и ФП мне кажется несколько сомнительной. ООП все-таки предполагает инкапсуляцию состояния.
IT>И?
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП. T>Я не решаю проблем, которых у меня нет. Никогда не страдал от побочных эффектов в ООП. Для того, что бы T>решать не существующие проблемы, мне не зачем изучать новую парадигму, которая, исправляет T>несуществующие проблемы.
Здравствуйте, PC_2, Вы писали:
PC_>Разведите рассадник глобальных переменных, ООП это позволяет
Не понял, какое отношение ООП имеет к глобальным переменным?
Здравствуйте, PC_2, Вы писали:
PC_>Знаешь что будет если в Жигулях попробовать поставить пятое колесо ? PC_>Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...
Я то примерно предстовляю, но только вот скажи, зачем и как это позволяет сделать ФП?
Вообще пятое колесо это серьезное изменение и требует перепроектирования.
Здравствуйте, Mr.Cat, Вы писали:
MC>Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
А что такое настоящая парадигма? ООП — это тоже несколько паттернов: инкапсуляция, наследование, полиморфизм.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Mr.Cat, Вы писали:
MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Существует. Просто ФП, конечно же, намного богаче, чем Василий тут пытается рассказать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>У кого выяснил-то? Проблемы возникают и часто. Возьмем хотя бы параллельное программирование. Или сложность отладки. Вернее, скажем так — жестую в ней необходимость.
T>Не знаю как в параллельном, но в мультипоточном, если проблемы, то это проблемы T>архитектуры.
Естественно это проблемы архитектуры и вызваны они именно изменяемым состоянием.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, minorlogic, Вы писали:
M>>Докажите что стоит , иначе предложение выше можно считать бредом. G>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.
Докажете ваше утверждение выше, иначе это бред по умолчанию.
P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, minorlogic, Вы писали:
M>>>>>Докажите что стоит , иначе предложение выше можно считать бредом. G>>>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.
M>>>Докажете ваше утверждение выше, иначе это бред по умолчанию. G>> Заклинило?
M>Нет , демонстрирую абсурдность твоих утверждений на примере. Думал что ты догадаешься.
Я говорил про аналогии, а ты фигню несешь.
M>>>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли. G>>Угадай что надо сделать для выделенного? M>Много чего можно сделать , а угадывать что ты тут себе напридумывал мне нет мотивации.
Ясно, слился.
Здравствуйте, 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>>
Здравствуйте, Mr.Cat, Вы писали:
MC>Идеи ООП вытекают из наблюдения за объектами реального мира, которые существуют, могут изменяться и воздействовать на другие объекты независимо от сознания наблюдателя.
Идеи могут вытекать откуда угодно, но современный ОО-дизайн не является зеркалом реального мира.
ООП удобен не тем, что моделирует реальный мир, а тем что мозг человека природой приспособлен мыслить сущностями, в том числе и абсолютно абстрактными. Объекты как раз и есть отражение абстрактных сущностей в мозгу человека.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава. S>У меня deja vu. Не напомнишь, как имитировать ФВП в чистом С? S>Там же нет функторов, так что скрытым параметром замкнутые данные не передашь.
А зачем именно скрытым?
Я не знаток "C", но думаю что можно вместо функтора передавать адрес стурктуры, где первым полем идет указатель на функцию, далее замыкаемые данные. Вызывающий должен первым параметром в метод подавать адрес структуры. Как-то так:
struct IntFunctor;
typedef IntFunctor* fptr;
struct IntFunctor
{
int (*f)(fptr, int);
};
struct ConcreteFunctor
{
IntFunctor functor;
int x;
};
ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
Здравствуйте, Cadet, Вы писали:
C>Да чтоб я так же провалился, как ООП.
А ты уверен, что хочешь провалиться так же? По-моему, "провалиться как ООП" означает примерно следующее:
Ты приходишь на работу и объявляешь, насколько ты крут.
Тебе верят, дают умопомрачительную зарплату и ожидают решения всех проблем.
Некоторое время все от тебя в восхищении.
Затем наступает некоторое разочарование и устанавливается мнение, что ты просто хороший программист, не хуже, но и не лучше других, и что особых чудес ждать от тебя не приходиться.
Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
Здравствуйте, Курилка, Вы писали:
К>Тебе говорят про "first class citizen в компиляторе", а ты показываешь некий недо-citizen
Речь была о возможности имитации вообще-то. Вообще говоря этот самый Combine — костыли еще те, а не "first class citizen в компиляторе". Композиция в нормальном ФЯ делается в поинт-фри стиле с помощью трех букв и двух знаков препинания
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>В идеале функция в ФП не имеет внутреннего изменяемого состояния, не влияет на состояние других функций и пр. А это опять же означает, что все результаты ее жизнедеятельности мы получим сразу после вызова. В итоге функция возвращает и принимает некое состояние, не хранит его. S>Угу. ВВ>>Что в ООП? Да, действительно у нас нет такого требования, чтобы класс, извините, объект "инкапсулировал побочные эффекты". S>Требования — нету. Возможность - есть. ВВ>>Но давай посмотрим в глаза реальности — как в действительности будет выглядеть ОО-приложение. В действительности во всех ОО программах, которые я видел, писал, переписывал и пр. у объектов есть внутренее *изменяемое* состояние. Причем поведение методов объекта будет зависеть от этого состояния. Все, бац, — у нас больше нет детерминированных функций. S>А разве у нас не может быть объектов с состоянием, которые пользуются детерминированными функциями?
Может быть, конечно. Тут вопрос немножко по-другому стоит. Как только у нас появляется это самое изменяемое состояние у объектов ведь кто-то же начинает им пользоваться, правильно? Например, функция Drive начинает "пользоваться" состоянием, выраженным через Gas.
ВВ>>Вот возникает такое серьезное подозрение — чего-то во всем этом не хватает. Мы же не просто контейнер для функций создали, у нас как бы класс, некоторая сущность, являющаяся проекцией объекта реального мира и т.д. и т.п. А помимо собственно действий, есть еще и такие штуки как характеристики. Ну вот например — у машины может быть такая отличная характеристика как количество бензина. S>Нет, никаких проекций объекта реального мира у нас нету. Открой рефлектором любую из сборок FCL и попробуй подсчитать проекции объектов реального мира.
"Объект реального мира" — это то, что рождается в воспаленном мозгу программиста. Сокеты, файлы, паки, сервисы. А ты думал, это кошки с собаками?
Но кроме шуток, вернемся к нашим баранам. Добавили мы св-во Gas к классу Car. Функция Drive теперь зависит (и изменяет) от этого свойства. Но вот с т.з. ОО-дизайна мне это свойство кажется очень уместным и удобным. Я могу его использовать, когда буду строить отчеты об имеющихся у меня в гараже машинах. Я могу использовать его при выборке автомобиля по критерию "какой доедет". И таки-да — у меня есть машина, у машины же не только мотор, но и бензобак имеется. В общем мне это свойство нравится, оно уместно.
А когда я начинаю думать, почему такого свойства мне не хочется в ФП, то и прихожу как раз к выводу, который до этого неудачно описывал как "ООП соединяет данные и функции в единое целое". Не данные и функции. Не совсем так.
Когда в рамках ООП я думаю об *экземпляре* класса Car, то я думаю о нем, как о конкретной машине. Ну т.е. вот есть у меня Москвич 2140 желтого цвета с вмятиной на крыле, бензина в баке — 20 литров, резина — лысая, а радио ловит только четные станции. Для меня экземпляр Car — это такой сложный уникальный механизм, у которого есть внутренние взаимосвязи, вернее скажем — который *детерминирован* своими характеристиками. И функция Drive в этом плане не просто какая-то там функция — я именно в этот Москвич сел, завел его и поехал.
В ФП я совсем иначе смотрю на вещи. У меня есть одна обобщенная функция Drive. Я пишу ее так, чтобы результат работы функции зависел только от ее параметров. Я могу эту функцию каррировать хоть до опупения, передавая таким образом кол-во бензина и проч., но все равно она не превратится в мой старенький Москвич 2140. Не будет той взаимосвязи, взаимной детерминированности, которая "наполняла жизнью" мой Москвич в ООП. Будет просто специализация функции Drive для некоторого — всегда константного — значения бензина.
Ну вот как-то так.
По этим причинам мне кажется, что с точки зрения моделирования ООП и ФП не очень совместимы.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не делать утверждения — это какая-то неинтересная позиция я бы сказал. У тебя нет мнения по этому вопросу?
Не переводи стрелки. Речь о твоих утверждениях, а не о моих.
AVK>>А я ее и не сравниваю. На прямое опровержение твоим словам, что данные и функции в ФП связать нельзя.
ВВ>Я не говорил, что нельзя.
Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно.
ВВ> Вообще само утверждение "в ФП нельзя то-то" какое-то неправильное. Что такое "в ФП нельзя"?
Ясно, пошла голимая софистика. Адьос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, -_*, Вы писали:
КЛ>>>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
FR>>По моему скорее наоборот.
-_*>Что ты имеешь сказать, ООА и ООД круто, но классы, наследование, полиморфизм — гнусь ?
Нет, не так категорично.
ОО проектирование не доведенное до маразма вполне рулит. А вот механизмы конструирования разработанные в ОО подходе в виде
классов, объектов и соответственно использование для реализации наследования полиморфизма и т. п. сильно уступает по
выразительности средствам появившимся в функциональных языках (алгебраические типы и связанный с ними паттерн матчинг,
вывод типов, ФВП и комбинаторы, монады).
Исключение Smalltalk и ему подобные, но там выразительность достигается за счет динамики и метапрограммирования
ортогональных ООП.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах.
Это огромное заблуждение. Одним большим побочным эффектом является не ООП, а программирование в целом. А ООП, ФП и даже МП — это средства завернуть игру с состояниями в понятную для человека абстрактную форму.
Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
ООП инкапсуляция состояние в объектах, ФП в замыканиях. МП инкапсуляция все под личиной некоего языка.
В итоге мы работаем на более высоком уровне, а значит можем решать более сложные задачи.
ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Так и сочетать. Функции могут оперировать объектами, объекты есть ни что иное как набор функций соединенный с некоторыми данными.
Вот и выходит, что один стиль позволяет упростить реализацию другого.
Методы объектов отлично реализуются в функциональном стиле. А ООП — это отличный клей.
Можно рассматривать гибридный язык как ФЯ с отличной модульной системой. Или наоборот, ООЯ поддерживающий ФП можно рассматривать как ООЯ в который добавлено много приятных фишек позволяющих сократить и упростить кодирование методов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>То, что мог я сформулировал в ответах Синклеру. Если вкратце, то обсуждаемую тему можно свести к следующему: каковы отличия ООП и ФП при *моделировании* и, в частности, в чем кардинальное отличие между функцией в ФП и классом в ООП. Моя мысль, что классы в ООП by design инкапсулируют изменяемое состояние. Функции в ФП — by design стараются этого избежать.
Даже если мыслить так (хотя это не так на 100%), то чем эти идеи противоречат и почему нельзя их эффективно использовать совместно?
ВВ>Если вкратце — то на основе чего в ООП программе мы решаем, что должно быть включено в класс? Собственно, класс есть некая единая сущность, не просто же определенный набор атрибутов и функций. Очевидно, что предполагается определенная связь между членами класса. Но какая?
Общая задача. Функции работы с окнами логично поместить в класс "Окно", а функции работы с файлами в класс "Файл". Все же просто и очевидно. Это если не умничать и не идеологизировать ООП.
ВВ>Представим, что мы сотворили такое:
ВВ>
ВВ>class Math {
ВВ> int Sum();
ВВ> int FirstOperand;
ВВ> int SecondOperand;
ВВ>}
ВВ>
Даже страшно такое представлять .
Конечно и такое бывает, но это ведь не лучший образчик ОО-ситиля, правда?
ВВ>Связь вроде присутствует, т.е. очевидно, что Sum зависит от полей FirstOperand и SecondOperand — абсолютно так же, как и функция sum(x, y) зависит от своих операндов. Но на класс это не тянет, тянет на бред. ВВ>А чего не хватает?
ВВ>Ни FirstOperand, ни SecondOperand не являются тем, что мы привыкли называть "состоянием класса". Эти поля используются лишь в момент работы функции Sum — в этом плане их перенос в поля абсолютно бессмысленен. Результаты работы Sum также никак не влияет на эти поля.
ВВ>Не хватает, как мне кажется, *взаимо*связи между полями и функциями класса, их как бы взаимной детерминированности. Сравни с этим:
ВВ>
ВВ>class Car {
ВВ> int Drive();
ВВ> int Gas;
ВВ>}
ВВ>
Опять какая-то херня из бредовых учебников.
Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом.
Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
ВВ>Вот это уже больше похоже на класс. Drive зависит от поля Gas (на пустом баке далеко не уедешь), но и Gas зависит от Drive (бензин-то кончается). И вот пожалуйста — получаем изменяемое состояние, которое несет в себе класс.
ВВ>В ФП безусловно есть такие же шутки, но обычно ФП пытается такого программирования избежать. Т.е. в ФП бы я создал скорее универсальную функцию Drive принимающую кол-во бензина и возвращающую расстроение, которое мы проехали и кол-во оставшегося бензина. В ООП же у меня получается так, что каждый экземпляр класса Car есть как бы конкретный автомобиль со своими индивидуальными, так сказать, характеристиками. ВВ>Можешь почитать ответы Синклеру, я там объясняю более подробно.
Да ладно фантазировать про гипотетические кары и драйвы.
Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
Что снова изобретем хэндл? О боги! Да это же старое доброе процедурное программирование!
А где же та замечательная завеса таинства что так привлекала многих в ФП?
Вот классы надо расстраивать как средство борьбы с хэндлами. Инкапсуляция — это оно и есть.
ВВ>Ну вот и получается, что у нас просто-напросто разное моделирование в ООП и ФП.
У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково.
В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
Мы просто не приемлем хэндлы и другие виды эмуляции ООП в не объектно-ориентированных языках.
VD>>Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
ВВ>Об этом речи нет, как-то ты утрируешь. Речь о том, что последовательный дизайн приложения в ООП-стиле и дизайн в ФП-стиле идут разными путями.
Я утрирую потому что свихнутые на ФП доходят и до такого бреда, что в их программах нет состояния. Надо же уточнить позицию?
Так вот я для себя сделал открытия. Не бывает ОО-дизайн или ФП-дизайн. А бывает хороший (красивый, удобный и т.п.) дизайн, и притянутый за уши. Когда преобразование А в Б пытаются оформить классом — это кривой дизайн, но все эти хэндлы — это точно такой же кривой дизайн.
Состояние есть, его не может не быть! Это объективная реальность. Состояние опасно! Точнее опасно не оно, а то что человеческий мозг не может представить состояние во времени и то, что мы не имеем возможности взглянуть в прошлое.
ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
В чистом ФП-стиле можно писать только конвертеры. Любая интерактивная программа или даже просто большая требует ОО-подхода. И самое лучшее что можно придумать — это сочетать ФП и ООП в одной программе, делая в ФП-стиле все что можно сделать с его помощью не доводя решение до идиотизма. А ООП использовать в тех случаях когда у нас появляется состояние которое нужно абстрагировать и превратить в черный ящик.
Вот как-то так. И что характерно я уже три года пишу код только так и не понимаю как можно писать по другому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не идеологизирую. Но неужели у тебя нет никаких других критериев, по которым ты "распихиваешь" функции по классам?
Нет. Точнее, я просто думаю каждый раз головой. Взвешиваю все за и против. Так что можно сказать, что их слишком много чтобы их перечислять, а можно сказать, что их нет.
ВВ> Просто мне кажется у тебя в таком случае класс выступает в виде этакого неймспейса для функций. "Все для работы с окном". "Все что нужно для ваших файлов". ООП — это что-то еще, не?
А меня не трогает чистота идей. Мне нужно ехать, а не шашечки.
К тому же от нэйспэйса это отличается наличием того самого инкапсулированного состояния. Ведь это не только набор функций, но и структура данных описывающая файл.
ВВ>Если ты считаешь это классом, просто "в плохом стиле" — то я тебе ничего объяснить не смогу.
Ну, не можешь так не можешь.
ВВ>Я всего-лишь высказал мысль, что у нас возникает повод говорить об "ООП классе", когда в классе этим присутствует взаимная детерминированность его членов.
Давай не будем жонглировать терминами. Что за "взаимная детерминированность"?
ВВ> Именно взаимная. Ты с этим не согласен? Может привести контр-пример?
Я не могу быть согласен с тем чего не понимаю. В прочем как и не согласен.
VD>>Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом. VD>>Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
ВВ>А зачем вводить "класс"? Что это даст?
Это даст удобство использования и инкапсуляцию.
ВВ>Может просто модуль File и накидать туда функций? В чем разница?
Модуль (в обычном понимании этого термина) не может иметь экземпляров. Модули можно использовать для реализации инкапсуляции. Сам объект при этом придется прятать за тот самый хэндл.
В итоге мы получаем эмуляцию ООП. Безусловно даже на С можно сэмулирвоать ООП и добиться приемлемого результата. Но использование для этих целей средств языка намного удобнее и интуитивно понятнее.
ВВ>В функциональном языке у меня была бы структура "Файл", описывающая файл *в конкретный помент времени*. В ООП — просто структура "Файл".
Если структура с отрытыми полями, то ты получаешь все прелести отсутствия инкапсуляции. Если ты начинаешь скрывать состав структуры за псевдонимом типа реализованного приватно в модуле, то ты опять же эмулируешь ООП, но менее удобными для этого средствами.
Короче, ты опять уперся в терминологию и какое-то свое понимание. Я с тобой бодаться не намерен.
Повторю только еще раз, что если не делать из ООП догмы, то это удобная и полезная технология.
Можешь рассматривать ее как модули на стеройдах плюс ряд других вкусностей.
Причем никто не заставляет все это применят. Не надо — не применяй.
ВВ>Т.е. классы нужны для:... ВВ>Иначе говоря, это что-то вроде туалета?
Странные у тебя ассоциации.
Я, в общем-то, все уже сказал. Интерпретировать мои слова не нужно.
ВВ> Завернули, запрятали — и уже не страшно?
Это называется инкапсуляция. Сложное прячется за интерфейсом и действительно становится проще.
ВВ>Не, я как бы согласен.
Как бы или согласен?
ВВ> Но вопрос прежний — почему "классы"?
А почему нет? Почему модули и внеположной секс с хэндлами и прочей самопальщиной?
ВВ>Такой вот "туалет" и в Си есть — там тоже можно завернуть, спрятать, инкапсулировать. Зачем мужики С++ придумали?
То что ты называешь туалетом в культурных кругах принято назыать инкапсуляцией. И таки — да, инкапсуляции можно добиться и в С, и в Хаскеле. Вопрос только сколько при этом танцев с бубнами надо предпринять.
В ООЯ мне нужно просто создать класс, описать в нем понятный/логичный интерфейс и скрыть за ним все детали реализации (данные, алгоритмы и т.п.).
Да инкапсуляция придумана не в ООП. Да она не является преимуществом именно ООП. Но мне пофику, если в ООП это сделано удобнее нежели в ФП или процедурном программировании (ПП), что по сути одно и то же.
VD>>У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково. VD>>В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
ВВ>Обладает что ли состоянием "внутри" или же это состояние у тебя будет "снаружи" (в чем собственно отличие ФП и ООП, не?) — ты решаешь сам.
Я хотел сказать "изменяемым состоянием".
ВВ>Здесь не существует каких-то объективных критериев для выбора. И вот выбор первого — это ООП выбор. Выбор второго — ФП выбор.
Да нет тут никакого выбора. Погляди на любой немерловый проект. Все решения ОЧЕВИДНЫ. Тебе внутренний голос подсказывает где лучше класс создать, а где еще что-то.
Возьми к примеру простенький проект макроса поддержки XML-литералов. Тут тебе и вполне функциональная реализация AST + его преобразование, и классы, и даже методы внутри в общем-то функциональных структур (вариантов). Причем реализация методов в большинстве случаев вполне себе функциональная.
ВВ>Если два разных человека, которые а) имеют мозг и б) используют его, то у них получится разный дизайн. Есть огромное кол-во разных способов решить задачу, не только два, из них нельзя выбрать какой-то "более правильный" или "более красивый" способ.
Причем тут разные люди? Ну, да — есть. И что? Разный дизайн все равно может быть как плохим, так и хорошим. В хорошем по любому будет сочетаться лучшие подходы. А догматический ООП-дизайни, как и догматический ФП-дизайн точно будут плохим.
ВВ>Ну да, через стек, отлично. Только вот "объект", в котором ты будешь таскать это состояние, является единомоментным иммутабельным слепком этого состояния,
А вот это уже догмы. Может быть так, а может быть иначе. Как удобно, так и делай.
ВВ>т.е. это значения для конкретного момента времени. Сам по себе этот объект не будет иметь состояние, он будет лишь его описателем. В ООП же такой объект именно что несет в себе состояние.
Ты мне еще расскажи про "миры".
ФП в чистом виде способен решать исключительно те задачи которые укладываются в трансформацию данных. Скажем интерактивный ГУЙ на чистом ФП не сделать в принцие. Для этого уже нужно придумывать разные реактивные системы в которых ФП станет не более чем частью реализации. Так почему бы изначально не рассматривать ФП как средство реализации частей программы которые укладываются в парадигму трансформации, а само приложение рассматривать как нормальное ОО-приложение внутри которого реализация методов преимущественно осуществляется методами ФП? Это дает отличные результаты. И что характерно, не надо разрушать старый мир, чтобы воспользоваться преимуществами нового.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, чтобы не было недопонимания. То, что я показал, это баловство и извращение на тему. В реальном функциональном коде для этого используют монады. Выглядит это как то так:
var data =
OpenFile(...)
.Take(100)
.ToArray();
Если нужна асинхронность, то тоже берем continuation монаду (Rx), либо фьючерс (PLinq), которые с ФП вполне совместимы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Ты не забыл, что файл еще закрывать надо? А как насчет рандом доступа? Плюс у файла есть состояние. Если прочесть что-то из файла, записать что-то в него, а потом прочесть еще раз, то прочитаны будут новые (только что записанные данные). А это противоречит принципу ФП — при одних и тех же аргументах получаем всегда один и тот же результат.
Кроме того файл может быть изменен и извне.
Так что никакие приседания тут не помогут. Состояние есть и с этим надо жить.
Здравствуй процедурное императивное программирование, завернутое в монаду IO!
Монада нужна только потому, что Хаскель ленивый язык. Для остальных ФЯ мы получим банальный C API времен Кернигана и Ричи.
VD>>Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.
AVK>Если мы делаем карринг, значение аргументов хранится не в стеке.
Что? Карринг — это возможность рассматривать функцию типа (A * B) -> C как A -> (B -> C). Нужно это, в основном, для того чтобы составить из двух функций третью (частичное применение, создание комбинаторов). К стеку это вообще отношения не имеет, так как подобные операции обычно осуществятся на стадии компиляции.
AVK>Это не ко мне вопрос. Я точно так же не смог добится никакого вразумительного объяснения, чем все таки ФП с ООП не совместимо.
Тогда не ясно почему ты мне оппонируешь, а не тому же Воронкову.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaPerouse, Вы писали:
LP>>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. L>>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
LP>Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.
Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали: LP>>Ну кто бы сомневался. Как всегда, без монады — никуда. AVK>А чем тебе монады не угодили?
Попытка почти любого практического применения функциональных языков оканчивается использованием монады IO, которая сама по себе императивна до безобразия.
Дальнейший спор считаю бессмысленным. Всего доброго, желаю успехов в обсуждении одного и того же в 1001-ый раз )).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, FR, Вы писали:
FR>Как будто с использованием ООП мы в этом случае получим что-то большее. Будет ровно тоже самое. Притом используя те же модули ML например код практически будет идентичным с ООП.
Конечно получим больше. Мы получим возможность не заморачиваясь писать то что мы хотим так как мы хотим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Когда в рамках ООП я думаю об *экземпляре* класса Car, то я думаю о нем, как о конкретной машине.... И функция Drive в этом плане не просто какая-то там функция — я именно в этот Москвич сел, завел его и поехал.
ВВ>В ФП я совсем иначе смотрю на вещи. У меня есть одна обобщенная функция Drive. Я пишу ее так, чтобы результат работы функции зависел только от ее параметров. Я могу эту функцию каррировать хоть до опупения, передавая таким образом кол-во бензина и проч., но все равно она не превратится в мой старенький Москвич 2140.
ВВ>По этим причинам мне кажется, что с точки зрения моделирования ООП и ФП не очень совместимы.
Может это от задач зависит? Да и что значит несовместимы. Если в то смысле, что интеллектуальный труд функциональшика (алгоритмы которые он настрочил в функциональном стиле) невозможно соединить с трудами имеперативщика ООП-шника в единую полезную систему. То тут скорее такое соединение, если получится, может оказаться крайне выгодным. А если в плане того что они чаще как противоположности — там где рулит ФП, там плохо дело у ИП,ОПП, и наоборот. То такое наверное есть.
Лучше взять Excel, чем Москвич 2140. Точнее использование API Excel из своей программы. Без внутреннего состояния никому такой Excel не будет нужен. Ради этого состояния он вобще-то и нужен — сложным внутренним состоянием позволяет управлять через простой API (хотя могли бы сделать и постройнее). Excel это точно не одна pure function, и даже не две.
Задача очень сложная, по крайней мере сделать качественно (например чтобы оказаться в первой пятерке), алгоритмы реально сложные. А по сути то надо написать всего лишь одну функцию — на вход берет 2 массива простеньких структур с 2-5 полями, на выходе результат как один массив структур. Никаких состояний там просто нет нигде, не нужны они. Хотя каких-то игрушек с двумя игроками совсем без состояний не бывает — но в данном случае этим можно полностью пренебречь. Т.е. теоретически как бы можно сказать состояние есть — но на самом деле его нет.
И кстати, там правила игры такие, что императивщикам на С++ будет очень тяжко — все недостатики ИП проявятся во всей красе. Хотя плюсники тоже наверное будут в первой десятке, но не столько как в прошлом году было. Тода задача была потупее нужно было вернуть одно число 1..4, тупой перебор был выгоднее. А сейчас уже сложным образом прийдется молотить списки и структурки данных. Эта задача однозначно лучше для ФП.
Здравствуйте, VladD2, Вы писали:
VD>Если честно, я тоже часто не согласен с твоим мнением. Ты зачастую споришь просто ради процесса, что не может не раздражать.
Не спорю я ради процесса. Можешь считать, что если я о чем-то с тобой спорю, это значит мне интересна твоя точка зрения И как раз в споре ты выскажешь ее наиболее аргументированно и подробно. В реальности у меня может и не быть "strong opinion" по обсуждаемым вопросам. Я, честно говоря, вообще не вижу большой пользы в этих самых "strong opinion". Но это же не значит, что я троллю?
Правильнее было бы так: ВВ> Я как-то нелестно высказался об его статье, причем весьма наивно, надо сказать...
=))
И да, там ты тоже нес пургу по поводу ООП.
ВВ>с тех пор он обожает ставить мне минусики со смайликами,
Просто мне сложно пройти мимо нелепых, но весьма категоричных заявлений, так что особо я тебя не выделяю — можешь не обольщаться.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Фукерман, Вы писали:
Ф>>http://citforum.ru/gazeta/165/
PD>Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики, после чего эфир был незаслуженно “закрыт” и отправлен в отставку, и вот уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра. “Ну и где мы теперь, с этой вашей красивой теорией относительности, кто-нибудь может мне назвать хоть какие-то реально-практические результаты её применения в вашей обыденной жизни после целого века её ковыряния и массового насаждения?” – как всегда язвительно вопрошает Гэбриел.
Ну программисты всегда отличались довольно ... необычным взглядом на физику.
. При наличии языка с сильной поддержкой функциональной парадигмы места ООП почти не остается. На уровне методов его полностью заменяет ФП, а на уровне интерфейсов подсистем — SOA (которое далеко не ООП).
G>Хотя и ФП, и SOA представимы с помощью инструментария ООП, но этот факт зачастую только мешает грамотному проектированию, а не помогает ему.
Имхо, ООП должен быть так, как его описал Алан Кей описал — объекты, сообщения и т.п. Вряд ли больше.
Здравствуйте, Mamut, Вы писали:
S>>>Дайте наконец пощупать "провал ООП" S>>>Или S>>>Провалите в конце концов это чертово ООП.
G>>Кстати провал ООП вживую можно увидеть на этом форуме
. При наличии языка с сильной поддержкой функциональной парадигмы места ООП почти не остается. На уровне методов его полностью заменяет ФП, а на уровне интерфейсов подсистем — SOA (которое далеко не ООП).
G>>Хотя и ФП, и SOA представимы с помощью инструментария ООП, но этот факт зачастую только мешает грамотному проектированию, а не помогает ему.
M>Имхо, ООП должен быть так, как его описал Алан Кей описал — объекты, сообщения и т.п. Вряд ли больше.
Только понимание описания кея сильно зависит от используемого языка.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Skynin, Вы писали:
S>>Дайте наконец пощупать "провал ООП" S>>Или S>>Провалите в конце концов это чертово ООП.
G>Кстати провал ООП вживую можно увидеть на этом форуме
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Skynin, Вы писали:
S>>Дайте наконец пощупать "провал ООП" S>>Или S>>Провалите в конце концов это чертово ООП.
G>Кстати провал ООП вживую можно увидеть на этом форуме
. При наличии языка с сильной поддержкой функциональной парадигмы места ООП почти не остается. На уровне методов его полностью заменяет ФП, а на уровне интерфейсов подсистем — SOA (которое далеко не ООП).
Первая статья, которую я начал читать, — Иннокентия Анненского — называлась «О современном лиризме».
Первая фраза была такая:
«Жасминовые тирсы наших первых мэнад примахались быстро…»
Мне отчасти до боли сделалось жаль наш бестолковый русский народ, а отчасти было досадно: ничего нельзя поручить русскому человеку… Дали ему в руки жасминовый тирс, а он обрадовался, и ну — махать им, пока примахал этот инструмент окончательно.
Здравствуйте, IT, Вы писали:
IT>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
Честно говоря, непротиворечивость ООП и ФП мне кажется несколько сомнительной. ООП все-таки предполагает инкапсуляцию состояния.
Здравствуйте, k.o., Вы писали: KO>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно.
Вообще, системы с объектоподобными агентами тот же Танненбаум отделял от ООП в отдельную категорию (у него "object-based" vs. "object-oriented"). Но если уж проводить параллели эрланга с ООП — надо обязательно вспомнить о его параметризованных модулях.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали: ВВ>>ООП все-таки предполагает инкапсуляцию состояния. MC>А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах.
По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Mr.Cat, Вы писали:
MC>>Здравствуйте, Воронков Василий, Вы писали: ВВ>>>ООП все-таки предполагает инкапсуляцию состояния. MC>>А ФП? В нем тоже есть инкапсуляции состояния: "внутри" STM или кастомных монад.
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах. ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Можно, поинтересоваться, реально ли у Вас практически встречаются побочные эффекты из-за состояний ?
Сколько программирую, внутренние состояния приносят только пользу .
Здравствуйте, Воронков Василий, Вы писали: ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Ну не такое уж оно и открытое получается. Вон, в xmonad — монада X по сути определяет набор аксессоров к состоянию x-сервера: http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#t%3AX.
Или в эрланге: у каждого процесса (или актера, если хочешь) свое внутреннее состояние, от других скрытое, которое изменяется само по себе или в ответ на сообщения.
Здравствуйте, Mr.Cat, Вы писали:
MC>Или в эрланге: у каждого процесса (или актера, если хочешь) свое внутреннее состояние, от других скрытое, которое изменяется само по себе или в ответ на сообщения.
Ну, строго говоря, ввод-вывод, ffi, обмен сообщениями и переменные процесса в эрланге несколько противоречат чистому ФП
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Я вообще не понимаю, саму суть такой идеологии. Возьмем объекты окружающего мира: человек, компьютер, машина, животное.
Все они имеют внутренние состояния и память и в этом их преимущество. "выворачивать наизнанку" что бы видеть внутреннее
состояние объекта это нормально? да и зачем?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>ООП все-таки предполагает инкапсуляцию состояния.
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект.
Ловко ты перепрыгнул. И, кстати, состояние (а точнее изменяемое состояние, просто состояние даже "чистому" ФП не протворечит) далеко не всегда приводит "побочным эффектам". Типичный пример — кеши (memoize в ФП).
ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции.
Утверждение нуждается в доказательствах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ВВ>>>>ООП все-таки предполагает инкапсуляцию состояния. ВВ>>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. AVK>Ловко ты перепрыгнул. И, кстати, состояние (а точнее изменяемое состояние, просто состояние даже "чистому" ФП не протворечит) далеко не всегда приводит "побочным эффектам". Типичный пример — кеши (memoize в ФП).
ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста. А скрытое от пользователя изменение состояния — это и есть побочный эффект. Как оно может не приводить-то? То, что инкапсуляция состояния в ФП есть — факт. Другой вопрос — почему оно там есть и с какими целями появилось.
Важнее то, что ФП и ООП предполагают разный подход к дизайну. ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч.
Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты.
С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек. Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом. Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя. Детальки — это, разумеется, функции.
А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП.
Здравствуйте, mrTwister, Вы писали:
ВВ>>ООП все-таки предполагает инкапсуляцию состояния. T>Во-первых, не только инкапсуляцию состояния, но и инкапсуляцию поведения. Ни то, ни другое не противоречит ФП. Проблемы будут только с изменением состояния.
Речь была именно про изменяемое состояние.
T>При этом ООП не заставляет тебя использование изменяемого состояния. Рассмотрим, например каталог ООП паттернов ГОФ: T>Abstract Factory T>1) Builder T>2) Factory Method T>3) Prototype T>4) Singleton T>5) Adapter T>6) Bridge T>7) Composite T>8) Decorator T>9) Facade T>10) Flyweight T>11) Proxy T>12) Chain of responsibility T>13) Command T>14) Interpreter T>15) Iterator T>16) Mediator T>17) Memento T>18) Observer T>19) State T>20) Strategy T>21) Template method T>22) Visitor T>Из всех этих паттернов только Builder, Iterator и State в классической реализации предполагают изменение состояния. При этом ничто не мешает сделать immutable реализацию даже этих трех паттернов.
Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие. Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста.
А теперь возвращаемся к твоему исходному утверждению — если туда подставить изменяемое состояние, то оно уже несколько не так звучит, не находишь?
ВВ> А скрытое от пользователя изменение состояния — это и есть побочный эффект.
Не всегда
ВВ> Как оно может не приводить-то?
Пример я привел.
ВВ>Важнее то, что ФП и ООП предполагают разный подход к дизайну.
Разный. Но ортогональный, а не противоположный. Это важно.
ВВ> ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч.
Ничего не понял. Какие, нафик, кирпичи?
ВВ>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт.
Это называется полиморфизм. В ФП языках тоже бывает. Функциональный тип, собственно, это оно и есть. ООП в этом плане отличается тем, что позволяет создавать полиморфную иерархию. Но ФП это никак не противоречит.
ВВ> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты.
Крайне спорный вывод, требующий доказательств.
ВВ>С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек.
Опять ничего не понял. Прежде чем приводить аналогии, попробуй пояснить свою мысль на предмете обсуждения.
ВВ> Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом.
Кирпичи тоже
ВВ> Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя.
В ООП тоже так можно. Это зависит от дизайна конкретной программы, а не от способа декомпозиции.
ВВ>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП.
Опять же крайне спорно и бездоказательно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Речь была именно про изменяемое состояние.
Изменяемое состояние допустимо в ООП, но необязательно.
ВВ>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие.
Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
ВВ>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников".
Вопросы к GoF, Фаулеру и пр.?
Здравствуйте, PC_2, Вы писали:
PC_>Смотря что проектировать. PC_>ООП по сути является средствами проектирования некоторого неживого автомата с фиксированой структурой. Чтобы хоть както сделать его полезным и модифицируемым для окружающих, придумали модное слово полиморфизм. Если не вдаваться в детали, если вы вытяните из своих старых жигулей карбюратор и вставите точно такой же но сделаный в китае и улучшеной конструкции, это и есть полиморфизм. Если выймите в салоне магнитолу и вставите точно такую же но с двд проигрывателем, то это тоже будет полиморфизм. Разработчик оставил вам "заглушки" для быстрой подмены модулей, но только тех которые он предусмотрел
PC_>С одной стороны это гибкость, но с другой где гарантия что вам не понадобится модифицировать в автомате то, что не предусмотрел разработчик ? Прийдется брать напильничек и выпиливать новый цилиндр в моторе жигулей старой модификации PC_>Но в большинстве случаев ООП диагнозы неутешительны. Новый цилиндр нельзя поставить вместо старого, архитектор жигулей не предусмотрел. Проще собрать новое, свое жигули
PC_>Вообщем-то "живые" организмы работают несколько по другому и отличаются тем, что для их допила нужно гораздо меньше.
ООП не требует фиксированности структуры. Где такие ограничения?
Объект вполне может быть динамическим.
А полиморфизм не модное слово, а удобное средство.
А что, часто приходится ставить неподходящий двигатель в машину? Такого не встречал.
Вряд ли пользователь класса окажется более продвинутым в его работе чем сам создатель
этого класса (тут нужны и чертежи и идея, лежащая за ним, которые не прописаны в конструкции).
Да и вообще, если разобраться, то есть время жизни в том числе жигулей. После его завершения
жигули действительно можно отправлять тем, кто будет что то выпиливать, а зачастую на свалку.
Собственно с машиной Вы ничего другого и не придумаете, кроме как предусмотренные и стандартизированные
комплектующие.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AndrewVK, Вы писали:
ВВ>С ФП все с точностью до наоборот. Это не кирпичи и не пирамида, это конструктор лего из маленьких таких деталек. Предназначение каждой детальки атомарно, при этом они прекрасно комбинируются друг с другом. Требуется более сложный функционал? Собираем из готовых деталек детальку покрупнее и посложнее, причем в данном случае все это происходит совершенно прозрачно для пользователя. Детальки — это, разумеется, функции.
Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой
информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то
"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну где-то так и есть. Перечисленные вами паттерны — это ООП паттерны. Остальные — просто паттерны, к ООП никакого отношения не имеющие.
T>Это все именно ООП паттерны, так как они основаны на объектной декомпозиции.
Естетсвенно что в ФП аналогичные вещи основаны на функциональной декомпозиции.
ВВ>>Вообще. В "учебниках" — да, сочетание "ООП" рядом с названиями этих паттернов иногда употребляется. Ну так это вопрос к авторам этих "учебников". T>Вопросы к GoF, Фаулеру и пр.?
Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>ОК, имелось в виду изменяемое состояние, если это не было понятно из контекста. AVK>А теперь возвращаемся к твоему исходному утверждению — если туда подставить изменяемое состояние, то оно уже несколько не так звучит, не находишь?
Ничего не понял. Что не так звучит?
ВВ>>Важнее то, что ФП и ООП предполагают разный подход к дизайну. AVK>Разный. Но ортогональный, а не противоположный. Это важно.
Может, и не противоположный, но взаимоисключающий.
ВВ>> ООП — это такая пирамида из кирпичей, и чем выше, тем больше эти кирпичи становятся, более специфицированным становится их поведение, а вместе с ней и внутренняя сложность, включая сюда разнообразнейшие инкапсуляции поведений, состояний и проч. AVK>Ничего не понял. Какие, нафик, кирпичи?
Все очень просто. В ООП и ФП разные принципы декомпозиции. В ООП ты мыслишь в категориях *сущностей* и их поведения, отношений между ними и пр. Производя декомпозицию, ты выделяешь новые виды сущностей.
В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
ВВ>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>Это называется полиморфизм. В ФП языках тоже бывает.
Это ты к чему? Ну да, частный случай полиморфизма, который прекрасно себя чувствует и без всякого ООП.
AVK>Функциональный тип, собственно, это оно и есть. ООП в этом плане отличается тем, что позволяет создавать полиморфную иерархию. Но ФП это никак не противоречит.
Причем тут функциональный тип?
Полиморфную иерархию можно создать и через алгебраические типы.
ВВ>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>Крайне спорный вывод, требующий доказательств.
Что тебе кажется спорным? Может, я неясно выразился? Любая программа так или иначе растет количественно. Идеал ООП — чтобы количественный рост не переходил в качественный. Т.е. у нас как был раньше фиксированный набор контрактов — он так и остается. В реальности же реализации объектов меняются, появляются новые объекты и пр.
ВВ>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>Опять же крайне спорно и бездоказательно.
Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП?
Здравствуйте, tripol, Вы писали:
T>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Вопросы к транскрипции этих "учебников". Вроде бы в каждом из них не написано, что все эти паттерны придуманы в рамках ООП. Там написано что такие вещи делают в ООП "вот так". Происхождению самих приемов внимание не уделяется. T>И опять да. Я, таким образом, лишь обратил внимание, что подавляющее большинство приемов объектно-ориентированной декомпозиции не предусматривают изменяемое состояние. Соответственно, утверждение, что ООП — это "один большой побочный эффект" является ложным.
В абсолютном плане — да, ложным. Но относительно 99% ООП оно справедливо.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>Ага, например для "тупого" парсера...
А кто говорит, что парсер умен? Это просто некий автомат, который выполняет то, для
чего предназначен.
Где обучаемость, способность запоминать и воспроизводить информацию?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>Ага, например для "тупого" парсера...
И даже парсеру требуется помнить состояние для его работы, собственно
вызов функции это тоже "запомнить" состояние, поскольку запоминается
адрес вызвавшей функции в стеке...
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, tripol, Вы писали:
T>>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
S>>Ага, например для "тупого" парсера...
T>А кто говорит, что парсер умен? Это просто некий автомат, который выполняет то, для T>чего предназначен.
Много чего выполняет то для чего предназначено...
T>Где обучаемость, способность запоминать и воспроизводить информацию?
А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Ага, например для "тупого" парсера...
T>И даже парсеру требуется помнить состояние для его работы, собственно T>вызов функции это тоже "запомнить" состояние, поскольку запоминается T>адрес вызвавшей функции в стеке...
Здравствуйте, samius, Вы писали:
T>>Где обучаемость, способность запоминать и воспроизводить информацию? S>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
Проблемы в том, что обучение это побочный эффект в ФП.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Где обучаемость, способность запоминать и воспроизводить информацию? S>>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
T>Проблемы в том, что обучение это побочный эффект в ФП.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
S>>>Ага, например для "тупого" парсера...
T>>И даже парсеру требуется помнить состояние для его работы, собственно T>>вызов функции это тоже "запомнить" состояние, поскольку запоминается T>>адрес вызвавшей функции в стеке...
S>За многоточием вывод о невозможности ФП?
Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций.
Можно сказать, что выполнение функции это то же состояние.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
T>>>>Где обучаемость, способность запоминать и воспроизводить информацию? S>>>А какие проблемы с этим? Можно и обучаемый парсер зарядить. В общем случае с воспроизведением в ФП проблем нет, но за воспроизводящим парсером не ко мне.
T>>Проблемы в том, что обучение это побочный эффект в ФП.
S>Чюш
Здравствуйте, tripol, Вы писали:
T>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
Откуда такие предрассудки?
Во-первых, с чего вы взяли, что парадигма языка программирования должна моделировать объекты реального мира — деревья, людей, кошек с собачками? По мне так сама эта идея довольно бредовая.
Наконец с чего это отсутствие побочных эффектов должно приводить к... гм... "потере интекллекта"? На ФЯ нельзя писать программы, которые занимаются "интеллектуальной обработкой"? По-моему это смешно.
Из того, что вы вместо класса Туалет с методом Сходить, сделаете функцию Сходить_В_Туалет, которая в качестве параметра будет принимать структуру, описывающую туалет, а возвращать... ну не будем об этом... и не сохранять результаты своей деятельности "по месту", в качестве "состояния", то данная функция, поверьте, совсем не потеряет в интеллектуальности.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, tripol, Вы писали:
T>>Собственно детальки не могут обладать каким либо интеллектом и интеллектуальной обработкой T>>информации, поскольку у них нет памяти и они не могут помнить состояний. Получается какая то T>>"сухая" конструкция, которая может использоваться для чисто каких то "тупых" целей.
ВВ>Откуда такие предрассудки? ВВ>Во-первых, с чего вы взяли, что парадигма языка программирования должна моделировать объекты реального мира — деревья, людей, кошек с собачками? По мне так сама эта идея довольно бредовая.
Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки
используется в жигулях для ... чего нибудь".
ВВ>Наконец с чего это отсутствие побочных эффектов должно приводить к... гм... "потере интекллекта"? На ФЯ нельзя писать программы, которые занимаются "интеллектуальной обработкой"? По-моему это смешно.
Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП?
ВВ>Из того, что вы вместо класса Туалет с методом Сходить, сделаете функцию Сходить_В_Туалет,
Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
Здравствуйте, tripol, Вы писали:
T>Ага, запомнить, значит скрытое состояние?
Нету абсолютно "чистых" ФП это бессмысленно.
Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>Где обучаемость, способность запоминать и воспроизводить информацию?
FR>В прологе конечно.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>Ага, запомнить, значит скрытое состояние?
FR>Нету абсолютно "чистых" ФП это бессмысленно. FR>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>За многоточием вывод о невозможности ФП?
T>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>Можно сказать, что выполнение функции это то же состояние.
Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, samius, Вы писали:
S>>>За многоточием вывод о невозможности ФП?
T>>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>>Можно сказать, что выполнение функции это то же состояние. S>Говорить-то можно много что, просто под "состоянием" в контексте ФП подразумевается не всякое состояние. Если ты побочный эффект приравниваешь к регистру или состоянию "выполнения функции", то мы не договоримся.
И к регистру, и к кэшу и к памяти, и к винчестеру, ко всему, что может хранить состояние.
В рамках ФП просто компьютер бы не смог работать.
Здравствуйте, tripol, Вы писали:
T>>>Где обучаемость, способность запоминать и воспроизводить информацию?
FR>>В прологе конечно.
T>И как там это организовано?
Здравствуйте, tripol, Вы писали:
T>Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки T>используется в жигулях для ... чего нибудь". T>Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП? T>Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ничего не понял. Что не так звучит?
ООП все-таки предполагает инкапсуляцию состояния
ВВ>>>Важнее то, что ФП и ООП предполагают разный подход к дизайну. AVK>>Разный. Но ортогональный, а не противоположный. Это важно.
ВВ>Может, и не противоположный, но взаимоисключающий.
Докажи.
AVK>>Ничего не понял. Какие, нафик, кирпичи?
ВВ>Все очень просто. В ООП и ФП разные принципы декомпозиции.
Разные.
ВВ>В ФП ты мыслишь в категориях *действий*.
Нет. В ФП я мыслю категориями вычисляемых функций. Функция не есть действие, в отличие от активного действия функция пассивна. Активная функция это уже с реактивным программированием связано, где верхушка реактивной цепочки обычно активная, но там вылазит таки соответствующая монада, которая, как ты утверждаешь, нифига не ФП.
ВВ> Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет.
А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?
ВВ> Есть данные — отдельно. Есть операции — отдельно.
Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.
ВВ> Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.
ВВ>>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>>Это называется полиморфизм. В ФП языках тоже бывает.
ВВ>Это ты к чему?
Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.
ВВ>Причем тут функциональный тип?
Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.
ВВ>Полиморфную иерархию можно создать и через алгебраические типы.
Верно. Отсюда простое следствие — полиморфизм никак не может служить отличием ООП от ФП.
ВВ>>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>>Крайне спорный вывод, требующий доказательств.
ВВ>Что тебе кажется спорным?
Твое утверждение, которое я, кстати, процитировал.
ВВ>Любая программа так или иначе растет количественно.
Растет. В том числе и функциональная.
ВВ> Идеал ООП — чтобы количественный рост не переходил в качественный.
И идеал ФП.
ВВ>В реальности же реализации объектов меняются, появляются новые объекты и пр.
И? Я по прежнему не вижу принципиальных отличий от ФП.
ВВ>>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>>Опять же крайне спорно и бездоказательно.
ВВ>Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП?
Например с того, что появились и широко используются они именно в функциональных языках для решения проблем, связанных с неспособностью чистых функциональных языков работать с изменяемым состоянием.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>ООП не требует фиксированности структуры. Где такие ограничения? T>Объект вполне может быть динамическим.
Еще как требует
Именно архитектор задает набор интерфейсов, эвентов, публичных методов. Он жестко прописывает порядок и типы переменных для каждого внешнего вызова. Шаг вправо шаг влево программа не то что будет работать с ошибкой, она просто не скомпилируется.
Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье ... Хотя той полезной функциональности может быть совсем ничего. Поэтому деклараций всяких интерфейсов, виртуальных методов и прочья в таких программах приближается а может и привышает количество полезного кода, который собственно наконец что-то делает с примитивами
Это всеравно что, чтобы создать универсальное Жигули архитектор придумал напихать туда самых разных разьемов и интерфейсов чтобы расширять и расширять возможности Жигули
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, tripol, Вы писали:
T>>Потому что, когда у чего то есть границы: внутреннее — внешнее, то не возникает чуши, подобно: "жедудок кошки T>>используется в жигулях для ... чего нибудь". T>>Ну да, скрытое состояние это в ФП = "побочный эффект". В конце концов мозги, это не сплошной "Побочный эффект" в ФП? T>>Похоже туалет, это как раз то место, где ФП идеально подходит (сохранять ничего не надо)...
ВВ>Студент?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
FR>>>Нету абсолютно "чистых" ФП это бессмысленно. FR>>>Вот разделение, минимизация и изолирование изменяемого состояния очень даже осмысленно и приносит неплохие дивиденды.
T>>В каких областях?
FR>Во всех, неизолированное изменяемое состояние — зло.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Споришь со своими догадками.
T>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило.
Вот и славно.
T>В ООП такой утопии нет.
А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>ООП не требует фиксированности структуры. Где такие ограничения? T>>Объект вполне может быть динамическим.
PC_>Еще как требует PC_>Именно архитектор задает набор интерфейсов, эвентов, публичных методов. Он жестко прописывает порядок и типы переменных для каждого внешнего вызова. Шаг вправо шаг влево программа не то что будет работать с ошибкой, она просто не скомпилируется.
PC_>Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье ... Хотя той полезной функциональности может быть совсем ничего. Поэтому деклараций всяких интерфейсов, виртуальных методов и прочья в таких программах приближается а может и привышает количество полезного кода, который собственно наконец что-то делает с примитивами
PC_>Это всеравно что, чтобы создать универсальное Жигули архитектор придумал напихать туда самых разных разьемов и интерфейсов чтобы расширять и расширять возможности Жигули
Что самое интересное, когда мне понадобится пятое колесо вместо четырех в Жигулях, то как всегда окажется что разьема такого то и нету среди остального хлама в программе и привет перепроэктированию программы снова, пока не появится шестое колесо
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
T>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>Вот и славно.
T>>В ООП такой утопии нет. S>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Но относительно 99% ООП оно справедливо.
T>Не согласен, моя практика показывает, что при понимании того, что immutable объекты — это круто, со временем остается очень мало mutable кода.
А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Что бы понять суть и ценность идеи, достаточно посмотреть, к чему стремятся и как это выглядит. Мне хватило. S>>Вот и славно.
T>>>В ООП такой утопии нет. S>>А в этой теме ты чем занимаешься? Изгоняешь беса из заблудших функциональщиков?
T>Пытаюсь понять ценность ФП, что бы зря не надеятся, что "где то лучше".
Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>ООП не требует фиксированности структуры. Где такие ограничения? T>>Объект вполне может быть динамическим.
PC_>Еще как требует
Улыбочкой не отделаетесь. ООП может быть динамическим.
PC_>Когда ООПэшный программист стремится к универсальности на все поколения, хоть какого-то достичь пристойного уровня полиморфизма, читай — видоизменяемости, программа становится походить на жуткую свалку каких-то интерфейсов, виртуальных методов, эвентов и прочье
Я к этому не стремлюсь, да и вообще к этому стремятся не часто. У программы есть период жизни. Перепроектировать придется
в любом случае, какая бы методология не использовалась, только в новом проекте большинство классов может остаться прежним,
а изменения коснутся только 5-того или 6-го колеса.
Здравствуйте, Mr.Cat, Вы писали:
MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Все-таки классическое процедурное на порядок "беднее".
Алгебраические типы данных (с ПМ) + ФВП с замыканиями уже прилично изменяют дизайн.
AVK>Нет. В ФП я мыслю категориями вычисляемых функций. Функция не есть действие, в отличие от активного действия функция пассивна. Активная функция это уже с реактивным программированием связано, где верхушка реактивной цепочки обычно активная, но там вылазит таки соответствующая монада, которая, как ты утверждаешь, нифига не ФП.
Брр, сейчас ты уже начинаешь спорить, т.к. тебе термин действие не понравился? Извини, придется тебе с этим смириться. Для меня "Развернуть список" — это именно что действие. Впрочем, можно использовать нейтральный термин "функция".
Рассуждения об активности/пассивности функций я, извини, не понял. Это о чем вообще?
ВВ>> Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. AVK>А как же, к примеру, замыкания? Итераторы? Или всего этого в ФП нет?
Про итераторы я же говорил — их в ФП нет
Замыкания. А что, ты считаешь замыкания смешивают данные и функции? Может лучше издалека начнем?
Зачем нужны замыкания и на что они, собственно, замыкаются-то?
ВВ>> Есть данные — отдельно. Есть операции — отдельно. AVK>Даже банальный карринг, абсолютно чистый в плане ФП, тебя опровергает.
Так можно решить только если воспринимать мои слова с каким-то чудовищным буквализмом. Но тут и в лес ходить далеко не надо. Даже такой вот код:
function foo() {
let x = 1
}
уже будет меня опровергать
Карринг — средство создания новой функции из имеющей. Аналогичный композиции. Кстати, композиция тоже вполне "меня опровергает", чем функции не данные?
Смешение данных и операций — это то, что мы наблюдаем в ООП. Когда операции становятся поведением объекта, т.е. фактически его сущностной характеристикой и как следствие — неразрывными от этого объекта. А карринг, частичное применение и прочие механизмы просто помогают тебе специфицировать обобщенные функции, они от этого не становятся частью чьего-то поведения. Никаких "классов" у нас не появляется. И данные остаются просто данными, а не чьим-то "состоянием".
ВВ>> Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр. AVK>А в ООП новые объекты путем комбинирования старых. Композиция называется. Наследование реализации, кстати, в какой то мере та же фигня.
Все правильно, только это уже не ООП. Все вот эти сентенции в стиле "наследование" есть рут ов олл ивил, композиция хорошо, как раз и показывают некоторую усталость от традиционного ООП.
Ты когда объекты комбинируешь, то с т.з. ООП делаешь, вообще говоря, полную хрень. А именно нарушаешь тот самый "иерархический ОО полиморфизм", ибо объекты-то ты скомбинировал, а вот их контракты увы не скомбинируются.
При этом ты, собственно, начинаешь писать в стиле, куда более близком к ФП, чем к ООП. Если по каким-то идеологическим причинам, тебе больше нравится называть это по-прежнему ООП, то я-то абсолютно не против. Но сабжа это никак не отменяет.
ВВ>>>>Самый цимус ООП — генерализация при работе с сущностями, т.е. объекты разные, имеющие свои особенности реализации, но работаем мы с ними через общий простой контракт. AVK>>>Это называется полиморфизм. В ФП языках тоже бывает. ВВ>>Это ты к чему? AVK>Ты пытаешься рассказать, почему ФП и ООП несовместимы, но при этом зачем то приводишь особенности, присущие и тому и другому.
Полиморфизм есть такая особенность, которая присуща чуть ли не всем парадигмам. Речь не о полиморфизме вообще, а о том, какими именно средствами он достигается в ООП. И вот эти средства — а не сам абстрактный полиморфизм — не очень-то с ФП дружат. Как и с отрекламированной тобой композицией, кстати.
ВВ>>Причем тут функциональный тип? AVK>Потому что предназначен он в основном для реализации динамического полиморфизма. В функциональной форме.
Не понял, честно говоря. Функциональный тип — ну это просто функция. О каком "динамическом полиморфизме" речь?
ВВ>>Полиморфную иерархию можно создать и через алгебраические типы. AVK>Верно. Отсюда простое следствие — полиморфизм никак не может служить отличием ООП от ФП.
Следствие отсюда еще проще — речь не о полиморфизме совсем.
ВВ>>>> Соответственно, усложнение программы == увеличение внутренней сложности объектов при сохранении внешней простоты. AVK>>>Крайне спорный вывод, требующий доказательств. ВВ>>Что тебе кажется спорным? AVK>Твое утверждение, которое я, кстати, процитировал. ВВ>>Любая программа так или иначе растет количественно. AVK>Растет. В том числе и функциональная. ВВ>> Идеал ООП — чтобы количественный рост не переходил в качественный. AVK>И идеал ФП. ВВ>>В реальности же реализации объектов меняются, появляются новые объекты и пр. AVK>И?
Если ты с этим согласен, то непонятно, почему мое предыдущее утверждение показалось тебе спорным.
AVK>Я по прежнему не вижу принципиальных отличий от ФП.
Странно. Ну начнем с того, что в ФП никаких объектов нет. Есть четкое разделение на функции и данные. Полиморфизм в стиле ООП невозможен в принципе — например, те же алгребраические типы хоть и предоставляют "иерархический" полиморфизм, но при этом являются принципиально "закрытыми". Попробуй добавить новую продукцию в АДТ — тебе придется переделывать *все* матчи, ибо они тут же протухнут.
Ну не знаю, мне правда надо дальше продолжать?
ВВ>>>>А генераторы там или монады — ИМХО! — к реальному ФП имеют отношение не больше, чем WWF к этому самому ФП. AVK>>>Опять же крайне спорно и бездоказательно. ВВ>>Давай от противного. С чего ты решил, что монады имеют какое-то отношение к ФП? AVK>Например с того, что появились и широко используются они именно в функциональных языках для решения проблем, связанных с неспособностью чистых функциональных языков работать с изменяемым состоянием.
Они появились в функциональных языках, потому что абсолютно чистый функциональный язык без всех этих костылей есть единорог, не имеющий никакого практического применения. Это факт, с которым спорить невозможно. Однако нужны они именно для этого. Выводить те же монады в ранг каких характерных функциональных фишек, мне кажется, неправильно. Монады нужны в том же несчастном Хаскеле чтобы был хоть какой-то способ задать порядок операций. Но суть Хаскеля не в том, что он позволяет "задавать порядок", а как раз в прямо противоположном.
Поэтому да, я не вижу смысла говорить о монадах, генераторах-итераторах и прочих корутинах, если мы хотим выделить какую-то сущность ФП подхода. Она точно НЕ в монадах.
Здравствуйте, samius, Вы писали:
S>А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко.
Мировая тенденция как раз движется сейчас в этом направлении с распространением многоядерных процессоров.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали: ВВ>>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр. MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
Можно, наверное, и так сказать. И не вижу тут ничего плохого
С другой стороны "набор паттернов в рамках настоящих парадигм" — какая-то уж очень обтекаемая формулировка. При желании и ООП так можно припечатать.
Здравствуйте, PC_2, Вы писали:
PC_>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. PC_>Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
Мне это напоминает: "Хреновому танцору и яйца мешают", не обижайтесь, но отказываться от переменных или данных
как таковых из-за глобальных переменных — это глупо.
Здравствуйте, tripol, Вы писали:
T>Улыбочкой не отделаетесь. ООП может быть динамическим.
только в местах предусмотренных архитектором обьекта.
А архитектор не может все предусмотреть, также как автоваз не предусматривает винта вертолета, крыльев самолета или гусенец трактора.
А вот в природе такое встречается сплошь и рядом, когда структура обьекта видоизменяется довольно серьезно. Это истинно полиморфные обьекты, а не псевдо-полиморфизм с участками подменяемого кода в основном алгоритме
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, tripol, Вы писали:
S>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
T>Конечно, исходя из утопии, что бы она не была утопичной, ее необходимо "облегчить" (вводим что T>то, что является состоянием, но таковым не называется).
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
T>Конечно, исходя из утопии, что бы она не была утопичной, ее необходимо "облегчить" (вводим что T>то, что является состоянием, но таковым не называется).
Ну я о том и говорю, что не приблизишься. Значит изгоняешь демонов.
T>"математические" проникновения в программирование считаю несуразным.
Это твои личные проблемы.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>А я не имел ввиду конкретно твою или чью-нибудь практику. Я про мировые тенденции. Не спорю, что ООП можно сочетать с ФП. Но мне кажется, что так делают редко. T>Мировая тенденция как раз движется сейчас в этом направлении с распространением многоядерных процессоров.
Я согласен с тем, что логично было бы чтобы она двигалась в этом направлении. И наверное кое-кто все-таки движется. Но вот называть эту тенденцию мировой наверное рано.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, PC_2, Вы писали:
PC_>>Функциональных подход например помогает избежать так называемых глобальных переменных. ООП их слегка поборол, спрятав за обложкой класса. PC_>>Стоит ли говорить что глобальные переменные по уровню зла стоят на втором месте после GoTo. Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
T>Мне это напоминает: "Хреновому танцору и яйца мешают", не обижайтесь, но отказываться от переменных или данных T>как таковых из-за глобальных переменных — это глупо.
я не обижаюсь, в среде некоторых индивидуумов часто ходит мнение о кривости рук чужих и исключительной ровности своих Обычно их эта мысль одолевает как раз когда очередная ООП подходит медленно но верно к своему серьезному переписыванию Чего уж греха таить.
А вообще новоиспеченного программиста в проект с ООП нужно пускать по хорошему только после прочтения двух-трех серьезных книг по рефакторингу
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Воронков Василий, Вы писали:
IT>>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
ВВ>Честно говоря, непротиворечивость ООП и ФП мне кажется несколько сомнительной. ООП все-таки предполагает инкапсуляцию состояния.
И?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PC_2, Вы писали:
PC_>я не обижаюсь, в среде некоторых индивидуумов часто ходит мнение о кривости рук чужих и исключительной ровности своих Обычно их эта мысль одолевает как раз когда очередная ООП подходит медленно но верно к своему серьезному переписыванию Чего уж греха таить.
А что ФП программы не подходят к переписыванию?
PC_>А вообще новоиспеченного программиста в проект с ООП нужно пускать по хорошему только после прочтения двух-трех серьезных книг по рефакторингу
А вообще новоиспеченного программиста лучше в любой проект не пускать, пока проект не поделен на практически независимые части.
Здравствуйте, tripol, Вы писали:
T>А что ФП программы не подходят к переписыванию?
Все подходят. Но одни раньше другие позже.
Зависит очень многое еще от проектирования.
И все эти штучки только метод борьбы с нарастающей непропорционально сложностью программы.
Как говорится
Программа достигает своего идеала в момент краха (с)
Разведите рассадник глобальных переменных, ООП это позволяет, в своей программе и окунитесь в дебаг с особыми извращениями. Конечно на ООП можно писать и по другому, о многом пишут в книжках по рефакторингу, по патернам и прочье. Но одни подходы дисциплинирует и как говорил ВВП "душат гадину на корню"(с), а другие только "рекомендуют" разными книжками по рефакторингу и патернам проектирования.
В любом случае еще можно прожить 50 лет с программой,
грохнуть по столу и сказать ктож так пишет, вот оно как надо !
Конечно через 50 лет оно как-то виднее будет
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
S>>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП.
Я не решаю проблем, которых у меня нет. Никогда не страдал от побочных эффектов в ООП. Для того, что бы
решать не существующие проблемы, мне не зачем изучать новую парадигму, которая, исправляет
несуществующие проблемы.
T>>"математические" проникновения в программирование считаю несуразным. S>Это твои личные проблемы.
Конечно "мои", только вводить ограничения математики в программирование, где таковых ограничений нет
это глупо.
Здравствуйте, FR, Вы писали: FR>Не напомнишь?
Нет, потому и спрашиваю.
FR>Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования"
Тут вот хз, я пытаюсь сгенерировать мысль в ответ тебе и Василию, но она пока не генерируется.
Здравствуйте, FR, Вы писали:
FR>Хуже чем фанат только догматик. FR>Давай лучше поговорим про улиток. Я вот никогда ни ел эту отвратительную гадость, и считаю их очень невкусными и несъедобными.
Вопрос, конечно, больше популяризационный и насаднический...
Однако поговорить с любителями улиток иногда полезно (может что ценного есть в улитках?).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, rsdn2010, Вы писали:
T>>>Как говорил не помню кто, что C или C++ это веревка достаточной длины, что бы выстрелить себе в голову... R>>в ногу
ВВ>Да ладно, пусть в голову себе стреляет. Мы не против...
Это я про то, что при желании конечно проект на С++ можно угробить, но обычно
ни у кого такого желания не возникает.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, FR, Вы писали:
FR>>Хуже чем фанат только догматик. FR>>Давай лучше поговорим про улиток. Я вот никогда ни ел эту отвратительную гадость, и считаю их очень невкусными и несъедобными.
T>Вопрос, конечно, больше популяризационный и насаднический... T>Однако поговорить с любителями улиток иногда полезно (может что ценного есть в улитках?).
недавно открыли такого паразита в улитках...
размножается клонированием
размножаясь внутри улитки особи этого паразита уничтожают всех др проникающих в улитку паразитов
делают улитку бесплодной
совокупная масса всех особей этого паразита внутри улитки может достигать 25% веса улитки
Здравствуйте, tripol, Вы писали:
T>Как говорил не помню кто, что C или C++ это веревка достаточной длины, что бы выстрелить себе в голову...
Даа ... С++ еще тот фрухт под флагами ООП, напортачишь с сборкой муссора в большом проекте и будешь касперов, этих милых приведений, ловить до скончания веков. Опять таки, в функциональном подходе еще 50 лет сборка муссора ложится в архитектуру вычислителя что дети в школу
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>>>Вряд ли упорствуя в безграмотности относительно состояний ты приблизишься к пониманию ценности ФП. T>Я не решаю проблем, которых у меня нет. Никогда не страдал от побочных эффектов в ООП. Для того, что бы T>решать не существующие проблемы, мне не зачем изучать новую парадигму, которая, исправляет T>несуществующие проблемы.
Выше ты писал, что хочешь понять. Понять не изучая не выйдет.
T>>>"математические" проникновения в программирование считаю несуразным. S>>Это твои личные проблемы. T>Конечно "мои", только вводить ограничения математики в программирование, где таковых ограничений нет T>это глупо.
Не понимая, ради чего вводятся ограничения — да, глупо.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>А по моему, добро, если изолируются от разного рода утопий...
FR>Угу и одна из иллюзий с названием ООП потихоньку развеивается
Здравствуйте, PC_2, Вы писали:
PC_>Даа ... С++ еще тот фрухт под флагами ООП, напортачишь с сборкой муссора в большом проекте и будешь касперов, этих милых приведений, ловить до скончания веков. Опять таки, в функциональном подходе еще 50 лет сборка муссора ложится в архитектуру вычислителя что дети в школу
Собственно среда разработки показывает, если вдруг где то налажался...
Здравствуйте, tripol, Вы писали:
T>>>>Как говорил не помню кто, что C или C++ это веревка достаточной длины, что бы выстрелить себе в голову... R>>>в ногу
ВВ>>Да ладно, пусть в голову себе стреляет. Мы не против...
T>Это я про то, что при желании конечно проект на С++ можно угробить, но обычно T>ни у кого такого желания не возникает.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>Здравствуйте, PC_2, Вы писали:
PC_>>>Даа ... С++ еще тот фрухт под флагами ООП, напортачишь с сборкой муссора в большом проекте и будешь касперов, этих милых приведений, ловить до скончания веков. Опять таки, в функциональном подходе еще 50 лет сборка муссора ложится в архитектуру вычислителя что дети в школу
T>>Собственно среда разработки показывает, если вдруг где то налажался...
PC_>неси зачотку
Здравствуйте, samius, Вы писали:
S>могу предложить ссылку на материал по ликбезу.
Какие вы все любезные. Так и хотят "наставить на путь "истинный"". Мне хватает описания, что такое ФП
и какие проблемы он решает. Я же сказал, что у меня такие проблемы не возникали ни на одном из
многочисленных проектов.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Можно и по делу — ты только уточни для начала что обсуждается-то. С++, улитки или ФП. И что спросить-то хотел, собственно.
Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП
вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.
А если возникают, то интересно, кто и как пишет, что они возникают.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>Улыбочкой не отделаетесь. ООП может быть динамическим.
PC_>только в местах предусмотренных архитектором обьекта. PC_>А архитектор не может все предусмотреть, также как автоваз не предусматривает винта вертолета, крыльев самолета или гусенец трактора.
Ага, только некоторые языки позволяют полностью заменять как методы, так и данные, в том числе и базовые классы.
T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП T>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, tripol, Вы писали:
T>>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП T>>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.
FR>Хуже ты не хочешь понимать.
Не, ссылку я конечно осилил ту что ты дал по D где то наполовину.
В основном разговор о том, почему const в языках плохой и как это исправить.
Собственно меня const в C++ вполне устраивает и проблем с этим никогда не возникало.
Здравствуйте, tripol, Вы писали:
T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП T>вроде как ни у кого не возникает.
У кого выяснил-то? Проблемы возникают и часто. Возьмем хотя бы параллельное программирование. Или сложность отладки. Вернее, скажем так — жестую в ней необходимость.
T>Зачем собственно ФП программирование, не пойму. А если возникают, то интересно, кто и как пишет, что они возникают.
Здравствуйте, tripol, Вы писали:
T>Не, ссылку я конечно осилил ту что ты дал по D где то наполовину. T>В основном разговор о том, почему const в языках плохой и как это исправить. T>Собственно меня const в C++ вполне устраивает и проблем с этим никогда не возникало.
T>А так в другую веру просто так не обращаюсь.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, tripol, Вы писали:
T>>>Улыбочкой не отделаетесь. ООП может быть динамическим.
PC_>>только в местах предусмотренных архитектором обьекта. PC_>>А архитектор не может все предусмотреть, также как автоваз не предусматривает винта вертолета, крыльев самолета или гусенец трактора.
T>Ага, только некоторые языки позволяют полностью заменять как методы, так и данные, в том числе и базовые классы.
Знаешь что будет если в Жигулях попробовать поставить пятое колесо ?
Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, tripol, Вы писали:
FR>>Блин клиническая демонстрация функциональной слепоты
T>Не ну дайте ссылку, в которой видится явное преимущество ФП перед T>императивным. Или расскажите, что вас вдохновляет в ФП.
Какие ссылки ты же их не читаешь. В той же pdf'ке есть почти все ответы есть.
Меня уже ничего ни вдохновляет в ФП, это просто одна из освоенных практик программирования, во многом более
удобная и красивая чем ОП.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>Вообще пятое колесо это серьезное изменение и требует перепроектирования.
PC_>Вот ты уже начинаешь понимать, что в ООП Жигулях разве что Магнитолу хорошо менять одну за одной
И колеса и запчасти и вообще почти все кроме корпуса. В ООП корпус легко можно
выкинуть на помойку и поставить другой. Так и не услышал на счет жигули vs ФП...
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, PC_2, Вы писали:
PC_>>Здравствуйте, tripol, Вы писали:
T>>>Вообще пятое колесо это серьезное изменение и требует перепроектирования.
PC_>>Вот ты уже начинаешь понимать, что в ООП Жигулях разве что Магнитолу хорошо менять одну за одной
T>И колеса и запчасти и вообще почти все кроме корпуса. В ООП корпус легко можно T>выкинуть на помойку и поставить другой. Так и не услышал на счет жигули vs ФП...
На самом деле тебе нужно представлять, машина с четырьмя колесами или с пятью — разница не большая. Ты предложил перепроектировать. Это хорошо что ты понимаешь, что даже если ООП программа как ёжик в интерфейсах, пятое колесо ведет к переписыванию структуры программы с кучей времени и багов.
Что касается ФП.
Есть такой афоризм про Лисп,
Лиспер долго запрягает но быстро едет (с)
Долго запрягает потому что пока опишет тоже Жигули, прийдется описать еще один промежуточный язык. Но зато когда напишет, добавить еще одно колесо будет что-то
вроде +1 колесо и вуаля. Все конечно утрировано, но правда как всегда где-то рядом
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>На самом деле тебе нужно представлять, машина с четырьмя колесами или с пятью — разница не большая. Ты предложил перепроектировать. Это хорошо что ты понимаешь, что даже если ООП программа как ёжик в интерфейсах, пятое колесо ведет к переписыванию структуры программы с кучей времени и багов.
На самом деле пятое колесо это из ряда вон выходящее, поэтому начальный дизайн такой
смены не предвидит и правильно делает.
PC_>Что касается ФП.
PC_>Долго запрягает потому что пока опишет тоже Жигули, прийдется описать еще один промежуточный язык. Но зато когда напишет, добавить еще одно колесо будет что-то PC_>вроде +1 колесо и вуаля. Все конечно утрировано, но правда как всегда где-то рядом
Не ну и в ООП типа можно написать "компилятор" машин, или использовать почти готовый.
Здравствуйте, PC_2, Вы писали:
PC_>Знаешь что будет если в Жигулях попробовать поставить пятое колесо ? PC_>Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...
Может для тебя это и новость, но доказательства по аналогии логически некорректны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>Нет, вывод о том, что в ФП состояния пытаются скрыть за вызовом функций. T>Можно сказать, что выполнение функции это то же состояние.
А вот и следствие вольного обращения ВВ с терминами. Речь не просто о состоянии, а об изменяемом состоянии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, PC_2, Вы писали:
PC_>Функциональных подход например помогает избежать так называемых глобальных переменных.
Ты таки продолжаешь доставлять Нет ничего лучше студента с активной позицией по сложным вопросам программирования.
PC_>Функциональный подход пытается ограничить как можно лучше область видимости переменных тем самым делая более универсальные кирпичики.
Не угадал. Бегом читать литературу по CS.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, tripol, Вы писали:
T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП T>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.
Квантор всеобщности тут явно лишний. Потому что как минимум у меня возникают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Mr.Cat, Вы писали:
FR>>Кстати ООП тогда тоже не более чем "позабытые паттерны процедурного программирования" MC>Тут вот хз, я пытаюсь сгенерировать мысль в ответ тебе и Василию, но она пока не генерируется.
Все-таки Василий, как уже отметили выше любит сужать функциональщину.
Если же ее брать в том виде как она реализована в существующих языках (ML образные, потомки миранды и схемо-лиспы),
то их выразительность и возможности (не исключая и императивные) практически позволяют быть полноценной
альтернативой ООП языкам. При этом ОО вполне может и наверно остается в декомпозиции, но реализуется все
из кирпичиков которые не включают классы и объекты, а состоят из ADT (в обоих расшифровках ) ФВП с замыканиями,
и очень небольшой примеси императивщины.
Здравствуйте, tripol, Вы писали:
T>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Можно и по делу — ты только уточни для начала что обсуждается-то. С++, улитки или ФП. И что спросить-то хотел, собственно.
T>Да я уже вроде бы как все выяснил, что проблем с состояниями в объектах ООП T>вроде как ни у кого не возникает. Зачем собственно ФП программирование, не пойму.
T>А если возникают, то интересно, кто и как пишет, что они возникают.
Проблемы возникают у всех. Просто одни к ним привыкли, а другие ищут способы избежать проблем.
Ты попадаешь в первую категорию.
Связность по состоянию (здесь и далее имеет ввиду наблюдаемое изменяемое состояние) делает значимым порядок вычислений. Становятся недоступными многие оптимизации, становятся сложнее рассуждения о программе. Это все ведет к увеличению количества багов. А если порядок вообще не фиксированный (многопоточность), то приходится прикладывать много усилий чтобы вычисления как-то упорядочить, чтобы это не приводило к случайным результатам.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали: ВВ>>В ФП ты мыслишь в категориях *действий*. Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно. Соответственно, мы производим декомпозицию на уровне действий, т.е. комплексные действия разделяем на простые, новые действия получаем путем комбинирования старых и пр.
MC>И получаем процедурное программирование. Иногда я начинаю сомневаться, что ФП существует само по себе как парадигма, а не является набором паттернов в рамках настоящих парадигм.
А что такое процедурное программирование?
Здравствуйте, AndrewVK, Вы писали:
MC>>А не может такого быть, что это были паттерны процедурного программирования, просто о них забыли? AVK>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе.
Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.
Т.е. например интерфейс USB по сути своей неверен ? Или розетка на 220 вольт со стандартным штекером не имеет права на существование ? Мне кажется вы в чем то неправы.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, tripol, Вы писали:
T>>Улыбочкой не отделаетесь. ООП может быть динамическим.
PC_>только в местах предусмотренных архитектором обьекта. PC_>А архитектор не может все предусмотреть, также как автоваз не предусматривает винта вертолета, крыльев самолета или гусенец трактора.
PC_>А вот в природе такое встречается сплошь и рядом, когда структура обьекта видоизменяется довольно серьезно. Это истинно полиморфные обьекты, а не псевдо-полиморфизм с участками подменяемого кода в основном алгоритме
Исходя из данного контекста , грамотный архитектор предусмотрит инткрфейс отвечающий за определенную ФУНкциональность. В примере выше это класс "транспортное средство" ответственностью которого будет переправить из одной точки в другую.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, PC_2, Вы писали:
PC_>>Знаешь что будет если в Жигулях попробовать поставить пятое колесо ? PC_>>Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...
AVK>Может для тебя это и новость, но доказательства по аналогии логически некорректны.
А тут кто то доказательства доказывает ? Я думал просто на примере пытаются продемонстрировать мысль ?и
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, PC_2, Вы писали:
PC_>>>Знаешь что будет если в Жигулях попробовать поставить пятое колесо ? PC_>>>Нужно наверное еще рулевую всю перебрать, поменять задний мост, старый можно на свалку, выпилить напильником еще одну арку в кузове, поставить новый амортизатор, перебрать электронику ... а потом еще молотком его, молотком, это по минимуму так ...
AVK>>Может для тебя это и новость, но доказательства по аналогии логически некорректны.
M>А тут кто то доказательства доказывает ? Я думал просто на примере пытаются продемонстрировать мысль ?и
По умолчанию демонстрация "на примере" неверна. Надо доказать что пример адекватный.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>По умолчанию демонстрация "на примере" неверна. Надо доказать что пример адекватный.
M>Вы ошибаетесь.
Да ну?
M>Пример нужен для демонстрации хода мысли.
Для демонстрации хода мысли можно продемонстрировать ход мысли.
M>Предьявлять какие либо требования к собеседнику это абсурд.
Счегобы?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, minorlogic, Вы писали:
M>>Пример нужен для демонстрации хода мысли. G>Для демонстрации хода мысли можно продемонстрировать ход мысли.
Пример на аналогии и является такой демонстрацией.
M>>Предьявлять какие либо требования к собеседнику это абсурд. G>Счегобы?
С того что если вы к себе предявляете одни требования а к собеседнику другие , диалог получится малопродуктивным (и это я тоже доказывать не собираюсь).
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, minorlogic, Вы писали:
M>>>Пример нужен для демонстрации хода мысли. G>>Для демонстрации хода мысли можно продемонстрировать ход мысли. M>Пример на аналогии и является такой демонстрацией.
Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.
M>>>Предьявлять какие либо требования к собеседнику это абсурд. G>>Счегобы? M>С того что если вы к себе предявляете одни требования а к собеседнику другие , диалог получится малопродуктивным (и это я тоже доказывать не собираюсь).
Я аналогиями не пользуюсь.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, minorlogic, Вы писали:
M>>>>Пример нужен для демонстрации хода мысли. G>>>Для демонстрации хода мысли можно продемонстрировать ход мысли. M>>Пример на аналогии и является такой демонстрацией. G>Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.
Докажите что стоит , иначе предложение выше можно считать бредом.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, minorlogic, Вы писали:
M>>>>>Пример нужен для демонстрации хода мысли. G>>>>Для демонстрации хода мысли можно продемонстрировать ход мысли. M>>>Пример на аналогии и является такой демонстрацией. G>>Ну так стоит доказать адекватность аналогии для доказательства адекватности хода мыслей. Иначе по-умолчанию можно считать бредом.
M>Докажите что стоит , иначе предложение выше можно считать бредом.
От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, minorlogic, Вы писали:
M>>>Докажите что стоит , иначе предложение выше можно считать бредом. G>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.
M>Докажете ваше утверждение выше, иначе это бред по умолчанию. Заклинило?
M>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли.
Угадай что надо сделать для выделенного?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, minorlogic, Вы писали:
M>>>>Докажите что стоит , иначе предложение выше можно считать бредом. G>>>От противного. Если адекватность аналогии не доказывать, то можно привести любую неверную аналогию, как "демонстрацию хода мысли", а потом опираться на нее в дальнейших рассуждениях. Вот и нужно аналогии обосновывать чтобы потом не повторяли бред, типа пятых колес, третьих рулей и тому подобного.
M>>Докажете ваше утверждение выше, иначе это бред по умолчанию. G> Заклинило?
Нет , демонстрирую абсурдность твоих утверждений на примере. Думал что ты догадаешься.
M>>P.S. "опираться на нее в дальнейших рассуждениях" можно только если собеседник понял рассуждения по аналогии и согласился с ними. Далее аналогия может служить для демонстрации других ходов мысли. G>Угадай что надо сделать для выделенного?
Много чего можно сделать , а угадывать что ты тут себе напридумывал мне нет мотивации.
WH>На первом. И с огромным отрывом. WH>goto пакостит только внутри функции, а глобальные переменные по всей программе. WH>Что называется почувствуйте разницу.
так это потому что Дейкстра критиковал вовсе не то goto, которое сейчас в C. goto в C действительно локальное и безобидное.
Дейстра критиковал goto по всей программе, типа longjmp.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.
Классы ООП тоже можно.
... << 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>Классы ООП тоже можно.
Можно. Об этом и речь. Собственно, вопрос, "а не является ли ХХХ лишь набором паттернов, а не отдельной парадигмой" применим к ним обоим.
Здравствуйте, AndrewVK, Вы писали: AVK>ФВП это не просто паттерн, это базовый функционал, first class citizen в компиляторе.
Ну вот в дотнете эвент — тоже first class citizen. А толку?
Здравствуйте, IT, Вы писали: IT>А что такое настоящая парадигма? ООП — это тоже несколько паттернов: инкапсуляция, наследование, полиморфизм.
Идеи ООП вытекают из наблюдения за объектами реального мира, которые существуют, могут изменяться и воздействовать на другие объекты независимо от сознания наблюдателя. Инкапсуляция, полиморфизм и наследование возникают в ходе попыток сабжевые объекты классифицировать.
Здравствуйте, 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>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>И никакого отличия между ней и классом нет, да?
С обьектом
Класс — это всё же тип, а не экземпляр.
Построим простенький класс:
public class LinearTransform
{
private double _k;
private double _b;
public Vector(double k, double b) { _k = k; _b = b}
publuc double Transform(double x) { return _k*x+_b;}
}
Он у нас получился immutable. Поэтому его крайне легко превратить в функцию (пишу на псевдокоде)
function LinearTransform(k, b)
{
return function(x)
{
return k*x+b;
}
}
Вот, собствено, замкнули. Вся разница — в том, что не нужно руками замыкать результат на параметры конструктора.
Та функция, которая связана с данными — наш анонимный аналог метода Transform — играет роль объекта.
А классом здесь выступает функция-генератор, LinearTransform.
Если бы мы развивали тему дальше в рамках ООП, то у нас бы возник ITransform с методом double Transform(double x), который бы реализовывали все, кому не лень. Ну, или (если учиться по старым книжкам), class TransformBase с аналогичным методом, и целая иерархия перегрузок. А в рамках ФП нам достаточно иметь тип x -> x, чтобы бесплатно получить возможность подставлять туда всё, что угодно — хоть результат вызова LinearTransform, хоть вручную сконструированное замыкание, хоть константу.
ВВ>>> В ООП у тебя функции привязаны к структурам данных всегда.
ВВ>Твоя позиция, видимо, сводится к тому, что программирование в "функциональном стиле" ООП никак не противоречит. Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП. Полноценно писать в ФП на Шарпе практически невозможно. Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной.
Есть подозрение, что это не из-за несоместимости моделей.
ВВ>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП.
Пример выше, скорее всего, поясняет смысл сравнения каррированной функции с классом.
ВВ>А *что* делает их несовместимыми я уже писал и повторял раз надцать — ООП приводит к тому, что программирование строится на инкапсуляции побочных эффектов, ФП напротив стремится избежать этого. Побочные эффекты есть, конечно, и там, и там. Но последовательный дизайн программы в ООП стиле противоречит ФП стилю — они идут в разные стороны. Программа не может быть одновременно ООП и ФП. А прикрутить сбоку пару функциональных фишек к ООП-ной программе конечно можно без проблем.
Интересное замечание. Программа — это такая штука, которую каждый понимает по-своему. Вот в Паскале было хорошо: там программа начиналась с ключевого слова program, и всё сразу понятно. А тут один под программой понимает какое-нибудь "решето Эратосфена", а другой — поисковую машину Гугла. Это я к тому, что насчёт решета я с тобой легко соглашусь, а вот насчёт поисковой машины — как-то непонятно. Не вижу, почему бы "программе" не быть в одном углу объектно-ориентированной, а в другом — функциональной.
ВВ>Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава.
У меня deja vu. Не напомнишь, как имитировать ФВП в чистом С?
Там же нет функторов, так что скрытым параметром замкнутые данные не передашь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mr.Cat, Вы писали:
KO>>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно. MC>Вообще, системы с объектоподобными агентами тот же Танненбаум отделял от ООП в отдельную категорию (у него "object-based" vs. "object-oriented"). Но если уж проводить параллели эрланга с ООП — надо обязательно вспомнить о его параметризованных модулях.
Не надо. Экземпляр параметризованного модуля не содержит мутабельного состояния, не имеет "идентити", и объектом не является. Соответственно — модуль это абстрактный тип данных, но не класс объектов.
Из встроенных штуковин — определению объекта в эрланге удовлетворяет только процесс.
Здравствуйте, k.o., Вы писали:
S>>Скорее всего баян, но эта статья кажется мне более адекватной.
KO>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно.
Ага. На эту тему мы как-то сцеплись с Джо в эрланговском мейллисте. Процессы эрланга один в один являются объектами Smalltalk 72. Просто одно и то же, без всяких натяжек.
Здравствуйте, samius, Вы писали:
S>А зачем именно скрытым?
S>Я не знаток "C", но думаю что можно вместо функтора передавать адрес стурктуры, где первым полем идет указатель на функцию, далее замыкаемые данные. Вызывающий должен первым параметром в метод подавать адрес структуры. Как-то так:
Скрытым — затем, чтобы избежать разбегания сигнатур.
Вот, допустим, пишу я алгоритм, который принимает в качестве callback функцию трансформации координат, (x, y) -> (x', y').
Интуитивно ожидаю получить в качестве сигнатуры что-то типа
Point (*Transform)(Point)
А на деле что? Вместо этого у меня transform превращается в структуру, да ещё и такую, которую я вынужден использовать вот так:
То есть это ещё хуже, чем ручная реализация замыкания на "ООП", как в моём примере. Потому как мы сначала эмулируем ООП, а потом на этой эмуляции ООП эмулируем замыкание.
И это всё ещё нифига не функции высшего порядка.
Реализация в этой идеологии чего-нибудь простого, типа fold, я так понимаю, будет довольно-таки весёлым упражнением.
И ах, да — у нас же здесь будет гарантия неоптимизируемости исполняемого кода: сплошные косвенные вызовы, без информации о типах, на основе которой компиляторы спекулируют...
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>А зачем именно скрытым?
S>А на деле что? Вместо этого у меня transform превращается в структуру, да ещё и такую, которую я вынужден использовать вот так: S>
S>То есть это ещё хуже, чем ручная реализация замыкания на "ООП", как в моём примере. Потому как мы сначала эмулируем ООП, а потом на этой эмуляции ООП эмулируем замыкание.
Конечно хуже. Лучше не может быть по определению.
S>И это всё ещё нифига не функции высшего порядка. S>Реализация в этой идеологии чего-нибудь простого, типа fold, я так понимаю, будет довольно-таки весёлым упражнением.
Не сомневаюсь.
S>И ах, да — у нас же здесь будет гарантия неоптимизируемости исполняемого кода: сплошные косвенные вызовы, без информации о типах, на основе которой компиляторы спекулируют...
На деле получилось криво, медленно и неудобно. Но вполне возможно.
Здравствуйте, samius, Вы писали:
S>На деле получилось криво, медленно и неудобно. Но вполне возможно.
Возможно примерно также как встретить динозавра по дороге на работу.
Если за столько времени никто ниче подобного не сделал, то и не сделает никогда. Поэтому можно считать такое невозможным.
А про теоретическую возможность спорить и не надо, у нас все языки полны по тьюрингу и то что умеет делать один теоретически умеет и другой.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>На деле получилось криво, медленно и неудобно. Но вполне возможно. G>Возможно примерно также как встретить динозавра по дороге на работу.
G>Если за столько времени никто ниче подобного не сделал, то и не сделает никогда. Поэтому можно считать такое невозможным.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>На деле получилось криво, медленно и неудобно. Но вполне возможно. G>>Возможно примерно также как встретить динозавра по дороге на работу.
G>>Если за столько времени никто ниче подобного не сделал, то и не сделает никогда. Поэтому можно считать такое невозможным.
S>Точно известно, что никто подобного не делал?
Здравствуйте, Klapaucius, Вы писали:
K>По-моему, парадигма — это базис, в котором другая парадигма может быть выражена как набор паттернов. Так что это отношение ФП-ООП и в обратную сторону работать будет.
Это почти верно, только не для парадигм, а языков, поддерживающих ту или иную парадигму.
Парадигма программирования — это методология + наработанные практики.
FR>>>Во всех, неизолированное изменяемое состояние — зло.
T>>Фанат ?
FR>Нет, и фраза выше справедлива и для императивных языков.
Дык,в ООП изменяемое состояние изолируется(инкапсулируется) в объекте.Поскольку ООП появилось как
надстройка над императивным языком,то можно сказать,что изоляция изменяемого состояния-одна из проблем,которую решает ООП в императивных языках.
Про вред употребления глобальных (PUBLIC)переменных — открытого изменяемого состояния,знаю не понаслышке.Доводилось разгребать кучу кода.Впрочем,инкапсуляции в закрытых переменных модуля вполне достаточно во многих случаях.В принципе модуль можно рассматривать как одиночный экземпляр класса(объект).И во многих случаях этого экземпляра достаточно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Авторов, использующих такую аргументацию, читать не стоит.
Если это единственная оплошность авторов, то можно считать их труд успешным.
Здравствуйте, Skynin, Вы писали:
S>Дык не понял — какой именно король голый, если нет разницы? Обое тогда голые.
ООП в свое время преподносился как парадигма, повышающая продуктивность разработчиков по сравнению с процедурной.
Здравствуйте, Gaperton, Вы писали: G>Экземпляр параметризованного модуля ... не имеет "идентити", и объектом не является.
Почему не имеет? Не помню точно, как это реализовано в эрланге, но мы бы могли считать идентичными экземпляры модулей, созданные с идентичными параметрами.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Gaperton, Вы писали: G>>Экземпляр параметризованного модуля ... не имеет "идентити", и объектом не является. MC>Почему не имеет? Не помню точно, как это реализовано в эрланге, но мы бы могли считать идентичными экземпляры модулей, созданные с идентичными параметрами.
Здравствуйте, Фукерман, Вы писали:
Ф>http://citforum.ru/gazeta/165/
ООП провалилось как серебрянная пуля, универсальный ответ на все вопросы разработки.
Именно эта пропаганда и почти что религиозная вера во всемогущество, являются основным провалом.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, k.o., Вы писали:
S>>>Скорее всего баян, но эта статья кажется мне более адекватной.
KO>>Учитывая, что процессы эрланга это, по сути, те же объекты, сам факт критики ООП выглядит неадекватно.
G>Ага. На эту тему мы как-то сцеплись с Джо в эрланговском мейллисте. Процессы эрланга один в один являются объектами Smalltalk 72. Просто одно и то же, без всяких натяжек.
А ссылок не осталось? Кстати, он, похоже, несколько изменил свои взгляды на ООП и его наличие в эрланге. Вот, например, пара цитат из его прошлогоднего сообщения в мейл-листе (здесь):
I now believe the following to be central to the notion of OO.
— Isolated concurrent things
— Communication through message passing
— Polymorphism
By these criteria there are actually no OO languages (nobody can do *complete* isolation) though Erlang is nearer to being OO than many other languages. And most so-called OO languages are not OO.
Здравствуйте, Sinclair, Вы писали:
ВВ>>Ну это можно вполне успешно сэмитировать без прямой поддержки в языке. Хоть на указателях, как в Си, хоть на классах, как в Джава. S>У меня deja vu. Не напомнишь, как имитировать ФВП в чистом С? S>Там же нет функторов, так что скрытым параметром замкнутые данные не передашь.
Гм, для начала тебе придется мне напомнить, почему это замыкания стали необходимым требованием ФВП.
Здравствуйте, Sinclair, Вы писали:
S>Если бы мы развивали тему дальше в рамках ООП...
Вот как раз это и нужно делать. В простейших случаях — да, все очень похоже. И каких-то кардинальных отличий между ФП и ООП подходами у нас как бы и нет. Мы всегда может сказать, что функция, ее сигнатура выступает в виде этакого контракта и полностью выполняет роль контракта в ООП. Но есть один нюанс.
В идеале функция в ФП не имеет внутреннего изменяемого состояния, не влияет на состояние других функций и пр. А это опять же означает, что все результаты ее жизнедеятельности мы получим сразу после вызова. В итоге функция возвращает и принимает некое состояние, не хранит его.
Что в ООП? Да, действительно у нас нет такого требования, чтобы класс, извините, объект "инкапсулировал побочные эффекты". Но давай посмотрим в глаза реальности — как в действительности будет выглядеть ОО-приложение. В действительности во всех ОО программах, которые я видел, писал, переписывал и пр. у объектов есть внутренее *изменяемое* состояние. Причем поведение методов объекта будет зависеть от этого состояния. Все, бац, — у нас больше нет детерминированных функций.
В качестве возражения тут выдвигается мысль, что
а) изменяемое внутренее состояние объектов не есть строгая необходимость в ООП, можно писать без этого
б) изменяемое внутренее состояние допустимо в ФП(см. итераторы и проч.)
По поводу б) все очень просто — да, допустимо в качестве этакого исключения из правил. Извините, статические методы в Шарпе тоже как-то слабо с ООП соотносятся. Но использование изменяемого внутреннего состояния не есть нормальный стиль программирования в ФП.
С пунктом а) все интереснее. Интерес как раз в том, что если бы можно было привести строгие формальные причины, по которым изменяемое внутреннее состояния в ООП необходимо и неизбежно, то и спора, собственно, не было бы.
Но если попробовать покопать. Класс в ООП — это изначально некая комплексная сущность, выделенная в процессе моделирования. Фактически мы берем некий набор действий и характеристик и объединяем их воедино. Вместо отдельного набора функций вроде "набирать скорость", "тормозить" и проч. у нас будет класс "Машина".
Ну хорошо — объединили мы несколько функций в один как бы "контейнер". Что нам это дало? Представим, что эти ф-ции ведут себя как 100% ФП функции, т.е. являются строго детерминированными. Возникает естественный вопрос — а на фига мы их в единую кучу слепили-то? Чтобы удобнее было в качестве единого параметра передавать? Ну ОК. А это точно ООП?
Вот возникает такое серьезное подозрение — чего-то во всем этом не хватает. Мы же не просто контейнер для функций создали, у нас как бы класс, некоторая сущность, являющаяся проекцией объекта реального мира и т.д. и т.п. А помимо собственно действий, есть еще и такие штуки как характеристики. Ну вот например — у машины может быть такая отличная характеристика как количество бензина.
Дальше точно стоит продолжать?
ВВ>>>> В ООП у тебя функции привязаны к структурам данных всегда. ВВ>>Твоя позиция, видимо, сводится к тому, что программирование в "функциональном стиле" ООП никак не противоречит. Но "функциональный стиль", который уверенно насаждается в последних версиях того же Шарпа, это не ФП. Полноценно писать в ФП на Шарпе практически невозможно. Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной. S>Есть подозрение, что это не из-за несоместимости моделей.
Это просто ремарка о неудобстве функциональщины в Шарпе, не более того.
Приведенная лишь в силу того, что я лично, со всеми подобающими ИМХО, не считаю опыт функционального программирования в Шарпе полноценным опытом, по которому можно судить о функциональном программировании.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>"Та самая" тема для тебя — это какая? Перечислить ряд банальностей, убедиться в том, что в википедии говорится о полной и окончательной совместимости ФП и ООП по всем фронтам и после этого считать свою позицию аксиомой, которую не нужно доказывать? AVK>Я тебе еще раз напоминаю, что утверждения здесь делаешь ты, а не я.
Не делать утверждения — это какая-то неинтересная позиция я бы сказал. У тебя нет мнения по этому вопросу?
ВВ>> Причем мешать будут всякие "мелочи". Например, у тебя объявления типов функций через Func<>, которые к тому же не выводятся, будут просто в километр длиной. AVK>Ужас просто.
Ну когда сигнатура функции уходит за край экрана — то вообще да, ужас.
ВВ>>Может, касательно "соединения функция и данных" ты меня тоже как-то превратно понимаешь? Ибо я не въезжаю, как можно сравнивать каррированную функцию с классом в ООП. AVK>А я ее и не сравниваю. На прямое опровержение твоим словам, что данные и функции в ФП связать нельзя.
Я не говорил, что нельзя. Вообще само утверждение "в ФП нельзя то-то" какое-то неправильное. Что такое "в ФП нельзя"? Есть конкретные языки. В конкретных языках, которые в большинстве своем гибридные, можно практически все что угодно.
Я говорил о том, что в ООП действия и *характеристики* некоторой сущности связываются воедино, чего не делается в ФП.
Вот посмотри мой ответ Синклеру: http://rsdn.ru/forum/philosophy/3989812.1.aspx
Возможно, он лучше поясняет мою мысль.
ВВ>>Я тебе уже говорил — покажи мне совместимый с ФП ООП дизайн. Дизайн, понимаешь? Ты в ответ написал одно слово — linq. Что linq? AVK>"Совместимый с ФП ООП дизайн"
Здравствуйте, Фукерман, Вы писали:
Ф>http://citforum.ru/gazeta/165/
ООП реально провалилось в современном мире. Еще 10 лет назад оно привило бал, сегодня же большая часть кода -- это PHP/JS-быдлокод. В нем ООП если и используется, то сугубо "клиентским" способом (стандартные классы со скрипом еще используем, сами же ничего объектного ни в жисть не напишем). Так что если сравнивать, грубо говоря, по количеству строк и/или модулей, то в последнее время ООП используется действительно совсем нечасто.
P.S. Кривая деградация программирования с лагом в несколько лет просто повторяет все изгибы кривой деградации образования.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Гм, для начала тебе придется мне напомнить, почему это замыкания стали необходимым требованием ФВП.
Мнэ-э-э... А как, собственно, мы собираемся строить функцию, которая принимает и возвращает другие функции?
Ну вот, давайте в качестве упражнения реализуем простейшую ФВП, которая возвращает комбинацию своих аргументов:
function Combine(f, h)
{
return new fuction(x)
{
return f(h(x));
}
}
Как её изобразить без замыканий?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)
Здравствуйте, Курилка, Вы писали:
ВВ>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор. К>Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)
Бррр, че сказать-то хотел? Обе функции есть частный случай ФВП, не более того. И Sort — ФВП ничуть не в меньшей степени, чем Combine, при этом замыканий не требует.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Курилка, Вы писали:
ВВ>>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор. К>>Как раз это(Combine) и есть ФВП, а Sorted — это лишь частный случай более общего понятия ФВП(включающего вариант Combine)
ВВ>Бррр, че сказать-то хотел? Обе функции есть частный случай ФВП, не более того. И Sort — ФВП ничуть не в меньшей степени, чем Combine, при этом замыканий не требует.
Тебе говорят про "first class citizen в компиляторе", а ты показываешь некий недо-citizen
ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор.
Всё как раз наоборот: в частном случае будет твоя Sort. А в общем случае будет в том числе и такая, как у меня.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ВВ>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор. S>Всё как раз наоборот: в частном случае будет твоя Sort. А в общем случае будет в том числе и такая, как у меня.
Обе функции есть частный случай ФВП. Такая формулировка устроит? Sort, конечно же, не более общий случай, что-то я заговариваюсь последнее время.
Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает. Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно. ФП есть все же вид декларативного программирования и вот с этим в ДжаваСкрипте тухло как-то. С т.з. выразительности и удобства написания функционального кода этот язык сосет по сравнению с каким-нибудь OCaml. И несмотря на то, что базовые механизмы есть, когда пишешь на ДжаваСкрипте функциональную программу не покидает чувство, что занимаешься по-прежнему имитацией настоящего ФЯ.
Твой пример с композицией — типичной операцией над функциональном типе в ФЯ — очень характерен (кстати, зачем там "new"? ). Попробуй изобразить композицию для трех функций, для четырех. Как все это будет выглядеть? Не очень-то декларативно. А еще и про каррирование не стоит забывать.
Поэтому мое личное ИМХО — джаваскрипт НЕ функциональный язык. Вроде и замыкания есть, но все равно чего-то не хватает. Все равно имитация. В этом смысле аналогичная имитация на Си будет ну просто несколько более уродлива, чем на ДжаваСкрипт и все. Но при этом будет такой же имитацией.
Здравствуйте, FR, Вы писали:
КЛ>>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
FR>По моему скорее наоборот.
Что ты имеешь сказать, ООА и ООД круто, но классы, наследование, полиморфизм — гнусь ?
Материал из Википедии — свободной энциклопедии, -_*
Какой, к чертям, провал ? За последние 10 лет количество девелоперов выросло примерно в 100 раз. Если раньше это были высокоуровневые профессионалы, то сейчас девелоперы это школота которая нахваталась технологий. В среднем конечно же. Технологии вроде .Net, Java несут программирование в массы, которые необученые, неграмотные, неинтересующиеся, немотивированые.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий.
А что по твоему first class sitizen ? Если "никак", то очевидно и ФП нет.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает.
Замыкания — обязательное условие. "их отсутствие ограничивает". Сравни first class sitizen по аналогии с ООП, сразу станет ясно.
>Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
СТЛ это только стиль, не более того.
ВВ>ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно. ФП есть все же вид декларативного программирования и вот с этим в ДжаваСкрипте тухло как-то. С т.з. выразительности и удобства написания функционального кода этот язык сосет по сравнению с каким-нибудь OCaml. И несмотря на то, что базовые механизмы есть, когда пишешь на ДжаваСкрипте функциональную программу не покидает чувство, что занимаешься по-прежнему имитацией настоящего ФЯ.
Сосёт. Имитация.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, IT, Вы писали:
IT>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
Дык в таком виде ООП существует только в нескольких маргинальных языках (Скала, Немерле, Питон, Руби). В остальных доминирует та или иная парадигма. Достаточно взглянуть на С++ или Яву (в меньшей мере Шарп). Там явно доминирует ООП. В Лиспе (который я сначала вписал в списко гибридов) все же доминирует ФП и МП. ООП там есть, но он там настолько своеобразный, что используется не часто.
А доклад, между прочем, делался 10 лет назад. В это время даже Руби с Питоном не были популярны. А уж Немерла и Скалы вообще не было.
Так что в принципе если судить по мэйнстриму, то ФП и ООП — это два разных мира.
Плюс если смотреть на программирование как на набор полезных практик, то преимущества ООП несомненно доступны и в процедурных языках. Чтобы далеко не ходить вспомним Win API. Это же принципы ООП реализованные в процедурном языке (Си).
А так, да ООП, ФП и даже МП отлично уживаются в одном языке. И мы все знаем как он называется.
Хотя причем тут...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Дык, сформулируй нам в чем это противоречие?
Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП. VD>Дык, сформулируй нам в чем это противоречие?
То, что мог я сформулировал в ответах Синклеру. Если вкратце, то обсуждаемую тему можно свести к следующему: каковы отличия ООП и ФП при *моделировании* и, в частности, в чем кардинальное отличие между функцией в ФП и классом в ООП. Моя мысль, что классы в ООП by design инкапсулируют изменяемое состояние. Функции в ФП — by design стараются этого избежать.
Если вкратце — то на основе чего в ООП программе мы решаем, что должно быть включено в класс? Собственно, класс есть некая единая сущность, не просто же определенный набор атрибутов и функций. Очевидно, что предполагается определенная связь между членами класса. Но какая? Представим, что мы сотворили такое:
class Math {
int Sum();
int FirstOperand;
int SecondOperand;
}
Связь вроде присутствует, т.е. очевидно, что Sum зависит от полей FirstOperand и SecondOperand — абсолютно так же, как и функция sum(x, y) зависит от своих операндов. Но на класс это не тянет, тянет на бред.
А чего не хватает?
Ни FirstOperand, ни SecondOperand не являются тем, что мы привыкли называть "состоянием класса". Эти поля используются лишь в момент работы функции Sum — в этом плане их перенос в поля абсолютно бессмысленен. Результаты работы Sum также никак не влияет на эти поля.
Не хватает, как мне кажется, *взаимо*связи между полями и функциями класса, их как бы взаимной детерминированности. Сравни с этим:
class Car {
int Drive();
int Gas;
}
Вот это уже больше похоже на класс. Drive зависит от поля Gas (на пустом баке далеко не уедешь), но и Gas зависит от Drive (бензин-то кончается). И вот пожалуйста — получаем изменяемое состояние, которое несет в себе класс.
В ФП безусловно есть такие же шутки, но обычно ФП пытается такого программирования избежать. Т.е. в ФП бы я создал скорее универсальную функцию Drive принимающую кол-во бензина и возвращающую расстроение, которое мы проехали и кол-во оставшегося бензина. В ООП же у меня получается так, что каждый экземпляр класса Car есть как бы конкретный автомобиль со своими индивидуальными, так сказать, характеристиками.
Можешь почитать ответы Синклеру, я там объясняю более подробно.
Ну вот и получается, что у нас просто-напросто разное моделирование в ООП и ФП.
VD>Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
Об этом речи нет, как-то ты утрируешь. Речь о том, что последовательный дизайн приложения в ООП-стиле и дизайн в ФП-стиле идут разными путями.
Здравствуйте, VladD2, Вы писали:
VD>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
Не любую
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, -_*, Вы писали:
VD>>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
-_*>Не любую
Например?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
VD>-_*>Не любую
VD>Например?
Например язык вида 0000011111 не распознается КА, т.к. КА не обладает полнотой по Тюрингу.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, VladD2, Вы писали:
VD>Дык нам никто не запрещает использовать циклы и даже if-ы с goto. Важен сам принцип решения проблемы — без абстракций.
Это я специально потроллил, по привычке, что бы извлечь из тебя толковую формулировку.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Lloyd, Вы писали:
VD>>А что не так с этим могучим языком?
L>Его нельзя задать регулярной грамматикой, которые эквивалентны конечным автоматам. L>Регулярная грамматика
Я всего лишь наступил ему на язык а про полноту он не может не знать.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, VladD2, Вы писали:
VD>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
(ReaderFunc, byte[]) ReaderFunc(int length);
Не?
VD>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
Не только. Есть, как минимум, экземпляры функторов, которые содержат в себе аргументы. Ну и замыкания. Правда, Василий считает, что замыкания толи с ФП несовместимы, толи еще что.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
И как этим открыть файл и прочесть его содержимое (скажем первые 100 байт)?
VD>>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открытой структуры с тучей полей или в виде хэндла.
AVK>Не только. Есть, как минимум, экземпляры функторов, которые содержат в себе аргументы. Ну и замыкания.
Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.
Что до замыканий и прочего, то я повторяю свой вопрос. Что с хэндлами то делать?
Да и зачем вручную каждый раз создавать какие-то замыкания, когда можно один раз создать класс который и будет этим замыканием только с блэкджеком и шлюхами?
AVK>Правда, Василий считает, что замыкания толи с ФП несовместимы, толи еще что.
Этого я в его рассуждениях не заметил. Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
VD>>-_*>Например язык вида 0000011111 не распознается КА, т.к.
VD>>А что не так с этим могучим языком?
L>Его нельзя задать регулярной грамматикой,
Да, ну?! (хотя причем тут грамматики не ясно)
L>которые эквивалентны конечным автоматам. L>Регулярная грамматика
Вот регекс разбирающий ваш язык:
0000011111
Можете проверить его на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, -_*, Вы писали:
VD>>Дык нам никто не запрещает использовать циклы и даже if-ы с goto. Важен сам принцип решения проблемы — без абстракций.
-_*>Это я специально потроллил, по привычке, что бы извлечь из тебя толковую формулировку.
Меня уже Лойд подобными вещами достал (но он похоже это от чистого сердца делает, а не ради тролинга), так теперь еще и ты? Это какой-то заговор против розовых слоников. Где Грипис, а?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>А что не так с этим могучим языком?
L>>Его нельзя задать регулярной грамматикой,
VD>Да, ну?! (хотя причем тут грамматики не ясно)
См. ниже.
L>>которые эквивалентны конечным автоматам. L>>Регулярная грамматика
VD>Вот регекс разбирающий ваш язык: VD>
VD>0000011111
VD>
VD>Можете проверить его на практике.
Я думаю ты прекрасно понял, что имелось в виду. Если все-таки не понял, перейди по ссылке и прочти, что там написано.
Здравствуйте, VladD2, Вы писали:
VD>Общая задача. Функции работы с окнами логично поместить в класс "Окно", а функции работы с файлами в класс "Файл". Все же просто и очевидно. Это если не умничать и не идеологизировать ООП.
Я не идеологизирую. Но неужели у тебя нет никаких других критериев, по которым ты "распихиваешь" функции по классам? Просто мне кажется у тебя в таком случае класс выступает в виде этакого неймспейса для функций. "Все для работы с окном". "Все что нужно для ваших файлов". ООП — это что-то еще, не?
ВВ>>
ВВ>>class Math {
ВВ>> int Sum();
ВВ>> int FirstOperand;
ВВ>> int SecondOperand;
ВВ>>}
ВВ>>
VD>Даже страшно такое представлять .
VD>Конечно и такое бывает, но это ведь не лучший образчик ОО-ситиля, правда?
Это я приводил как пример того, что не является ООП-классом в принципе. Т.е. формально — да, класс. По сути — нет. Это, если хочешь, отправная точка для рассуждений.
Если ты считаешь это классом, просто "в плохом стиле" — то я тебе ничего объяснить не смогу. Ибо само понятие "ООП класс" у нас становится настолько широким, что оно ничему не может противоречить в принципе.
VD>Опять какая-то херня из бредовых учебников.
Я всего-лишь высказал мысль, что у нас возникает повод говорить об "ООП классе", когда в классе этим присутствует взаимная детерминированность его членов. Именно взаимная. Ты с этим не согласен? Может привести контр-пример?
VD>Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом. VD>Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
А зачем вводить "класс"? Что это даст? Может просто модуль File и накидать туда функций? В чем разница?
VD>Да ладно фантазировать про гипотетические кары и драйвы. VD>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
В функциональном языке у меня была бы структура "Файл", описывающая файл *в конкретный помент времени*. В ООП — просто структура "Файл".
VD>Что снова изобретем хэндл? О боги! Да это же старое доброе процедурное программирование! VD>А где же та замечательная завеса таинства что так привлекала многих в ФП? VD>Вот классы надо расстраивать как средство борьбы с хэндлами. Инкапсуляция — это оно и есть.
Иначе говоря, это что-то вроде туалета? Завернули, запрятали — и уже не страшно?
Не, я как бы согласен. Но вопрос прежний — почему "классы"? Такой вот "туалет" и в Си есть — там тоже можно завернуть, спрятать, инкапсулировать. Зачем мужики С++ придумали?
VD>У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково. VD>В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
Обладает что ли состоянием "внутри" или же это состояние у тебя будет "снаружи" (в чем собственно отличие ФП и ООП, не?) — ты решаешь сам. Здесь не существует каких-то объективных критериев для выбора. И вот выбор первого — это ООП выбор. Выбор второго — ФП выбор.
VD>Так вот я для себя сделал открытия. Не бывает ОО-дизайн или ФП-дизайн. А бывает хороший (красивый, удобный и т.п.) дизайн, и притянутый за уши. Когда преобразование А в Б пытаются оформить классом — это кривой дизайн, но все эти хэндлы — это точно такой же кривой дизайн.
Если два разных человека, которые а) имеют мозг и б) используют его, то у них получится разный дизайн. Есть огромное кол-во разных способов решить задачу, не только два, из них нельзя выбрать какой-то "более правильный" или "более красивый" способ.
VD>Состояние есть, его не может не быть! Это объективная реальность. Состояние опасно! Точнее опасно не оно, а то что человеческий мозг не может представить состояние во времени и то, что мы не имеем возможности взглянуть в прошлое. VD>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
Ну да, через стек, отлично. Только вот "объект", в котором ты будешь таскать это состояние, является единомоментным иммутабельным слепком этого состояния, т.е. это значения для конкретного момента времени. Сам по себе этот объект не будет иметь состояние, он будет лишь его описателем. В ООП же такой объект именно что несет в себе состояние.
AVK>>Не?
VD>И как этим открыть файл и прочесть его содержимое (скажем первые 100 байт)?
var (rest, buffer) = OpenFile(...)(100);
var (nextRest, nextBuffer) = rest(...)(100);
...
Как то так.
VD>Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.
Если мы делаем карринг, значение аргументов хранится не в стеке.
VD>Да и зачем вручную каждый раз создавать какие-то замыкания, когда можно один раз создать класс который и будет этим замыканием только с блэкджеком и шлюхами?
Это не ко мне вопрос. Я точно так же не смог добится никакого вразумительного объяснения, чем все таки ФП с ООП не совместимо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD> Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой.
Я бы не идеализировал этот факт. По крайней мере, что такое ООП он точно не очень уверенно понимает. =)
AVK>>Не?
LP>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
Просто уровень инкапсуляции ниже — только функция, а завязаться на реализацию даже еще сложнее, чем в ООП.
LP>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
LP>Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Здравствуйте, LaPerouse, Вы писали:
LP>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
Можно раскрыть мысль?
LP> Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).
LP> Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Про преклонение это какие то странные фантазии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>>>Не?
LP>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>Просто уровень инкапсуляции ниже — только функция,
В этом примере нету инкапсуляции — голый byte[] на выходе.
L>а завязаться на реализацию даже еще сложнее, чем в ООП.
Почему сложнее? Где пример правильной реализации этой функции на ФЯ?
LP>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. L>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>>Просто уровень инкапсуляции ниже — только функция, LP>В этом примере нету инкапсуляции — голый byte[] на выходе.
Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
LP>>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>>>Просто уровень инкапсуляции ниже — только функция, LP>>В этом примере нету инкапсуляции — голый byte[] на выходе. C>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
AVK>Можно раскрыть мысль?
Смотри сообщение выше.
LP>> Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. AVK>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).
Что такое декларативность? Меня всегда восхищал этот термин.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, LaPerouse, Вы писали:
LP>>>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>>>>Просто уровень инкапсуляции ниже — только функция, LP>>>В этом примере нету инкапсуляции — голый byte[] на выходе. C>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
LP>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
*asByteArray()
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
C>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls. LP>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP.
Здравствуйте, LaPerouse, Вы писали:
AVK>>Можно раскрыть мысль?
LP>Смотри сообщение выше.
Смотрел. Мысль не понял.
AVK>>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).
LP>Что такое декларативность? Меня всегда восхищал этот термин.
Декларативное описание отвечает на вопрос "что", императивное "как".
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуй процедурное императивное программирование, завернутое в монаду IO! VD>Монада нужна только потому, что Хаскель ленивый язык. Для остальных ФЯ мы получим банальный C API времен Кернигана и Ричи.
Как будто с использованием ООП мы в этом случае получим что-то большее. Будет ровно тоже самое. Притом используя те же модули
ML например код практически будет идентичным с ООП.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
C>>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls. LP>>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива). C>А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP.
Разумеется, в данном конкретном случае логично иметь один интерфейс BinaryStream, а указанные тобой представления должны получаться из BinaryStream в каком-нибудь хелпере. Я же совсем не про это говорил. А говорил я про скрытие используемых структур данных за интерфейсами. Насколько я понимаю, такой стиль кодирования в ФП не в почете.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали: AVK>>>Можно раскрыть мысль? LP>>Смотри сообщение выше. AVK>Смотрел. Мысль не понял.
Завязка на конкретную структуру данных (массив).
AVK>>>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект). LP>>Что такое декларативность? Меня всегда восхищал этот термин. AVK>Декларативное описание отвечает на вопрос "что", императивное "как".
Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами. Вот логическое программирование — там и в самом деле "как".
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
AVK>Да, чтобы не было недопонимания. То, что я показал, это баловство и извращение на тему. В реальном функциональном коде для этого используют монады. Выглядит это как то так: AVK>
AVK>var data =
AVK> OpenFile(...)
AVK> .Take(100)
AVK> .ToArray();
AVK>
AVK>Если нужна асинхронность, то тоже берем continuation монаду (Rx), либо фьючерс (PLinq), которые с ФП вполне совместимы.
Ну кто бы сомневался. Как всегда, без монады — никуда.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
AVK>>Смотрел. Мысль не понял.
LP>Завязка на конкретную структуру данных (массив).
Хм, а как иначе? Приведи пример.
AVK>>Декларативное описание отвечает на вопрос "что", императивное "как".
LP>Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами.
ФП — является в основном, а ООП вообще ортогонально, как я уже писал.
LP> Вот логическое программирование — там и в самом деле "как".
Знаешь, вот лично я к адептам единственно правильной парадигмы отношусь с очень большим подозрением. Не надо опять заводить тягомотину про всемирную коммунистическую базу знаний.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
-_*>Здравствуйте, LaPerouse, Вы писали: LP>>>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. L>>>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь? LP>>Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.
-_*>Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано
Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
AVK>>>Смотрел. Мысль не понял. LP>>Завязка на конкретную структуру данных (массив). AVK>Хм, а как иначе? Приведи пример.
Функция должна иметь в качестве возвращаемого значения универсальный интерфейс для доступа к потоку бинарных данных, а не хардкорный массив.
AVK>>>Декларативное описание отвечает на вопрос "что", императивное "как". LP>>Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами. AVK>ФП — является в основном, а ООП вообще ортогонально, как я уже писал. LP>> Вот логическое программирование — там и в самом деле "как". AVK>Знаешь, вот лично я к адептам единственно правильной парадигмы отношусь с очень большим подозрением. Не надо опять заводить тягомотину про всемирную коммунистическую базу знаний.
И не собираюсь. С чего ты взял, что я призываю использовать логическое программирование? Я к нему отношусь почти так же отрицательно, как к ФП. Просто оно в отличие от последнего на самом деле декларативно.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Функция должна иметь в качестве возвращаемого значения универсальный интерфейс для доступа к потоку бинарных данных
Какому потоку? Массив байтов это уже считанный из потока результат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, LaPerouse, Вы писали:
LP>-_*>Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано
LP>Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.
"немного" Функтор может модифицировать кто угодно. Замыкание — легальных способов практически нет. Следовательно функтор держится исключительно на честном слове.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали: LP>>Функция должна иметь в качестве возвращаемого значения универсальный интерфейс для доступа к потоку бинарных данных AVK>Какому потоку? Массив байтов это уже считанный из потока результат.
Здравствуйте, LaPerouse, Вы писали:
C>>А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP. LP>Разумеется, в данном конкретном случае логично иметь один интерфейс BinaryStream, а указанные тобой представления должны получаться из BinaryStream в каком-нибудь хелпере.
Мимо. BinaryStream подразумевает потоковое чтение, а не произвольный доступ. Тебе нужно контейнер, заточенный на произвольный доступ/изменение и не поддерживающий произвольное увеличение/уменьшение размера.
Это получается... э... массив байт.
LP>Я же совсем не про это говорил. А говорил я про скрытие используемых структур данных за интерфейсами. Насколько я понимаю, такой стиль кодирования в ФП не в почете.
Ибо нафиг он не нужен в 95% случаев. А для остальных 5% можно использовать и этот ваш полиморфизм с интерфейсами.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что с ООП у него тоже все довольно не плохо.
Не хорошо, я проверял.. =))
VD> Инкапсуляция и полиморфизм не есть изобретения или достоинства только лишь ООП. Они достижимы где угодно. Наследование вообще спорная вещь. Тот же АВК не раз говорил о его вреде в ряде случаев. Вот и рождаются сомнения в умах.
Это все верно, но сомнения рождаются от недопонимания...
Здравствуйте, LaPerouse, Вы писали:
LP>Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.
Здравствуйте, LaPerouse, Вы писали:
LP>Попытка почти любого практического применения функциональных языков оканчивается использованием монады IO, которая сама по себе императивна до безобразия.
Функциональные языки не ставят свой целью полностью исключить императив. У них цель гораздо более скромная изолировать его с целью минимизировать
связанные с ним ненадежность и непредсказуемость.
Здравствуйте, VladD2, Вы писали:
FR>>Как будто с использованием ООП мы в этом случае получим что-то большее. Будет ровно тоже самое. Притом используя те же модули ML например код практически будет идентичным с ООП.
VD>Конечно получим больше. Мы получим возможность не заморачиваясь писать то что мы хотим так как мы хотим.
Для тех же файлов и подобных вещей решаемых в процедурном программировании использованием абстрактных типов данных никаких преимуществ
не получим. Даже сахар не существенный.
Здравствуйте, FR, Вы писали:
FR>Для тех же файлов и подобных вещей решаемых в процедурном программировании использованием абстрактных типов данных никаких преимуществ FR>не получим. Даже сахар не существенный.
Не надо с умным видом говорить глупости. Прочти в вики определение абстрактных типов данных и ты поймешь, что как раз классы — это они и есть, только с блэкджеком и шлюхами, а вот в С таких средств вообще нет. Так что в С придется поплясать с бубном чтобы добиться того же результата.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не надо с умным видом говорить глупости. Прочти в вики определение абстрактных типов данных и ты поймешь, что как раз классы — это они и есть, только с блэкджеком и шлюхами, а вот в С таких средств вообще нет. Так что в С придется поплясать с бубном чтобы добиться того же результата.
С просто плохой процедурный язык, практически не поддерживает модульность. В языках с хорошей модульностью никаких плясок нет.
Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине
использует АТД начинается крик что это объекты. Это не объекты.
Здравствуйте, FR, Вы писали:
FR>С просто плохой процедурный язык, практически не поддерживает модульность.
Да ладно тебе. С модульностью у него все ОК. Его проблемы — это прероцессор и плохой контроль за типами.
FR>В языках с хорошей модульностью никаких плясок нет.
Да ну? Хаскель обладает "хорошей модульностью"?
FR>Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине использует АТД начинается крик что это объекты. Это не объекты.
Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
В прочем, кому я это все рассказываю? Ты ведь у нас пишешь на Питоне и С++, так? Тебе ли всего этого не знать? Даже в ОКамле объекты не лишние. Хотя казалось бы язык сначала функциональный и только потом немного объектно-ориентированный. Согласен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да ладно тебе. С модульностью у него все ОК. Его проблемы — это прероцессор и плохой контроль за типами.
В языке вообще нет модульности, компиляторы да с грехом пополам ее обеспечивают.
В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
FR>>В языках с хорошей модульностью никаких плясок нет.
VD>Да ну? Хаскель обладает "хорошей модульностью"?
Наверно, я не знаток Хаскеля.
FR>>Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине использует АТД начинается крик что это объекты. Это не объекты.
VD>Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
Я тоже так думаю, но я думаю что и нормальные модули такая же отличная штука.
VD>В прочем, кому я это все рассказываю? Ты ведь у нас пишешь на Питоне и С++, так? Тебе ли всего этого не знать? Даже в ОКамле объекты не лишние. Хотя казалось бы язык сначала функциональный и только потом немного объектно-ориентированный. Согласен?
Конечно, но в OCaml давняя традиция не пользоваться объектами
Вот эту фразу не понял:
“Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой."
Может нам не ту математику преподавали, но вроде как в матемаике (например геометрии) все начинают с аксиом а уж потом даказательства разных теорем вытекают из аксиом.
Здравствуйте, FR, Вы писали:
FR>В языке вообще нет модульности, компиляторы да с грехом пополам ее обеспечивают.
Ты же на С++ пишешь!
Модульность обеспечивается за счет директив extern и typedef-ов.
Раздельная компиляция, объектники и т.п., если не ошибаюсь прописаны в стандарте.
FR>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
Что убили?
VD>>Да ну? Хаскель обладает "хорошей модульностью"?
FR>Наверно, я не знаток Хаскеля.
Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
Единственное преимущество — это более удобные модули.
VD>>Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
FR>Я тоже так думаю,
Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
FR>но я думаю что и нормальные модули такая же отличная штука.
А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты же на С++ пишешь! VD>Модульность обеспечивается за счет директив extern и typedef-ов. VD>Раздельная компиляция, объектники и т.п., если не ошибаюсь прописаны в стандарте.
Угу, только эта фигня не обеспечивает нормальной модульности. Все вручную, турбо паскаль
и тот лучше.
FR>>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
VD>Что убили?
Application binary interface.
Я вот сейчас часто делаю dll на VC которые должны вызываться и из C++ Builder, интерфейс
приходится делать сишный.
FR>>Наверно, я не знаток Хаскеля.
VD>Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
И что в этом плохого?
В OCaml в общем также, но писать в этом стиле удобнее и проще чем на Си, модули (даже без функторов) рулят.
VD>Единственное преимущество — это более удобные модули.
Этого вполне достаточно для АТД.
FR>>Я тоже так думаю,
VD>Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
Я и не спорю, просто не разделяю твоего мнения (может неправильно понял) что только объекты хороши для АТД.
VD>А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
В OCaml и вообще в ML семействе хорошие.
В питон — руби, паскаль — дельфи и по слухам и в modula, ada и oberon вполне нормальные.
Здравствуйте, deimos, Вы писали:
D>Вот эту фразу не понял: D>“Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой."
D>Может нам не ту математику преподавали, но вроде как в матемаике (например геометрии) все начинают с аксиом а уж потом даказательства разных теорем вытекают из аксиом.
В школе — да. Но если ты захочешь родить раздел математики, то тебе придется _найди_ базис. В ООП вобщем то тоже так — реально никто не начинает городить классы. Не ясно, что автор имел ввиду.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, FR, Вы писали:
FR>Угу, только эта фигня не обеспечивает нормальной модульности. Все вручную, турбо паскаль FR>и тот лучше.
Оно обеспечивает такую же "нормальную" модульность, как и большинство других не ООЯ.
Другое дело, что там других проблем хватает. Но уже устал это обсуждать.
FR>>>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
VD>>Что убили?
FR>Application binary interface. FR>Я вот сейчас часто делаю dll на VC которые должны вызываться и из C++ Builder, интерфейс FR>приходится делать сишный.
Байнари в С небыло никогда. Это как раз соглашения негласные. А что до переименования, то таки — да, только через С. Спасибо Страуструпу за точ, что он в угоду совместимости со старыми сишными линкерами заложил в язык такую баяку.
VD>>Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
FR>И что в этом плохого?
А ты напиши такую библиотеку и узнаешь.
VD>>Единственное преимущество — это более удобные модули.
FR>Этого вполне достаточно для АТД.
Нет. Это только обеспечивает часть механизма абстрагирования. Причем при этом абстрагирование становится паттерном, а не фичей языка. Что и есть большой минус в сравнении с классами.
FR>>>Я тоже так думаю,
VD>>Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
FR>Я и не спорю, просто не разделяю твоего мнения (может неправильно понял) что только объекты хороши для АТД.
Я не говорил "только". Я говорил, что объекты (точнее классы) хороши. Просто модули, даже очень хорошие все равно вынуждают применять паттерн так хорошо известный по С. А паттерн — это набор действий который нужно постоянно повторять, плюс возможность допустить ошибку. Класс же описывает АТД за один прием и без приседаний.
VD>>А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
FR>В OCaml и вообще в ML семействе хорошие. FR>В питон — руби, паскаль — дельфи и по слухам и в modula, ada и oberon вполне нормальные.
Да ладно. Не гони. Все это не обеспечивает того удобства что обеспечивают классы. Возможно на счет АДЫ я не прав. В остальных же языках или надо танцевать с бубном, или есть те же классы которые решают задачу прямо и удобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Оно обеспечивает такую же "нормальную" модульность, как и большинство других не ООЯ.
Гораздо хуже, особенно си.
VD>Байнари в С небыло никогда. Это как раз соглашения негласные. А что до переименования, то таки — да, только через С. Спасибо Страуструпу за точ, что он в угоду совместимости со старыми сишными линкерами заложил в язык такую баяку.
Так в си хоть и неформальное соглашения, но его придерживаются все производители OS и компиляторов (куда денешься если хочешь вызывать
системные функции ), в C++ его вообще нет.
VD>А ты напиши такую библиотеку и узнаешь.
Неоднократно писал и на C/C++ и недавно на OCaml.
Писать такое:
module Dir : sig
type handle
val _open: utf8 -> handle
val _close: handle -> unit
val _read: handle -> DirData.t
end
Не сложнее чем класс.
VD>Нет. Это только обеспечивает часть механизма абстрагирования. Причем при этом абстрагирование становится паттерном, а не фичей языка. Что и есть большой минус в сравнении с классами.
Паттерн, да, но в языках с нормальной модульностью элементарный.
VD>Я не говорил "только". Я говорил, что объекты (точнее классы) хороши. Просто модули, даже очень хорошие все равно вынуждают применять паттерн так хорошо известный по С. А паттерн — это набор действий который нужно постоянно повторять, плюс возможность допустить ошибку. Класс же описывает АТД за один прием и без приседаний.
Хорошие модули также за один прием. Плюс в тех же модулях OCaml есть приватные и фантомные типы, плюс возможность параметризации, это с избытком покрывает АТД.
VD>Да ладно. Не гони. Все это не обеспечивает того удобства что обеспечивают классы. Возможно на счет АДЫ я не прав. В остальных же языках или надо танцевать с бубном, или есть те же классы которые решают задачу прямо и удобно.
В ML семействе обеспечивают. Трудности появляются только когда нужен полиморфизм в рантайме.
В новой версии OCaml (3.12) уже и в рантайме все нормально, модули стали первоклассными сущностями http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc81 можно завести модульную переменную
например.
Здравствуйте, VladD2, Вы писали:
VD>На С++ то зачем такое писать?
Был нужен сишный интерфейс, ну и проще было так сразу писать, хотя внутри даже буст и STL были
FR>>Не сложнее чем класс.
VD>Все же посложнее. Особенно если сравнивать с организацией классов с ява-подобных языках, где не надо отделять описание интерфейса от реализации.
Здесь тоже можно не отделять, особенно для чисто внутренних модулей.
VD>"Dir." здесь совершенно лишний. Можно конечно "открыть тип", если язык это позволяет, но там уже не факт что не пойдут конфликты имен и т.п.
VD>Конечно, можно и тут по приседать, но это паттерны которые нужно соблюдать. А ООЯ — это язык в которые эти паттерны уже зашиты.
VD>В общем, я не утверждаю, что в не-ООЯ нельзя достичь того же, но все же придется делать много лишних приседаний. А зачем? Только от нелюбви к ООП?
Не вижу много лишних приседаний.
FR>>Паттерн, да, но в языках с нормальной модульностью элементарный.
VD>Дык проблемы они имеют свойство накапливаться. Например, автокомплит в точечной нотации удобнее получается, связанное использование (x.y.z). По мелочи... там неудобно... тут надо последовательность действий соблюдать... в итоге получается довольно неудобно и это только от того, что мы просто из необъяснимых соображений неприемлем ООП.
Автокомплит по тем же модулям например в OCAIde отлично работает.
Да нет практически никаких неудобств. Вон в яве/шарпе чтобы получить свободные функции приходится ненужный класс например описывать,
здесь неудобств даже меньше.
FR>>Хорошие модули также за один прием.
VD>Нет. Тебе нужно знать о наличии той самой концепции АТД и выдерживать ее каноны. В общем, я повторяюсь в сотый раз.
Если ты не знаешь этого, то даже в языке с классами ничего написать не сможешь.
FR>>Плюс в тех же модулях OCaml есть приватные и фантомные типы, плюс возможность параметризации, это с избытком покрывает АТД.
VD>Это все кирпичи для их создания. Но не они сами. VD>Но в OCaml то как раз есть и классы, которые делаю там АТД, а за одно обеспечивают и другие прелести, в один присест.
Есть, но АТД принято описывать модулями.
FR>>В ML семействе обеспечивают. Трудности появляются только когда нужен полиморфизм в рантайме.
VD>Ну, а этого мало?
Для АТД это не нужно. Там где нужно конечно объекты удобней.
FR>>В новой версии OCaml (3.12) уже и в рантайме все нормально, модули стали первоклассными сущностями FR>>http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc81 можно завести модульную переменную FR>>например.
VD>Здорово конечно, но а) слишком сложно, б) зачем все это нужно если есть классы?
Да вроде ничего сложного, особенно как разберешься с функторами.
А так наверно привычки авторов и пользователей языка.
VD>Ну, на фиг мне вообще манипулировать понятиями модуль, хэндл и т.п., если я могу оперировать понятиями класс и объект?
Ну тебе не надо, мне в общем пофигу, а вот ядреным камлистам почем-то модули больше по душе
Здравствуйте, FR, Вы писали:
VD>>"Dir." здесь совершенно лишний. Можно конечно "открыть тип", если язык это позволяет, но там уже не факт что не пойдут конфликты имен и т.п.
FR>Да можно открыть тип, в последней версии OCaml есть и локальный open http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc77 он же доступен FR>для более старых версий как camlp4 расширение.
А что делать если кроме Dir в этом же месте надо использовать и, к примеру, File? Опять модульные префиксы использовать?
А ради чего? Чтобы без ООП?
VD>>Конечно, можно и тут по приседать, но это паттерны которые нужно соблюдать. А ООЯ — это язык в которые эти паттерны уже зашиты.
VD>>В общем, я не утверждаю, что в не-ООЯ нельзя достичь того же, но все же придется делать много лишних приседаний. А зачем? Только от нелюбви к ООП?
FR>Не вижу много лишних приседаний.
А не важно много или не очень много. Важно что они есть, а можно обойтись без них. Причем платой за то является всего лишь принятие не такого уж и страшного слова ООП.
Считай что ООП — это такая идеальная система модулей позволяющая создавать их экземпляры и поддерживающая динамический полиморфизм.
FR>Автокомплит по тем же модулям например в OCAIde отлично работает.
А мне не нужно по модулям. Мне нужно по хэндлам которые у вас вместо объектов используются.
Хотя о чем я? У каких у "вас"? Ты сам в реальной работе классы используешь, а сюда так поторолить и поупражняться в софистике зашел. Правда?
FR>Для АТД это не нужно. Там где нужно конечно объекты удобней.
Да они по любому удобнее. Как минимум не нужна лишняя абстракция.
Сам же говоришь, что в последних версиях ОКамла модули довели почти до уровня классов.
Но ведь это маразм для языка где все это уже было с самого начала.
FR>А так наверно привычки авторов и пользователей языка.
Это привычки неондертальцев которые так и не смогли принять огонь и медный топор. Борются с ООП в ООЯ ради никому не ясных идей.
FR>Ну тебе не надо, мне в общем пофигу, а вот ядреным камлистам почем-то модули больше по душе
Во-во. Маньяки они. Они видимо считают, что если делать ООП через ухо, то оно от этого ООП-ом являться не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>А что делать если кроме Dir в этом же месте надо использовать и, к примеру, File? Опять модульные префиксы использовать?
Модули вкладываются, хотя конечно возможны пересечения.
VD>А ради чего? Чтобы без ООП?
Конечно.
VD>А не важно много или не очень много. Важно что они есть, а можно обойтись без них. Причем платой за то является всего лишь принятие не такого уж и страшного слова ООП.
VD>Считай что ООП — это такая идеальная система модулей позволяющая создавать их экземпляры и поддерживающая динамический полиморфизм.
Не идеальная, даже параметризованные шаблонами классы C++ не обеспечивают всей функциональностей которые дают модули + функторы OCaml.
Ну и как прикол классы OCaml всю эту функциональность обеспечивают
VD>А мне не нужно по модулям. Мне нужно по хэндлам которые у вас вместо объектов используются. VD>Хотя о чем я? У каких у "вас"? Ты сам в реальной работе классы используешь, а сюда так поторолить и поупражняться в софистике зашел. Правда?
Нет ты неправ, я стараюсь писать так как принято в OCaml. Поэтому классов практически не использую, за редкими исключениями,
например те кто писали кодогенератор под OCaml для Thrift не совсем разобрались
в традициях и вместо генерации модулей и функторов сделали классы, как и для других ОО языков, при работе с ним конечно никуда не
денешься.
Но вообще есть планы попробовать писать на OCaml в ОО стиле, там все-таки не очень обычное ОО, просто интересно что получится.
VD>Да они по любому удобнее. Как минимум не нужна лишняя абстракция. VD>Сам же говоришь, что в последних версиях ОКамла модули довели почти до уровня классов.
Угу, в некторых версиях SML это уже давно было, но у них нет объектов.
VD>Но ведь это маразм для языка где все это уже было с самого начала.
Есть несколько причин.
Первая традиция, Caml, как диалект ml и без объектов просуществовал около 10 лет.
Вторая модули быстрее, там многое делается в compile time, плюс объекты медленнее так как у них есть оверхед на вызов
метода из-за структурной типизации, требующей поиска метода в рантайме.
Третья модули, функторы, сигнатуры растут из алгебраических структур и идейно ближе функциональщикам чем объекты
VD>Это привычки неондертальцев которые так и не смогли принять огонь и медный топор. Борются с ООП в ООЯ ради никому не ясных идей.
Ну на данном этапе как раз ООП медленно занимает место неандертальцев. Ты неправ ни с чем они не борются просто язык достаточно
выразителен чтобы во многом обходится без ООП, они его просто не замечают.
FR>>Ну тебе не надо, мне в общем пофигу, а вот ядреным камлистам почем-то модули больше по душе
VD>Во-во. Маньяки они. Они видимо считают, что если делать ООП через ухо, то оно от этого ООП-ом являться не будет.
Нет просто ООП присвоило себе то что раньше и без него прекрасно делали.
Здравствуйте, FR, Вы писали:
FR>Модули вкладываются, хотя конечно возможны пересечения.
Причем тут "вкладываются"? Речь идет об открытии в одной области видимости двух модулей содержащих одинаковые имена.
Для ОКамла — это вообще "приплызд".
VD>>А ради чего? Чтобы без ООП?
FR>Конечно.
То есть — "назло маме отморожу уши"?
VD>>Считай что ООП — это такая идеальная система модулей позволяющая создавать их экземпляры и поддерживающая динамический полиморфизм.
FR>Не идеальная, даже параметризованные шаблонами классы C++ не обеспечивают всей функциональностей которые дают модули + функторы OCaml.
Да полно гнать то. Можно примеры этой мега-крутости?
FR>Ну и как прикол классы OCaml всю эту функциональность обеспечивают
Это случаем не противоречит предыдущему утверждению?
VD>>А мне не нужно по модулям. Мне нужно по хэндлам которые у вас вместо объектов используются. VD>>Хотя о чем я? У каких у "вас"? Ты сам в реальной работе классы используешь, а сюда так поторолить и поупражняться в софистике зашел. Правда?
FR>Нет ты неправ, я стараюсь писать так как принято в OCaml. Поэтому классов практически не использую,
А когда на С++ пишешь, или на Питоне?
Стало быть все же назло маме?
FR>Но вообще есть планы попробовать писать на OCaml в ОО стиле, там все-таки не очень обычное ОО, просто интересно что получится.
Может дело в том, что там ОО просто недоделанный?
Я не раз об этом слышал. Вроде как проблемы с up cast-ом и с виртуальностью вроде бы не все замечательно. Хотя сам я в этом не очень то разбирался. В F# с ООП почти все ОК (почти, потому что модификаторы доступа таки эти умники не прикрутили).
FR>Угу, в некторых версиях SML это уже давно было, но у них нет объектов.
Но классами конечно не назвали из политических соображений?
Вопрос риторический.
Ну, а тогда это никак не противоречит моим исходным словам, так как, если нам нужны не шашечки, а ехать, то это и есть обледенение сильных сторон ООП и ФП в одном флаконе.
FR>Первая традиция, Caml, как диалект ml и без объектов просуществовал около 10 лет.
И что? Зачем было тогда новый язык создавать?
FR>Вторая модули быстрее,
Это вопрос реализации, а не принципиальный вопрос. За 10 лет можно было бы и поправить.
FR>Третья модули, функторы, сигнатуры растут из алгебраических структур и идейно ближе функциональщикам чем объекты
Еще рез говорю — не гони. Модули растут из структурного программирования. Сигнатуры из статической типизации.
FR>Ну на данном этапе как раз ООП медленно занимает место неандертальцев.
Не смешите мои тапочки! Это ФП робенько пытается пролезть на рынок который давно занят ООП-ом.
У тебя уже полный отрыв от реальности пошел.
FR>Ты неправ ни с чем они не борются просто язык достаточно выразителен чтобы во многом обходится без ООП, они его просто не замечают.
Такое язык не должен существовать. Если фичи есть, то они должны использоваться.
FR>Нет просто ООП присвоило себе то что раньше и без него прекрасно делали.
Да никто ничего не присваивал. Просто в ООП инкапсуляция и динамический полиморфизм доведен до промышленного уровня (доступного для применении в массовом порядке), под ООП подведена понятная людям база, написано море очень доходчивых учебников, сделано куча реализаций. А ФП большую част времени развивалось даже не фриками, а консервативными около-научными кругами которые только сейчас дорастают до того, что все приняли и взяли на вооружение еще в начале 80-ых годов.
Больше же всего меня в этой ситуации радует то, что ООП и ФП разделился на непримиримые лагеря хотя по сути это всего лишь принципы программирования органично дополняющие друг-друга.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Причем тут "вкладываются"? Речь идет об открытии в одной области видимости двух модулей содержащих одинаковые имена. VD>Для ОКамла — это вообще "приплызд".
Никаких приплыздов просто последний open перекрывает, ну и все всегда доступно через <имя модуля>.<функция>
VD>То есть — "назло маме отморожу уши"?
Когда появился ML ОО было маргинальным. Так что это опять присваивание ООП'щиками всех достижений которые были до них.
FR>>Не идеальная, даже параметризованные шаблонами классы C++ не обеспечивают всей функциональностей которые дают модули + функторы OCaml.
VD>Да полно гнать то. Можно примеры этой мега-крутости?
Я уже несколько раз приводил тебе и описывал ML модули здесь, как-то поднадоело.
Кратко если бы в новом стандарте С++ не отменили концепты получили бы близкие возможности.
FR>>Ну и как прикол классы OCaml всю эту функциональность обеспечивают
VD>Это случаем не противоречит предыдущему утверждению?
Нет просто объекты в OCaml по сути многое унаследовали от модулей и структур.
Ну и появились гораздо позже их.
FR>>Нет ты неправ, я стараюсь писать так как принято в OCaml. Поэтому классов практически не использую,
VD>А когда на С++ пишешь, или на Питоне?
Тогда я стараюсь делать так как принято в них, но тоже ОО не злоупотребляю.
VD>Стало быть все же назло маме?
Нет, так как принято в данной среде. Влад ты же уже начинаешь свой любимый парадокс демонстрировать
FR>>Но вообще есть планы попробовать писать на OCaml в ОО стиле, там все-таки не очень обычное ОО, просто интересно что получится.
VD>Может дело в том, что там ОО просто недоделанный?
Нет он просто не майнстримный.
VD>Я не раз об этом слышал. Вроде как проблемы с up cast-ом и с виртуальностью вроде бы не все замечательно. Хотя сам я в этом не очень то разбирался. В F# с ООП почти все ОК (почти, потому что модификаторы доступа таки эти умники не прикрутили).
Там есть проблемы, но не из-за плохого ОО, а из-за чрезмерно жесткой статической типизации OCaml'а.
VD>Но классами конечно не назвали из политических соображений? VD>Вопрос риторический.
Нет модули ML появились раньше чем майнстримный ОО.
VD>Ну, а тогда это никак не противоречит моим исходным словам, так как, если нам нужны не шашечки, а ехать, то это и есть обледенение сильных сторон ООП и ФП в одном флаконе.
Дело в том что ехать вполне комфортно и без ОО прицепа
FR>>Первая традиция, Caml, как диалект ml и без объектов просуществовал около 10 лет.
VD>И что? Зачем было тогда новый язык создавать?
Как гласит байка чтобы один из создателей языка смог защитить диссертацию
FR>>Вторая модули быстрее,
VD>Это вопрос реализации, а не принципиальный вопрос. За 10 лет можно было бы и поправить.
Не совсем, модули обеспечивают как раз в силу своей большей ограниченности большие возможности для оптимизации,
особенно при работе с иммутабельными типами.
FR>>Третья модули, функторы, сигнатуры растут из алгебраических структур и идейно ближе функциональщикам чем объекты
VD>Еще рез говорю — не гони. Модули растут из структурного программирования. Сигнатуры из статической типизации.
Влад термины структура, сигнатура, функтор прямиком из алгебры заимствованны.
Модули ML образных в большей степени растут оттуда.
VD>Не смешите мои тапочки! Это ФП робенько пытается пролезть на рынок который давно занят ООП-ом. VD>У тебя уже полный отрыв от реальности пошел.
Дело не только в ФП, просто уже понятно что ООП себя практически исчерпал. И теперь авторы новых языков не стараются
хотя бы для приличия делать их ОО, как пример Go.
FR>>Ты неправ ни с чем они не борются просто язык достаточно выразителен чтобы во многом обходится без ООП, они его просто не замечают.
VD>Такое язык не должен существовать. Если фичи есть, то они должны использоваться.
Так они используются, но редко.
VD>Да никто ничего не присваивал. Просто в ООП инкапсуляция и динамический полиморфизм доведен до промышленного уровня (доступного для применении в массовом порядке), под ООП подведена понятная людям база, написано море очень доходчивых учебников, сделано куча реализаций. А ФП большую част времени развивалось даже не фриками, а консервативными около-научными кругами которые только сейчас дорастают до того, что все приняли и взяли на вооружение еще в начале 80-ых годов.
Инкапсуляция в тех же модулях была доведена до промышленного уровня тогда когда ОО языки только — только становились популярными,
VD>Больше же всего меня в этой ситуации радует то, что ООП и ФП разделился на непримиримые лагеря хотя по сути это всего лишь принципы программирования органично дополняющие друг-друга.
Да ладно кроме флеймов этой непримиримости что-то не наблюдается.
Ладно, мне это переливание из пустого в порожнее уже надоело. Все все поняли, но как всегда остались при своих. Так что отвечу только на:
FR>Дело в том что ехать вполне комфортно и без ОО прицепа
Если бы было комфортно, то так бы все (большинство) ездили. Но не ездят и явно никогда не будут (это я не о ФП, а о ML и прочих).
Что до времени появления, то ООП в лице Симулы появился не многим раньше ML. Учитывая что модули и сейчас до классов не доросли (ну, или только сейчас доросли, если ты считаешь, что они таки доросли), то почему было не взять правильные решения в процессе развития лично я не понимаю. Думаю, что все же непринятие ООП — это неосознанное поведение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>Ладно, мне это переливание из пустого в порожнее уже надоело. Все все поняли, но как всегда остались при своих. Так что отвечу только на:
FR>>Дело в том что ехать вполне комфортно и без ОО прицепа
VD>Если бы было комфортно, то так бы все (большинство) ездили. Но не ездят и явно никогда не будут (это я не о ФП, а о ML и прочих).
Я говорил исключительно о камлистах.
VD>Что до времени появления, то ООП в лице Симулы появился не многим раньше ML. Учитывая что модули и сейчас до классов не доросли (ну, или только сейчас доросли, если ты считаешь, что они таки доросли), то почему было не взять правильные решения в процессе развития лично я не понимаю. Думаю, что все же непринятие ООП — это неосознанное поведение.
Я думаю больше традиция. Ну и так как в первую очередь на OCaml пишут в функциональном стиле то большой проблемой это не является.
Здравствуйте, FR, Вы писали:
FR>Так в си хоть и неформальное соглашения, но его придерживаются все производители OS и компиляторов (куда денешься если хочешь вызывать FR>системные функции ), в C++ его вообще нет.
Не путай модульность с интероперабельностью. Борландовские tpu/dcu тоже никто, кроме него не понимает, однако это не мешает ихнему Паскалю быть вполне модульным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не спорь с ним. Я как-то нелестно высказался об его статье, где он критиковал жирную модель Фаулера, причем весьма наивно, надо сказать, а Фаулер и Ко мне вообще нравится, его по крайней мере читать интересно, в отличие от, с тех пор он обожает ставить мне минусики со смайликами, обидчивый, видно, человек
Если честно, я тоже часто не согласен с твоим мнением. Ты зачастую споришь просто ради процесса, что не может не раздражать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
ВВ>Не спорю я ради процесса. Можешь считать, что если я о чем-то с тобой спорю, это значит мне интересна твоя точка зрения И как раз в споре ты выскажешь ее наиболее аргументированно и подробно. В реальности у меня может и не быть "strong opinion" по обсуждаемым вопросам. Я, честно говоря, вообще не вижу большой пользы в этих самых "strong opinion". Но это же не значит, что я троллю?
Значит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
FR>>Так в си хоть и неформальное соглашения, но его придерживаются все производители OS и компиляторов (куда денешься если хочешь вызывать FR>>системные функции ), в C++ его вообще нет.
AVK>Не путай модульность с интероперабельностью. Борландовские tpu/dcu тоже никто, кроме него не понимает, однако это не мешает ихнему Паскалю быть вполне модульным.
В C++ эти понятия полностью перепутаны, достаточно поменять пару опций и уже нельзя вызывать скомпилированные одним и тем же компилятором функции из dll.
Здравствуйте, IB, Вы писали:
IB>Правильнее было бы так: ВВ>> Я как-то нелестно высказался об его статье, причем весьма наивно, надо сказать... IB>=)) IB>И да, там ты тоже нес пургу по поводу ООП.
Там я пересказывал вам Фаулера и Эванса, которых вы и остальные участники цирка, не читали, но "мнение имели". Из чего был сделан вывод, что я не понимаю ООП
Такое, видимо, только на РСДН бывает.
ВВ>>с тех пор он обожает ставить мне минусики со смайликами, IB>Просто мне сложно пройти мимо нелепых, но весьма категоричных заявлений, так что особо я тебя не выделяю — можешь не обольщаться.
Аналогично, поэтому "пишите исчо". А мы тут поржем.
Если нам не помогут, то мы тоже никого не пощадим.
Если нет желания думать об этом — какой смысл вообще что-то обсуждать. Спорить с оппонентом, позиция которого основана на аксиомах, невозможна.
? 
?
.
Мы уже победили, просто это еще не так заметно...
