Объекты провалились

vsegda govoril sto OOP tormoz i zaputannyj:)))

oxonian, ты хоть читал, что там накропал этот неграмотный человек? Там куча голословных утверждений и вывод, что все дураки, кто не согласен. Чистая провокация flame вызвающе неверной информацией.

P.S. Сотрите ее, не новость это, не статья и не исследование.

Автор во многом прав.
Тщательное планирование - Это область, которая имеет ограничение.
Мысль о том, что необходима парадигма, которая описывала
приспособляемость - правильная.

В мире вообще много правильных мыслей. Вот круто было бы, что бы облака грузы возили, или вот, футболисты, что они просто так носятся? Пусть динамо крутят!

голословно как-то...

но он прав в одном: сча кругом как тока увидят 'ооп', так сразу готовы писаться от счастья и крутизны увиденного...

имхо

ИМХО заголовок статьи не соответствует содержанию. У автора придирки к реализации ООП в современных "модных" языках (C++, Java, C#) и к квалификации программеров их использующих, а к парадигме ООП я вобще там серъёзных аргументированных притензий не увидел... ИМХО довольно сложно автору показать недостатки таких языков (не их реализаций) как Smaltalk, Forth - их самый большой недостаток - непопсовость и "немодность" (может поэтому качественных их реализаций от софтверных "авторитетов" практически нет - это и понятно: деньги приносит массовый потребитель, а толпе не нужна классическая музыка, толпа хочет Бритни Спирс и Киркорова :( )...

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

> Сотрите ее, не новость это, не статья и не исследование.

Присоединяюсь. Судя вот по этому: "Smalltalk, Lisp, Haskell, ML и другие языки зачахли, в то время когда C++, Java и ее почти что клон C# стали единственными языками, достойными внимания" - это просто вопли обиженного жизнью функциональщика, которому лень доучиваться.

Сотрите коментарии Shaman007, не коментарии это. Там куча голословных утверждений и вывод, что все дураки, кто не согласен. Чистая провокация flame вызвающе неверной информацией.

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

ООП - лажа, его применение в больших проектах даёт эффект обратный желаемому. как ни крути (с)

> И реально, ничего там особенно крутого нету.
5 баллов! на лицо юношеский нонкомформизм ;)))

~_^

5 балов!

Глупый, глупый Shaman007.
Этак Вы вообще ничему новому не научитесь.

Ну а что есть в Smalltalk или ML, чего нет в Java или C++ и без чего я не смогу жить и писать программы?

Ну, во-первых, классикой и наиболее ранней реализацией ООП является шведская Simula, а совсем не американский Smalltalk. Кстати, Страуструп использовал именно синтаксис и идеи Simula при создании своего C with Classes, а потом и C++, откуда пошли все эти Java, C# и прочие. И это - совсем не "попсовость", а вполне разумный подход.

Во-вторых, посылка статьи довольно правильная, а вот выводу - немного крикливы...

В-третьих, приведу без комментариев вырезку из статьи: "...Безумие большого бизнеса конца прошлого века ослепило исследователей и привело к тому, что на их взгляд, то, что существует в сфере ООП сегодня, настолько близко к идеалу, что это бесспорно... Я на собственном опыте перенёс это. До того, как я ушел изучать поэзию в 1995 году, моя карьера исследователя вращалась вокруг языка программирования LISP. Когда я вернулся в 1998, я обнаружил, что моя область исследований оказалась уничтоженной ..."

Хе-хе, а вот в Haskell есть частичная реализация функций интерфейса, при котором класс становиться полностью реализованным, расскажи как это сделать на яве.

Я не понял что это такое и зачем оно мне может понадобиться. Какой выигрыш кроме нечетабельности я получу?

> Ну а что есть в Smalltalk или ML, чего нет в Java или C++ и без чего я не смогу жить и писать программы?

Это тебя уже куда-то не в ту степь занесло.

С таким подходом, жили бы мы и по сей день исключительно в консоли, и лабали проги на фортране и коболе. А что? жить можно, и даже вот программы писать...

"Что есть ... чего нет" - а ты поставь и посмотри. Или хотя бы книжки почитай, этого добра в Сети навалом. Ладно еще Smalltalk, хотя и тут жабе до него ой как далеко... но ML - это ты уже сравнил подлодку с паровозом.

