LINUX.ORG.RU

Гради Буч - о средствах разработки и их будущем


0

0

По ссылке вы найдете замечательное интервью с Гради Бучем.

Гради Буч (Grady Booch), главный исследователь корпорации Rational Software, признан всем международным сообществом разработчиков программного обеспечения благодаря его основополагающим работам в области объектно-ориентированных методов и приложений, а также благодаря созданию языка UML. Гради - постоянный автор в таких журналах, как "Object Magazine" и "C++ Report" и автор многих бестселлеров, посвященных объектно-ориентированному проектированию и разработке программ. Гради Буч участвует в написании серии "Разработка объектно-ориентированного программного обеспечения" ("Object-oriented Software Engineering Series"), издаваемой Addison-Wesley Longman.

P.S. Большая благодарность TanaT за интервью.

>>> Подробности

★★★★★

Проверено: maxcom

Ответ на: Кино для настоящих линуксоидов ;) от sS

Re: Кино для настоящих линуксоидов ;)

>а можно поподробнее про "ублюдочность" C++ ?

> C++ _гибридный_ язык

Вот вы сами себе и ответили

>именно в этом его _сила_

угу. Низкоровневый примитивный нерасширяемый синтаксис с указателями и спмостоятельным контролем за памятью при этом скрещённый с тормозными неэффективными механизмами vmt, ексепшенов и ран-тайм контролем типов. Вот уж сила так сила :)

> в мире мало реальных задач которые 100% ложились бы под какую либо "чистую" парадигму

Да-да. И вместо ипользования двух (трёх, четырёх...) удобных инструментов, надо пренепрменно использовать одного уродца. Хорошо хоть г-н Страуструп решил изгадить только ОО-парадигму и недобрался до SQL'я, а то бы счас ещё и запросы к базе писали на "великом и могучем".

>но зато для решения задачи _в_комплексе_ он оказывается эффективнее любого "чистого" языка

какая скука... Всё уже лет десять назад, как пережёвано столлманами-остерхаузами. Читай, учись, бери готовые решения, пользуйся. Нет, лезут, как тараканы из щелей, очередные обкуренные даже не "Введением в о-ориентированое проектирование", а гении-самоучки с томиком трупастрауса наперевес...

dsa ()
Ответ на: Re: Кино для настоящих линуксоидов ;) от dsa

Кино для настоящих линуксоидов ;)

> Да-да. И вместо ипользования двух (трёх, четырёх...) удобных инструментов,

Ага. См. флейм в Development на эту тему - лень делать copy&paste

Эффективность знаете как измеряется ?

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

Это аргументы ? ;) ой -ну не смешите народ ;)

Вам рассказывают _почему_ так произошло а вы тут размахиваете флаком с надписью "C++ must die"

sS ★★★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

С-шный подход: HANDLE handle = CreateObject(); /*handle - opaque handle :-)*/ DoSomething(handle); /*DoSometing declared in "inteface1.h":-) defined in "lib1.c" */ Почесали репу, добавляем: DoSomethingElse(handle);/*DoSometingElse declared in "inteface2.h":-)defined in "lib2.c" */

C++: Object *op = new Object(); // Object declared in "object.hpp", //defined in "object.cpp" op->DoSomething() //DoSomething defined in "object.cpp" Почесали репу, добавляем op->DoSomethigElse() //DoSomethigElse, not declared in "object.hpp" //not defined in "object.cpp" OOPS:-) - рефакторинг:-)

anonymous ()

Re: Гради Буч - о средствах разработки и их будущем

Люди добрые! Мне горько надо в XEmacs'е понять как выйти в меню с клавы. Помогите кто может.

anonymous ()
Ответ на: Кино для настоящих линуксоидов ;) от sS

Re: Кино для настоящих линуксоидов ;)

>Эффективность знаете как измеряется ?

количеством строк набитыми мартышками-кодёрами?

>Вам рассказывают _почему_ так произошло

А что произошло то? *nix'ы на 90% состоят из нормального сишного кода перемешенного нормальными, заточенными под свои области приминения по-настоящиму высокоуровенвыми языками. Смотрю на Emacs и вижу более чем достойное подтверждение, того, что два правильных инструмента, по всем параметрам (скорость написания, поддержка, развитие, документирование, надёжность) перебивают рассусоливания про "гибридные языки". Смотрю на винду и вспоминаю радостные рекламные вопли во времена появления win32 -- "Наша ОС переписана с нуля только на C".

Смотрю на порождения "универсальной" супер-пупер вся из себя джавы и вижу уродливых, тормозных монстров, по функциональности уступающимх старому-доброму tcl/tk.

...и ещё у кого-то хватает наглости петь военные песни про достоинства c++/java...

dsa ()

Re: Гради Буч - о средствах разработки и их будущем

