LINUX.ORG.RU

Интервью Bjarne Stroustrup


0

0

Как-то жизнь замерла... Для поднятия тонуса предлагаю почитать
данное интервью. Мне кажется оно добавляет новые оттенки в
дискуссию о С/С++.

Интервью Bjarne Stroustrup, данное 1 января 1998 года
для журнала Computer.
╘ 1998, Computer
перевод: Mike Bluesman

Первого Января 1998 года Bjarne Stroustrup давал интервью журналу
'Computer'. Вообще-то редакторы предполагали, что он расскажет о семи годах
объектно-ориентированного программирования с применением языка, который он и
разработал.
К окончанию беседы выяснилось, что интервьюер извлек больше информации,
чем предполагал, и, естественно, редакторы решили урезать содержание 'для
пользы индустрии', но, как обычно получается в таких случаях, произошла
утечка информации.
Вот полный и нередактированный протокол интервью - это не похоже на
обычные запланированные вопросы/ответы.
Вам наверняка покажется это интересным.
-------------------------------------------------------------

Интервьюер - далее И., Stroustrup - далее C..

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

C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните
- все писали свои версии 'C', и проблема была в том, что все это делали
чертовски замечательно. Университеты тоже чертовски замечательно преподавали
этот язык. Это привело к понижению компетенции. Под 'компетенцией' в данном
случае я подразумеваю феноменальность. Вот что породило проблему.

И. Проблему?

C. Да, проблему. Помните когда все писали Cobol?

И. Конечно, я тоже это делал.

C. Ну вот, в начале эти ребята были как боги. Им платили кучу денег и
относились как к королям.

И. Да уж, вот это были времена...

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

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

С. Точно. То же самое случилось и с программистами, писавшими на 'C'.

И. Понятно, ну и что же Вы все-таки хотите этим всем сказать?

C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка,
как хоть немного восстановить баланс. Я подумал: интересно что же было бы,
если бы был язык программирования с такими широкими возможностями и такой
сложный для изучения, что никто бы уже не смог заполнить рынок толпой
программистов, пишуших на этом языке? У меня уже были тогда кое-какие мысли
по этому поводу. Вот, знаете наверно, X10 и X windows. Это тогда была такая
графическая система, которая работала на этих самых Sun 3/60. У нее были все
ингредиенты, которые мне были нужны - комплексный синтаксис, неявно
определенные сложные для понимания мрачные функции,
псевдо-объектно-ориентированная структура. Даже сейчас никто не пишет чистый
код X-windows. Motif - единственный путь, если хочешь сохранить
здравомыслие.

И. Шутите?

C. Ничуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то,
что любой программист, пишущий на 'C', мог очень легко стать системным
программистом. Помните сколько обычно зарабатывали большинство системных
программистов?

И. Да, я же ведь тоже этим занимался.

С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания
всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда
ребята, которые только про DOS и знали, получили бы по заслугам.

И. Не верится в то, что Вы это сказали...

С. Это уже происходит достаточно долго, но вроде сейчас большинство людей
уже уяснили для себя, что C++ - это пустая трата времени, но должен сказать,
что осознание этого происходило дольше чем я ожидал.

И. Ну расскажите поточнее, как же Вы все-таки сделали это?

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

И. Что?

С. И относительно 'переносимого кода' - когда Вы слышали чтобы хоть одна
компания переносила что-либо?

И. Ну, вообще-то не слышал, но...

С. Вот так-то. Некоторые, кстати, пытались. Была такая компания из Орегона -
Mentor Graphics, в которой просто заболели тем, что пытались переписать все
что можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но
думаю, что люди по крайней мере, научились чему-то на их ошибках.

И. Очевидно у них ничего не вышло?

С. Вообще ничего. Но было бы сложно объяснить держателям акций компании
ущерб в 30 миллионов долларов и вот, надо отдать им должное , они все-таки
заставили это работать в итоге.

И. Так все-таки у них получилось? Это доказывает что
'объектное-ориентирование' работает.

C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут
на рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет
камнем преткновения, но это никого особенно не заботило. Sun и HP были очень
рады продавать до ненормальности мощные ящики с огромными ресурсами для
выполнения на них тривиальных программ. Знаете, когда мы в AT&T
откомпилировали нашим первым компилятором C++ программку 'Hello World', я не
мог поверить своим глазам: запускаемый файл получился размером 2.1Mb.

И. Да уж... Но компиляторы с тех пор прошли долгий путь.

C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней
версией g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще
множество примеров со всего мира. У British Telecom чуть было не возникли
большие проблемы, но к своему счастью они вовремя догадались свернуть проект
и начать все заново. И им больше повезло, чем Australian Telecom. А теперь я
слышал, что Siemens cоздает какого-то динозавра и все больше и больше
волнуется по поводу размера того, что у них получается. Не правда ли забавно
смотреть на это всеобщее заблуждение?

И. Да, но C++ -то, в общем, вполне нормальный язык.

С. Вы в это так верите? Попробовали ли вы когда-нибудь сесть и поработать
над проектом на C++ ? Во первых, я расставил достаточно ловушек, чтобы
просто так работали только тривиальные проекты. Под конец проекта получается
что одни и те же операторы в разных модулях означают совершенно разные вещи.
А теперь попробуйте соединить все эти модули в единое целое, особенно если у
вас их штук 100. Боже, я иногда не могу удержаться от смеха, когда слышу о
проблемах разных компаний, которые не могут сделать так, чтоб их модули
общались между собой.

И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы
сказали что сделали это для того, чтоб повысилась оплата труда
программистов. Но это же бессмыслица.

С. Не совсем так. У каждого есть его выбор. Я не предполагал, что все это
так выйдет из-под контроля. Но все-равно, практически все у меня получилось.
C++ cейчас уже умирает, а труд програмистов продолжает нормально
оплачиваться - особенно тех, кто имеет дело со всей этой чепухой - вы же
понимаете, что невозможно использовать эффективно большой программный модуль
на C++ , если не вы сами его написали.

И. Как это?

С. Не понятно что-ли? Помните typedef ?

И. Конечно.

С. А теперь вспомните сколько времени приходится копаться в заголовках для
того, например, чтобы просто найти, что какое-нибудь там 'RoofRaised' -
число с двойной точностью. Представьте теперь сколько времени уйдет на
нахождение всех определений типов в большом проекте.

И. Значит, Вы утверждаете, что Вам все, что Вы хотели удалось...

C. Ну, вспомните сколько занимает реализация проекта среднего размера на
'C'. Это около 6 месяцев. Не достаточно долго чтобы парень с женой и детьми
мог заработать себе на нормальное существование. Попробуйте тот же проект
реализовать на C++ , и что получится? Вам понадобится 1-2 года. Не правда
ли, это замечательно? Кроме этого: в университетах уже так давно не
преподают 'C', что теперь стало мало людей программирующих на 'C', особенно
таких, которые знают все о программировании под Unix. Как вы думаете :
сколько парней смогут сообразить что делать с 'malloc' , после того как
втечение многих лет они пользовались 'new' и никогда не заботились о
проверке кода возврата? Большинство программистов на C++ вообще не
выбрасывают этот код возврата. Что произошло со старой доброй '-1' ? По
и?айней мере было сразу понятно, что у тебя где-то ошибка без всяких там

С. Нет, я же говорил... Замечали, в чем разница между стадиями планирования
проектов на 'C' и C++ ? Для проекта на C++ эта стадия в три раза дольше.
Время уходит на то, чтоб убедиться что все что надо наследуется, а все что
не надо - нет. И все-равно без ошибок не обходится. Кто слышал когда-нибудь
об утечке памяти в программе на 'C' ? Теперь нахождение этих утечек - целый
труд. Большинство компаний сдаются, так и выпускают продукт, зная что утечка
памяти существует.