Выигрыш в том, что тебе не надо весь интерфейс реализовывать, неужели непонятно?

Или досточтимый господин забыл:

Правило экономии: время программиста дорого; сохраняйте его, предпочитая машинное время. (c) Принципы UNIX(принципы KISS)

А нечИтаемость, разве что, при наличии отсутствия логического мышления, тогда тебя вообще к программированию нельзя допускать!

> Ну, во-первых, классикой и наиболее ранней реализацией ООП является шведская Simula, а совсем не американский Smalltalk.

Положим, классикой является и то, и другое =) Но симула - она все-таки из разряда первого блина, который вышел в виде местами неровноповерхностной сферы.

> Я не понял что это такое и зачем оно мне может понадобиться

Есть предложение тебе сходить вот сюда:

http://www.haskell.org/tutorial/

и почитать о том, "что это такое". Чтоб ты хотя бы знал, о чем вообще речь идет, а не просто рэндомно кидал реплики типа "а нах оно мне?"

Объекты не только не провалились, а развиваются сверх резвыми темпами, автор вероятно никогда не слышал о MDA/MDD.

> ООП - лажа, его применение в больших проектах даёт эффект обратный желаемому. как ни крути (с)
Подозреваю этот вывов следствие вашего "богатого" опыта ;-)

Не, начали сраться, так начали. У меня есть задача, сложная, очень сложная. У меня есть некоторый набор знаний, полученных в школе/универе/работе/от соседки. Вопрос - если я и так вижу ясно и четко, как будет выглядеть реализация на Java, который обрезан относительно C++, хотя бы на счет множественного наследования (да, шаблонов там действительно не хватает, факт, но это исправили и жизни по большому счету это не мешает), что может дать мне тот же самый Smalltalk? Я подозреваю, что в нем есть какие-то очень полезные и удобые вещи, о которых здорово пофлеймить в форуме. Но реальность такова, что в общем-то множественное наследование уже избыточно, так как некоторые лемминги засовывают в классы вообще все, даже если им 2 и 2 сложить надо, делая код нечитабельным.

Есть понятие инкапуляции, у инкапсулированной байды есть интерфейс, через который она замечательно работает и еще ее можно расширить, сделав частью другой байды. Чего господам еще в этой жизни надо? На С и С++ с Java, вон Oracle написан, или Microsoft Outlook, не к ночи помянут. А что написано на Smalltalk, чем можно пользоваться леммингам?

P.S. Кстати, процедурных языков тоже хватает для решения всего чего только можно.

> Объекты не только не провалились, а развиваются сверх резвыми темпами, автор вероятно никогда не слышал о MDA/MDD.

я не автор, но про MDA/MDD не слыщал. где можно ознакомиться с "программными документами"? я серьёзно.

> У меня есть некоторый набор знаний, полученных в школе/универе/работе/от соседки. Вопрос - если я и так вижу ясно и четко, как будет выглядеть реализация на Java, который обрезан относительно C++, хотя бы на счет множественного наследования (да, шаблонов там действительно не хватает, факт, но это исправили и жизни по большому счету это не мешает), что может дать мне тот же самый Smalltalk?

Смотря что делаешь, разумеется. Если еще проще - в зависимости от того, окупятся ли потери времени на изучение нового языка выигрышем от уменьшения срока разработки. Почему никто и не предлагает всем в срочном порядке выкидывать жабу и гцц и дружным строем переходить на Smalltalk или там Eiffel. Но полностью их игнорировать - тоже глупо.

> Но реальность такова, что в общем-то множественное наследование уже избыточно, так как некоторые лемминги засовывают в классы вообще все, даже если им 2 и 2 сложить надо, делая код нечитабельным.

Реальность такова, что некоторые лемминги просто слишком тупы, чтобы полноценно понять MI, и уметь разруливать возникающие при этом конфликты (кстати, за грамотным примером реализации MI, см. Eiffel и Sather). И за три года обучения впихнуть им это в голову никак не получается. Поэтому MI выкинули, а потом уже, постфактум, объявили это чуть ли не величайшим достижением на пути развития ООП.

> Есть понятие инкапуляции, у инкапсулированной байды есть интерфейс, через который она замечательно работает и еще ее можно расширить, сделав частью другой байды. Чего господам еще в этой жизни надо?

Тебе напомнить про такие костыли, как жабские inner classes? Или про (неотъемлимую) убогость интерфейса любой реализации потоков (в смысле streams) в отсутствие множественного наследования?