Спасибо. Всё: счастье.

anonymous ()

Re: Гради Буч - о средствах разработки и их будущем

Не понимаю, о чем вы тут спорите?..

Если человек не понимает OOП или C++, так пусть и не использует их тогда. Все равно толку большого не будет. Сам замучается и других замучает ;)

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

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

dave ★★★★★ ()

Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>> тогда придётся сравнивать, доказывать и интегрировать

>тогда да. Приведи пример достаточно сложной проги, написанной без применения технологии ООП,

А почему обязательно "без". Вполне себе "с". _С_ другими не менее эффективными технологиями и на других не куда более эффективных инструментах.

>> ...ну в принципе рождённого слепым палочка тоже вполне устраивает

>и что бы он сделал, если бы не устраивала?

А она его не может не устраивать. Потому, что ничего другого не знает. Как и здешнего опестола, для которого весь мир ужался до "процедурщиков и объектников" (интересно, что делать с SQL'ем?)

dsa ()

Re: Re: Гради Буч - о средствах разработки и их будущем

>Если человек не понимает OOП или C++, так пусть и не использует их тогда. Все равно толку большого не будет. Сам замучается и других замучает ;)

Ключевые слова: "...и других замучает". Абсолютная истина. При том, что количество тех, кто "понимает ООП или С++" стремится к нулю.

dsa ()
Ответ на: Re: Кино для настоящих линуксоидов ;) от dsa

Кино для настоящих линуксоидов ;)

>>Эффективность знаете как измеряется ?

>количеством строк набитыми мартышками-кодёрами?

Ответ неправильный ;)

Судя по нему вы не только не кодер но уж не постановщик это точно ;)

>А что произошло то? *nix'ы на 90% состоят из нормального сишного кода перемешенного нормальными, заточенными под свои области приминения по-настоящиму высокоуровенвыми языками.

Дык вы видимо не в курсе что 70% (сейчас уже наверное больше) всего кода написанного в мире за все времена это именно C++ >Смотрю на порождения "универсальной" супер-пупер вся из себя джавы

Дык вот жава как раз не гибрид ... к сожалению

>тормозных монстров, по функциональности уступающимх старому-доброму tcl/tk.

какие такие преимущества имеет тикль перед джавой ?

BTW: то есть если переписать движек LOR-а на тикле будет проще и быстрей ? ;)))

PS: тикль хорош для написания программ типа "hellow world"

про все остальное это сказки для пионеров (глядя на весь из себя тиклевый "поделий" XPVM)

sS ★★★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

Приятно порадовало то, что Буч активно использует Java.

beetles ()

Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

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

http://www.khoral.com/

ANSI C + Fortran 77

Sun-ch ()

Re: Гради Буч - о средствах разработки и их будущем

Ассемблер был и будет! Всё остальное - фуфло для чайников

anonymous ()

Re: Re: Re: Гради Буч - о средствах разработки и их будущем

> При том, что количество тех, кто "понимает ООП или С++" стремится к нулю.

Сложно сказать. Здесь скорее идет речь о стиле или культуре мышления, чем о каких-то зазубренных вещах. А такую культуру нужно развивать годами. Кстати, Гради Буч вскользь упомянул об этом в своем интервью.

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

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

Поэтому сложно требовать от всех понимания идей ООП. Да и просто глупо это требовать.

dave ★★★★★ ()

Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Такая задача не катила (10 лет назад) под существовавшие тогда компиляторы С++ ввиду их (компиляторов сложности и, как следствие, глючности). Если вы внимательно почитаете интервью Линуса, то обнаружите, что в одном из них (извините, ссылок нет, но я ничего не придумываю) он говорит о том, что он делал попытки писать ядро на С++, да бросил потом из-за указанных выше причин.

--koivu--

anonymous ()

Re: Авторегулирование подкачки подсистемы виртуальной памяти

ладно уж, разругались.

тезис:
C++ достиг такой же захламлённости, что и Common LISP. А что вы хотели ? языку уже 20 лет. C++ непортабелен (да! почитайте разработчиков Mozilla, их рекомендации по тоому, что нельзя использовать, чтобы добиться реальной переносимости). Он просто слишком огромен, чтобы существовала его _правильная_ реализация. В парадигмальном плане намерения автора тоже неясны: таки ООП или generic programming ? плюс тяжёлое наследие C. Всё это делает C++ языком не высокого урорвня (я бы даже сказал невысокого ;).

нужна свежая кровь. если говорить про "лично мне", то нравится ocaml.

ну, поехали..

yakuza ()
Ответ на: C++ apology от atoku

Re: C++ apology

Не, с кодом из книжки все не так, как в Вашем варианте. Там не происходит выделения памяти ДО запуска main. Поэтому и неконтролируемого падения по этому поводу там быть не может.