И. Но есть различные программные инструменты...

С. Большинство из которых написаны на C++.

И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ?

C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Ни одна компания без
предварительного тестирования теперь не начнет проект на C++, а если будет
тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так
им и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на
C++.

И. О Боже. И что же он сказал?

C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и
Brian понимали что я тогда делал. Он ответил, что может мне помочь написать
версию DOS на C++, если я захочу.

И. Ну и как? Вы захотели?

С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20
в другой комнате. Просто летает на четырех процессорах и занимает всего то
70 мегабайт на диске.

И. На что же это похоже на PC ?

С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем
величайшем успехе.

И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то
может сидеть парень, которому придет в голову сделать это...

С. Но не после того, как он прочитает это интервью.

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

С. Но это же история века. Я просто хотел чтоб мои приятели-программисты
помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается
программирование на C++ ?

И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в
час.

С. Понимаете теперь? И я уверен, что он заслуживает этих денег. Отслеживание
всех этих ловушек, которые я встроил в C++ - не легкая работа. И, как я
говорил раньше, каждый программист на C++ чувствует себя связанным тем
обстоятельством что он должен использовать каждый элемент языка в каждом
проекте. Вообще это и меня часто раздражает, даже тогда, когда это служит
моим целям. Но сейчас, когда прошло столько времени, мне уже начинает
нравиться этот язык...

И. Имеете ввиду, что раньше Вам C++ не нравился?

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

И. Погодите, а как насчет ссылок? Вы подтверждаете что шли от поинтеров 'C'
?

С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с
парнем, который написал C++ с самого начала. Он говорил, что не мог
запомнить были ли ссылки на его переменные или нет, поэтому он всегда
использовал поинтеры.

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

С. Пообещайте мне, что опубликуете это.

И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по
этому поводу.

С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию
этой записи?

И. Это я могу.

-------------------------------------------------------------

Примечание переводчика :

Я не программирую на C++. Я не являюсь знатоком русской словестности. Посему
прошу извинения за возможные ошибки в переводе.

специальный перевод для Hacknet Review выполнил Mike Bluesman, март 1998

anonymous

Забавно конечно, но мало вероятно. Года полтора-два назад я читал, что то подобное но про чистый С. К сожалению исходной доки у меня не сохранилось. :( Речь там шла о том, что С был разработан как первоапрельская шутка и названия получил как продолжение извращеных диалектов языка Pascal(назывались они A, B). :)) Оформлено это было, как заявление Ричи, Томсона и Кернигана на некой конференции. Вот так вот...

anonymous
()

уважаемый Бьярн Страуструп судя по всему был весьмяа пьян...(если он это говорил) или фраза "прошу извинения за возможные ошибки в переводе" оставляет надежду что Блузман просто бредит...

Chico
()

Приятно, конечно, что данный опус вызвал эмоции,
но не кажется ли почтенной публике что проблемы
M$Windows описаны очень узнаваемо? А насчет
немеренного размера конечного продукта вроде тоже
звучит убедительно (вроде очевидно?, что чистый С будет
давать запускаемые файлы много меньших размеров, так
как жестче привязан к конечному представлению программы
в машине. а С++ программа может иметь совершенно не
машинную логику. Иначе говоря, чтобы написать эффективную
программу нужно все-равно думать о том как это будет
затем работать с имеющимися библиотеками). Насколько
я слышал, сопровождение больших программ на С++ и их
переносимость --- весьма нетривиальная задача.

Ну а насчет достоверности текста, разве это серьезный
вопрос для мыслящих людей?

anonymous
()

Понятно что это интервью шутка, тем более что это выясняется за 30 сек не принужденного поиска по сети: http://www.research.att.com/~bs/bs_faq.html#IEEE Тому кто говорил, чтo у С++ результируюший код будет обязательно больше http://www.research.att.com/~bs/bs_faq.html#Hello world PS Читайте источники

Ogr
()

