LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от www_linux_org_ru

> Попробуй, например, опиши множество операций над обычным четыерхбайтовым int. А я посмеюсь.

а в чём проблема? Там нет операций, пока их не задали в виде кода. Абстрактная область памяти - четырёхбайтовый int - это 32 бита памяти, какой бы адрес ни был. Всё. А вот если бухгалтер _дополнительно_ скажет, что реально там должна лежать зарплата - я уже дополнительно знаю, что оно не отрицательно, и хорошо ограничено сверху, а если тётя ещё больше мне сообщит - то я больше буду знать, и более компактно смогу использовать память и может и некоторые биты отщипну от данных, например смогу хранить центы или флаги или другие внутренние аттрибуты, которые скажет тётя Особенно если надо обрабатывать гигабайты. Но будем различать внешние типы (как протокол бизнес-программер) от внутренних типов внутри «чёрного ящика» (программер-программер). короче, если не описаны множества операций над int - их просто нет. Ты хочешь описать все возможные программы на будущее? Или я не понял?

anonymous ()
Ответ на: комментарий от www_linux_org_ru

> тип — это подмножество множества предикатов от: результатов операций над типом и строк, именующих сам тип и эти операции. В случае включения Т1 в Т2 (включения как множества) Т2 часто (всегда?) считается тем же типом, что Т1.

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

anonymous ()
Ответ на: комментарий от anonymous

> В случае включения Т1 в Т2 (включения как множества) Т2 часто (всегда?) считается тем же типом, что Т1.

а антиномию Рассела не получим?

anonymous ()
Ответ на: комментарий от tailgunner

> Берем за основу.

Это хорошая основа для того, чтобы *представлять себе* тип, но не *определять* его. (Впрочем, предикаты иногда вне конкуренции и для того, чтобы представлять себе)

Я еще подумаю, как наехать на твое определение.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

на область определения можно наплевать

достаточно задать некие предикаты, что значений не меньше чем... и все будет ОК

например: 255 раз прибавляя к 0 типа char единицу, мы не получим 0 ни на одном шаге

а если в реализации char оказался 4-х байтовый — нам наплевать

мы можем добавить предикат 1+1+...+1+1=0 (256 единиц), это будет другой тип

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

> а антиномию Рассела не получим?

не врубаюсь откуда можно ее получить

вообще там я не сказал про эквивалентность типов Т1 и Т2 — но видимо легко домыслить, что она дается T1<T2* && T2<T1*, где * это транзитивное замыкание множества операцией логического вывода, а < обозначено включение множеств.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> на область определения можно наплевать

отсутствиее области определения сильно усложнит жизнь. (или наоборот: наличие - сделает жизнь несравнимо легче, а предикаты - проще). Зачем ждать любого ввода - когда известно что число ограничено?

вообще там я не сказал про эквивалентность типов Т1 и Т2 — но видимо легко домыслить, что она дается T1<T2* && T2<T1*, где * это транзитивное замыкание множества операцией логического вывода, а < обозначено включение множеств.

значит я не так понял. против иерархии типов (различных) конечно же ничего не имею.

anonymous ()
Ответ на: комментарий от anonymous

>это то что может описать реальным языком бухгалтер

То, что может описать реальным языком бухгалтер, называется объектом предметной области.

А у такого рода объектов должен быть единственныйй тип... Абстрактный. О нем мы не знаем ничего, кроме того что он а) есть, б) можем с ним работать с помощью некего публично доступного интерфейса.

Не собачье дело бухгалтера знать струкуру типа Деньги. Может быть он у меня двумя интежерами представлен, а может быть БигИнтом, но в копейках. Самое смешное, как только я закончу проектировать соответствующий модуль, конкретная струкура типа тоже не мое собачье дело, и я так же как и все простые смертные буду пользоваться публичным интерфейсом.

ООПники это кажется называют энкапсуляцией. Только ООПники не понимают, что для ее достижения не обязательно прятать исходную структуру в бочку и общаться с ней с помощью мессаг. Можно сделать все с точностью до наоборот. Только сделать так, чтобы на орпеделенном уровне компилятор «забывал», что имеет дело с конкретной структурой. Все!

И тогда тип твоего объекта предметной области или объекта бизнес-логики или как там его назыают, будет самым обычным типом языка. И не будет нужды заставлять программиста заморачиваться и интерфейсом и поведением, как это делается в мейстрим ООП.

Macil ★★★★★ ()
Ответ на: комментарий от tailgunner

> Берем за основу.