Да, ваша версия заняла больше. И на диске, и в памяти. Как показывает мой опыт, разница эта никак не нивелируется. Особенно с использованием STL и прочих замечательных возможностей языка и стандартных библиотек. В лучшем случае, эта разница - константа (в %). В худшем - растет. Кстати, лет 7 назад один коллега произвел сравнение скорости вывода cout << и printf (не помню точно - то ли на Борланде, то ли на ВижуалС). Результаты получились удручающие (понятное дело, не в пользу С++). Надо бы сейчас попробовать...

С удовольствием передаю вымпел апологета С++. ОО - это действительно удобно.

Чесс слово, не знаю, где бы взять такой каталог. А настроить мускул - это не такая уж rocket science.

svu ★★★★★ ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

М-м. Я не знал, что можно использовать try/catch вне функций (давно я на С++ не работал - может, поменялось что). Это для меня абсолютная новость (надо бы проверить - есть у меня сомнения, что это скомпилируется). И, согласитесь, в этом случае количество кода растет (как исходного. так и результирующего). Так что эффективность "красивого" и "корректного" С++ кода все хуже и хуже. Чем красивее и корректнее - тем хуже.

svu ★★★★★ ()

Re: Re: Re: Re: Гради Буч - о средствах разработки и их будущем

Смотрю я на вас... Похоже у многих ООП связан исключительно с плюсовыми фенечками. Сразу видно, луди НЕДОПОНИМАЮТ что такое ООП который можно свободно использовать даже если на pure C пишешь.Несогласные могут читать здесь :

http://www.osp.ru/os/1996/06/2.htm
http://www.osp.ru/os/1996/06/27.htm

По поводу Ada сёдня нашёл http://www.osp.ru/os/2003/10/063_print.htm

anonymous ()
Ответ на: C++ apology от atoku

Re: C++ apology

> for(int i=0;i<10;++i)

> cout << Hello_World << endl;

До чего убогий язык, если простую фразу "вывести hello-world ровно константу раз" в нем нужно записывать через цикл с изменяемой переменной :)

anonymous ()

Re: Re: Гради Буч - о средствах разработки и их будущем

> anonymous (*) (20.11.2003 10:54:52) ... добавляем op->DoSomethigElse() //DoSomethigElse, not declared in "object.hpp" //not defined in "object.cpp" OOPS:-) - рефакторинг:-)

Respect! В принципе и добавить больше не чего.

ОО, равно как и процедурный подход являются разными гранями одной математической сущности: ADT. Просто исторически так получилось, что программерская общественность в начале обратила внимание и сделала акцент на операциях, в результате чего мы получили процедурный подход. Затем -- на величины (данные), и в итоге имеем ОО. Но этот временнОй фактор не правильно отождествлять с такими категориями как "современность" или "правильность" подхода.

Lucky ★★ ()

Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Вот дурак. 10 лет учить мат. модель, которая в 10 строк формулируется. Ты гуманитарчик, да? Так вот, гуманитарчик, ОО - далеко не единственная технология, позволяющая рассуждать в терминах предметной области. Далеко не каждая предметная область может быть вообще выражена в терминах ОО. Так что, гуманитарчик, иди, ещё 10 лет учись. Всё равно никогда ничему не научишься.

anonymous ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

Если кто считает говняный STL произведением искусства, то он - дурак. Он даже Haskell не видел. Ну а сравнивать могучие макры в common lisp с говняными придурочными темплейтами в C++ может только безмозглая жертва аборта...

anonymous ()

Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Боюсь, звание к.т.н не позволяет мне гордо наименоваться "гуманитарчиком". А учусь я не самой мат модели - а разумным способам ее применения. И если Вы уже научились и для каждого случая можете сходу создать наилучшую - могу только позавидовать.

И не хами, парень.

svu ★★★★★ ()
Ответ на: C++ apology от atoku

Re: C++ apology

Хахаха. Есть два типа программистов - математики, и придурки. Для придурков придумана религия - ООП, это дабы они издали умными казались. Математикам религии не нужны - они выбирают себе мат.модель по объективным критериям. И, так уж получилось, что ООП в качестве базовой модели они выбирают весьма нечасто - эта модель слишком уж узенькая и частная сама по себе. А кто такие "процедурщики" - я не в курсе. Вероятно, мелкий подвид придурков...

anonymous ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

>Код порождает не библиотека, а компилятор. Запомните на будующее - пригодится. Если речь идет об stl то это отлично сработанная вещь. boost тоже классная штука, а loki - вообще произведение искусства. Рекомендую. Хотя наверное зря. Вы там ничего не поймете...

А что такое loki? Первые два респект, согдасен ). Только для сети, xml и юникода что-нибудь бы ещё. Мне Qt очень нравится. И Gui, и остальное. Сигналы-слоты вообще прелесть. Хотя libsigc++ хвалят, но по мне так Qt поудобнее будет. Почти идеал C++ либы.

