S>>Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг? BS>за такое надо банить. переход на личности.
Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.
Здравствуйте, samius, Вы писали:
V>>Но да... сами данные для трансформации тоже являются понятиями некоей предметной области, то бишь сами по себе заведомо являются объектами... Даже если это структура со всеми публичными полями... просто это другой уровень дизайна... В итоге, получается та самая классика: объекты состоят из объектов, а процедуры обрабатывают одни объекты, получая из них другие.
S>Долго пытался вникнуть и не вник. Ты хочешь сказать что ФП это объекты + процедуры, которые на выходе дают объекты? Так, наверное, можно считать, но это далековато от положения вещей.
Ничуть не далеко. Хотя ООП-дизайн состоит сплошь из абстрактных типов, но в рантайм работают вполне конкретные типы, которые орудуют вполне конкретными данными, ничуть не хуже, чем ФП орудует структурами. Там всех отличий в механике ФП vs ООП, что в первом случае мы просто трансформируем данные, а во втором случае мы эти трансформированные данные перезаписываем по одним и те же адресам, в которых хранится состояние объекта.
Кароч, нет в ФП никакой магии, котрую ты уже примерно второй год пытаешься найти. Это естественное развитие процедурного подхода, точно так же как ООП является развитием процедурного подхода. Поэтому ФП отлично смотрится в методах объекта, вычисляющих следующее состояние этого объекта. Впрочем, еще хрен его знает когда здесь это подробно обсуждали.
S>Все равно что сказать что паровоз это телега с самоваром, забыв упомянуть что ездит по рельсам и что чай не является побочным продуктом от езды.
На подобные кривые аналогии у меня всегда реакция как на кислый лимон. Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет.
Здравствуйте, samius, Вы писали:
V>>Для выражения ИМХО и не требуется ничего такого приводить. Приводи в ответ своё ИМХО... Правда, тут такой прикол, что как раз отрицание чужого ИМХО потребует аргументов. Не обратил внимание, что тем ИМХО и отличается от безусловной подачи информации, что нападающие и защищающиеся меняются в споре меняются местами? У тебя сейчас не было оснований для нападения, поэтому нападки выглядят криво... А в каче-ве защиты твоеё т.з. пост откровенно слаб... Потому что не был заточен заточен под защиту твоего ИМХО, очевидно. S>Надеюсь, это было твое ИМХО
Это был здравый смысл. В пылу спора коллеги на этом сайте как-то охотно забывают о субъективном характере практически любой информации, которой обмениваются.
S>>>Т.е. то что мозг мыслит объектно, выдвигается вами за постулат. Причем, выглядит это так, что утверждение абсолютно. Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.
V>>Вообще-то да. Несмотря на хорошо понимаемую нашим братом-программистом бесконечность и непрерывность числового ряда, каждое конкретно взятое число мы представляем себе как отдельный объект. Взять те же самые значения временных переменных при вычислении факториала... S>Мы вообще-то говорили об ООП. Это на тот случай, если ты решил контекст восстановить по одному лишь моему сообщению. В рамках того контекста, в котором я тут общаюсь, я делаю предположение о том что твое ИМХО считает что все, где встречается упоминание числа либо какой-то величины, можно смело относить к ООП...
Я понял твоё усиление и весь нагнетаемый трагизм. Надо было тебе еще н авсякий случай переспросить и поставить такой смайл: .
Но ответ — да. Да, любое конкретное значение — это не абстракция, это выражение некоего понятия предметной области.
V>>============== V>>Ну ты понял как надо будет строить возражение, если тебе захочется его строить. S>Я не рассчитывал что ты влезешь с середины и не поймешь о чем речь (или сделал вид что не понял).
Я влез с самого начала. Другое дело, что мммм... не могу согласиться со столь серьезным отношением к столь несерьезным вещам. ООП как и ФП, это в первую очередь набор практик, которые обслуживают некую т.з. на способ решения задачи. А ты пытаешься эти набры практик мало того, что возвести в антагонизм друг к другу, дык еще каждую из них в абсолют. Самое время вот этому:
Кароч, неблагодарное это дело... Хотя бы потому, что эти наборы практик постоянно развиваются. То бишь любая твоя т.з., пусть даже самая адекватная, назавтра безбожно устареет.
Здравствуйте, Wolverrum, Вы писали:
W>Мысль простая... и ложная.
W>Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.
Мозг работает образно и это уже многократно доказано. Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
У кого-то проблемы с дверью? А по физике разве ни одной задачи не решили в школе? А импульсы тел не находили?
LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
Ну ты с ошибками описал. Конкретно здесь есть:
— состояние+поведение травы,
— состояние+поведение коровы.
Ты предложил некое действие, совершаемое кем? Коровой. корова.щипать(трава)
В результате действия изменяется состояние чего? Травы. трава.бытьОщипанной(кол-во ощипанного). Заметь, в твоем варианте интерфейс травы какой-то левый, нерелевантный исходному дизайну.
Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так:
Природа.поедание(коровы, трава).
И да, возможен аналогичный же сценарий: Коровник.поедание(коровы, комбикорм).
LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.
Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях. Думаешь, нахрена нужны суперкомпьютеры для вычисления результатов ядерного взрыва??? По-твоему, эти суперкомпьютеры нужны для вычисления смешной формулы с максимум всей сложности — возведением в 3-ю степень? ))
Здравствуйте, AlexCab, Вы писали:
AC>на сегодня ООП наиболее мощная из реально используемых парадигм. AC>------------------- AC>Тем не менее, ООП должно умереть!
какой странный вывод.
почему должно?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Steamus, Вы писали: S>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
Это — шаг в сторону.
Человек мыслит некими образами. Можно сказать, что он мыслит понятиями, ок.
Любой матаппарат — это попытка формализовать понятия, которыми мы мыслим.
Формализаций может быть много и разных. Говорить, что "человек мыслит объектами" — это то же самое, что сказать "человек мыслит сепульками".
В том смысле, что объекты, которыми мыслит человек, совсем не то же самое, что и объекты в ООП. Человек мыслит чем-то размытым, нечётким, изменчивым.
Объекты ООП формальны и строги.
Только нуб, кругозор которого ограничен ООП, полагает, что "человек мыслит объектами", понимая под последними объекты из ООП.
А DBA мыслит реляциями. Функциональный программист — функциями, причём в основном высшего порядка. Программист Виртовской эпохи мыслил алгоритмами и структурами, т.е. процедурами и данными. Алгебраист мыслит тензорами.
Человек мыслит тем, чем его научили.
В этом смысле ООП никакого особенного преимущества перед другими нотациями не имеет. Более того, применять ООП для того, чтобы моделировать "реальный мир" или хотя бы те образы, которыми мы его у себя в голове описываем — как правило, ошибка. ООП удобно применять там, где решение задачи хорошо выразимо в виде некоторых "виртуальных механизмов", обладающих достаточно сложным поведением и состоянием. Особенно здорово, если в решении участвуют похожие друг на друга, но отличающиеся механизмы. Тогда есть место для мощных абстракций типа наследования и композиции.
Если поведение механизмов решения примитивно, то ФП может оказаться значительно более удобным способом описывать решение.
Если нет разнообразия в поведении механизмов решения, а вся сложность перенесена на обрабатываемые данные, то РА и языки вроде SQL (или Linq) будут значительно более уместны, чем ООП или рукопашное ФП.
Если решение находится при помощи однотипных механизмов логического вывода, то Пролог порвёт всех по удобству и понятности записи.
И в любом случае, попытки выхода за пределы комфортной зоны той или иной технологии приводят к резкому росту трудозатрат на разработку. Серебряной пулей тут является умение мыслить несколькими парадигмами и свободное переключение между ними.
Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу. Я пока смотрю на этот подход с осторожным оптимизмом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, pkl, Вы писали:R>>Понимане ерез органы чувств хоть и ограниченное, но зато наиболее естественное и простое для восприятия. Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия. Вы ввели абстрактную сущность IОткрываемое, описали состояния двери, да, это ООП, но мы ведь так и не приблизились к решеню проблемы — дверь всё еще закрыта. И чтобы нам её открыть, нужно совершить действие — тот самый глагол, который во всем этом примере первичен для обычного человеческого восприятия. Для решения задачи нужно разложение этого открыть на последовательность более мелких действий. А назначение всех этих иерархий наследования — лишь натянуть на всю эту ситуацию ООП ради самого ООП. pkl>Вот мне даже в реальной жизни пофигу на процесс, происходящий с дверью во время открытия. Я её толкнул или пнул ногой или повернул ключ — это такие ерундовые для меня действия, что я вполне назову это "вызов метода open()". Мне важно, чтобы объект поменял состояние на "открыто" и я смог войти, а как она конкретно открывается — в какую сторону, каким ключём — мне до такой большой лампочки, что просто нет такого подъёмного крана на свете, чтобы эту лампочку поднять. Для меня открытие двери — как она движется, вися на петлях, как в ней работает замок, — это всё инкапсулировано в методе "open()".
Прекрасно. Вот для вас, получается, важен не процесс открытия, а результат. То есть в вашей модели у двери есть свойство, которое может принимать два состояния "открыто" и "закрыто" (опустим пока подробности промежуточных состояний). Для вашей задачи естественным будет такой язык, в котором вы можете потребовать theDoor.state = open и всё. Зато вам может оказаться важно, что дверь была уже открыта, чтобы не делать лишних действий.
Для таких задач REST-архитектуры подходят гораздо больше, чем ООП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг?
Оттуда, что Мамут не зациклен на чём-то одном, и хорошо разбирается в применимости нескольких парадигм. А вы пока что не демонстрируете ни понимания ООП, ни готовности понять другие парадигмы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так: V>Природа.поедание(коровы, трава).
Прекрасно. Ваши аргументы против ООП безупречны.
LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.
V>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.
Осталось выяснить, какое место в этих видах моделирования занимает ООП.
Надо полагать, там молекула воды наследуется от двух атомов водорода и одного атома кислорода?
Или всё сводится к какому-то аналогу cluster.Compute(task)?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Steamus, Вы писали:
S>Здравствуйте, BrainSlug, Вы писали:
S>>>Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг? BS>>за такое надо банить. переход на личности.
S>Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.
Я не думаю, что "портал заинтересован в том, чтобы шла напряжённая, интересная людям дискуссия" о рейтинге Мамута.
Здравствуйте, Steamus, Вы писали:
S>Смешно моделировать действительность функциональным языком. Хотя, скорее грустно.
Смотря что вы называете действительностью. Моделировать "действительность" с помощью ООП значительно смешнее. Я пока ещё не встретил такого случая, где ООП было бы реально пригодно для моделирования "действительности". Скажем, в бухгалтерии делать class Account — верх глупости. Делать class FinancialDocument — ещё большая глупость. Какое-то место можно найти классам BalanceCalculation и TransferRestrictionRule. Но ни того, ни другого в "действительности" не наблюдается, по крайней мере на первый взгляд. Большинство из "объектов", наблюдаемых в дикой природе, не заслуживают в программе большего, чем некая структура данных.
Потому, что объекты в жизни никак не хотят вести себя как объекты в ООП. Понятия идентичности в реале совсем другие; понятия классификации тоже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, minorlogic, Вы писали:
M>По крайней мере ООП может быть использована для лучшей читабельности. Это и декомпозиция и уменьшение связанности и т.п.
А может быть использована для худшей читабельности. Потому что в чистом ООП решение квадратного уравнения вы устанете читать, и уж тем более запаритесь понимать, как оно работает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так: V>>Природа.поедание(коровы, трава). S>Прекрасно. Ваши аргументы против ООП безупречны.
Было бы неплохо обосновать. А то не вышло бы как рядом с константностью, поторопимшись.
Я уже запасся попкорном, бо прекрасно понял, что ты имел ввиду. Но хочу это услышать во избежание будущих обвинений в инсинуациях. ))
LCR>>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.
V>>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях. S>Осталось выяснить, какое место в этих видах моделирования занимает ООП.
И ты до сих пор не выяснил?
Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
S>Надо полагать, там молекула воды наследуется от двух атомов водорода и одного атома кислорода?
Надо полагать, что ты решил опустить обсуждение ООП на уровень 1-го курса ВУЗа... Твой выбор, но это без меня. Правильный ответ тут такой: наследование — лишь удобный инструмент, но не обязательная часть ООП-программы. Обсуждать в эту область я не буду, бо неинтересно. При последущем ответе всё-равно скипну.
S>Или всё сводится к какому-то аналогу cluster.Compute(task)?
Нет, всё сводится исключительно к тому, что без состояния нет поведения. См. пометку (*). Кто этого не понимает, тот не понимает как устроено и работает ООП. Тот не понимает фундаментальное отличие повдеения от безусловнх реакций. ООП — это такой механизм моделирования "поведения сущностей", который реализован через изменяемое состояние.
Здравствуйте, Sinclair, Вы писали:
S>Потому, что объекты в жизни никак не хотят вести себя как объекты в ООП. Понятия идентичности в реале совсем другие; понятия классификации тоже.
Хех. Я помню дискуссии о том, какой же отстой этот ООП. Ведь им придётся имитировать плевок в лужу в виде обмена сообщений между молекулами лужи.
Здравствуйте, Cyberax, Вы писали:
S>>Потому, что объекты в жизни никак не хотят вести себя как объекты в ООП. Понятия идентичности в реале совсем другие; понятия классификации тоже. C>Хех. Я помню дискуссии о том, какой же отстой этот ООП. Ведь им придётся имитировать плевок в лужу в виде обмена сообщений между молекулами лужи.
Ну вот по соседству мы как раз вернулись к плевку и луже. http://rsdn.ru/forum/philosophy/4834765.1.aspx
.
Если нам не помогут, то мы тоже никого не пощадим.