Между тем в каждой шутке есть доля шутки...
Узнаваемы проблемы не только M$, но и Mozillы,
на сайте которой можно как раз почитать про переносимость C++
( http://www.mozilla.org/hacking/portable-cpp.html ), загибая
пальцы по don't use.
Правильного в этой пародии довольно много, как в применении к
большим, так и средним проектам. 

anonymous
()

Плохонькая издевка недоучки, а не шутка. Вот, кстати, ответ B.S. "Did you really give an interview to IEEE in which you confessed that C++ was deliberately created as an awful language for writing unmaintainable code to increase programmers' salaries? Of course not. Read the real IEEE interview. http://www.research.att.com/~bs/ieee_interview.html " P.S. Классная фразочка из интервью с B.S., для тех, кто не научившись граматному ООП, начинает гнать пургу про С++: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." :)) Вот отсюда ноги и растут, а точнее, у некоторых, уже не... :)))

Sam
()

Я как-то не рассмотрел недоучек - по "ихонней статье про ихоннюю индустрию" судить об этом трудно. А интервью для АйЯйЯй высьма и весьма выдержанное. И вряд ли вообще стоит начинать такие (С vs. С++) треды - пустая трата времени. Вероятно от безделья - никто не обсуждает PHP vs. Zope (или perl vs. python ) - просто зарабатывают на жизнь. Может быть какой-то смысл имело бы обсуждение "С++ в проекте GNU", но похоже что предмет спора отсутствует.

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

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

В конце-концов новичков в С++ волнуют и философские проблемы языка.

anonymous
()

Здесь - пустая трата времени. В самом верху недвусмысленно написано - "для поднятия тонуса". Нужно идти на сайты живых полезных проектов, лезть в их CVS, смотреть багрепорты и читать мэйлинг-листы (которые тоже относятся к ресурсам, но игнорируются). Есть style и developers гайды - это более подходит под "философию". Причем практическую и инструментальную, в отличие от учебников. Которые тоже надо не манкировать, а перечитать как-нить по второму разу.

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

Кто ясно мыслит - тот ясно излагает. логика и математика науки точные. формализация языка - до абсурда - Вот истина !!! с уважением Виктор

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

Так грамотно написано, что я чуть было не поверил в это :(( Статья придумана, судя по всему, профессионалом в области программирования и в ней здравого смысла больше, чем может показаться на первый взгляд. А как ловко человек воспользовался именем B. Strоustrup'а??

anonymous
()

Видимо товаришч поучаствовал в проекте на 100 модулей, остался жив, подлечился, переквалифицировался в журналисты и пишет теперь такие пародии. Бодриться с С++ можно только после небольших шабашек (в основном на Qt и/или других ГОТОВЫХ библиотек классов ПРМЫШЛЕННОГО качества, с документацией и др.). А вот "С++ в GNU", точнее его редкое применение - это тема...

anonymous
()

Интервью абсолютно правдивое :)
Пусть с ехидством, пусть не Страуструпа но чистая правда.
Объектно-ориентированное програмивование извращение ума
и когда нужно делать дело не подходит абсолютно.
(кстати абсурд сравнивать perl и python это все равно
что сравнивать гиганта с карликом).

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

Если кому надо style-guide - можно использовать CoreLinux++ (искать на freshmeat)- там правда все по-английски, но достаточно скурпулезно изложены концепции строго об[ектно-ориентированного программирования на C++ (да и для любых других языков сойдет). Доки расчитаны на профессионалов и больше похожи на набор заповедей или правил какой-либо софтверной компании (там нет слов о пончиках тещи одного из авторов). Там все очень отполировано. Я бы не сказал, что я согласен полностью со всем этим (слишком там все строго). А так - приведенное "интервью" - очень глупо. Я лично торчу от C++ (последнего стандарта августа 1998го и STL в частности). Те, кто говорит, что С++ это дерьмо - посмотрите на код Mozilla и попробйте представить, какой бы он был, если бы он был написан на С (и как геморойно его было бы изменять). Большинство из тех, кто ненавидит С++ либо вообще не на чем ни программировал (чисто юзер/админ), либо ему не хватило времени/ума освоить С++ и написать на нем чего-нибудь длиннее чем 1000 строк. И не надо путать недовольство реализацией С++ с недовольством к С++. Ну а величайшим достоинством ООП яв-ся абстракция (то есть ассоциация структуры данных и методов, связанными с этими данными) - то есть вызвать метод FOO у об[екта по имени BAR - записывается BAR.FOO(), а не BAR_foo(). Абстракция свойственна человеческому мозгу - поэтому она облегчает разработку софта. Полиморфизм (наличие у некоторых классов метода с одинаковым названием) еще более облегчает программирование (по крайне мере запоминание названий функций). Инкапсуляция тоже полезна. Наследование - тоже ничего. В целом использование ООП позволяет переложить часть рутинной работы на компилятор.

hvv
()

Код Мозилы я видел и видел как она работает. Немного лучше Оперы
ИМХО. Код Нетскапе я тоже видел на C между прочим и видел как он
работает - конкурентов не имеет несмотря на то что далеко не все
гладко.
Абстракция и полиморфизм для тех кто действително в жизни не написал
еше пары десятков тысяч строк кода это кажется самым гениальным и
заманчивым. Hardcore программеры наоборот кривятся от слов OOP
особенно когда речь идет о времени, отвечают как правило "только
за большие деньги". (Сталкивался с этим не раз уже).
Наивно думать что абстракция свойственна человеческому мозгу поэтому
давайте ее везде использовать. Абстракция и вообше надуманность и
мудренность вредят. Вредят дико работе. Это я могу заявит как
окончивший МехМат если кто знает что это такое было.
Статья перечисляет в шутку все серезные минусы OOP
memory leaks, long learning curve, long project development,
non optimized code ... etc etc etc
Все это чистейшая правда.
В обшем можно говорить и говорить на эту тему.
На моем опыте никогда не удавалось завершить C++ проект так как
хотелось бы. А подбирать чужой проект уже написанный, чтобы его
содержать я уже не буду ни за какие коврижки. предложу переписать
на C сначала.
(Да для того чтобы определится с квалифицированностью...
2 года назад у меня был 4х летний опыт работы на OOP, C++
проектами то есть к теперешнему моменту он бы был 6 летний
если бы я не подвел 2 года назад для себя черту под занятием OOP)

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

Первый раз слышу словосочетание "hardcore программеры" (скорее всего это те, которые пишут ядра и демоны). Мне кажется, что по крайней мере демоны - софт требования (приводящие к измененени внутренних структур данных) к которому увеличиваются намного реже, чем для пользовательского софта. Поэтому писать их на С не намного сложнее чем на С++ (раз нахрапом написал - можно потом забывать, как там все устроено). А к пользовательскому софту требования меняются гораздо чаще. Поэтому выгоднее его писать на С++. Наверное наибольшая проблема ООП - то что трудно правильно спорэктировать архитекуру классов (может просто некогда думать), да и не все области хорошо подходят для вписывания их в ООП рамки. По крайне мере писать с использованием чужих С++ библиотек, которые умно спроектированы, гораздо легче, чем с использованием С-шных (также умно спроектированных). Насчет абстракции: ядро линуха и unix API использует эту абстракцию (например - функции read, write работает и с сокетами, и с дескрипторами файла) (иначе было бы как в винде - одна функция для чтения из файла, одна - из сокета (по-моему там так)). Само дерево каталогов файловой системы - тоже можно в большой степени считать абстракцией (/usr/bin/login вместо /the-login-program). Даже то, что ты покупаешь пиво в магазине, а не делаешь его сам - тоже абстракция (ты знаешь, какими свойствами обладает об[ект, и поэтому его используешь). То, что если на бутылке написано пиво и неизвестная тебе марка - дает тебе право надеется, что там что-то похожее на пиво по вкусу (это наследование или полиморфизм). Было бы хуже, если бы на бутылке было написано "балтика" и не было бы написано "пиво". При ООП пространство имен тоже меньше загрязняется и дает возможность использовать более осмысленные имена для методов и членов, не содержащие префиксы и суффиксы. ЗЫ: "Стаж" у меня такой же.

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

Прочитайте сначала мое сообщение ниже. Вот еще примеры элементов ООП в повседневной жизни, но менее пищевые. То, что все gnu'шные программы имеют опцию командной строки --help, --version можно считатть полиморфизмом (у разных классов имеются методы с одним именем) (и это удобно!). То, что вместо /usr/bin/make можно написать make это удобно! (примерно та же экономия при реализации методов класса или при использовании пространств имен и глобальных функций в С++). То, что можно делать "cp file1 file2" и "cp file dir" можно считать перегрузкой имен (несколько функций имеют одно имя но параметры различных типов) - иначе бы пришлось писать "cp file1 file2" и "cp-to-dir file dir". Программу 'tar' можно разценивать как об[ект, имеющий несколько методов - 'c', 'x', 't' и др. - это абстракция (иначе пришлось бы писать tar-c ..., tar-x ...). Итого: принципы ООП облегчают работу (человеку). Можно писать ООП код на С (например - ядро linux'a), но на С++ ООП код писать легче, так как помогает компилятор (не надо . инициализировать вручную таблицы указателей на функции). Мне кажется, что софт, предметная область которого трудно вписывается в ООП рамки, можно писать в полуфункциональном стиле, но все равно IMO удобнее использовать ООП библиотеки, чем не-ООП. А, блин, еще один пример: параметры функций со значениями по умолчанию (тоже есть в С++): если бы такого не было в команде echo, пришлось бы явно указвать, что нужно присоединять \n к строке, не надо интерпретировать \-последовательности (то есть явно указывать то, что мы подавляем флаги -n и -e). Все это освобождает человека от нудной машинистской работы и потенциальных опечаток). И при программировании на С++ не обязательно использовать все концепции ООП - можно использовать его как С (с сильной проверкой типов), но также вовлечь шаблоны, пространства имен, аргументы функций по умолчанию, перегрузку имен, инлайн-функции. Я люблю говорить так: лопатой научиться работать намного проще, чем экскаватором, но и производительность труда тоже сильно различается.

hvv
()

2hvv-1: Как можно так чудовищно саморазоблачаться?
> величайшим достоинством ООП яв-ся абстракция
У Страуструпа в интервью из Айяйяй: So what is OO? ... I tend to
equate OOP with heavy use of class hierarchies and virtual functions
> абстракция (то есть ассоциация структуры данных и методов,
> связанными с этими данными)
Связывание данных и методов - это модульное программирование,
известный принцип Парнаса 1972 года, но не более. Этого мало даже
для создания абстрактного типа - нужно еще уметь экспортировать его
определение и создавать его экземпляры.
> Полиморфизм (наличие у некоторых классов метода с одинаковым
> названием
Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
полиморфными аргументами.
> Наследование - тоже ничего.
Все, а не ничего - смотри выше "...heavy use..." Иначе просто не стоит
огород городить. Работа без наследования в С++ (класс==тип) есть
просто работа с типами пользователя (например с векторами, матрицами,
тензорами), а не ООП. 

anonymous
()

2hvv-2:
> Наверное наибольшая проблема ООП - то что трудно правильно
> спорэктировать архитекуру классов (может просто некогда думать)
ГЕНИАЛЬНО!!! (== ПОЛНЫЙ П@#$%Ц!!!, простите за такое слово).
После этого обсуждение ООП можно сразу закрывать.
> да и не все области хорошо подходят для вписывания их в ООП рамки.
Страуструп тоже так думает: ... not every problem is best approached
with a primary focus on objects.
> То, что все gnu'шные программы имеют опцию командной строки --help,
> --version можно считать полиморфизмом (у разных классов имеются
> методы с одним именем)
С 4..6-летним стажем принять функцию (даже не шаблон)
main (int argc, char **argv) за класс с методами? Нет слов!..
Наличие --version у GNU-программ нужно считать не полиморфизмом,
а уважением к autoconfу. Если КАЧЕСТВЕННО писать для GNU, а не для
"Линукса-only", им необходимо пользоваться и либо ограничиваться
portable-cpp с Мозиллы, либо честно предоставлять альтернативы для
всех HAVE_feature. Посмотрите The official GNU autoconf macro archive.
Вряд ли туда заглядывали те, кто от С++ тащится взахлеб. 

anonymous
()

!!!
Браво anonymous!
Ответ твой без сумления солиден.
Мне нечего добавить :)
Даже сторонники C++ с огромным опытом ошибаются в идеалогии,
что тут можно говорить.
P.S. hardcore програмеры это маньяки програмирования, не удивительно
что не слышал потому что в России их мало.
Пример разработчики Quake или Myth2 (3-4 програмера по сути дела).
Я вот недавно познакомился с людьми которые в Sun спортировали
Solaris на x86 - тоже 3 человека, они сейчас архитекторы в фирме
(ведут проект на Java/C ругаясь на Java матом и все настоятельно
клонят в сторону C. Стонут от Java но пишут... Такой архитектор
делает bugfix в течении 2-3 часов... Вот это hardcore)

Tima_ ★★★★
()

От чего же вы пришли в восторг, Tima ?
>> величайшим достоинством ООП яв-ся абстракция
>У Страуструпа в интервью из Айяйяй: So what is OO? ... I tend to
>equate OOP with heavy use of class hierarchies and virtual functions
Разве это не одно и то же ? Что же тогда по вашему виртуальная функция, как не абстрактный метод ?
>> Полиморфизм (наличие у некоторых классов метода с одинаковым
>> названием
>Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
>полиморфными аргументами.
Ошибаетесь, дорогой анонимус - перегрузка, это несколько методов с одинаковым именем. Конечно определение hvv тоже не сахар, но оно ближе к полиморфизму.
>> Наследование - тоже ничего.
>Все, а не ничего - смотри выше "...heavy use..." Иначе просто не стоит
>огород городить. Работа без наследования в С++ (класс==тип) есть
>просто работа с типами пользователя (например с векторами, матрицами,
>тензорами), а не ООП.
Ну здесь вообще все ясно. У слова "ничего" есть по крайней мере два известных мне значения: ничего - пусто и ничего - хорошо. После хотя бы 10 лет общения на русском языке принять "ничего" в этой фразе за пусто ? Нет слов ! А придираться к словам - глупо и недостойно.
>> Наверное наибольшая проблема ООП - то что трудно правильно
>> спорэктировать архитекуру классов (может просто некогда думать)
>ГЕНИАЛЬНО!!! (== ПОЛНЫЙ П@#$%Ц!!!, простите за такое слово).
>После этого обсуждение ООП можно сразу закрывать.
Все правильно, трудно спроектировать -> нужна высокая квалификация -> не всем доступно. Почему надо закрывать обсуждение ООП ?
>> То, что все gnu'шные программы имеют опцию командной строки --help,
>> --version можно считать полиморфизмом (у разных классов имеются
>> методы с одним именем)
>С 4..6-летним стажем принять функцию (даже не шаблон)
>main (int argc, char **argv) за класс с методами? Нет слов!..
Я надеюсь, что это не придирка к словам, а либо неправильное понимание, либо неумение абстрагироваться. Вам не говорят об использовании класса в программах GNU, но говорят об иерархии вида 'программа GNU, от которой наследуются программы cp,rm etc., у которых один и тот-же метод ( ради бога не понимайте это буквально ) работает по разному (--help выводит разные сообщения у разных программ).
Tima: Статья перечисляет в шутку все серезные минусы OOP
>memory leaks,
Даже не хочется комментировать этот бред. Исходя из презумпции невиновности обвините C++ по всем правилам пожалуйста.
>long learning curve,
Правда.
>long project development,
Лукавство. На больших проектах дает выйгрыш в основном счет быстрой отладки. Ну а сопровождение быстрее на любых проектах.
>non optimized code
Ерунда. Посмотрите на выходы компилятора. Все механизмы в C++ это compiletime механизмы. Только прежде чем смотреть на выходы, включите пожалуйста оптимизацию.(В С++ компиляторах она тоже встречается).

timur
()

Timur, C++ виновно :) обсуждать тут нечего.
1) Memory leaks плодятся как вши даже в неплохо разрабатываемом
проекте. Вылавливать их -- шило в заднице, особенно когда они
сделаны не тобой.
Если не сталкивался то это значит что либо не искал либо в больших
проектах не учавствовал.
От чего memory leaks? Все от этой сраной абстракции, полиморфизма
и наследования -- то есть от всего того что отличает C++ от C.
Так что действительно коментировать нечего.
2) "Быстрой отладки" не бывает как класса. Вообше. Счастлив тот
кто гробит на отладки 70% времени, в основном это 90%, тем более
на проектах с OOP.
3) Доводилось ли уважаемый наблюдать что делает стандартный C++
компилятор с проектом иерархией на 30 классов? Со всей оптимизацией?
Размеры бинарника не мерянные. C++ компиляторы делают более
медленный и более большой код чем C компиляторы. Это факт. Точно
так же C компиляторы делают более большой и более медленный код
чем Assembler. Это тоже факт.
Кстати на Unix free C++ компиляторов приличных нет в принципе.
g++ далеко не фонтан хотя поднатужившись прорваться можно. Об оптимизации
речь даже не заходит. Лишь бы собирало как надо.

Далее
> Разве это не одно и то же ? Что же тогда по вашему виртуальная функция, как не абстрактный метод?
Мне как то с трудом верится что ты понимаешь о чем говоришь если такие
вопросы задаешь. IMHO рекомендую почитать двухтомник B. Strustrup. Не
прилично тут как то на такие вопросы отвечать.
Чтобы не идти по списку дальше скажу просто:
У anonymous замечания все справедливы. "Не используйте слово abstract
i polymorf в суе. Вам этого не простят."

P.S.
>программа GNU, от которой
>наследуются программы cp,rm etc., у которых один и тот-же метод ( ради бога не понимайте это буквально )
>работает по разному (--help выводит разные сообщения у разных программ).
Не путайте грешное с праведным, божий дар с яишницей а интерфейс с полиморфизмом,
Пожалуйста.

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

Не надо считать собеседника за полного барана и придираться к словам. Честнее будет принимать гипотезу, согласно которой собеседник умнее чем ты думаешь.
>> Полиморфизм (наличие у некоторых классов метода с одинаковым
>> названием
>Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
>полиморфными аргументами.
Ну, блин, оговорился: Полиморфизм (наличие у нескольких классов метода ...
То, что я сказал "классов", а не "класса", должно было привести к
мысли, что именно я имел ввиду.
>> Наследование - тоже ничего.
Я сказал "ничего", а не "ничто" (и правильно сказал - но кого-то это
могло сбить с толку).
Tima: ты сказал, что полиморфизм, наследование и абстракция - для
баранов (то есть что это не нужно). Я привел контрпримеры, приводя в
меру терпения комментарии. 

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

Спасибо, timur - ты правильно понял мои мысли. Со всеми твоими мыслям
я согласен.
to anonymous: насчет --help -= ну ты вообще сморозил. Напомню, я
доказывал, что абстракция, наследование и полиморфизм - вещи с которыми
мы часто сталкиваемся в нашей бытовой жизни и которые ее облегчают.
Ну ладно, к делу.
>1) Memory leaks плодятся как вши даже в неплохо разрабатываемом
   проекте. Вылавливать их -- шило в заднице, особенно когда они
   сделаны не тобой.
   Если не сталкивался то это значит что либо не искал либо в больших
   проектах не учавствовал.
   От чего memory leaks? Все от этой сраной абстракции, полиморфизма
   и наследования -- то есть от всего того что отличает C++ от C.
   Так что действительно коментировать нечего.
Полный бред. В C-шном коде memory leaks намного чаще встречаются. А
логичная организация классов и их методов (а также написание
деструкторов, которые правильно все удаляют) решают все проблемы. С++
позволяет сделать такой деструктор inline, что сэкономит вызов функции
(но сделает код больше). Правда, gcc позволяет использовать inline
функции и в С. Есть дохрена tools, которые отслеживают memory leaks.
>3) Про оптимизацию. Во первых - код, сгенеренный С++ не настолько
увеличивается, как ты рассказываешь. Большая часть дополненного кода -
из-за того что многие вещи inline (то есть работают быстрее, чем C
аналоги). Также само ООП заставляет грамотно писать код (в некоторых
ситуациях он может показаться лишним, но при длительном сопровождении
проекта только правильно написанный избыточный код, написанный "впрок",
спасает от постоянного переписывания ядра проекта). В третих, глядя
на участок С++ кода (исходника) можно сказать, какой будет
ассемблерный код. Следовательно, критические ко времени выполнения
участки можно написать так оптимально, как будет тебе нужно. (Не хуже С).
Еще про оптимальность: посмотри многие programming guide и style-guide
, везде написано, что человеческое (программистское) время дороже
машинного - что лучше написать логически более стройный (и более
гибкий), но менее оптимальный код. Идеализация - борьба за каждую
наносекунду - это пережиток советских времен. (Или чисто user'овский
подход - хочу быстрее и все). Надо свыкаться с мыслью, что если хочешь
быстрее - плати еще.
Про free C++ compilers (почему-то unix): я кроме g++ ничего не знаю -
может просвятишь? А коммерческих - туча (правдо чаще это очень умные
трансляторы С++ в С, но зато доступные для всех ОС). Так что для
коммерческого использования преград к использованию С++ вообще нет.

Насчет последнего твоего предложения (про яичницу) - см. начало моего ответа.
Чем бы это ни было - это черты ООП, облегчающие нам жизнь. 

hvv
()

По моему слово бараны я не употреблял.
И не хотел.
Я хотел сказать что не смотря на всю красивую теорию OOP
а вместе с ним C++ и Java не являются эфективным и дешовым
решением задач.

Tima_ ★★★★
()

hvv еще раз попрошу не путать жизнь с абстракцией так в
сумашедший дом попадают, серьезно.
А про memory leaks до появления C++ никто слыхом не слыхивал
а C старее C++ на 15 лет по хорошему.
>Еще про оптимальность: посмотри многие programming guide и style-guide
>, везде написано, что человеческое (программистское) время дороже
>машинного - что лучше написать логически более стройный (и более
>гибкий), но менее оптимальный код
Мама моя родная!!! Это гдеж такое написано??
Вот после таких гайдов атомный крейсер на буксире ташить приходится.
Ракеты не попадают в цел. Окошки закрываютья с blue screen.
И наступает мир Микро$oft и RAD разработки.
Меня USA научила: делать надо отпимально точно и без глюков, время
которое потратишь не важно главное качество кода во всех отношениях.
>В третих, глядя
>на участок С++ кода (исходника) можно сказать, какой будет
>ассемблерный код.
Ээээ ты со сколькими вообше компайлерами знаком?
По моей практике каждый такое городит свое...
Ладно латер...

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

> hvv еще раз попрошу не путать жизнь с абстракцией так в
сумашедший дом попадают, серьезно.
Просто такой взгляд на вещи из далека и ИМО очень наглядно все показывает.
А про memory leaks до появления C++ никто слыхом не слыхивал
а C старее C++ на 15 лет по хорошему.
Да ну! Ты меня удивляешь. C - не garbage-collectable язык, позволю себе
заметить (да и С++ тоже) - leaks это проблема любого языка без сборки памяти.
А то, что о них не слышали до появления С++ (это 1990 г) - так просто
компьютеры были слабые, и поэтому не было такого сложного и большого софта, как
например word и corel. Да и машинное время ценилось больше, да и людей было
умных тогда больше в процентном отношении.
>Еще про оптимальность: посмотри многие programming guide и
style-guide
>, везде написано, что человеческое (программистское) время дороже
>машинного - что лучше написать логически более стройный (и более
>гибкий), но менее оптимальный код
Мама моя родная!!! Это гдеж такое написано?!
Во всех guide'ах. Например, в CoreLinux++, в gnumeric/HACKING, во многих
других. А для оценки производительности участков кода есть профайлеры.
И еще - программеры специально ставят tab на 8 пробелов (как в gnumeric,
linux kernel) - специально, чтобы не создавать больших функций (с большим
глубиной nesting) - это помогает писать более гибкий софт. Но менее
оптимальный.
Кстати, С++ со своим гарантированным наличием inline (вообще факт, что любая
inline-функция будет развернута, не гарантируется) позволяет избегать
использования сложных макросов, по крайне мере с очень длинными именами,
заменой на inline функции (можно шаблоные) с полной проверкой типов аргументов.
Вот после таких гайдов атомный крейсер на буксире ташить приходится.
Ракеты не попадают в цел. Окошки закрываютья с blue screen.
Ты путаешь надежность и оптимальность. Эти величины для сложного софта
зависят обратно пропорционально. К счастью, части кода, наиболее критичные
ко времени выполнения, достаточно невелики по размеру и часто не вписываются
в ООП (такие, как декодирование mp3).
И наступает мир Микро$oft и RAD разработки.
Согласен, что иногда дело доходит до маразма. Но рынок тут наказывает
продавца (если есть конкуренция).
Меня USA научила: делать надо отпимально точно и без глюков, время
которое потратишь не важно главное качество кода во всех отношениях.
Она так никого не учит - у них - лишь бы было конкурентноспособно и с
правильным маркетингом (вообще, это и есть оптимально, но с экономической
точки зрения). Но глюков желательно поменьше Ж:-)
>В третих, глядя
>на участок С++ кода (исходника) можно сказать, какой будет
>ассемблерный код.
Ээээ ты со сколькими вообше компайлерами знаком?
По моей практике каждый такое городит свое...
Я не говорю, что смогу сказать, в какой регистр что уйдет.
Для того, чтобы знать примерный алгоритм сгенеренного кода, достаточно
знать С++ и declarations классов, которые принимают участие в участке
кода. Все, что C++ компилер может добавить "от себя" - так это инициализация
указателя на таблицу виртуальных методов, и предков, ну и создание
временных обхектов, а также их уничтожение.. Главное - не использовать
исключения (exceptions) - иначе код будет пухнуть. Но exceptions уже не
классическое ООП, AFAIK.
Ну и практика показывает, что лучше иметь дело с как можно меньшим кол-вом
компилеров/трансляторов (в смысле, от различных поставщиков).

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

Предыдущее сообщение - от меня. Когда я его запостил, у текста от Tim'ы был отсут пробелов 6, да и было поддписано мной. Сейчас все отступы исчезли, и авторство почему-то изменилось на anonymous. To maxcom: если это сделано вами вручную, не плохо было бы это зафиксировать маленьким сообщеньицем.

hvv
()

>Я не говорю, что смогу сказать, в какой регистр что уйдет.
Еще раз повторяю, мало компайлеров видели.
Не то что про регистр не скажешь как баран на новые ворота
на код ассемблера будешь смотреть и чесать затылок "разве это
можно на ассемблере так сделат???". Примеры компайлеры HP, DEC,
Sun, да и тогоже Micro$oft.
Gcc единственный компайлер который генерирует читаемый ассемблерный код.

>Для того, чтобы знать примерный алгоритм сгенеренного кода, достаточно
>знать С++ и declarations классов, которые принимают участие в участке
>кода. Все, что C++ компилер может добавить "от себя" - так это инициализация
>указателя на таблицу виртуальных методов, и предков, ну и создание
>временных обхектов, а также их уничтожение.. Главное - не использовать
>исключения (exceptions) - иначе код будет пухнуть. Но exceptions уже не
>классическое ООП, AFAIK.
Очень наивная точка зрения.

>Ну и практика показывает, что лучше иметь дело с как можно меньшим кол-вом
>компилеров/трансляторов (в смысле, от различных поставщиков).
Да если бы это было возможно... Gcc замечательная вешь.

>Во всех guide'ах. Например, в CoreLinux++, в gnumeric/HACKING, во многих
>других. А для оценки производительности участков кода есть профайлеры.
>И еще - программеры специально ставят tab на 8 пробелов (как в gnumeric,
>linux kernel) - специально, чтобы не создавать больших функций (с большим
>глубиной nesting) - это помогает писать более гибкий софт. Но менее
>оптимальный
В этих гайдах написано что програмист не должен уделять временя
на ускорение работы программы и всяческого рода оптимизации?
Что время програмиста дороже???
Кстати разговор о проекте gnumeric отдельный и о его качестве.
У меня в vi таб стоит 8 пробелов по умолчанию.

>Да ну! Ты меня удивляешь. C - не garbage-collectable язык, позволю себе
>заметить (да и С++ тоже) - leaks это проблема любого языка без сборки памяти.
>А то, что о них не слышали до появления С++ (это 1990 г) - так просто
>компьютеры были слабые, и поэтому не было такого сложного и большого софта, как
>например word и corel. Да и машинное время ценилось больше, да и людей было
>умных тогда больше в процентном отношении.
Не было мошьных компьютеров???
Не было мошьных програм???
ИМХО вообще не представляешь о чем говоришь.
Windows и M$ Office шедеврами програмирования _не_ являются они
являются его позором. Как DOS как Xenix как SCO.
Люди писали код грамотней и думали о коде а не о class inheritance
virtual/abstract methods или полиморфизме потому и memory leaks
не было и garbidge collection вообще никому не нужна была.
Garbidge collection это друг и брат OOP -- признание OOP в импотентности
в борьбе с memory leaks. Типа пишите что хотите за вас все сделает дядя.
Маразм.
Кухарки за клавиатурой короче.

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

Насчет компилеров: ну и хрен с этим кодом. Главное чтоб работал. Если
качество оптимизации не удовлетворяет, берешь транслятор от KAI (он
С++ в С перегоняет с дикой оптимизацией) и компилишь полученый С-шный
код. Но я не думаю, что если копилер криво генерит код для С++, то он
будет генерить хороший код из С.
Насчет style-guides: именно так и рекомендуют. См. любую уважаемую
всеми книжку, там то же написано это.
Насчет gnumeric: как раз это хороший пример очень большого проекта
(правда он на С). Очень показательный пример.
Про memory leaks: раньше компьютеры с мощностью PII не были доступны
рядовым гражданам. Соотвественно не было сложного ширпотребного (
коммерческого софта). Поэтому проблема memory leaks так остро не стояла
(т.к. коммерческий софт был проще и менее сложен).
Я не называл msoffice шедевром - я привел его в качестве примера
большого и сложного (для написания) софта. К счастью, memory leaks
в нем не заметно, так как все писали на С++.

Насчет ООП подхода в С - можешь посмотреть код gtk. Так вот, там
своя система об[ектов, но так как это реализовано на С, программерам
приходится вручную писать код для инициализации виртуальных таблиц
"класса" и тд - геморой! Посмотри Motif, corba - это ООП на С.
Ну ладно, у меня времени нет этот чат разводить...

hvv
()

Супер - просто обалденно! Смело можно давать первую премию за сочинение в стиле киберпанка :) А еще, я бы сказал, очень похоже на Станислава Лема с его великими конструкторами. COOOOOL!!!!

anonymous
()

Интересная картина - те кто не разбираются, обычно больше всего и критикуют. Так юникс, и в частности линукс, чаще всего критикуют те, кто не разу в глаза не видел. Также уважаемый Тима не разбираясь в ООП (он сам так сказал: "На моем опыте никогда не удавалось завершить C++ проект так как хотелось бы.") Так может проблема не в ООП? Так конечно проще - у меня не получается, значит это плохо и у всех не получится. > "Быстрой отладки" не бывает как класса. Вообше. Счастлив тот кто гробит на отладки 70% времени, в основном это 90%, тем более на проектах с OOP. Опять таже история, если "Быстрой отладки" не бывает как класса у Вас уважаемый Тима, это не значит, что всех так не бывает. У меня при хорошо обдуманном ОО проекте отладка занимает процентов 20-30 (точно не замерял) >Абстракция и полиморфизм для тех кто действително в жизни не написал еше пары десятков тысяч строк кода это кажется самым гениальным и заманчивым. Ну не правда. Написал я большой проект и полностью использовал наследование, полиморфизм и исключения (чтобы там не говорили про набухание кода). И работает. И не написал бы на Си за такой срок, и изменять так быстро на Си не получилось бы. >Hardcore программеры наоборот кривятся от слов OOP особенно когда речь идет о времени, отвечают как правило "только за большие деньги". Почитайте "двухтомник" Страуструпа. (Последняя редакция вышла в одном томе) Он там так и пишет, что опытные программисты на Си скорее всего встретят внедрение ООП в штыки. Это же их ставит наравне с начинающими, слишком многому нужно переучиваться. А вообще ООП нужно учиться. Как нужно учиться правильно писать программы. Не кидаться сразу программировать, а потом 90 процентов времени тратить на отладку. А сначала на бумаге выразить свои мысли, потом еще подумать, а потом уже приступать к кодированию. И по моему глубокому мнению ООП стимулирует к этому. Конечно написать плохую программу можно на любом языке, но когда язык и идеология программирования стимулирует к хорошему стилю - это хорошо. А насчет скорости выполнения программ, если у Вас действительно такой опыт написания программ уважаемый Тима, то Вы должны знать, что на скорость на несколько порядков больше влияет выбранный алгоритм и продуманность программы, а не эффективность оптимизации компилятора. Никакой компилятор не сделает медленный алгоритм быстрым. Есть такая поговорка - плохая жена, еще не повод говорить плохо о женщинах вообще, и о женах в частности. Поэтому Ваш плохой опыт в ООП уважаемый Тима, еще не значит, что ООП плох в корне.

rGlory
()

Уважаемый rGlory, прошу заметить что мой опыт ООП это далеко не написание
не один год и не в университете для зачета по информатике.
Я ставлю жирный крест на ООП и утверждаю что не возможно закончит ни
один проект так чтобы быть им воплне довольным не по причине плохого
опыта, неумения и не знания что я делаю, а именно изза более чем полного
понимания что происходит. Высшая матеметика учит простой истине:
"В абстракции нет границ". Поскольку ключем ООП остается все таки
абсолютная абстракция (как уже многие ниже заметили) то не удивительно
что я когда возвращаюсь к ООП проектам частенько хватаюсь за голову
и говорю что все надо переделать потому что каждый раз появляется
представление на качественно новом уровне. Тот кто не сталкивался с
этим не может утверждать что он понимает ООП, не правда ли? ООП это
тоже самое что получается когда инженеры прикладного профиля лезут
в высокую красивую и глубокую науку математику из-за которой иногда
можно вполне здраво сойти с ума.
Смысл?
Никакого. Ведь цель прикладного инженера, в частности програмиста,
это конечный продукт, а не раскрашивание кода.
ООП приносит только ненужные проблеммы и именно раскрашивание кода
совершенно ненужными высокими материями которые вредят процессу
компиляции.
Применить "чуть-чуть" ООП в проекте а потом бросить и удовлетворится?
Написать один класс и сказать что написал объектно-ориентированную
программу? Уже звучит глупо не правдали?
Не менее глупо для меня звучит трата нескольких месяцев на разработку
дерева классов и спецификации каждого в отдельности а потом лишь начинать
писать код. А ведь именно это является настояшим ООП.
Очень интересный у вас опыт с отладкой уважаемый rGlory. Надо понимать
что я пишу код быстрее вас скорее всего, либо проекты у меня посложнее
потому что большенство програмистов тратят именно 70% времени именно
на отладки, прошу не путать отладку и исправление грамотических и т.п.
ошибок.
Предложение применять более быстрые алгоритмы интересно но не практично.
После университета я почти не использовал уже написанных алгоритмов,
потому что мне не собирались платить деньги за написание быстрой
сортировки, или метода Гаусса.
К сожалению все простые задачи уже решены, на наш век остались лишь
сложные.
Скажу более я еше не разу не учавствовал в проекте в которым уже сначала
было известна конечная цель. Все проекты вырастали из 0 потому что
были рожденны сушествованием проблеммы которую надо было решать. Как
ее решать сначала никто не имел понятия.
Так как же такие практические задачи можно решать на ООП? Как возможно
сначала разработать дерево классов если не ясно решение?
Начать с чего то, потом прилепить еще что-то, потом еще чуть чуть и еще...
В какой-то момент понимаешь что все надо было делать абсолютно по
другому и преходится переписывать весь проект.
Кто нибуть здесь переписывал C++ проект?
Ладно, думаю я уже достаточно обяснил причины непригодности ООП
для проектов "реального времени".
Надеюсь до всех дошло что я хотел сказать.

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

>Поскольку ключем ООП остается все таки абсолютная абстракция (как уже многие ниже заметили) то не удивительно что я когда возвращаюсь к ООП проектам частенько хватаюсь за голову и говорю что все надо переделать потому что каждый раз появляется представление на качественно новом уровне. Проблема черезмерной абстракции - это не новость. "Паралич анализа" достаточно закономерная вещь, и она не привязана к ООП как таковому. Искусство именно в том и состоит, чтобы вовремя остановиться. А переписать по новому можно практически любую программу. "В конце работы становится ясно, с чего ее нужно было начинать" Эта истина применима не только к ООП и не только к программированию. Но анализ и выявление абстракций позволяют доскональнее вникнуть в проблему и многие проблемы, которые при быстром кодировании становятся видны только на этапе отладки, выявляются на раннем этапе анализа. >Не менее глупо для меня звучит трата нескольких месяцев на разработку дерева классов и спецификации каждого в отдельности а потом лишь начинать писать код. А ведь именно это является настояшим ООП. Начинать писать код без ясной картины в голове еще глупее звучит. >Очень интересный у вас опыт с отладкой уважаемый rGlory. Надо понимать что я пишу код быстрее вас скорее всего, либо проекты у меня посложнее потому что большенство програмистов тратят именно 70% времени именно на отладки, прошу не путать отладку и исправление грамотических и т.п. ошибок. Я знаю что такое отладка и я не сказал, что пишу код медленнее. Но продуманность позволяет мне не писать лишний или неправильный код. >Скажу более я еше не разу не учавствовал в проекте в которым уже сначала было известна конечная цель. Все проекты вырастали из 0 потому что были рожденны сушествованием проблеммы которую надо было решать. Как ее решать сначала никто не имел понятия. Так как же такие практические задачи можно решать на ООП? Как возможно сначала разработать дерево классов если не ясно решение? Извините не верю. Написать программу, когда неизвестно, как она должна работать невозможно в принципе. Не важно используется при этом ООП, или нет. >Кто нибуть здесь переписывал C++ проект? Я переписывал. Начинал писать, останавливался и начинал сначала. Останавливался на той или иной стадии. При готов поспорить, что при использование функционального подхода не ускорило бы проект. Если вообще смог бы его завершить.

rGlory
()

Pisat' kod bez idei v golove eto rabota sejchas y programistov takaja. (c)
Kod pishetsja potomy chto nado reshat' problemy a ne ot xoroshej guzni i jasnogo soznanija ili ydovol'stvija esli ygodno.
Izvestno chto programma dolgna sdelat', kak etogo dobitsja ni malejshego ponjatija ne sushetvuet.
Vot isxodnaja tochka. Vremennue ramki kak pravilo sgatu do ypora. V smusle rogu kruvit' budut mnogie esli poprosish bolshe
vremeni, xotja vremja dadut. Vpered.
Perepisuvat' Procedurno Orientirovannuju programmu gorazdo proshe chem obektono. Sporit' zdes' nechego.

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

Хорошо, давай посмотрим на проекты KDE и GNOME для Linux. Какой из них наиболее динамично развивается ? Правильно, KDE. А теперь задайся вопросом "ПОЧЕМУ ?" Я объясню тебе - KDE пишется на C++ и соответственно производительность во много раз выше. C++ и ООП являются ключами к эффективному программированию. Безоглядное отрицание ООП показывает лишь НЕУМЕНИЕ пользоваться инструментом. ООП - это прежде всего проектирование. Умно спроектированный ОО проект нет надобности переписывать, иначе проектировщиков гнать в зашей.

Melted_Brain
()

Melted Brain KDE развивается более динамично Gnome/GTK???
Ха Ха Ха Ха :)
Ну насмешил ты меня уважаемый.
Ты вообше в курсе современного Open Source Development?
Какие проекты идут, и какой рейтинг у проектов, ну и такое?
Или знаешь OSD по пиратским CD "Красная Шапочка 6.2" :))
В общем рекомендация: разобратся в том что говоришь
а потом приходить и выдавать заявления и в беседе учавствовать.
Пожалуйста, welcome как говорится.

