Здравствуйте, Sinclair, Вы писали:

S>Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике. И там абстракции находятся в более сложных отношениях, чем отношения иерархии.

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


S>Имхо, ООП успешно не потому, что оно как-то особенно похоже на привычный нам способ выделения абстракций,

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


S>а по более банальным причинам: производственное удобство.

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


S>Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

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

ИМХО, всё гораздо проще — ООП предлагает два вида декомпозиции: объектную и процедурную, а ФП — только функциональную, которая несильно отличается от процедурной. И что характерно, что в том же ООП объектная декомпозиция на первом месте на высоких уровнях, на уровне общей структуры/архитектуры, а процедурная декомпозиция на первом месте лишь в самых глубоких подробностях реализаций алгоритмов/методов. В этом смысле ФП выглядит как бедный родственник рядом с ООП, т.к. способен выполнять лишь ту работу, которая с т.з. ООП самая непрестижная.

Здравствуйте, Mamut, Вы писали:

M>Только это даже близко не относится к реальному миру. Потому что ты считаешь, что действие по открыванию двери принадлежат двери.

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

В общем, дверь в его модели — пассивный объект, которому приходит нотификация об уже де-факто состоявшемся событии.


M>Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

Дык, если ты хочешь совершить бредовую замену, типа: мусор.выкидывайся(), то да, а если небредовую с т.з. реального мира: мусороконтейнер.принять(мусор), то сразу всё ОК.


M>ООП всегда является очень грубой, и не всегда корректной моделью мира — как и любая другая модель.

Любое ПО является лишь моделью мира.

Здравствуйте, samius, Вы писали:

S>>>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

V>>Что значит "рулит"?
S>значит крут

Крут? )))
Добро пожаловать в реальный мир, Нео:

ООП предлагает два вида декомпозиции: объектную и процедурную, а ФП — только функциональную, которая несильно отличается от процедурной. И что характерно, что в том же ООП объектная декомпозиция на первом месте на высоких уровнях, на уровне общей структуры/архитектуры, а процедурная декомпозиция на первом месте лишь в самых глубоких подробностях реализаций алгоритмов/методов. В этом смысле ФП выглядит как бедный родственник рядом с ООП, т.к. способен выполнять лишь ту работу, которая с т.з. ООП самая непрестижная.

Реальность такова, что в ООП применимы любые наработки ФП безо-всяких адаптаций, зато наоборот — увы и ах.


V>>Мозг мыслит абстракциями, то бишь упрощениями. Именно абстрагирование от подробностей позволяет мозгу систематизировать и накапливать знания. Иначе не было бы никакого "обучен".
S>И причем тут ООП?

При том, что мы склонны наделять свои абстракции-образы:
— характеристиками;
— поведением, зависящим от характеристик;
— отношениями с другими абстракциями.

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

Указанный выше список разве не описывает ОО-парадигму?

Здравствуйте, vdimas, Вы писали:

V>В этом и состоит моя ирония, т.к.:
V>- по определению чистых ф-ий им не важен порядок вычисления операндов;
V>- ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;
V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.

Когда надоест писать чушь про Хаскелл, рекомендую сходить сюда: http://haskell.org

Здравствуйте, samius, Вы писали:

V>>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.
S>Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться.