> Кстати, процедурных языков тоже хватает для решения всего чего только можно.

Дык я больше скажу - древнего басика, с его единственной конструкцией IF cond THEN label хватает. А еще вполне можно передвигаться исключительно пешком, жарить еду на костре, и жить в пещере. Вот щасте-то...

>oxonian, ты хоть читал, что там накропал этот неграмотный человек? Там куча голословных утверждений и вывод, что все дураки, кто не согласен.

Да нет, просто автор задумался, куда все идет. ООП действительно не панацея. И АОП (Аспектно Ориентированое Програмирование) тоже. Кстати, советую просветится - програмировать в аспектном стиле можно и на ООП языках (так же как GNOME написан на Си).

Императивные языки хороши на небольших участках. Глобальные задачи лучше описывать на декларативных языках или их гибрдах. Например HTML,XUL,etc. - декларативные языки. SQL, make(котоый в Makefile) - гибридные. C, Java, perl, ML, etc. - императивные (с некоторыми елементами декларативности - полностю императивный только машинный код).

Ну и на чем легче описать интерфейс - на HTML или на Си?

Я бы с удовольствием писал бы програмы на ООП/АОП варианте Make-подобного языка. Мне намного легче поставить цель и описать какие цели от нее зависимы и как ее достичь, чем рассказывать каждому отдельному обьекту куда ему ити. Кстати, почему-то коефециент повторного использования кода в makefile-ах намного выше 50%, в отличие от всех остальных языков, где он не превышает 5%. Возможно потому, что цели очень часто бывают одинаковыми, в отличие от путей их достижения.

Возьмем к примеру простую задачу: каждый день к обеду нужны батон и пакет кефира (Шурик, мы тебя не забудем!). В императивном стиле мы пишем алгоритм для того чтобы выйти с работы (встать, повернутся на 180о, пройти 15 шагов, повернуться на 270о, открыть дверь,...), купить батон, купить кефир, вернутся на работу. Все работает отлично, пока ничего не меняется. Но пускай батон у нас уже есть и нам нужен только кефир - но алгоритмом ето не предусмотрено. Или мы уже стоим в магазине - тогда нам нужно вернутся в исходное положение, на работу, иначе алгоритм не сработает. Или нам нужно купить батон и ити домой - тогда нам полностю нужен новый алгоритм.

Пускай мы теперь используем make - тогда нам нужно описать цели и пути достижения целей, таких как путь с работы в магазин, путь с магазина на работу, с магазина домой, купить продукт Х и т.п. Пускай нам теперь нужно купить батон и ити домой - мы ставим две цели - купить батон, вернуться домой. Цель "купить" зависит от цели "магазин". То есть сначала надо попасть в магазин ("путь в магазин" у нас есть), потом купить батон ("купить продукт" у нас есть), потом идти домой ("путь домой" у нас есть). И хотя мы писали програму не для етой задачи, тем не менее с ней она отлично справится.

Анекдот в тему: Идут занятия для командиров взодов. Инструктор ставит задача - упала 5-ти метровая мачта, надо ее поднять. Тут же сыплятся различные предложения, как ето сделать. Инструктор сходу отметает их все - Неправильно! Вы должны сказать одно - Сержант, поставте мачту на место!

> я не автор, но про MDA/MDD не слыщал. где можно ознакомиться с "программными документами"? я серьёзно.
пример программоно

http://www.omg.org/mda/
http://www-106.ibm.com/developerworks/rational/library/3100.html

http://team.andromda.org/docs/lookandfeel.html - "программнымый документ" если это можно так назвать ;)

> Объекты не только не провалились, а развиваются сверх резвыми темпами, автор вероятно никогда не слышал о MDA/MDD.

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

Некоторые заметки:

> "До того, как я ушел изучать поэзию в 1995 году, моя карьера исследователя вращалась вокруг языка программирования LISP. Когда я вернулся в 1998"

Перевожу. Чел выпал из мира ИТ на несколько лет. Мир за это время изменился. Новому он учится не хочет и поэтому решил катить бочку на всё новое.

> "работающих на различном оборудовании, написанных разными производителями, так что не было бы ошибкой сказать — никто не знает, как это всё работает."

Уверяю, если этого не знает он - это не значит, что этого не знает никто. Вот из-за таки и появляются байки о самозарождении жизни в компьютерных сетях... :-F