Вероятно (щас точно не скажу), что можно выписать предикат над объектом так, что множество атомарных операций, модифицирующих объект с сохранением предиката В ЛЮБОМ СЛУЧАЕ будет бесконечно и более того, не сможет быть параметризовано вычислимой функцией (т.е. нельзя написать макрос, которому на вход подаешь натуральное число, а на выходе получаешь одну из атомарных операций).

Я это без колебаний назову типом данных. А ты?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

А я не стану. По крайней мере, в программировании тип с бесконечным количеством атомарных операций бесполезен.

tailgunner ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

С моей точки зрения, это тип данных, так как можно выписать *только нужные* для проекта атомарные операции и временно забить на остальные. Если потребуется, в будущем будут добавлены еще атомарные операции.

Однако предикат неизменен.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

> По крайней мере, в программировании тип с бесконечным количеством атомарных операций бесполезен.

Вовсе нет. Множество необходимых *для данного проекта* атомарных операций всегда конечно, т.к. исходный код конечен :-)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

это аналогично тому, как вместо бесконечно длинного вещественного числа использовать 80-битное

практично

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от Macil

Значит именно и только абстрактный тип - должен считаться типом, так как тип абстрактен а не конкретен. Конкретна реализация из-за конкретного умения конкретного программиста (а другой всё сделает по иному, за более короткий срок) на конкретном железе для конкретного перформанса. Программист или железо поменяется - конкретные внутренние типы придётся менять. А бизнес - нет. Они так и будут оперировать с деньгами с такими-то пределами. Внутри чёрного ящика тоже есть типы, но мы не должны врываться внутрь. Тогда при разделения на модули или другие чёрные ящики - появятся новые абстрактные типы как протоколы коммуникации между модулями/программистами.

Я всё время называю тип также и протоколом коммуникации между кем-то и кем-то (людьми), четвёртое определение, эквивалентное грамматике. Машине типы не нужны. А людям нужно что-то простое, легко описываемое. А не несколько экранов сплошного кода с кучей индирекшенов и без пробелов (я и такое видел: чувак написал DSL как бы для облегчения. В результате он не то что не читаем бизнесом, но и си или джава программисты не могут разобраться в коде неделями. Смысл в таком протоколе?). Т.е. и объект предметной области - это тоже тип, только на человеческом языке (чем строго определённая грамматика использующая английские слова хуже?). Главное, чтобы противоречий не было. А разобрать - дело техники (написания парсера) чем и занимается дата майнинг. Главное - чтобы было просто и управляемо.

И именно бухгалтер знает деньги, а я не знаю. Я знаю фишки своего языка и приспособлю язык - к реальному типу, вынужденный подкручивать какой-нибудь int или long из-за того что ничего другого (того типа «Деньги», что надо именно этому бухгалтеру) у меня нет. Да и не надо.

anonymous ()
Ответ на: комментарий от anonymous

я тут случайно смешал 2 вещи не так скопипастив с транслита. Дата-майнинг хотел привести как пример также оперирующий чисто стрингами (никаких типов изначально). Так же как и в эксперных системах фреймевые языки (или как и в теории множеств) - все слоты хранят объект одного типа - стринг. Много типов не нужно. А вот уже интерпретатор (функция) сделает всё как надо и может вообще без типов. О чём и топик.

anonymous ()

В функцианальщине есть оопе, в оопе есть функцианальщина. Кто куда провалился?

Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Особенно если учесть, что в лиспе ООП не на последнем месте.

“Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы.

Что за бред?

Как только ты сказал слово «объект», можешь сразу забыть о модульности

Снова какой-то бред сумасшедшего.



Booster ★★ ()
Ответ на: комментарий от www_linux_org_ru

А чем не подойдёт представление int как чисел по модулю 2^(4*8)? На таком множестве вполне вводится кольцо и соответствующие арифметические операции.

quasimoto ★★★★ ()
Ответ на: комментарий от anonymous

>Я всё время называю тип также и протоколом коммуникации между кем-то и кем-то (людьми)

Мне кажется, что стоит таки разделять понятия «тип» и «интерфейс». К сожелению, одной из самых грустных фишек ООП является понятие «интерфейск как супертип». Т.е. если наша сущность хочет получить какой-то интерфейс, она автоматически становится его субтипом. По идее, это нужно для соответствия принципу замещения Лисков. Еще комичнее дела состоят с абстрактными классами, где в отличие от интерфейсов, некоторые методы оставлены нереализованными. Тут LSP вообще не может работать, т.к. абстракный класс по-оперделению не может использоваться.

