Здравствуйте, Sinclair, Вы писали:
J>>Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps). S>Вот как раз такие штуки и выдают, скажем так, малопригодность ООП для вычметодов. Потому что непонятно, updateField — это метод у Field, у Environment, или у Particles.
Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так:
timeModel.update(Environment e, Particles ps).
А гду-то унутрях timeModel будет подавать на вычисления некое dt, по которому происходит численное интегрирование. Но опять же, если dt не константа... А если константа, тогда состояние timeModel перемещается в глобальную область вслед за этой константой и остается просто оригинальный update().
Здравствуйте, samius, Вы писали:
S>Надеюсь что возвращая заданный тобой акцент, я сделал продолжение в этом духе малоперспективным. Но боюсь, что продолжение может оказаться для тебя все-таки занимательным.
Да нет, ес-но, это был троллинг чистой воды в ответ на твоё плохоосознаваемое погружение в троллинг же по теме обсуждения. С кем не бывает...
Но читать твой ответ было таки забавно... Ты прекрасно всё понял... хоть и не был этому рад. ))
========
И да... насчет устаревания — увы и ах. Обсуждаемые наборы практик (ООП и ФП) не мертвы, а вовсе наоборот — активно развиваются и дополняются. И даже заимствуют практики друг у друга.
Здравствуйте, Mamut, Вы писали:
M>[skip]
M>Кхм. В итоге ты размазываешь непонятно что десятком предложений По ссылке — как раз яркий пример, что мы не мыслим объектами
По ссылке мусор. Покажи внятный труд по когнитивной психологии на эту тему, а велосипеды очередного программиста оставь в покое.
Здравствуйте, kittown, Вы писали:
V>>Мозг работает образно и это уже многократно доказано. Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...
K>Обрзность и мышление обтектами — это не так уж рядом.
Рядом, рядом...
K>Образы могут прозвольно трансформироваться из гусеницы в водопроводный кран или грецкий орех,
Это только если ты себе вообразишь процесс такой трансформации. А так-то ничего зазорного в том, чтобы перестать думать об объекте "гусеница" и переключиться на "водопроводный кран" нет.
K>а потом в течение времени или сожаление от опоздания на поезд,
И это ничему не портиворечит. Когды мы о чем-то сожалеем, мы моделируем ту реальность, которая могла бы быть, сравниваем с той, что по факту, видим отличия не в нашу пользу и нас душит жаба. Но в течении описанного процесса вышесказанное никуда не девается — всё остается в силе.
K>по самого разного рода ассоциативным связям.
Дык, ассоциативность связей — это и есть самый яркий пример того, что мы наделяем образы количественными показателями, то бишь никакой аморфности... потому что у ассоциаций обязательно есть арность отношения. )))
Здравствуйте, Sinclair, Вы писали:
S>Если нет разнообразия в поведении механизмов решения, а вся сложность перенесена на обрабатываемые данные, то РА и языки вроде SQL (или Linq) будут значительно более уместны, чем ООП или рукопашное ФП.
Что такое "поведение механизмов решения"?
S>Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу. Я пока смотрю на этот подход с осторожным оптимизмом.
Как раз таки DSL меньше всего должны быть мультипарадигменными, иначе это будет профанацией на фоне мультипарадигменных языков общего назначения. То бишь, ваяние нескольких DSL в процессе решения задачи по-прежнему может означать то самое переключение м/у парадигмами.
Здравствуйте, 0x7be, Вы писали:
0>У меня складывается впечатление, что мантру о том что "ООП естественно для человека, потому что мы мыслим объектами" многие заучили ещё в университетах, не пытаясь осмыслить её критически.
0>Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?
Можно сказать, что понятия тождественны абстракциям. Классы это один из способов работы с абстракциями, не единственный, вообще говоря. Главное помнить, что у понятия есть имя, то есть такое слово, которое может выполнять замещающую функцию для этого понятия.
Вопрос в том, на кого ориентироваться при разработке. Если ориентироваться на широкие массы, чего боятся функционалисты, нужно давать простые инструменты, это именно то направление которым движется основная часть софтверной индустрии много лет, эта часть ориентирована на вещи общего назначения. Если ориентироваться на гиков, что нравится функционалистам, надо вводить более сложные инструменты, это то направление которым движется небольшая часть софтверной идустрии, которая ориентирована в основном на специфические или высокоуровневые вычислительные задачи.
Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения.
Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.
Функционалисты хотят что бы один мега-специалист вооружившись мега-языком накодил небольшое ядро и сгенерил код для всего остального. Это утопия, просто потому что задач очень много, просто вникнуть в эти задачи это адское количетсво времени, хватит на сотню а то и тысячу лет жизни одного такого функционалиста.
Отсюда ясно, что ориентироваться нужно не по признаку программистских умений, например врач никогда не будет писать код даже на самом распрекрасном ДСЛ, а по признаку отношения к продукту, т.е. бизнесу. Общество уже тысячи лет развивается по пути разделения труда — одни лечат, другие пишут код. У функционалистов какое то хроническое заболевание, никак не могут понять что этой тенденции больше лет чем всем функциональным языкам вместе взятым.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали:
pkl>>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта... S>Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения". S>Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение. S>А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта. S>В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.
Я чё-то охладел к разговору (-;
Здравствуйте, Sinclair, Вы писали:
>Ф>С "Вычислителем" было бы интереснее, ведь это вполне его метод: >Ф>вычислитель.РешитьУравнение() S>>Ага. Смотрели на то, как Bart de Smet прикручивал linq к Z-theorem prover? Вот это — ГОСТ 13345-85.
Wouldn’t it be nice if we could write something like this:
static void Main()
{
Solve((a, b) => a && b);
Solve((a, b) => !(a && b));
Solve((a, b) => a || b);
Solve((a, b) => !(a || b));
Solve((a, b) => a ^ b);
Solve((a, b) => !(a ^ b));
Solve(a => a && !a);
Solve(a => a || !a);
}
удареный он чувак
Оно?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали:
pkl>>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта... S>Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения". S>Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение. S>А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта. S>В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.
По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема?
Здравствуйте, samius, Вы писали:
S>Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии.
Вот именно с таким антогонизмом я и спорю. Ты правильно уловил суть. Набор практик не такой уж несовместимый. Например, есть такое понятие, как безопасность к исключениям и разные уровни этих гарантий. Дык, самые сильные гарантии по исключениям в ООП можно получить лишь применив практики из ФП. И мне по работе приходится именно это делать с утра до вечера... Я, можно сказать, физически не могу воспринимаять попытки разнести ООП и ФП на разные полюса. Они слишком рядом, в отличие от, например, логического программирования.
S>Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции.
Это типа решил поупражняться в искусстве "лечения по фотографии"? Я тут с одним клиентом уже на эту тему работаю, в очередь, в очередь. )))
В общем, всё что Я сказал — запечателось в подветке. То бишь если подзабыл — можно освежить.
S>Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.
Да, вроде, ты пока споришь с собой, а со всем сказанным мной — пока что согласился.
V>>Кароч, нет в ФП никакой магии, котрую ты уже примерно второй год пытаешься найти. Это естественное развитие процедурного подхода, точно так же как ООП является развитием процедурного подхода. S>В ФП нет магии, но развитием процедурного подхода оно не является. Соглашусь лишь что в развитии ФП и ООП многое шло параллельно и они безусловно влияли друг на друга.
Да, но обратил внимание, в чем именно заключается это влияние??? Они черпают друг у друга исключительно наработки в системах гарантий. ООП находит для себя удобным разделение кода на чистый вычислительный код метода и транзакционное затем обновление состояний, а в ФП изо всех сил лезут гарантии обслуживания "одних и тех же логических экземпляров сущностей", в виде разного рода монад, задача большиснтва которых — изолировать независимые вычислительные потоки друг от друга без механизма многопоточности.
V>>Поэтому ФП отлично смотрится в методах объекта, вычисляющих следующее состояние этого объекта. Впрочем, еще хрен его знает когда здесь это подробно обсуждали. S>смотрится неплохо, но причина вовсе не "поэтому".
Поэтому, поэтому. Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
V>>На подобные кривые аналогии у меня всегда реакция как на кислый лимон. S>Лимон? Ну и что... Вот если бы ты сказал как на пенку от кипяченого молока... Лимон-то это круто.
Я бы на нашей 40-й жаре холодного пивка лучше навернул... )))
V>>Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет. S>Вопросы воспроизводимости механизмов и возможности эмуляции одного на другом вторичны и не особо меня интересуют, как ты уже наверное понял.
Э нет, речь не об эмуляции одного на другом, а о прямой подержке в языке этих парадигм. Эмуляция — это всегда разновидность анонизма. Хотя порой без этого никак... Увы, современные языки несовершенны. А если даже язык попадается неплохой, то у него самый ужасный в мире компилятор и порождаемый конечный образ. Так что, исходим из того, что есть. ))
S>Мне любопытны наборы практик,
Во, о чем и речь. А практики эти сложились от системы гарантий.
S>а не выводы типа "все **П выполняются в машинных кодах => произошли от него".
А уже где-то был такой вывод? Или как? Или это опять то, о чем я подумал?
Ты бы эта... без вот этих мансов, что ле... "Не читай Синклера, Вольфхаундом станешь". ))
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали:R>>Понимане ерез органы чувств хоть и ограниченное, но зато наиболее естественное и простое для восприятия. Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия. Вы ввели абстрактную сущность IОткрываемое, описали состояния двери, да, это ООП, но мы ведь так и не приблизились к решеню проблемы — дверь всё еще закрыта. И чтобы нам её открыть, нужно совершить действие — тот самый глагол, который во всем этом примере первичен для обычного человеческого восприятия. Для решения задачи нужно разложение этого открыть на последовательность более мелких действий. А назначение всех этих иерархий наследования — лишь натянуть на всю эту ситуацию ООП ради самого ООП. pkl>>Вот мне даже в реальной жизни пофигу на процесс, происходящий с дверью во время открытия. Я её толкнул или пнул ногой или повернул ключ — это такие ерундовые для меня действия, что я вполне назову это "вызов метода open()". Мне важно, чтобы объект поменял состояние на "открыто" и я смог войти, а как она конкретно открывается — в какую сторону, каким ключём — мне до такой большой лампочки, что просто нет такого подъёмного крана на свете, чтобы эту лампочку поднять. Для меня открытие двери — как она движется, вися на петлях, как в ней работает замок, — это всё инкапсулировано в методе "open()". S>Прекрасно. Вот для вас, получается, важен не процесс открытия, а результат. То есть в вашей модели у двери есть свойство, которое может принимать два состояния "открыто" и "закрыто" (опустим пока подробности промежуточных состояний). Для вашей задачи естественным будет такой язык, в котором вы можете потребовать theDoor.state = open и всё. Зато вам может оказаться важно, что дверь была уже открыта, чтобы не делать лишних действий. S>Для таких задач REST-архитектуры подходят гораздо больше, чем ООП.
Открывание и закрывание двери можно описать в любой парадигме, какой захочется. Что означает "какая лучше подходит"? По какой формуле вычислить показатель лучшести?
Здравствуйте, Sinclair, Вы писали:
S>Если у вас есть другая информация — поделитесь. А надувать щёки и переводить разговор на личности не надо — я вам уже говорил, здесь это оффтоп.
Ай, ладно, это норма и ты сам это показал сначала ad hominem "Надо полагать, там молекула воды наследуется ", "надувать щёки" а потом уже пальчиком погрозил за аналогичный пассаж
Вобщем
Не в защиту vdimas было сказано, просто за много лет както поднадоело что тимовцы все носятся с идеей расовой чистоты, а сами дружно изощряются в том, как бы поэлегентнее, повежливее да полегальнее задеть или вовсе оскорбить человека. Хочешь задеть — пиши матом, это во первых честно, во вторых экономит время и тебе и модератору.
Steamus,
M>>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду
LCR>>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач: LCR>>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?). LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.
S>Причём тут вообще ООП? ООП — это методологический подход, построенный на декомпозиции задачи/системы с целью снижения её сложности. Кокое он имеет отношение к изменению некоей величины с течением времени? В математике это называется функция, функцией и будет смоделировано в программе.
S>Что интересно, люди понимающие ООП, как правило имеют неплохое представление и об ФП. А вот обратное — неверно. ФПшники тотально не понимают на каком уровне ООП работает. Откуда и всё эти наивные вопросы, которые им самим кажутся прикольными и типа ООП-тупиковыми. И тема очень ярко это показывает. 40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.
Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.
А приблизит нас тоненькая брошюрка "Введение в динамику жидкости" товарища Бэтчелора и такая же тоненькая "Вычислительная математика" Тихонова+Самарского. В первой книжке мы найдём как выписать систему уравнений Навье-Стокса для нашей лужи, а во второй книжке мы найдём методы, как решать системы диффур численно. Покроем лужу достаточно мелкой сеткой, напишем алгоритм числнного решения (с прицелом на кластер) и вот тогда мы приблизимся таки к моделированию нашей действительности. И тут — о чудо — появятся объекты, да. Например, vector<Point3D>, matrix, обёртки над сокетами и тому подобные технические сущности. Причём набор этих сущностей будет существенно зависеть от выбранного способа решения. Однако куда делись лужа с камнем? Чёрт!
Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл:
1. Это когда действительность можно раздербанить на множество мелких кусочков (то есть объектов), не слишком много и не слишком мало. Когда объектов слишком много, мы обнаружим практическую непригодность нашей модели; когда объектов слишком мало (лужа и камень), мы обнаружим, что эти объекты слишком сложно взаимодействуют друг с другом, и ООП нам здесь не поможет.
2. Видов взаимодействий не должно быть слишком много. То есть количество методов у объектов не должно быть слишком большим. Иначе, сложность взаимодействия комбинаторно возрастает и мы окажемся не в силах запрограммировать и отладить.
3. Взаимодействия должны быть ассиметричными. Самое лучшее, если мы взаимодействие можем сформулировать в виде "с объектом А можно делать то, то и сё". Ассиметричность нам даст уверенность приклеить метод к данному объекту.
4. Можно вводить синтетические объекты для уменьшения количества методов и/или для упрощения методов. (Чаще всего нужно, многие паттерны об этом)
5. Можно вводить синтетические методы опять же для уменьшения количества и/или упрощения. (То же что и в 4)
Заметь, я нигде не говорил про классы, интерфейсы и наследование (они в сущности лишь инструмент тайпчекинга и для облегчения понимания этих объектов человеками). Также я нигде не сказал про состояние, ибо оно не является ключевым атрибутом для объектов. Оно нужно лишь для того, чтобы правильно отразить взаимодействия.
я дискутировал с Klapaucius, он меня как-то попросил привести примеры, где сабтайпинг с его полиморфизмом был бы особенно органичен и полезен (ну ты знаешь, IFigure / метод draw ). Так вот, время шло, я перебирал один пример за другим, и не оказалось ни одного, где бы комбинация ad-hoc полимофизм (+TC) + параметрический полиморфизм была бы хуже, чем сабтайпинг. По сути, сабтайпинг — это единственный доступный способ в ОО для абстрагирования, которое в свою очередь нужно скорее для человеков, чем для машин.
Резюмирую. То есть, наша действительность должна выглядеть как сложная система, причём можно (чаще — нужно) вводить синтетические кусочки и синтетические взаимодействия. Соответственно, ни о каком отражении действительности речи не идёт, а отражается скорее выбранный способ того, как мы будем отражать эту действительность.
(Кстати, кто мне скажет, зачем у класса Complex определены методы '+','-','*' и '/'?)
vdimas,
LCR>>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач: V>У кого-то проблемы с дверью? А по физике разве ни одной задачи не решили в школе? А импульсы тел не находили?
Вероятно, здесь все когда-то вычисляли импульсы тел. Но пока никто с помощью ООП дверь не открыл.
LCR>>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?). V>Ну ты с ошибками описал. Конкретно здесь есть: V>- состояние+поведение травы, V>- состояние+поведение коровы. V>Ты предложил некое действие, совершаемое кем? Коровой. корова.щипать(трава) V>В результате действия изменяется состояние чего? Травы. трава.бытьОщипанной(кол-во ощипанного). Заметь, в твоем варианте интерфейс травы какой-то левый, нерелевантный исходному дизайну. V>Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так: V>Природа.поедание(коровы, трава). V>И да, возможен аналогичный же сценарий: Коровник.поедание(коровы, комбикорм).
Я так и не понял почему взаимодействие между одной коровой и травой (которая представлена одним или несколькими объектами?) свелось ко множеству коров и повторному взаимодействию. Ещё комбикорм откуда-то появился...
LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени. V>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях. Думаешь, нахрена нужны суперкомпьютеры для вычисления результатов ядерного взрыва??? По-твоему, эти суперкомпьютеры нужны для вычисления смешной формулы с максимум всей сложности — возведением в 3-ю степень? ))
В моём детском саду я честно говоря подозревал, что максимум можно только во вторую степень, а суперкомпьютеры я думал они для обогрева помещения...
И да, порезать лужу на квадратики — тоже один из самых популярных видов моделирования в этих областях. Но мне так и не стало яснее, какой вклад в эту модель составляет именно ООП. Подозреваю, что почти нулевую, весь вклад формулируется трюизмом "частица — это объект". Если ты не сочтёшь за труд и пробежишь глазами по ветке выше, ты увидишь, что речь шла о том, как "здорово" ООП отражает действительность.
LCR>Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.
Ну вы правильно всё пишите. Нет никакой необходимости вклеивать ООП в каждую дырку. ООП это прежде всего подход к решению задачи, с целью минимизировать её сложность. Математики/психологи давно заметили, что мозг способен держать и оперировать конечным количеством сущностей. Соответственно и нужно любую задачу каким-то образом упростить до того уровня, на котором мозг способен с ней совладать. Два ходовых приёма: абстрагироваться от неважного и внятно выделить общие части. ООП язык даёт синтаксический способ фиксации этих вещей. Классы, объекты, наследование. Вот и всё. Остальное уже для удобства и техники.
И вот из этого абсолютно никак не следует, что обязательно надо использовать эти возможности для того что бы сложить два числа, смоделировать выражаемое формулой поведение некоей величины во времени и так далее.
Все борцы с ООП с маниакальным упорством выкусывают мелкий обозримый кусок и подсовывают его со словами ..ну давай-давай унаследуйся тут, декомпрозируй классом... мы поржём... Что так и будешь как дурак вместо 2+2=4 писать new Integer(2).добавить(new Integer(2)). Ха-ха-ха... и всё такое. Посрамили млин. Разумеется не буду. Я чё, кретин?
То есть, адекватных возражений практически нет. Есть какое-то желание подловить на синтаксисе. Вроде все по жизни используют абстракцию и генерализацию. Почему людей так пугает, что некие языкы программирования предоставляет средства для удобной фиксации этих вещей? Тараканы чтоль какие в голове?
S>Вроде все по жизни используют абстракцию и генерализацию. Почему людей так пугает, что некие языкы программирования предоставляет средства для удобной фиксации этих вещей? Тараканы чтоль какие в голове?
ну так, afaiu, в этом и суть претензий -- абстракция, модульность, изменяемое состояние это все общечеловеческие ценности и элементы общей культуры. И люди недоумевают, почему некоторые сторонники ООП присваивают их себе.
Здравствуйте, Философ, Вы писали:
Ф>логично было взять самое широкое множество.
Октонионы? Тока не забываем, что тогда x.Add y это совершенно не то же самое, что y.Add x
S>>Вроде все по жизни используют абстракцию и генерализацию. Почему людей так пугает, что некие языкы программирования предоставляет средства для удобной фиксации этих вещей? Тараканы чтоль какие в голове?
D>ну так, afaiu, в этом и суть претензий -- абстракция, модульность, изменяемое состояние это все общечеловеческие ценности и элементы общей культуры. И люди недоумевают, почему некоторые сторонники ООП присваивают их себе.
Почему присваивают? Кто присваивает? Просто пытаются убедить, что если язык поддерживает эти вещи синтаксически, то это хорошо и удобно мозгу. И это никак не отменяет кодирования непосредственно алгоритмов с использованием ФП подходов или любых других. Она вот и умиляет эта песочница. ООП типа присваивает себе что-то, жестоко отнимая ведёрки и формочки от страдающих ФП которые в ответ встают на путь партизанского сопротивления злу и насилию. Детский сад штаны на лямках.
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Философ, Вы писали:
Ф>>логично было взять самое широкое множество. W>Октонионы?
во-первых, я не знаю что это такое, а во-вторых, при решении квадратного уравнения запросто могут получиться комплексные корни — почему-бы его тогда с самого начала не решать с комплексными коэффициентами?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии.
V>Вот именно с таким антогонизмом я и спорю. Ты правильно уловил суть. Набор практик не такой уж несовместимый.
Я не говорил что он несовместимый. Я говорил что он разный.
S>>Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции.
V>Это типа решил поупражняться в искусстве "лечения по фотографии"? Я тут с одним клиентом уже на эту тему работаю, в очередь, в очередь. )))
V>В общем, всё что Я сказал — запечателось в подветке. То бишь если подзабыл — можно освежить.
Дык, это была гипербола была
S>>Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.
V>Да, вроде, ты пока споришь с собой, а со всем сказанным мной — пока что согласился.
Я тебе рассказываю о ценности твоих выводов, а не спорю с тобой.
S>>В ФП нет магии, но развитием процедурного подхода оно не является. Соглашусь лишь что в развитии ФП и ООП многое шло параллельно и они безусловно влияли друг на друга.
V>Да, но обратил внимание, в чем именно заключается это влияние??? Они черпают друг у друга исключительно наработки в системах гарантий. ООП находит для себя удобным разделение кода на чистый вычислительный код метода и транзакционное затем обновление состояний.
Это не ООП находит для себя удобным. Это ты находишь для себя удобным. Говорить о том что это общепринято в ООП рановато. ООП может делать обновление состояний и без ФП вобщем-то.
V>а в ФП изо всех сил лезут гарантии обслуживания "одних и тех же логических экземпляров сущностей", в виде разного рода монад, задача большиснтва которых — изолировать независимые вычислительные потоки друг от друга без механизма многопоточности.
А, ну точно, монады в ФП прилезли ведь из ООП, что бы обходиться без механизма многопоточности, в точности как у ООП (снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)
S>>смотрится неплохо, но причина вовсе не "поэтому".
V>Поэтому, поэтому. Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
Это банально справедливо для всей статики
S>>Вопросы воспроизводимости механизмов и возможности эмуляции одного на другом вторичны и не особо меня интересуют, как ты уже наверное понял.
V>Э нет, речь не об эмуляции одного на другом, а о прямой подержке в языке этих парадигм. Эмуляция — это всегда разновидность анонизма.
Прямая поддержка тоже бывает разной степени прямоты и анонизма.
V>Хотя порой без этого никак... Увы, современные языки несовершенны. А если даже язык попадается неплохой, то у него самый ужасный в мире компилятор и порождаемый конечный образ. Так что, исходим из того, что есть. ))
S>>Мне любопытны наборы практик,
V>Во, о чем и речь. А практики эти сложились от системы гарантий.
От систем. Системы-то разные.
S>>а не выводы типа "все **П выполняются в машинных кодах => произошли от него".
V>А уже где-то был такой вывод? Или как? Или это опять то, о чем я подумал?
Это опять была гипербола. И она не так далека от выводов, которые ты предлагаешь.
V>Ты бы эта... без вот этих мансов, что ле... "Не читай Синклера, Вольфхаундом станешь". ))
Я лучше тебя не буду читать.
По ссылке — как раз яркий пример, что мы не мыслим объектами 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