> "Но с приходом C++ и Java, динамичное мышление, воспитанное в духе ранних объектно-ориентированных языков, было практически полностью подавлено теологией статичного мышления, взятого из математического наследия, и взглядами на вычисления, восходящими к Чарльзу Бэббиджу, с мировоззрением, ориентированным на всеведение и всемогущество."

Ахренеть! Где он такую траву берёт? Ему хочется, что бы натуральные пляски с бубнами коруг компов выстраивались? Мораль - если не знаешь, или учись, или не лезь. Тоже мне, учитель нашёлся... "Сам я не знаю, но советую!.." Блин! Поубывав бы!!! :-F~

> "В будущих системах ненадёжность (многих компонентов в целом) станет обычной, сложность выйдет за пределы поля зрения, и строить системы на тщательно "вылизанном" коде станет нереально."

> "Вместо статичных типов, точных интерфейсов и математических обоснований, появилась острая необходимость в самоорганизующихся механизмах, способных к самопроверке и различной реакции на ошибки, в управляемых системах, общая сложность которых будет лежать за пределами понимания одной личности."

Короче, старая песня о главном - проги писать он не умеет, но готов переложить ответсвенность за свои глюки на кого угодно, в том числе и на ООП. Блин! Плохому танцору...

> Ну и на чем легче описать интерфейс - на HTML или на Си?

Гуй - на HTML. А вот его поведение - на C. А не на каком-нибудь там SQL =)

> императивном стиле мы пишем алгоритм для того чтобы выйти с работы (встать, повернутся на 180о, пройти 15 шагов, повернуться на 270о, открыть дверь,...), купить батон, купить кефир, вернутся на работу. Все работает отлично, пока ничего не меняется. Но пускай батон у нас уже есть и нам нужен только кефир - но алгоритмом ето не предусмотрено.

Кажется, такие проблемы успешно решал еще структурный подход =) И вообще, типа там компоненты и прочая reusability.

> Или мы уже стоим в магазине - тогда нам нужно вернутся в исходное положение, на работу, иначе алгоритм не сработает.

А мы его берем и делаем event-driven. Типа обработчик события "в магазине" говорит "this->buy(kefir); this->buy(baton)", а как мы в этот магазин попали - это совершенно не его дело.

> Или нам нужно купить батон и ити домой - тогда нам полностю нужен новый алгоритм.

Да нет, мы просто меняем одну строчку в методе Shurik::goShopping()

> http://team.andromda.org/docs/lookandfeel.html - "программнымый документ" если это можно так назвать ;)

Становится понятно, почему Swing занимает >3Mb, а Skinlets/Thinlets <60kb, при сравнимом внешнем виде интерфейса и функциональности. :-(

> я не автор, но про MDA/MDD не слыщал. где можно ознакомиться с "программными документами"? я серьёзно.

http://www.omg.org/mda
http://www-106.ibm.com/developerworks/rational/library/3100.html

"программный документ" - в MDA это UML модель.
http://team.andromda.org/docs/lookandfeel.html - процесс разработки с использованием одного из open source MDA средств.

> Гуй - на HTML. А вот его поведение - на C. А не на каком-нибудь там SQL =)

Именно ето и имелось ввиду. Просто было бы неплохо, если бы все ето было бы в одном флаконе. Посмотрите на Thinlets - там используется XUL для описания интерфеса вместо Component o=new Component(); o.setLabel("Bla"); ... Выходит намного проще.

Кстати - get-еры и set-теры ето нарушение инкапсуляции. Поетому, если ваш обьект их имеет, то вы пишете не по ООП.

> Кажется, такие проблемы успешно решал еще структурный подход =) И вообще, типа там компоненты и прочая reusability.

Ну и где оно? Компонентный подход успешно решает проблемы размером не меньшые за сам компонент. С помощью панельных блоков можно построить высотный дом но нельзя построить трансформаторную будку. С помощью makefile я могу построить всю програму или отдельный файл. С помощю аналогичного батника - только всю програму.

> А мы его берем и делаем event-driven. Типа обработчик события "в магазине" говорит "this->buy(kefir); this->buy(baton)", а как мы в этот магазин попали - это совершенно не его дело.