Tima_ ★★★★
()

И все таки спорщики меня так и не переубедили! C - язык подходящий для написания OS, утилит, драйверов но никак не для сложных графических интерфейсов и больших проектов. Пример тому gtk-шные исходники которые никак нельзя назвать удобочитаемыми расширяемыми и логичными. А про сам Gnome я вообще молчу...

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

Зря ты Артем с этим уродом MeltedBrain,
вообще как с человеком разговариваешь.
Имя его уже нарицательное, переводится
как особо вредный и злобный ламер.
Пусть сначала что-нибудь путное сделает
и под GNU GPL выложит. Ну аналог FineRider
например. И не забудет кликуху сменить :-)
Трудно с человеком под матерной фамилией
общаться.
 

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

То Tima & others: не наезжайте на MeltedBrain по поводу его сообщения в этом форуме - оно содержит хоть какие-то аргументы, а ты, Тима, приводишь лишь свои впечатления и ничего более. Да, ООП - сложно. Да, не всякая предметная область ложится на ООП-рельсы. Но gui - прекрасно ложиться. Или ты что-то имеешь против (правда С-шных, но сделанных с ООП подходом) Xt, Motif, gtk+, groff (man formatter)? И еще - KDE пишут большей частью студенты, изучающие С++ - поэтому такое низкое качество. И еще: если человек не шлет постоянно сообщения в ответ на вновь появляющиеся - это не значет, что ты его переубедил - просто это культурный человек, не собирающийся разводть спор типа "Моя машина лучше" - "Нет моя!" - "Нет, моя лучше".

