Здравствуйте, Undying, Вы писали: VE>>Гэбриел не в курсе про существование GPS что ли?
U>Разработчик GPS с тобой не согласен: U>http://bourabai.kz/hatch/clocks_rus.htm
Нет это не аргумент. Если бы ученый хорошо знающий СТО+ОТО был бы несогласен тогда другое дело.
Да и из статьи следует что никаких проблем и отклонений в расчетах нет.
Есть только проблемы у него самого с объяснением этого всего на уровне болтологии/рассуждений без формул и без расчетов, на основе словестных обьяснений надерганных из какой-то литературы.
Есть где нибудь информация что описанные проблемы, еще для кого-то являются проблемами, или с расчетами значительно не сходится?
Часы GPS показывают, как и ожидается, что перемещающиеся часы идут медленней и, что часы идут медленней при более низком гравитационном потенциале.
Что ему еще надо?
Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS.
Его комментарии к этой фразе похожи на болтологию. Тем более что он ничего вычислять и не пытался.
U>Разработчик GPS с тобой не согласен: U>http://bourabai.kz/hatch/clocks_rus.htm
Вобщем, Гофман согласен, Хатч не согласен.
Re[4]: Почему объектно-ориентированное программирование пров
Здравствуйте, Silver_S, Вы писали:
S_S> Нет это не аргумент. Если бы ученый хорошо знающий СТО+ОТО был бы несогласен тогда другое дело.
Вообще-то наука строится на фактах, а не на мнении авторитетов.
S_S>Да и из статьи следует что никаких проблем и отклонений в расчетах нет. S_S>Есть только проблемы у него самого с объяснением этого всего на уровне болтологии/рассуждений без формул и без расчетов, на основе словестных обьяснений надерганных из какой-то литературы. S_S> Есть где нибудь информация что описанные проблемы, еще для кого-то являются проблемами, или с расчетами значительно не сходится?
Читай внимательнее:
Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.
Т.е. объяснение Гофмана противоречит наблюдаемым фактам.
S_S>Вобщем, Гофман согласен, Хатч не согласен.
С точки зрения науки совершенно не важно с чем согласны или нет Гофман и Хатч, важно то, что объяснение предлагаемое Гофманом противоречит фактам, а, значит, является неверным.
Re[5]: Почему объектно-ориентированное программирование пров
Здравствуйте, Undying, Вы писали:
U>С точки зрения науки совершенно не важно с чем согласны или нет Гофман и Хатч, важно то, что объяснение предлагаемое Гофманом противоречит фактам, а, значит, является неверным.
Его рассуждения может чему то и противоречат. Но найдутся такие знатоки, которые якобы докажут, что теория относительности не верна потому что якобы есть проблема с парадоксом близнецов. На уровне рассуждений так все логично опишут что и не придерешься. Но проблемы то у них в рассуждениях.
Очень похоже это тот же случай с Хатчем.
Re[5]: Почему объектно-ориентированное программирование пров
Здравствуйте, Undying, Вы писали:
U>Читай внимательнее: U>
U>Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.
На земле нет разницы в ходе часов от такого фактора как разная близость к солнцу и разная скорость вращения вокруг солнца часов в разных точках, как-то компенсируются факторы.
Для разных точек спутниковой орбиты такой разницы тоже нет. Это пока еще ничему не противоречит.
Его обьяснения про то что радиус спутниковой орбиты в 4 раза больше земли неубедительны. Если он что по-делу хотел сказать, или что-то откопал толковое, привел хотя бы цифры — насколько у него расчеты не сходятся, миллионные доли процента или десятки процентов, но он этого и сам похоже не знает.
Re[5]: Почему объектно-ориентированное программирование пров
И кстати, самое главное, о каком порядке величин идет речь.
Это верно, что часы, которые облетают Солнце за год по радиусу земного полдня должны иметь тот же ход, что часы, которые облетают Солнце за год по радиусу земной полночи, то есть потенциальное гравитационное различие должно компенсироваться скоростным различием.
Какой получается порядок величины скоростного различия?
Скорость земли по орбите 100 000 км/ч. Радиус земли меньше радиуса ее орбиты в 12500 раз.
Разница скоростей между ночной и дневной орбитами 100000/12500 км/ч ~~ 8 км/ч
Это скорость пешехода. А скорости спутников в тысячи раз больше, если прибавить скорость пешехода то мало что изменится.
Если до такой точности эффекты проститывать, то гораздо сложнее, т.к. можно что-то потерять, привнести погрешность. Тем более что что там нелинейности. И тем более что там не только скорости замерять, а и отклонения от округлой формы Земли учитывать.
Я таких расчетов не делал и не видел, он похоже тоже.
P.S.
И вобще, если бы кто-то действительно нашел экспериментальные нестыковки в ТО. То ученые все бы бросили, забросили и многострадальный колайдер, ринулись бы ставить эксперименты перепроверять, такой бы шум подняли...
А так, есть еще не только Хатч, но и Хатчинсон
Вот первое из гугла, но сам не читал (только какой-то сюжет по ТВ видел): http://x-faq.ru/index.php?topic=67.0
Он уже научился делать антигравитацию, при помощи нескольких осциллографов и приборов 60-годов. Даже по телевидению показывали. Но все равно тишина по этому поводу, наверное не из-за того что антигравитация в народном хозяйстве пока не нужна.
А ао поводу Хатча, тишина, наверное не из-за того что что никому нет дела ТО ошибочна или нет.
Re[5]: Почему объектно-ориентированное программирование пров
Здравствуйте, igna, Вы писали:
I>В данном случае проблема действительно не в ООП, а в конкретной его реализации в большинстве языков программирования, допускающих диспетчеризацию только по одному параметру. Тем не менее большинство программистов как бы не чувствуют закорюченности используемых ими ООП языков программирования, что печально, поскольку тормозит прогресс.
Т. е. исходное утверждение сводится к "ООП провалилось, потому что в нём нет мультиметодов"? Не боитесь опухнуть это доказывать? Можете начать с того, что ООП исключает наличие мультиметодов. =))
Re[5]: Почему объектно-ориентированное программирование пров
Здравствуйте, Undying, Вы писали:
U>С точки зрения науки совершенно не важно с чем согласны или нет Гофман и Хатч, важно то, что объяснение предлагаемое Гофманом противоречит фактам, а, значит, является неверным.
Вот так вот греки и отвергли гелиоцентрическую систему...
ЗЫ Разбудили во мне тролля. Хотя, под такой статьёй — можно.
Re: Почему объектно-ориентированное программирование провали
Здравствуйте, Игорь САВЧУК, Вы писали:
ИС>Аннотация: ИС>Среди множества идей, которые звучат красиво скорее в теории, чем на практике, объектно-ориентированное программирование занимает особое место. Попробуем разобраться и ответить на главный вопрос, почему всё же объектно-ориентированное программирование провалилось?
Раз тут все такие обобщатели, я тоже хочу оттянуться и обобщить. Чем я хуже?
Изменения (какие бы то ни было) часто происходят скачком. В ходе этого скачка изменения, бывает, заходят слишком далеко и наступает то, что на советском русском называлось "реакция". В википедии я нашел только политическое значение этого термина. А оно гораздо шире. Пример из области доткомов (и тоже с обобщением) приводит Игорь Ашманов. Другой пример — религиозная реакция. Общество переходит от религиозного прошлого к игностическому будущему, его заносит в ярое богоборчество, в настоящее время происходит откат (религиозная реакция). Ну вот, его поколбасит еще немного на стрелках и переход на новые рельсы состоится.
То, что мы видим с ООП, по-моему, отлично укладывается в эту схему. Переход от лапши к ООП сопровождался таким нездоровым hype, его всовывали в такие дыры... Да вот же, рядом пример: Так ли нужны делегаты и лямбды?
. По мне, так сама Джава — еще один готовый пример. После чего происходит реакция на overhype. Голоса против громко зазвучали. Повышенный интерес к ФП появился. Это значит, что мы (только теперь!) проходим неизбежный откат, теряем иллюзии и отучаемся совать ООП не в те дыры. Обсуждаемый текст (скорее, его первоисточники) — манифестация реакционеров.
Вопрос, следовательно, в том, каково оно — программирование на productivity plateau этой технологии? Мой личный ответ: подобающее ООП место — "скелет" проектов. Набор классов, который описывает предметную область, позволяя проектным нубам быстрее врубаться. Набор интерфейсов, который показывает, какие роли какие сущности могут играть. Не больше и не меньше. При этом "мясо", то есть реализация и алгоритмы, может быть замешано на чем угодно — на процедурном подходе, на ФП, на лямбдах, делегатах etc. etc.
Лично мне очень печально бывает наблюдать реакционеров, которые отрицают объектность как таковую, не пытаются провести декомпозицию... и при этом мнят себя прогрессивными силами. Поэтому, идею реакционности следовало бы знать и уметь применять.
Re[2]: Почему объектно-ориентированное программирование пров
Здравствуйте, SV., Вы писали:
SV.>Вопрос, следовательно, в том, каково оно — программирование на productivity plateau этой технологии? Мой личный ответ: подобающее ООП место — "скелет" проектов. Набор классов, который описывает предметную область, позволяя проектным нубам быстрее врубаться. Набор интерфейсов, который показывает, какие роли какие сущности могут играть. Не больше и не меньше.
А есть ли там вообще ООП? Те самые наследование реализации, инкапсуляция, полиморфизи, объекты с идентичностью и поведением.
Или это всетаки больше SOA, где выкинуты сомнительные свойства вроде идентичности и наследования реализации?
Re[3]: Почему объектно-ориентированное программирование пров
Здравствуйте, gandjustas, Вы писали:
SV.>>Вопрос, следовательно, в том, каково оно — программирование на productivity plateau этой технологии? Мой личный ответ: подобающее ООП место — "скелет" проектов. Набор классов, который описывает предметную область, позволяя проектным нубам быстрее врубаться. Набор интерфейсов, который показывает, какие роли какие сущности могут играть. Не больше и не меньше. G>А есть ли там вообще ООП? Те самые наследование реализации, инкапсуляция, полиморфизи, объекты с идентичностью и поведением. G>Или это всетаки больше SOA, где выкинуты сомнительные свойства вроде идентичности и наследования реализации?
Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее.
Например, и "воробьи", и "вороны" (обобщенно — "птицы") имеют в своем составе "крылья" и летает, "махая" ими. "Воробьи" являются "птицами", и летают как любая другая "птица" — "махая" (по-птичьи) "крыльями" (птичьими). НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как). При написании софта, надо повторять это объективное отношение (подкласс <вид "воробей"> наследует такое поведение, как полет, у суперкласса <класс "птиц">), потому, что такой софт проще писать, читать и понимать, а также потому, что дурацких противоречий ("Ва-а-ась, как оно теперь у нас будет плавать, с такими-то крыльями?!") гарантированно не возникнет.
Что делали оверхайперы? Одни засирали эту простую и понятную схему тысячами типов-терминаторов (воробьи — воробьиноклювые — воробьинообразные — ... — серокрылые — птицевидные — ... — зерноядные — ... — летающие динозавры) до полной нечитаемости. Другие засирали эту простую и понятную схему неумеренной детализацией ("воробей" состоит из костей 100 видов, примерно 1.314 костей каждого вида, тканей 100 видов, а расфазовка отдельного "маха" приведена на той же схеме) до полной нечитаемости. Третьи, совсем никчемные, выводили бескрылых воробьев, оброщенных мехом, и получали таким образом белку-летягу (хороший пример из жизни — если повар наш не врет — можно найти тут: http://burrarum.livejournal.com/32707.html).
Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций.
Re[4]: Почему объектно-ориентированное программирование пров
Здравствуйте, SV., Вы писали:
SV.>Грамотная декомпозиция на значимые сущности...
Настоящим открытием для меня было, как мало людей умеют это делать. Взять хоть написание документа, посвященного интерфейсу разрабатываемого продукта П. Читаешь — все в кучу, мысли с пятого на десятое, оглавление похоже черт знает на что. Когда такие люди садятся программировать в ООП-стиле, можете себе представить.
Re[4]: Почему объектно-ориентированное программирование пров
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, gandjustas, Вы писали:
SV.>>>Вопрос, следовательно, в том, каково оно — программирование на productivity plateau этой технологии? Мой личный ответ: подобающее ООП место — "скелет" проектов. Набор классов, который описывает предметную область, позволяя проектным нубам быстрее врубаться. Набор интерфейсов, который показывает, какие роли какие сущности могут играть. Не больше и не меньше. G>>А есть ли там вообще ООП? Те самые наследование реализации, инкапсуляция, полиморфизи, объекты с идентичностью и поведением. G>>Или это всетаки больше SOA, где выкинуты сомнительные свойства вроде идентичности и наследования реализации?
SV.>Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее.
Но далеко не любая программа является моделью части реального мира. Даже наоборот, программ где такой подход оправдан исчезающе мало.
SV.>Например, и "воробьи", и "вороны" (обобщенно — "птицы") имеют в своем составе "крылья" и летает, "махая" ими. "Воробьи" являются "птицами", и летают как любая другая "птица" — "махая" (по-птичьи) "крыльями" (птичьими). НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как). При написании софта, надо повторять это объективное отношение (подкласс <вид "воробей"> наследует такое поведение, как полет, у суперкласса <класс "птиц">), потому, что такой софт проще писать, читать и понимать, а также потому, что дурацких противоречий ("Ва-а-ась, как оно теперь у нас будет плавать, с такими-то крыльями?!") гарантированно не возникнет.
Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.
SV.>Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций.
Выделенное необоснованно.
Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.
Re[5]: Почему объектно-ориентированное программирование пров
Здравствуйте, gandjustas, Вы писали:
SV.>>Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее. G>Но далеко не любая программа является моделью части реального мира. Даже наоборот, программ где такой подход оправдан исчезающе мало.
Коль скоро это так, вас, конечно же, не затруднит привести пример программы, которая не является моделью?
SV.>>Например, и "воробьи", и "вороны" (обобщенно — "птицы") имеют в своем составе "крылья" и летает, "махая" ими. "Воробьи" являются "птицами", и летают как любая другая "птица" — "махая" (по-птичьи) "крыльями" (птичьими). НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как). При написании софта, надо повторять это объективное отношение (подкласс <вид "воробей"> наследует такое поведение, как полет, у суперкласса <класс "птиц">), потому, что такой софт проще писать, читать и понимать, а также потому, что дурацких противоречий ("Ва-а-ась, как оно теперь у нас будет плавать, с такими-то крыльями?!") гарантированно не возникнет. G>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.
Откуда взялась такая странная цель — отношение is-a? Моя цель, извините, это код, который проще писать, читать и понимать, и с гарантированным уничтожением риска противоречий (если какие-то отношения непротиворечивы в природе, значит в модели они тоже будут такими же). Если не подменять прагматические цели фантомными, то я же на все ответил, прочитайте еще раз.
Возьмем, например, старый добрый COM. Он регламентирует только наследование интерфейсов. Дальнейшее — дело ваше. Можно строить параллельную иерархию классов с (возможно, множественным) наследованием реализаций, можно прибегнуть к агрегированию. Специально этот случай я и рассмотрел:
>НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как).
Что касается утиной типизации, то это способ перейти от явных контрактов к неявным, сэкономив на объявлении контракта, и к делу (способу выполнения контракта) не относится.
SV.>>Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций. G>Выделенное необоснованно.
Очень странно, что именно выделенное, поскольку это пример. Как может быть обосновано утверждение, но пример к нему — нет?
G>Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.
А это смотря что считать достижениями. Если is-a, то это не достижение, а тип отношения. Если код, который проще писать, читать и понимать, и с гарантированным уничтожением риска противоречий, то парадигма ООП может работать как на него, так и против. Примеры и того, и другого я привел.
Re[6]: Почему объектно-ориентированное программирование пров
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, gandjustas, Вы писали:
SV.>>>Сама "сомнительность" наследования реализации — следствие тех самых overhype и втыкания во все дыры. Сомнительным может быть конкретное применение, но не прием. Почему? Потому, что наследование реализации — объективное явление (вне нашего сознания и интерпретаций). И если оно наблюдается в моделируемом куске жизни, повторение его в модели (а любой софт это модель) делает ее полезнее. G>>Но далеко не любая программа является моделью части реального мира. Даже наоборот, программ где такой подход оправдан исчезающе мало.
SV.>Коль скоро это так, вас, конечно же, не затруднит привести пример программы, которая не является моделью?
Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.
SV.>>>Например, и "воробьи", и "вороны" (обобщенно — "птицы") имеют в своем составе "крылья" и летает, "махая" ими. "Воробьи" являются "птицами", и летают как любая другая "птица" — "махая" (по-птичьи) "крыльями" (птичьими). НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как). При написании софта, надо повторять это объективное отношение (подкласс <вид "воробей"> наследует такое поведение, как полет, у суперкласса <класс "птиц">), потому, что такой софт проще писать, читать и понимать, а также потому, что дурацких противоречий ("Ва-а-ась, как оно теперь у нас будет плавать, с такими-то крыльями?!") гарантированно не возникнет. G>>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.
SV.>Откуда взялась такая странная цель — отношение is-a?
Так ты об этом написал выше. Переведя на английский часть выделенное выше получим "sparrow is a bird".
SV.>Что касается утиной типизации, то это способ перейти от явных контрактов к неявным, сэкономив на объявлении контракта, и к делу (способу выполнения контракта) не относится.
А вот и нет, далеко не всегда ты сможешь утинотипизированный код заменить на явнотипизированный. Далеко не все языки позволят такое написать.
G>>Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.
SV.>А это смотря что считать достижениями. Если is-a, то это не достижение, а тип отношения. Если код, который проще писать, читать и понимать, и с гарантированным уничтожением риска противоречий, то парадигма ООП может работать как на него, так и против. Примеры и того, и другого я привел.
А кто тебе сказал что наследование реализации "проще писать, читать и понимать"?
Re[7]: Почему объектно-ориентированное программирование пров
G>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.
но значит у тебя модель другого мира. модель проекта, например.
SV.>>Что касается утиной типизации, то это способ перейти от явных контрактов к неявным, сэкономив на объявлении контракта, и к делу (способу выполнения контракта) не относится. G>А вот и нет, далеко не всегда ты сможешь утинотипизированный код заменить на явнотипизированный. Далеко не все языки позволят такое написать.
так и пиши тогда целую фразу правильно: далеко не во всех языках ты сможешь утинотипизированный код заменить на явнотипизированный.
но ведь это же проблема языков. верно ведь?
G>А кто тебе сказал что наследование реализации "проще писать, читать и понимать"?
наследовать реализацию обычно проще, чем писать ее заново.
Re[7]: Почему объектно-ориентированное программирование пров
Здравствуйте, gandjustas, Вы писали:
SV.>>Коль скоро это так, вас, конечно же, не затруднит привести пример программы, которая не является моделью? G>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.
Техзадание на ваше приложение имеется? Оно — модель реальности, а ваш код — перевод этой модели с русского или английского языка на ЯП, а, следовательно, тоже модель. В то, что при переводе ключевые сущности оказались заменены другими, я не очень верю, но если поверить, то гордиться тут нечем. А если считаете, что есть чем, расскажите больше.
SV.>>>>Например, и "воробьи", и "вороны" (обобщенно — "птицы") имеют в своем составе "крылья" и летает, "махая" ими. "Воробьи" являются "птицами", и летают как любая другая "птица" — "махая" (по-птичьи) "крыльями" (птичьими). НЕ ПОТОМУ, что внутри у "воробья" сидит абстрактная "птица" или какой-нибудь вполне конкретный "летатель", и летает за него (при этом, имеет форму черного ящика, то есть летает неизвестно как). При написании софта, надо повторять это объективное отношение (подкласс <вид "воробей"> наследует такое поведение, как полет, у суперкласса <класс "птиц">), потому, что такой софт проще писать, читать и понимать, а также потому, что дурацких противоречий ("Ва-а-ась, как оно теперь у нас будет плавать, с такими-то крыльями?!") гарантированно не возникнет. G>>>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.
SV.>>Откуда взялась такая странная цель — отношение is-a? G>Так ты об этом написал выше. Переведя на английский часть выделенное выше получим "sparrow is a bird".
А если не часть перевести, а все целиком? Может, на английском понятнее будет?
Being a "bird", a "sparrow" flies like a "bird" NEITHER BECAUSE it delegates flying to an aggregated "bird" or a "flyer" (which are black box shaped at that, since we don't know how they fly), NOR because it somehow imitates flying in a special sparrow manner, but because it uses the same "wings" in the same way as every "bird" does. SO HOW DOES IT FLY?
К черту шутки и мой скверный английский. Каким образом обеспечивается is-a, вот о чем речь.
SV.>>Что касается утиной типизации, то это способ перейти от явных контрактов к неявным, сэкономив на объявлении контракта, и к делу (способу выполнения контракта) не относится. G>А вот и нет, далеко не всегда ты сможешь утинотипизированный код заменить на явнотипизированный. Далеко не все языки позволят такое написать.
Этого я не понял.
G>>>Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.
SV.>>А это смотря что считать достижениями. Если is-a, то это не достижение, а тип отношения. Если код, который проще писать, читать и понимать, и с гарантированным уничтожением риска противоречий, то парадигма ООП может работать как на него, так и против. Примеры и того, и другого я привел. G>А кто тебе сказал что наследование реализации "проще писать, читать и понимать"?
Я не буду уподобляться оверхайперам от ООП и принимать на себя бремя такого спорного утверждения, которое вы мне приписали. Вот мое утверждение: когда в моделируемой системе мы выделяем значимые сущности, одна из которых ведет себя как другая за счет того, что имеет те же приспособления, используемые таким же образом, то обе значимые сущности на этапе программирования должны стать классами, причем первый унаследовать реализацию от второго. Должны, конечно, если мы хотим иметь код, который проще писать, читать и понимать.
Re[8]: Почему объектно-ориентированное программирование пров
Здравствуйте, DarkGray, Вы писали:
G>>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.
DG>но значит у тебя модель другого мира. модель проекта, например.
Ты всегда сводишь к абсурду. У тебя получается что объект — модель какого-то "мира".
SV.>>>Что касается утиной типизации, то это способ перейти от явных контрактов к неявным, сэкономив на объявлении контракта, и к делу (способу выполнения контракта) не относится. G>>А вот и нет, далеко не всегда ты сможешь утинотипизированный код заменить на явнотипизированный. Далеко не все языки позволят такое написать.
DG>так и пиши тогда целую фразу правильно: далеко не во всех языках ты сможешь утинотипизированный код заменить на явнотипизированный.
Далеко не во всех вообще возможна утиная типизация. но если взять типовой язык где она возможна (js) и сравнить с типовым языком со статической типизацией (java) то многое не получится в них выразить.
DG>но ведь это же проблема языков. верно ведь?
Не языков, а парадигмы. Об этом и разговор.
G>>А кто тебе сказал что наследование реализации "проще писать, читать и понимать"? DG>наследовать реализацию обычно проще, чем писать ее заново.
Есть другие способы повторного использования кода.
Re: Почему объектно-ориентированное программирование провали
Здравствуйте, Игорь САВЧУК, Вы писали:
ИС>Аннотация: ИС>Среди множества идей, которые звучат красиво скорее в теории, чем на практике, объектно-ориентированное программирование занимает особое место. Попробуем разобраться и ответить на главный вопрос, почему всё же объектно-ориентированное программирование провалилось?
Никто никуда не проваливался. И парадигма позволяет стандартным образом подходить к новой задаче. Это уже плюс так как стандартизирует сам процесс понимания и общения.