Как результат, в любом разлапистом фреймворке сушествуют конкретные обертки интерфейсов/абстрактных классов, реализации которых либо ничего не делают, либо кидают исключение. За оба варианта такого «использования» нужно убивать. Хотя вроде бы в яве есть соответствующие аннотации, и можно на этапе компиляции отловить.

Интерфейс не определяет тип. Тип не определяет инетрфейс. А вот определяет ли интефейс пресловутый объект предметной области? А почему бы и нет. Если что-то лает, как собака, кускает, как собака...

Кстати, вспомнил 1С. Там объекты предметной области вообще не определяются с помощью языка программирования. С его помощью реализована работа с разлапистыми метаданными конфигурации. А язык откровенно слабый. Где-то на уровне shell'а. Это к вопросу о мощи языка, и определения типов вне его.

Macil ★★★★★ ()
Ответ на: комментарий от Booster

>Что за бред?

Это не бред. Это суровая правда жизни. Класс тройственен по своей природе. Он определяет тип, интерфейс и поведение своих объектов. Более того, в реальной ситуации, типы, интерфейс и поведение объекта будут определяться иерархией классов. И мы не можем этому помешать: нам обязательно наследовать тип, нам обязательно наследовать полный интерфейс, нам обязательно наследовать поведение. В противном случае мы будем нарушать LSP.

Снова какой-то бред сумасшедшего.


Опять же нет. Традиционный ООП подразумевает, что класс — единица компиляции. Любое расширение, либо через наследование, либо через включение (но тогда резко пострадает реюзабельность). Если мы не хотим, или не можем реализовать интерфейс полоностью, мы обязаны объявить класс абстрактным, и расширять его только наследованием.

Macil ★★★★★ ()
Ответ на: комментарий от pathfinder

Народ, завязывайте с этой схоластикой. Найдите темы для более конструктивного разговора.

pathfinder ★★★ ()

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

Divius ★★ ()
Ответ на: комментарий от Divius

Всем кто написал в своем недокомментарии слово «бред»: вы его сами пишите или из предыдущих постов копипастите?

unlog1c ★★★ ()
Ответ на: комментарий от unlog1c

Мы это поняли, ибо у нас есть инструмент под названием «мозг», в отличие от тех, кто этот бред писал и копипастил.

Divius ★★ ()
Ответ на: комментарий от Divius

Судя по всему, у вас это инструмент для забивания гвоздей.

unlog1c ★★★ ()

> Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома

Аристотель перевернулся в гробу.

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

>> Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома

Аристотель перевернулся в гробу.

Он бы перевернулся уже из-за понятия отрицательного числа, не говоря об алгебре и мнимых. Учите историю математики, и особенно тем - чем математика занималась в 20 веке. Вы не в теме и остановились на математике средней школы.

anonymous ()
Ответ на: комментарий от pevzi

Форма работы с ней, и самое главное - что нужно считать аксиомой - изменились. Если вы не математик - почему у вас есть основания недоверять математику Степанову? Или другим постерам, в числе которых есть люди в теме. Откуда такая самоуверенность?

anonymous ()
Ответ на: комментарий от Macil

Ого. Какой критик реализации «настоящего ООП» нарисовался. Сделай свою реализацию ООП (хотя бы на тех же LISP или FORTH). Потом критикуй смалтолкеров.

Meerkat ()
Ответ на: комментарий от Meerkat

Умник, иди учи матчасть. Особенно CLOS. А потом систему модулей в SML.

Macil ★★★★★ ()
Ответ на: комментарий от Meerkat

> Ого. Какой критик реализации «настоящего ООП» нарисовался. Сделай свою реализацию ООП (хотя бы на тех же LISP или FORTH). Потом критикуй смалтолкеров.

Эта... В Forth уже есть реализация словарей VOCABULARY, с CURRENT, CONTEXT, DEFINITIONS, EXECUTE, FIND и прочими...

Впрочем, есть неплохой пример JOOP: http://www.forth.org.ru/~day/

anonymous ()
Ответ на: комментарий от anonymous

>> тип — это подмножество множества предикатов от: результатов операций над типом и строк, именующих сам тип и эти операции. В случае включения Т1 в Т2 (включения как множества) Т2 часто (всегда?) считается тем же типом, что Т1.

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

IMHO:

Операция: переход от начального множества к результирующему множеству.