hvv
()

hvv да я тоже устал уже от этого спора, каждый все равно останется при своем. Опятьже могу снова с пеной у рта доказывать что GTK,Motif,groff(GNU nroff если об этом) объектного подхода не содержат а являються просто грамотно написанными программи на простом C, даже не на Object C вместе с CORBA. С КДЕ мне было все ясно с начала ее появления. Да, насчет аргументов, кроме собственных впечатлений и опыта тут аргументов не найдешь ведь именно про них и идет речь. По моему опыту интерьвью в шутку рассказывает именно те серезные вещи к которым приходят многие люди. Студентам это естественно кажется чушью, поэтому они берут QT и пишут KDE, смотрите что получается.

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

Я одни из скромных anonymous, кому Ваш спор
весьма интересен.  Если попытаться найти общий
знаменатель, то вроде получается так:

C++ --- способ экономить время программиста
более лаконичной формой записи программ (предположим,
что новое мировоззрение тоже "форма")
Реальная суть (и основной труд) лежит в библиотеках, 
используемых программистом.
Если все было хорошо продумано заранее (иерархия классов), 
 то результат может быть приличным.
Проблемы начинаются при попытках реализации
идей не зашитых (хорошо бы понять как такие
идеи сразу отличать) в исходную библиотеку.
При этом добавить в уже готовую библиотеку
способность хорошо работать с новыми идеями
практически невозможно.
Возможно, примером будет попытка реализации
на KDE какого-нибудь драйвера?
Мне не совсем ясно --- как понять какие "идеи"
уже зашиты в библиотеку, а какие все испортят 
 (и начнутся падения, утечки памяти и прочие глюки). 
 Да, если можно, при ответе, нельзя ли само