adarovsky ★★★★ ()
Ответ на: Re: C++ apology от anonymous

Re: Re: C++ apology

... И в воздухе запахло математическим снобизмом. Может быть, Вы до сих пор думаете, что компьютеры существуют, чтобы что-то ВЫЧИСЛЯТЬ?:)

svu ★★★★★ ()

Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Eiffel (включая дорогие коммерческие реализации) компилит в промежуточный Си. И весьма эффективно.

Да и байткоды - не такое уж и зло, что нам наглядно демонстрирует .NET.

anonymous ()

Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Пример сложной абсолютно не-ОО системы, работающей на традиционном поле ООПности - Fudgets. Так же это пример того, когда правильно выбранная мат.модель оказывается на порядки эффективнее попсовой "универсальной" псевдометодологии.

anonymous ()

Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Буду хамить. КТН - это диагноз. Такими вот КТНами переполнены уродские конторки вроде РАЕН, которые разогнать давно с расстрелом и конфискацией пора. Ненавижу эту публику. Ну и учиться способам применения настолько примитивной и узкой модельки может только КТН, с этим я готов согласиться... Спасибо за очередную демонстрацию, что "технари" ещё более неприспособлены к аналитическому мышлению, чем гуманитарии. Только математики - люди, остальным надо улицы подметать.

anonymous ()
Ответ на: Re: Re: C++ apology от svu

Re: Re: Re: C++ apology

Я считаю, что любое ЗНАНИЕ - объект математический. Всё, связанное с информацией, знанием, прогнозированием, управлением - задачи математические. Не-математиков - гнать ссаными тряпками из этого дела. В первую очередь - всех КТН-ов - к стенке!

anonymous ()

Re: Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Хамите. Дальнейшую дискуссию считаю бесполезной в связи с неконструктивной позицией, занятой противоположной стороной.

svu ★★★★★ ()
Ответ на: Re: C++ apology от anonymous

Re: Re: C++ apology

>>Хахаха. Есть два типа программистов - математики, и придурки
Настоящие программисты выбирают асемблер.
Все крутые программы написанны на нем.
Вовеки веков ...

anonymous ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

> Настоящие программисты выбирают асемблер.

Есть три типа ассемблеров - лиспообразные, фортообразные и безобразные. Ты наверно виДДел только последние.

anonymous ()
Ответ на: Re: Re: Re: C++ apology от anonymous

Re: Re: Re: Re: C++ apology

>>Я считаю, что любое ЗНАНИЕ - объект математический. Всё, связанное с >>информацией, знанием, прогнозированием, управлением - задачи
>>математические
Вашими устами да мед бы пить.
В нашем бухучете возможна ситуация a + b != b + a

anonymous ()
Ответ на: Re: C++ apology от svu

Re: Re: C++ apology

>Результаты получились удручающие (понятное дело, не в пользу С++). Надо бы сейчас попробовать...

Попробуйте. С хорошо умеющим инлайнить компилятором с пристойной реализацией библиотеки. С MSVC последним, например. Потоки будут быстрее. По вполне понятной причине.

anonymous ()
Ответ на: Re: C++ apology от svu

Re: Re: C++ apology

>В лучшем случае, эта разница - константа (в %). В худшем - растет.

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

Даже для вычислительного кода.

anonymous ()
Ответ на: Re: Re: Re: C++ apology от anonymous

Re: Re: Re: Re: Re: Re: Re: Ядро FreeBSD собирается компилятором Intel

>Он даже Haskell не видел.

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

anonymous ()

Re: Re: Авторегулирование подкачки подсистемы виртуальной памяти

>Он просто слишком огромен, чтобы существовала его _правильная_ реализация.

Тем не менее, они имеют место быть.

>В парадигмальном плане намерения автора тоже неясны: таки ООП или generic programming ?

GP в его, так сказать, нынешнем прикладном виде придумали как приложение плюсовых шаблонных фич. Это, не к автору вопросы, а "к языку" -- он по-всякому позволяет писать.

Хотя, захламленности, и самое главное, _многословности_ плюсов отрицать не стану.

anonymous ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

Попробовал. Извините, под винюки перегружаться было влом - использовал gcc (уже вижу летящую в меня кучу камней). Без оптимизаций вообще (вторая куча камней показалась в воздухе). Тест - элементарный - 1е6 раз вывел Hello World на стандартый выход. Очевидно, при тестировании в качестве оного использовал /dev/null. Для измерения использовал старый добрый time.

C++ (cout):

real 0m2.918s

user 0m2.890s

sys 0m0.000s

C (printf):

real 0m0.185s

user 0m0.170s

sys 0m0.000s

Принимаются предложения по ключам оптимизации - как для С, так и для С++.

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