S>Тут вообще в SP речь об операциях, точнее об statement-ах (см http://en.wikipedia.org/wiki/Structured_programming).
S>Согласно http://en.wikipedia.org/wiki/Imperative_programming
S>

S>In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state.

S>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

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

Здравствуйте, Sinclair, Вы писали:


S>ООП прекрасно работает там, где оно уместно. Но это никак не связано с особенностями того, как мыслит человек.

Сколько сахар не повторяй, во рту сладко не станет.


S>Пытаться программировать так, как мыслит человек, вообще вредно. Скажем, банальное сложение целых внутри компьютера устроено вовсе не так, как его делает человек — потому, что компьютер может лучше.

Смотря что вычислять. Например, вычислять синус как предел ряда в реалтаймовых задачах невозможно, поэтому компьютер его вычисляет в точности как человек — ассоциативно, через предварительное "заучивание" значения синуса по некоторой сетке (и интерполяции значений м/у узлами сетки).


S>Так и ООП — оно хорошо там, где есть что моделировать с его помощью. Это встречается гораздо реже, чем думают нубы.

Гы, нубы думают, что задача диктует решение, а это встречается гораздо реже, чем они думают.

Здравствуйте, samius, Вы писали:

S>Это не ООП находит для себя удобным. Это ты находишь для себя удобным. Говорить о том что это общепринято в ООП рановато. ООП может делать обновление состояний и без ФП вобщем-то.

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


V>>а в ФП изо всех сил лезут гарантии обслуживания "одних и тех же логических экземпляров сущностей", в виде разного рода монад, задача большиснтва которых — изолировать независимые вычислительные потоки друг от друга без механизма многопоточности.
S>А, ну точно, монады в ФП прилезли ведь из ООП, что бы обходиться без механизма многопоточности, в точности как у ООП (снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)

Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но.


V>>Поэтому, поэтому. Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>Это банально справедливо для всей статики

Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?
S>>В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

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

Здравствуйте, elmal, Вы писали:

E>Пожалуйста. Набор статических функций без какого либо состояния, которыми очень часто пользуюсь.

Отличный пример. Борьба с нулевыми ссылками — это главная на сегодня фишка ООП.

Здравствуйте, Философ, Вы писали:


Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.

А зачем его туда тулить? У тебя методы объектов из чего состоят-то? Из вызовов методов других объктов? А те, в свою очередь? А где же, собственно, начинается полезный код?

А то тут уже некоторые предлагали изъять арифметику из ООП.


Ф>Разве что само уравнение представить в виде объекта

Если требуется изменяемое состояние — то можно и представить? Или не требуется?


Ф>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

V>Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться.
Покажи сайд-эффект if-а Хаскеля, не балаболь.

S>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

V>Полнейшее бла-бла-бла...
V>Функциональная программа так же состоит из выражений языка, которые в процессе работы меняют состояние программы. Просто некоторые слишком молодые адепты ФП в пылу споров забывают, что состояние стека вычислений + положение указателя инструкций в потоке исполнения образуют то самое состояние программы.
Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>значит крут

V>Крут? )))
V>Добро пожаловать в реальный мир, Нео:
V>

V>ООП предлагает два вида декомпозиции: объектную и процедурную, а ФП — только функциональную, которая несильно отличается от процедурной. И что характерно, что в том же ООП объектная декомпозиция на первом месте на высоких уровнях, на уровне общей структуры/архитектуры, а процедурная декомпозиция на первом месте лишь в самых глубоких подробностях реализаций алгоритмов/методов. В этом смысле ФП выглядит как бедный родственник рядом с ООП, т.к. способен выполнять лишь ту работу, которая с т.з. ООП самая непрестижная.

Покажи мне ту работу, которую ФП выполнить неспособен.

V>Реальность такова, что в ООП применимы любые наработки ФП безо-всяких адаптаций, зато наоборот — увы и ах.
твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.

S>>И причем тут ООП?

V>При том, что мы склонны наделять свои абстракции-образы:
V>- характеристиками;
V>- поведением, зависящим от характеристик;
V>- отношениями с другими абстракциями.

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

V>Указанный выше список разве не описывает ОО-парадигму?
и почему-же он описывает только лишь ее?

Здравствуйте, vdimas, Вы писали:

V>Противоречие самому себе:
V>

V>* специальный метод bool isOpen().
V>* видите, открыта ли дверь.

Где противоречие?

Здравствуйте, vdimas, Вы писали:
S>>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты?
V>Как минимум глаза, получающие сообщения от рецепторов света.
Вы уверены, что эта мысль выражена внутри сознания именно в терминах глаз, рецепторов, и сообщений?
Я говорю не про реализацию, а про абстракцию.

Здравствуйте, vdimas, Вы писали:
V>"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания.
В С и паскале ссылочные типы данных имеются в полный рост, без малейших признаков ООП.
В коде x86 есть понятие указателей, но нет понятия объектов.