То есть делаем плохонькую повторную реализацию уже реализованого алгоритма достижения цели... В каждой новой програме. :-(

> Да нет, мы просто меняем одну строчку в методе Shurik::goShopping()

В любом случае, нужно изменение алгоритма. После некоторого времени програма разбухнет в небольшого монстрика. Но использовать хоть один метод из етого монстрика в другой програме будет очень тяжело.

> Кстати - get-еры и set-теры ето нарушение инкапсуляции.

Это пиздец какой бред!

> Поетому, если ваш обьект их имеет, то вы пишете не по ООП.

Где траву берёте?

Интересно, где чувак траву берет? Сильно забористая видать...

%)

> > "До того, как я ушел изучать поэзию в 1995 году, моя карьера исследователя вращалась вокруг языка программирования LISP. Когда я вернулся в 1998"

> Перевожу. Чел выпал из мира ИТ на несколько лет. Мир за это время изменился. Новому он учится не хочет и поэтому решил катить бочку на всё новое.

Кто-то в середине прошлого века сказал: "Я видел скульптуры Фидия и памятник Юрию Долгорукому. Если это прогресс, то мне хочется выброситься из окна".

Так вот "чел", похоже, испытывает похожие ощущения после возвращения в "мир ИТ". Не потому, что он против нового вообще, а потому, что ему есть с чем сравнивать.

> > Кстати - get-еры и set-теры ето нарушение инкапсуляции.

> Это пиздец какой бред!

Сравни:

struct O o;

int b=1;

o.a=b;

int c=o.a;

и

O o=new O();

int b=1;

o.setA(b);

int c=o.getA();

Чем они отличаются? В первом случае инкапсуляции нет. Во втором она есть? Инкапсуляция - ето сокрытие внутренней реализаци. Если доступ к внутренностям обьекта есть (пускай не напрямую, а через getters&setters), то никакой инкапсуляции нет. Ибо при изменении типа проперти, изменится и интерфейс обьекта.

> > Поетому, если ваш обьект их имеет, то вы пишете не по ООП.

> Где траву берёте?

Пиво "Льв&#1110;вське Прем&#1110;ум".

Ну и google на предмет encapsulation (не incapsulatuion), Law Of Demetry, OOP violation, etc.

... Law of Demeter ...

> автор вероятно никогда не слышал о MDA/MDD.

зато он об MDMA наверно слышал :)

Луговского на вас нет.

> Пускай мы теперь используем make - тогда нам нужно описать цели и пути достижения целей, таких как путь с работы в магазин, путь с магазина на работу, с магазина домой, купить продукт Х и т.п.

Это - путь Пролога, языка декларативного программирования.

отныне все пишем только на ассемблере

type truepix { private bit128 store;

public void set(bit128 a){ store=a; }

public bit128 get(){ return store; }

public void set(double a){ store=(double)a; }

public double get(){ return (double)store; }

public void set(long a){ store=(long)a; }

public long get(){ return (long)store; } }

truepix true_hidden_storage = 1.1E+8; long a = true_hidden_storage;

Вот настоящее скрытие реализации и не надо гнать!

>это просто вопли обиженного жизнью функциональщика, которому лень доучиваться.

[кусок статьи] Я на собственном опыте перенёс это. До того, как я ушел изучать поэзию в 1995 году, моя карьера исследователя вращалась вокруг языка программирования LISP. Когда я вернулся в 1998, я обнаружил, что моя область исследований оказалась уничтоженной. Я был вынужден искать новые способы зарабатывания на жизнь в рамках новой экологии компьютерного мира, созданного языком Java, который деловито перестраивал мир программирования по своему образу и подобию.

ИМХО похоже на неудачника который в ИТ области потому что тут больще платят прямо сейчас. Если за уборку мусора начнут больше платить то этого автора можно будет на помойке встретить - где ему и место

>> Кстати - get-еры и set-теры ето нарушение инкапсуляции.

> Это пиздец какой бред!

Да ну?

> Кстати - get-еры и set-теры ето нарушение инкапсуляции.

Вот в этом с ооп и проблема, каждый понимает его по своему, вместо того чтобы классику читать.

> Если за уборку мусора начнут больше платить то этого автора можно будет на помойке встретить - где ему и место

Мусор руками только приплюснутые собирают %)

> public void set(double a){ store=(double)a; }

Здается если OOP то не надо явно типы приводить. Компилер сам подставит вызов нужного operator. А то блин C пахнет.