это представление описывать профессиональными
терминами (а не моими, ламерскими).

 

anonymous
()

ну ребята и поорали ..... Ничерта не понимаю , причем тут ООП , причем GNOME , причем KDE ..... Hу нравится человеку cpp , пусть пишет , нравится c , флаг ему в руки. Хочет эфективно , пусть asm юзает . Хочет динамично - forth -;). Лишь бы человек был хороший . А проблема cpp не в этой мурне (leaks ....) , а в том что UNIX и С родились вместе , а cpp не повезло. И ось на cpp написать можно , но как .... (писать то можно и стихи девушке). Круто перейти к template базовому классу ? Я к тому , что быть умным это классно , но еще K&R советовали - будьте проще , и все будет работать . (кстати cpp родился в году этак ~80) --- вопрос на засыпку : как сделать entry simbol'ом в бинарнике , метод класса ? ;)

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

>C++ --- способ экономить время программиста более лаконичной формой записи программ (предположим, что новое мировоззрение тоже "форма") Реальная суть (и основной труд) лежит в библиотеках, используемых программистом. Я не уверен, будет ли ООП программа короче (она может быть короче и может длинее). Чистая С программа теоретически работает быстрее, чем ООП на С++. Например процентов на 5. Дело не в этом. Проблема функционального подхода в том, что при росте программы существует тенденция к выталкиванию данных наверх (от локальных переменных к глобальным на уровне файла, затем глобальным на уровне проекта) При этом отслеживание зависимостей в большом проекте становится проблемой отнюдь не тривиальной. Что происходит при необходимости смены структуры данных? Нужно проверить не один десяток функций, которые с этими данными работают. При ООП больше времени уходит на дизайн (я думаю и в функ. подходе стоило бы тратить больше времени на продумывание). Но, если при объектном дизайне просто не получиться создать что либо путное, без досконального продумывания, то в функ. подходе очень велик соблазн сесть и начать писать программу сразу. При этом приводят такие аргументы: 1. у меня нет времени на обдумывание. Самообман. 5 минут потраченных на предварительный дизайн и продумывание обернется в несколько часов, потраченных на отладку и доводку. 2. Эта программа пишется на один раз, зачем мне тратить лишнее время? Таже история. Если программу не попросят доделать (или переделать) - скорее всего вообще не было смысла в написании этой программы. 3. у меня нет представления, как эта программа должна работать вообще - как я могу впроектировать иерархию классов? (Тима (c) ) Почитайте литературу по объектному моделированию. Разрабатываете макет программы. Вставляете заглушки в неважных местах. Проверяете. Выбрасываете макет (это принципиально) Разрабатываете снова. Зря потраченное время? Как бы не так. С помощью макета вы уже получите представление о том, как должна работать программа. В общем нет смысла пересказывать здесь литературу, вы можете прочитать сами (например Буч или тот же Страуструп) В общем ООП это не краткая форма записи, а форма записи более понятная и легче модифицируемая. Как бы с этим не спорили. Проверено на личном опыте. Мин нет.

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