V>Занавес.
Опять клоунада? Я говорю не про макросистему, а про команды косвенной адресации.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Это не ООП находит для себя удобным. Это ты находишь для себя удобным. Говорить о том что это общепринято в ООП рановато. ООП может делать обновление состояний и без ФП вобщем-то.

V>Это не только я нахожу и не я это изобрел. Эта лишь одна из практик, которая дополняет современное многопоточное ООП. Ведь ООП не отменяет ни атомарности, ни транзакционности. А понятие валидности состояния в нем было изкаробки.
Многопоточный ООП? Ты опять что-то намешал.
Ну и другими словами ты хочешь сказать что ООП без ФП не самодостаточен? Веский довод...

S>>А, ну точно, монады в ФП прилезли ведь из ООП, что бы обходиться без механизма многопоточности, в точности как у ООП (снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)

V>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но.
нет, не могу. Уже надоедает.

V>>>Поэтому, поэтому. Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>>Это банально справедливо для всей статики

V>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.
А что делает ссылочный тип в чистом ФП (это раз)? А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).

А что там с Немерле?

Здравствуйте, vdimas, Вы писали:

V>Математика вполне делится на области, которые можно сложить иерархически. Другое дело, что там получается полноценный направленный граф, а не урезанный его вариант — дерево.
Иерархия и есть дерево. Появился цикл — прощай иерархия.
Я не очень понимаю, что вы называете "делением на области". Вот, скажем, топология и мат.анализ — это такие области? И как вы сложите их "иерархически"?
V>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.
Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них.

V>Производственное удобство связано с удобством для производителя-человека. Как ни крути, но он так мыслит. Как бы некоторым не хотелось думать, что уж они-то мыслят не так. Чем мутнее образ в мозгу, тем он абстрактнее... только и всего.
Не надо натягивать презерватив на глобус. Человек не мыслит объектами из ООП, как бы некоторым ни хотелось думать, что уж они-то мыслят именно объектами.

Здравствуйте, vdimas, Вы писали:

V>Предположу, что только у наследованных от структурной.
V>Например, в логическом программировании никакого ветвления нет.
Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет?

Здравствуйте, vdimas, Вы писали:

Коллега, плотность бреда на квадратный пост превысила ПДК. Ваши заблуждения настолько всеобъемлющи (я пока не нашёл области, где хотя бы 20% ваших утверждений соответствовали действительному положению вещей), что впредь я буду игнорировать все ваши посты на любые темы.

Здравствуйте, SV., Вы писали:

SV.>Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

SV.>Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).
Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом:

(T, T) resolveSqEq<T>(T a, T b, T c);

Потому, что алгоритму неважно, какая там точность. Ему важно, чтобы для T были определены операции умножения, сложения, возведения в степени -1 и 1/2, и получения обратного элемента. Всё. А, ещё пригодится константа 0.
Кормите алгоритм хоть октонионами, хоть матрицами — дайте определения операций, и дело в шляпе.

SV.>Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает.
У этого класса нет никакого поведения, поэтому совершенно непонятно, что именно инкапсулировать. "Состояние" объекта Account полностью прозрачно. Еще есть такая проблема, что в принципе понятие "состояние" у счёта штука очень условная. Грубо говоря, бухгалтерия — это набор проводок.
Исходя из этого набора мы можем высчитать всякие виртуальные вещи — типа "каков у нас остаток дебиторской задолженности на 1 августа 2012".
Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый. Есть ещё куча показателей, которые совсем никак не похожи на "объекты", существующие объективно и независимо от наблюдателя — к примеру, тот же "оборот дебиторской задолженности за период".
Решение, в котором счета — это объекты, а проводки — сообщения, которыми они обмениваются, потребует гонять эти проводки туда-сюда каждый раз, как мне захочется заглянуть в прошлое. Внезапно обнаруженный первичный документ, датированный прошлым сентябрём, сломает нафиг эту модель, т.к. его не "вставишь" между уже отправленными сообщениями.

Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор. Проводка — это тоже не объект, а просто запись некоторого факта. Поверх этого рисуются всякие расчётные операции, которые тоже нифига не объекты, а просто формулы (уровня пятого класса). Сведение баланса = проведение примитивного расчёта.