Тип: начальное множество + операции над ним. В виде побочного эффекта можно получить набор результирующих множеств. (Для строк это может быть и подстрока, и количество символов /число/, и ссылка на источник-место в тексте или толковом словаре, к примеру. Этот подход предполагает наличие определений всех упомянутых типов.)

Иерархия наследования типов - изначально умозрительна, а полиморфизм - , вообще, система синонимов. Вся система, imho, слишком завязана на субъективные ассоциативные ряды /воображение/ разработчика. Это проблема повторного использования.

anonymous ()
Ответ на: комментарий от anonymous

Хотел подчеркнуть, что реализация «настоящего ООП» в Forth была от рождения, в виде реализации словарей и набором фишек с ними связанных.

А JOOP (http://www.forth.org.ru/~day/ для SPF) - скорее пример более «привычного» ОПП, в том, кхм, маниакальном виде, в каком он присутствует в современных языках программирования. :)

anonymous ()

ООП провалилось, ахаха. Тонны кода пишется ежедневно с объектами Жаба-Жабаскрипт-Дельфи-Шарпы и прочее.

anonymous ()
Ответ на: комментарий от anonymous

>Тонны кода пишется ежедневно с объектами

Так в этом же и дело! «Объектность» (в популярном нынче смысле) делает код нынешних задач «многотонным».

DonkeyHot ★★★★★ ()
Ответ на: комментарий от anonymous

> ООП провалилось, ахаха. Тонны кода пишется ежедневно с объектами Жаба-Жабаскрипт-Дельфи-Шарпы и прочее.

Голод, болезни и войны исчезли, ахаха. Миллионы людей ежедневно голодают, воюют, убивают.

anonymous ()
Ответ на: комментарий от DonkeyHot

а на лиспе оно типа короче выглядит? Тута на лоре уже мерялись количеством строк одинаковых алгоритмов на С++ и Лисп. Лисп нисколько не короче оказался, несмотря на все старания лисперов.

anonymous ()
Ответ на: комментарий от quasimoto

имхам не место в этом деле...

Гы... А ты знаешь, чем сознательное отличается от несознательного?

anonymous ()
Ответ на: комментарий от Rastafarra

> ты кстати воюешь на ai-contest? а то чет лисперы там сливают.

Нет, конечно, я не занимаюсь «конкурсными» задачами.

archimag ★★★ ()
Ответ на: комментарий от anonymous

А ты знаешь, чем сознательное отличается от несознательного?

Ты не можешь осознавать бессознательное полностью в силу самой его природы. А та реплика к тому что типы, отображения и прочее - определённые математические понятие. Что тут выяснять?

quasimoto ★★★★ ()
Ответ на: комментарий от anonymous

>Хотел подчеркнуть, что реализация «настоящего ООП» в Forth была от рождения, в виде реализации словарей и набором фишек с ними связанных.

Афигеть, круче будет только Фортран назвать функциональным языком.. Дружище, ты хоть раз Форт в глаза видел? Словари там с трудом на неймспейс тянут..Где там инкапсуляция данных и методов? Или хотя бы их имитация?

anonymous ()
Ответ на: комментарий от anonymous

>Словари там с трудом на неймспейс тянут..Где там инкапсуляция данных и методов?

Вот словари инкапсуляцию и обеспечивают. И полиморфизм :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>Вот словари инкапсуляцию и обеспечивают. И полиморфизм :)

Угу, как слово FUNCTION обеспечивает функциональное программирование в фортране. А COMMON - обобщенное.

Чёж за наследование забыли? Или словари не обеспечивают?

anonymous ()
Ответ на: комментарий от anonymous

>Угу, как слово FUNCTION обеспечивает функциональное программирование в фортране

Да нет, тут именно некий идеологический аналог «настоящего» ООП получается.

Чёж за наследование забыли?


Наследование имитировать можно :) Сделать так, чтобы при вызове нового словаря автоматически подставлялся контекст «родительского». Собственно, очень частый приём был.

Другое дело, что «ООП» такое где-то ближе к Смолтоковским понятиям, без разделения на класс и объект, как в Си++ и потомках. Плюс к этому обычная уже необходимость программисту следить за типами.

...

Но в любом случае, как я выше ссылкой кидал, «настоящее ООП» на Форте делается на коленке за вечер. Но оно так никому и не нужно :D

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>Да нет, тут именно некий идеологический аналог «настоящего» ООП получается.

Нет, не получается.. Смотрите: на стеке лежит указатель на объект, нам нужно получить доступ его атрибуту(методу). Каким волшебным образом должен переключиться словарный контекст? Только вагон костылей спасет отца русской демократии..

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.