Если проблема C++ в том, что родился поздно,
то почему тогда считается, что проекты на С++
сложнее переносить на другие архитектуры?
И насчет идей плохо релизуемых на С++.
Может это касается программ внутри которых
нет больших иерархий? Типа, зачем городить
огород с проектированием умных классов, если
все-равно не будет нужды устраивать цепочку
вложенных друг в друга понятий.
Но ведь, если это правда, то переносимость
должна быть прекрасная --- Вы определили самые
низшие понятия (машинно-зависимые), а дальше
идет иерархия.

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

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

С++ появился в 91 году AFAIR. Метод класса нельзя сделать entry symbol'ом. Даже если бы и можно было, во-первых, его имя будет mangled каждым компилятором по-разному (то есть проблема с переносимостью между компилерами), да и во-вторых - стандарт C++ не предоставляет возможности его вызвать (если метод не статический). Указатели на члены для этого, но их entry symbol'ом не сделаешь. Выход: пишешь extern C void call_method(void* object) который вызвает метоl класса, и делаешь call_method entry symbol'ом (его имя не будет mangled).

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

С++ появился в 91 году AFAIR. Метод класса нельзя сделать entry symbol'ом. Даже если бы и можно было, во-первых, его имя будет mangled каждым компилятором по-разному (то есть проблема с переносимостью между компилерами), да и во-вторых - стандарт C++ не предоставляет возможности его вызвать (если метод не статический). Указатели на члены для этого, но их entry symbol'ом не сделаешь. Выход: пишешь extern C void call_method(void* object) который вызвает метоl класса, и делаешь call_method entry symbol'ом (его имя не будет mangled).

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