Почему ООП провалилось?
что вы об этом думаете?Уже обсуждали, это просто толстый вброс. Например (фраза против ООП):
Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома.
там есть и объективная критика:
Томас Поток из MIT даже провел масштабное прикладное исследование, которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами работающими в ООП и в обычном процедурном стиле программирования.
ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно считать C# в .NET 3.5 с более чем 50,000 реализованных классов "венцом эволюции".
Томас ПотокВо-первых, кто это? Во-вторых, ссылка не работает.
ООП ради самой ООП уже давно превратилось в замкнутый круг.
Это не критика, а игра словами ни о чём.
да ладно! признай свое поражение, Майк! 
переходи в наш лагерь НАХУЙБУСТ, пока не поздно!
пока мы едины мы непобедимы!
даже уже на нашей стороне.
ПРОЦЕДУРЫ ДЛЯ ПРОГРАММИСТОВ, ОБЪЕКТЫ ДЛЯ ЛОХОВ!
переходи в наш лагерь НАХУЙБУСТ, пока не поздно!
пока мы едины мы непобедимы!
даже уже на нашей стороне.
ПРОЦЕДУРЫ ДЛЯ ПРОГРАММИСТОВ, ОБЪЕКТЫ ДЛЯ ЛОХОВ!
что вы об этом думаете?ООП — это религия. С фанатичными адептами ООП спорить бесполезно, они невменяемые.
Пусть дальше классы свои проектируют.
Особенно бесят синглтоны.
Это же каким ебанутым надо быть, чтобы хотеть синглтонить класс.
Это же каким ебанутым надо быть, чтобы хотеть синглтонить класс.
в обычном процедурном стиле программированияинтересно посмотреть - где например так программируют?
или в эту категорию просто тупо всех C-шников записали потому что в C ключевого слова "class" нет?
интересно посмотреть - где например так программируют?Я так программирую.
В класс оформляю только то, что целесообразно объединить как объект.
ООП - не стал единственной серебряной пулей, так же как до этого не стали серебряной пулей: структурное программирование, процедурное программирование и т.д.
но ООП стал частью базиса программирования на котором вырастают текущие языки программирования
и скорее всего в будущем ООП будет другим, чем оно сейчас реализовано в main-stream языках: так же как процедуры в фя стали функциями, а в ооп - процедуры стали методами.
но ООП стал частью базиса программирования на котором вырастают текущие языки программирования
и скорее всего в будущем ООП будет другим, чем оно сейчас реализовано в main-stream языках: так же как процедуры в фя стали функциями, а в ооп - процедуры стали методами.
Коменты жгут.
От ООП плавно перетекли к GPS.
От ООП плавно перетекли к GPS.
простите, а можно вопрос: А куда оно провалилось-то?
Вася П. 5ый вэ класс.
Вася П. 5ый вэ класс.
ПРОЦЕДУРЫ ДЛЯ ПРОГРАММИСТОВhttp://en.wikipedia.org/wiki/Unlambda
Ы-ы-ы-ы-ы-ы, why IO monad failed.
Это же каким ебанутым надо быть, чтобы хотеть синглтонить класс.сегодня синглтонишь класс,
а завтра ты !
ООП - не стал единственной серебряной пулейэто наверное наиболее разумная оценка в отношении много чего.
Меня интересует мнение профессионалов относительно всяких там наследований, шаблонов и пр.: действительно ли это на порядок упрощает разработку по сравнению с процедурным программированием или наоборот, в конечном итоге все запутывает и обрекает поколения программистов на нескончаемый рефакторинг.
Меня интересует мнение профессионалов относительно всяких там наследований, шаблоноввот тебе самому разве не упрощает жизнь использование шаблонов(генериков)? Фишка в том, что непонятно как определить золотую середину сложности - когда упрощение обернется усложнением. Те же макросы в си можно использовать во благо, а можно создать совершенно нечитаемый код.
что вы об этом думаете?мы думаем, что такое использование пресуппозиции недопустимо, должно осуждаться всеми благноравными членами нашей общины, а его автору зачтут его на последнем суде.
а куда ООП провалилось?
что вы об этом думаете?думаю, что провала нет, так как парадигма прожила довольно много
вообще, у каждой парадигмы есть и плюсы и минусы
если ее с умом использовать (то есть поменьше минусов и побольше плюсов то мы будем в выигрыше
проблема еще есть в подсчете количественных характеристик\мерах полезности, т.к. объективных метрик нет, но есть субъективные. поэтому и существуют холиворы - некоторым одни плюсы кажутся больше минусов, а некоторым наоборот
часто подходы применяют в неудачных (неподходящих) местах и начинают их считать провальными
выбор подходящего инструмента под конкретную задачу должен способствовать более продуктивному\быстрому\надежному\etc результату при выборе подходящего инструмента, имхо. отсюда и могут произрастать причины "провалов" при использовании "универсальных" языков. есть мнение, что будущее не за гибридными языками (ООП+ФЯ которые опять же претендуют на универсальность, а за DSL.
и вообще, Хаскель всех порвёт
вот тебе самому разве не упрощает жизнь использование шаблоновя потому и спрашиваю, что ничем этим не пользуюсь - пишу на python по науке, да на голом C для контроллеров
Те же макросы в си можно использовать во благо, а можно создать совершенно нечитаемый код.когда программист идет от кода (и при наличии определенных навыков работы с кодом) обычно получается вменяемый код. А ООП-шники саму задачу начинают решать по OO методологии, вот тут, да, часто наблюдается усложнение, которое не сопоставимо с решаемой задачей. А когда идешь от кода, то по результирующему коду можно разобраться, откуда появилась сложность и увидеть, что сложность вызвана самой задачей (ну или недостатоком навыка у автора
).// Меня интересует мнение профессионалов относительно всяких там наследований, шаблонов и пр.: действительно ли это на порядок упрощает разработку по сравнению с процедурным программированием или наоборот, в конечном итоге все запутывает и обрекает поколения программистов на нескончаемый рефакторинг.
А говорят - Development скучный раздел.
А говорят - Development скучный раздел.
даже уже на нашей стороне.Спасибо, что предупредили
ПРОЦЕДУРЫ ДЛЯ ПРОГРАММИСТОВ, ОБЪЕКТЫ ДЛЯ ЛОХОВ!
Только это не так.
Я не на чьей стороне. Во всем есть плюсы и минусы, как верно подметили, и использование того или иного зависит от ситуации. (Мелким шрифтом: только ситуаций, где удобно использовать ООП, я вижу больше
)Но когда на Си пишут виртуальные функции через собственные таблицы виртуальных функций, я искренне удивляюсь.
Спасибо за ссылку, поржал от души. Похоже, под ООП в этой статье все понимают что-то свое. Но всегда что-то плохое, злое и непонятное
Вообще в свое время "большая тройка" задумывала ООП и ООД как удобный способ моделирования объектов бизнеса (т.н. "реального мира"). И, кстати, этот способ моделирования до сих пор остается хорошим.
Вообще в свое время "большая тройка" задумывала ООП и ООД как удобный способ моделирования объектов бизнеса (т.н. "реального мира"). И, кстати, этот способ моделирования до сих пор остается хорошим.
Вообще в свое время "большая тройка" задумывала ООП и ООД как удобный способ моделирования объектов бизнеса (т.н. "реального мира"). И, кстати, этот способ моделирования до сих пор остается хорошим.А зачем нужно моделирование?
Если только для разработки софта. Тогда вопрос: зачем нужен двухэтапный процесс: a) моделирование, b) написание кода, если можно обойтись одноэтапным: написание кода?
Тоже пишу на чистом Си. Не ну шаблоны можно юзать для сокращения количества кода, но читаемости каюк придет. А я не настолько суров . Или классический пример - рекурсивный факториал на шаблонах на этапе компиляции - можно, но все равно ж там глубина ограничена. Громоздкость не тру имхо. Насколько я знаю, в ABBYY, например, шаблоны запрещены из-за читаемости. А в когнитиве суровый бородатый мехмат пишет на шаблонах . Чернов на ВМК больше уделяет внимание сям чем плюсам. B еще толстый том есть "проблемы программирования С++". Это же ахтунг по сути.
. Или классический пример - рекурсивный факториал на шаблонах на этапе компиляции - можно, но все равно ж там глубина ограничена. Громоздкость не тру имхо. Насколько я знаю, в ABBYY, например, шаблоны запрещены из-за читаемости. А в когнитиве суровый бородатый мехмат пишет на шаблонах . Чернов на ВМК больше уделяет внимание сям чем плюсам. B еще толстый том есть "проблемы программирования С++". Это же ахтунг по сути. Основной принцип то "пиши проще - не вы******ся".
Баян, но будет в тему имхо http://habrahabr.ru/blogs/htranslations/111348/
http://zloy_zhake.yvision.kz/blog/2136.html
Баян, но будет в тему имхо http://habrahabr.ru/blogs/htranslations/111348/
http://zloy_zhake.yvision.kz/blog/2136.html
Шаблоны, шаблоны. Как вы на чистом Си пишете динамическую коллекцию однотипных объектов?
Ну в ABBYY да, они запрещены по дефолту из боязни абуза.
Ну в ABBYY да, они запрещены по дефолту из боязни абуза.
динамическую коллекцию однотипных объектов?что это такое?
type *dynamic_collection_of_objects_of_type_type;
:?
Основной принцип то "пиши проще - не вы******ся".Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям. Мартин Фаулер Вроде не хватает там этой цитаты.
а, во второй ссылке есть, да.
массивчег
type *dynamic_collection_of_objects_of_type_type;ну да, в некотором роде, а дальше что? Интерфейс будет такой?
void add_element(void *dynamic_collection_of_objects_of_type_type, size_t elementSize, void* element, size_t currentSize)
void remove_at(void *dynamic_collection_of_objects_of_type_type, size_t elementSize, size_t index, size_t currentSize)?
ну тебя, вероятно, вопросы распределения памяти интересуют.
ну они же сильно зависят от задачи. ну если охота перфекционистом быть.
а если не охота, вон библиотек полно.
никому не нужны "динамические коллекции объектов одного типа"
или, проще говоря, массивчеги, как вещь в себе.
judy - очень хорошая библиотека для работы с динамическими массивами в сях.
интерфейс там чуть посложнее описанного тобой, но умеет больше.
ну они же сильно зависят от задачи. ну если охота перфекционистом быть.
а если не охота, вон библиотек полно.
Интерфейс будет такой?да какой угодно.
никому не нужны "динамические коллекции объектов одного типа"
или, проще говоря, массивчеги, как вещь в себе.
judy - очень хорошая библиотека для работы с динамическими массивами в сях.
интерфейс там чуть посложнее описанного тобой, но умеет больше.
ну да, там вон за счет макросов экономится.
Мне на C не приходилось ничего серьезного писать, поэтому не знаю, как вы обходитесь.
Мне на C не приходилось ничего серьезного писать, поэтому не знаю, как вы обходитесь.
никому не нужны "динамические коллекции объектов одного типа"ну а кто говорит о вещи в себе? Просто привел пример из повседневной практики.
или проще говоря массивчеги как вещь в себе.
ну да, там вон за счет макросов экономится.где?
в judy экономится не засчет макросов,
хотя они вообще полезны и там тоже используются.
Просто привел пример из повседневной практики.ну ты привел плохой пример, т.к. никому обычно не нужен контейнер общего назначения,
а если нужен, то это не очень важное место и можно взять что угодно (это и есть общесть назначения).
ну judy подходит и если нужно общее назначение,
хотя он сложноват по читабельности, пожалуй, чтоб везде его использовать.
Ок, как тогда там можно сделать массивчег из структур и чтобы туда добавлять постепенно (неизвестное число элементов)?
size_t elementSize, void* elementЫ-ы-ы.
#define REF(cont) cont, sizeof(cont[0])
add_element(REF(cont lmnt, SIZE(cont;
ну ты привел плохой пример, т.к. никому обычно не нужен контейнер общего назначения,Ну так о читабельности и речь, естественно. Ну что значит не нужен контейнер общего назначения? И откуда эта импликация про неважность места? Недавно написал довольно шустрый алгоритм на графах, использовал довольно много std::vector (правда выделение памяти там было один раз, только вначале, поэтому динамичность не особо использовалось, просто контроль за выделением памяти). Причем «место» — это весь алгоритм
а если нужен, то это не очень важное место и можно взять что угодно (это и есть общесть назначения).
ну judy подходит и если нужно общее назначение,
хотя он сложноват по читабельности, пожалуй, чтоб везде его использовать.
ну вот, мне так и показалось, что там макросами сделано, а говорят, что макросы тут ни при чем 
Ок, как тогда там можно сделать массивчег из структур и чтобы туда добавлять постепенно (неизвестное число элементов)?/usr/include/ggi/gg-queue.h?
Вообще, сишные макросы - это плохо. Они даже плюсовые шаблоны толком не заменяют.
Ну так о читабельности и речь, естественно.ой, ты какой-то пенартур. мне лень с тобой чето обсуждать, чесгря. =)
ну т.е. ты добрый пенартур.
то есть не бесишься, но при этом какие-то вопросы дурацкие задаешь.
ну если тебе не читабельно, сделай по-другому, кто мешает.
ну или сходи в доку про judy и сам реши, насколько она лично для тебя читабельна.
я тебе хорошую ссылку дал, а тебе лишь бы попиздеть. =)
да я же сходил. И я не заставляю тебя пользоваться плюсами или std::vector там, просто интересуюсь, как там у вас. А у тебя какая-то пенартурофобия.
Ну так о читабельности и речь, естественно. Ну что значит не нужен контейнер общего назначения? И откуда эта импликация про неважность места? Недавно написал довольно шустрый алгоритм на графах, использовал довольно много std::vector (правда выделение памяти там было один раз, только вначале, поэтому динамичность не особо использовалось, просто контроль за выделением памяти). Причем «место» — это весь алгоритмну это "морфология волшебной сказки", слушай.
в самом деле, трудно найти что-то новое и увлекательное в очередном повествовании о том,
что-де жила-была некоторая система, и всем она устраивала заказчиков, да только вот все равно плоха была. (c)
вместо твоего вектора можно было взять еще миллион других вариантов общего назначения,
существующих в каждом языке. это не очень интересно обсуждать. изюминки нету.
И я не заставляю тебя пользоваться плюсами или std::vector там, просто интересуюсь, как там у вас.у меня пиздежефобия. =)
А у тебя какая-то пенартурофобия.
такое ощущение, что ты интересуешься просто с целью в очередной раз убедиться.
у меня фобия такого интереса еще. мне неинтересны люди, которые вот с такой целью интересуются.
вобщем, мне кажется, Си в среднем немного менее читабельны, чем Плюсы,
но мне сложно сформулировать точнее и я знаю много вопиющих примеров.
скажем, библиотека PIRE из яндекса, в которой для обучающего примера автор
завернул свои монадообразные конструкции типа нижеследующей
в обычные сишные функции. видимо, иначе никто не понимал просто.
ну и вообще, читабельность штука сложная и с языком итселф связана гораздо меньше,
чем с окружающим язык комьюнити. с культурной традицией своего рода.
но мне сложно сформулировать точнее и я знаю много вопиющих примеров.
скажем, библиотека PIRE из яндекса, в которой для обучающего примера автор
завернул свои монадообразные конструкции типа нижеследующей
Lexer(str.begin str.end.AddFeature(Features::CaseInsensitive.SetEncoding(Encodings::Utf8.Parse.Surround.Compile<NonrelocScanner>
в обычные сишные функции. видимо, иначе никто не понимал просто.
ну и вообще, читабельность штука сложная и с языком итселф связана гораздо меньше,
чем с окружающим язык комьюнити. с культурной традицией своего рода.
Динамику вообще применять лучше только в крайнем случае если обычными массивами не обойдешься. Ща меня затроллят по ходу . На стеке быстрее память.
. На стеке быстрее память.тебя щас пианист на работу возьмет с такими утверждениями.
он таких молодых и дерзких любит. =)
он таких молодых и дерзких любит. =)
У меня было собеседование в яндекс по яве недавно в отдел моделирования медиарекламы. Вежливо отказали.
И я забил на яву.
Я на всерос ездил в школе в 10 классе. Но так как система подготовки к этом у делу у нас в Нальчике не очень хорошо поставлена была (сейчас - не знаю то диплом я не заработал. А потом забил на это дело, поступил в сунц в физмат и год вообще не прогал считай, математику ботал. А человек с дипомом всероса быстрее пишет осмысленный код. Так что я не считаю себя особо тру программером, но в элементарных вещах я типа не ошибаюсь.
А плюсы - если уж писать на плюсах (то есть на си с классами) то токо какие-нибудь комплексные числа например - где перегружать операции надо все аккуратно, то есть без этого (классов) не обойдешься. Но это спасибо чернову - к нему попал на 2 курсе.
И я забил на яву
.Я на всерос ездил в школе в 10 классе. Но так как система подготовки к этом у делу у нас в Нальчике не очень хорошо поставлена была (сейчас - не знаю то диплом я не заработал. А потом забил на это дело, поступил в сунц в физмат и год вообще не прогал считай, математику ботал. А человек с дипомом всероса быстрее пишет осмысленный код. Так что я не считаю себя особо тру программером, но в элементарных вещах я типа не ошибаюсь.
А плюсы - если уж писать на плюсах (то есть на си с классами) то токо какие-нибудь комплексные числа например - где перегружать операции надо все аккуратно, то есть без этого (классов) не обойдешься. Но это спасибо чернову - к нему попал на 2 курсе.
Сообщение удалил
Вообще, сишные макросы - это плохо. Они даже плюсовые шаблоны толком не заменяют.Мне никогда не были понятные холивары, противоспоставляющие макросы шаблонам, когда они так хорошо дополняют друг друга. Трудно написать по-настоящему гибкий и удобный интерфейс на плюсах без использования обоих этих инструментов.
ну в каком крайнем? Когда нужно динамическое выделение памяти (заранее размер неизвестен как и было написаноо. Это — крайний случай?
ну да как бы. не ну это понятно все от предметной области зависит - какой инструмент юзать. чем сложнее и мудренее пишешь имхо, тем вероятность написать небажный код падает. но динамика и в си есть - каллоки, маллоки, их по горло хватает. ну если много народу в плюсосовй команде - и один на другом конце шарика забыл че-нить освободить, начинается песец =) - течет же она и все с бубном бегают. ну к сям это тоже относится. в яве это решили конечно, но ява медленней потому что интерпертируемый, в куче все и мусор на автомате собирается - он же менее производительно его собирает чем человек. но ява приятная, потому что поддержка среды хорошая - когда код пишешь и компилится в байт код быстрее. это гуд.
а вообще - соблюсти балланс читаемости, адекватности и производительности - вот это мастерство. к этому типа надо стремиться. я стараюсь типа. чтоб не через жопу все и красиво =). но на сях честно скажу - побитово ломает че-нибудь хранить меня. все интами или побайтово и пох. может потом как-нибудь стану лучше писать.
в плюсах имхо нагрузка на программера высокая очень - поэтому к дедлайну релиз бажный всегда =). и потом сроки добавляют. такое проганье типа вешь в себе быдлокодить ради быдлогодинга. ну это я уже погнал эмоционально. имхо свое. си - без ооп. ява - ооп но образана, а плюсы - аромат, вышибающий вообще все запахи - все в одном флаконе. метамегаизбыточный изык. это тоже имхо. от задач все зависит. короче погнал я уже под конец =)
а вообще - соблюсти балланс читаемости, адекватности и производительности - вот это мастерство. к этому типа надо стремиться. я стараюсь типа. чтоб не через жопу все и красиво =). но на сях честно скажу - побитово ломает че-нибудь хранить меня. все интами или побайтово и пох. может потом как-нибудь стану лучше писать.
в плюсах имхо нагрузка на программера высокая очень - поэтому к дедлайну релиз бажный всегда =). и потом сроки добавляют. такое проганье типа вешь в себе быдлокодить ради быдлогодинга. ну это я уже погнал эмоционально. имхо свое. си - без ооп. ява - ооп но образана, а плюсы - аромат, вышибающий вообще все запахи - все в одном флаконе. метамегаизбыточный изык. это тоже имхо. от задач все зависит. короче погнал я уже под конец =)
шаблоны можно юзать для сокращения количества кода, но читаемости каюк придет.И нужно.
STL прекрасен и читабелен, писать надо уметь.
А то что в Абби там что-то запрещено — Абби вообще не пример, я их кода не видел ни на экране, ни в практике что-то выдающегося.
Разумеется, я не на стороне идиотизма ООП. Просто надо отдать должное, что string/vector/map сильно упрастили наше жизнь. Ну и в классы заворачивать что-то самостоятельное вовсе не грех. Грех начинается не когда в класс объединяют что-то, а когда думают "какие у нас будут классы" и начинают прогу проектировать из одного места.
Согласен очасти. Надо. На это время надо и побольше,а оно видимо с опытом приходит - умение писать код без багов на шаблонах понятный. Я для себя решил, что шаблонами буду делать токо когда рефакторить буду. может быть. Короче шаблоны - ну для меня это сложно, надо проще быть. =)
эээм. весь тред не осилил. ссылку на блогераторе прочитал.
киньте плиз ссылку чтобы понять что значит писать "процедурами"
киньте плиз ссылку чтобы понять что значит писать "процедурами"
как-то так наверное
http://en.wikipedia.org/wiki/Procedural_programming#Comparis...
но реально все срутся не из-за собственно классов (которые часто удобны а из-за сопутствующих механизмов (типа шаблонов-синглетонов впрочем порожденных ООП парадигмой
http://en.wikipedia.org/wiki/Procedural_programming#Comparis...
но реально все срутся не из-за собственно классов (которые часто удобны а из-за сопутствующих механизмов (типа шаблонов-синглетонов впрочем порожденных ООП парадигмой
блин, что за мрак? каллоки и маллоки — как раз для того, чтобы забыть освободить. В этом-то и фишка плюсов, что там есть время жизни объектов, смарт-поинтеры, эти самые дин. массивы — как раз для мемори менеджмента. Так что каллоки и маллоки не надо мне предлагать, это совсем другое.
Сложно не шаблоны, а какое-нибудь метапрограммирование, потом поддерживать невозможно (наверное, не поддерживал ) а вот пишешь ты свою структуру данных, почему бы не сделать сразу шаблон, чтобы можно было хранить все, что угодно? Это: читабельно, не надо будет потом делать замену по всему коду, производительность не рушит.
) а вот пишешь ты свою структуру данных, почему бы не сделать сразу шаблон, чтобы можно было хранить все, что угодно? Это: читабельно, не надо будет потом делать замену по всему коду, производительность не рушит.ну да, смарт поинтеры есть. а если ты в деструкторе забыл че-нибудь (ресурс освободить) то все упадет или некорректно работать будет =). и громоздко это. ну время жизни и в си есть, объектов токо нету. вобщем меня задрало говорить на эту тему. осталось предложить ситечко в ответ на мрак тебе как остап
а если ты в деструкторе забыл че-нибудь то вешайся =)щито?
а если ты в деструкторе забыл че-нибудь то вешайся =).У нас не неделя флейма, а неделя кодеров, которые делают выводы о вещах, в которых ровным счётом ничего не понимают.
Блин, какая у тебя каша в голове...
http://unicorn.cmc.msu.ru/3sem/c.shtml
вот короче. самый тру вмкашный препод кодер тут. дальше че то доказывать влом. переходит в холивар действительно.
вот короче. самый тру вмкашный препод кодер тут. дальше че то доказывать влом. переходит в холивар действительно.
а там ссылок много. там чего смотреть-то?
все как бы
на плюсах (то есть на си с классами)
http://avchernov.livejournal.com/312.html
Да вот еще холиварчик. Но это на тему паскаль - си.
Да вот еще холиварчик. Но это на тему паскаль - си.
к чему ты это постишь? это же не относится к теме треда. В учебнике по C не написано, хорошо или плохо ООП, в блоге Чернова — тем более.
ну не читай. это вмкашный холивар. думают че вводить. кста спорят то между двумя процедурными языками если че.
ну так он шарит как прально юзать плюсы. и юзает. токо мало. поэтому и не написано. плюсы - порог вхождения ну самый большой чтоли из всего. его в универе слабореально весь изучить.
ну так он шарит как прально юзать плюсы. и юзает. токо мало. поэтому и не написано. плюсы - порог вхождения ну самый большой чтоли из всего. его в универе слабореально весь изучить.
Я читал это и сам учился у Чернова (на 3-м курсе, правда). Я не понимаю, зачем ставить ссылки на него здесь, если он там не разъясняет, чем процедурное программирование лучше или хуже ооп.
ты как бы тему читай. попросили материалы по процедурному проганью. я дал. по сям все в одном месте. че ты еще хочешь?
Тогда всё ок, но холивар паскаль-си всё равно лучше отдельно обсудить, если хочется.
обсуждали уже
ну так он шарит как прально юзать плюсы. и юзает.а сайт почему тогда на сях написан?
Я целиком и полностью за ООП и не считаю вовсе что оно провалилось. Структура классов есть даже в хаскеле. А шаблоны в си действительно полезная штука - посмотрю как без переопределения операторов вы будете писать аналог векторного сложения на expression templatах. Вот пример достигнутого. Любителям системного программирования рекомендую обратить внимание на сравнительные листинги ассемблера в конце, вряд ли они не смогут обнаружить толк от применения темплатов. Никто не спорит, что ту же самую задачу можно решить и на голом си, но как неудобно будет применять получившиеся процедуры? Куда как неудобнее просто написать (-)
Любителям системного программирования рекомендую обратить внимание на сравнительные листинги ассемблера в конце, вряд ли они не смогут обнаружить толк от применения темплатов.Он с помощью темплатов пытается сделать работу компилятора по оптимизации программы вместо компилятора? А он уверен, что это правильное применение шаблонов?
Немножко экспериментальных данных:
скомпилировать его программу я не смог, какой-то там уж слишком диалект C++
предложенный им откомпилированный бинарник на тесте 3 (vD = vD + vA + vB + vC) работает 0.65 (Jim's) и 0.58 (Tomas'). Видимо в секундах. Наивная реализация на C, скомпилированная в режиме совместимости с i386, работает 0.56 секунды. Если разрешить компилятору использовать SSE - в полтора раза быстрее. Процессор - core2 3GHz.
PS: мне не нравится его метод измерения времени, а именно эти BREAK внутри цикла и куча if-ов.
upd:
листинг (10^8 раз в цикле делаем vD = vD + vA+ vB + vC)
.L8:
addss %xmm11, %xmm0
addl $1, %eax
addss %xmm10, %xmm1
cmpl $100000000, %eax
addss %xmm9, %xmm2
addss %xmm8, %xmm0
addss %xmm7, %xmm1
addss %xmm6, %xmm2
addss %xmm5, %xmm0
addss %xmm4, %xmm1
addss %xmm3, %xmm2
jne .L8
Там есть материалы по плюсам с переопределением операторов. По шаблонам, насколько я помню, нет.
Вот, кстати, том http://books.tr200.ru/v.php?id=114530
Название говорит само за себя.
Вот, кстати, том http://books.tr200.ru/v.php?id=114530
Название говорит само за себя.
На мой взгляд с ООП быстрее разрабатывать большие программы. Как ни крути в процессе разработки нельзя полностью удалиться от терминов и объектов исходной задачи. ООП явно представляет их классами, процедурный подход - неявно в множествах процедур и переменных, из-за этого приходится помнить на какие составляющие был разобран исходный объект - а это дополнительная нагрузка на программиста.
Единицы компиляции в виде множества объединенных по смыслу процедур, имхо, вполне хватает. А интерфейсы во внешнюю среду разумно предоставить через ключевое слово extern (в сях).
Фактически получаются статические классы.
ООП является просто расширением процедурного подхода, когда программисту разрешено создавать свои типы данных и определять операции на ними. Мне было бы интересно послушать про недостатки ООП по сравнению с процедурным подходом.
Если говорить о конкретике, то я против сугубо процедурного подхода так как после разделения исходных объектов задачи на данные теряются такие вкусности как:
1) динамическое создание объекта по его имени или типу
2) доступ к списку методов объекта (список всех процедур для работы с объектом)
3) наследование, о котором уже говорилось
4) виртуальные\абстрактные\перегруженные в наследниках методы
5) свойства
Сужу по C#.
Нашел интересную статью в тему.
ООП является просто расширением процедурного подхода, когда программисту разрешено создавать свои типы данных и определять операции на ними. Мне было бы интересно послушать про недостатки ООП по сравнению с процедурным подходом.
Если говорить о конкретике, то я против сугубо процедурного подхода так как после разделения исходных объектов задачи на данные теряются такие вкусности как:
1) динамическое создание объекта по его имени или типу
2) доступ к списку методов объекта (список всех процедур для работы с объектом)
3) наследование, о котором уже говорилось
4) виртуальные\абстрактные\перегруженные в наследниках методы
5) свойства
Сужу по C#.
Нашел интересную статью в тему.
тебе очень сложно ответить, т.к. ты не привязываешь свои слова к чему-то из жизни.
поэтому все, что ты говоришь, ложится куда-то в область субъективной сексуальности,
о которой говорить интересно, но доказывать бесполезно (каждый дрочит, как он хочет).
же пытается сформулировать мысль, что для решения задач из жизни,
сишных способов для работы с концепцией объекта, как правило, достаточно.
по крайней мере ему.
и вот с этой точкой зрения уже можно согласиться или не согласиться.
а по поводу того, что тебе не нравится, когда ты не можешь уютненько "отнаследоваться"
сложно что-то сказать конструктивное. можно только тебя пожалеть, например. ну, успокоить там.
поэтому все, что ты говоришь, ложится куда-то в область субъективной сексуальности,
о которой говорить интересно, но доказывать бесполезно (каждый дрочит, как он хочет).
же пытается сформулировать мысль, что для решения задач из жизни,
сишных способов для работы с концепцией объекта, как правило, достаточно.
по крайней мере ему.
и вот с этой точкой зрения уже можно согласиться или не согласиться.
а по поводу того, что тебе не нравится, когда ты не можешь уютненько "отнаследоваться"
сложно что-то сказать конструктивное. можно только тебя пожалеть, например. ну, успокоить там.
Ну если ты UI пишешь, то ок - юзай шарпы и наследование. К бд запросы на скул через си кста меня тоже ломает писать - поэтому тоже шарп (хотя можно и си). Были бы интересны вопросы производительности с# vs c в этих случаях. Точной инфы я не знаю.
К бд запросы на сях кста меня тоже ломает писать - поэтому тоже шарп[троллинг]запросы на скл пишуцо![/троллинг] Кстати вот как запрос оттранслировать в бд - вообще разницы нет.
А поддержка наследования и полиморфизм на уровне языка(а не эмуляцию) действительно помогает(сокращает код, повышает читабельность там где нужно.
Он с помощью темплатов пытается сделать работу компилятора по оптимизации программы вместо компилятора? А он уверен, что это правильное применение шаблонов?
Наивная реализация на C, скомпилированная в режиме совместимости с i386, работает 0.56 секунды. Если разрешить компилятору использовать SSE - в полтора раза быстрее. Процессор - core2 3GHz.почитай http://www.oonumerics.org/blitz/papers/
Он с помощью темплатов пытается сделать работу компилятора по оптимизации программы вместо компилятора? А он уверен, что это правильное применение шаблонов?вот хаскель, казлось бы, идеальный язык для оптимизация - однако поди же ты, не так много тамошний компилятор умеет. Сишный тоже не блещет. И ждать когда компиляторы разовьются до того уровня, чтобы они могли сами оптимизации производить (не только очевидные) ждать бессмысленно. Поэтому хороший язык должен оставлять пользователю возможность намекнуть компилятору, какие именно оптимизация и как надо производить. Только оптимизаций много, разработчиков компиллятора - мало, так что неудительно, что си подобных фич не поддерживает. А раз так вышло, то пустующее место занимает методика, позволяющая встроенными средствами языка достичь того же эффекта - темплаты с++
Провалилось не ООП, а те, кто считали, что действительно его использовали
что вы об этом думаете?
Пардон, был неточен =)
Какой-то поток эмоций, не привязанный ни к каким фактам из реальной жизни. Если ты вдруг не заметил, на приведенном тобой примере сишный компилятор (тот самый, который "не блещет") отлично справился со своей работой: заинлайнил функции, векторизвал цикл. Можешь предложить код лучше?
Нушел по твоей ссылке страничку с кучей ссылок на статьи. Статьи не открываются. Завтра еще раз гляну, может заработает. А ты тем временем можешь словами сформулировать, что ты хотел сказать.
он намекал, что существуют более сложные примеры
да, что-то уже недоступен сайт с статьями Todd L. Veldhuizen
но все статьи там вполне находятся поисковиками (тем же CiteSeer)
вот одна из статей: Will C++ be faster than Fortran (1997) — по ссылке нужно жать на значок PDF рядом со словом CACHED
но все статьи там вполне находятся поисковиками (тем же CiteSeer)
вот одна из статей: Will C++ be faster than Fortran (1997) — по ссылке нужно жать на значок PDF рядом со словом CACHED
Так, прочитал я эту статью. Но что ты ей хотел сказать я так и не понял. И как она связана с процитированными тобой частями моего поста?
PS: эта статья у меня вызывает желание стебаться над С++: "используя вот такое вот извращение здесь, а так же вот такой прием здесь, мы можем получить программу, которая работает так же быстро, как и программа на фортране, зато на С++".
PS: эта статья у меня вызывает желание стебаться над С++: "используя вот такое вот извращение здесь, а так же вот такой прием здесь, мы можем получить программу, которая работает так же быстро, как и программа на фортране, зато на С++".
"используя вот такое вот извращение здесь, а так же вот такой прием здесь, мы можем получить программу, которая работает так же быстро, как и программа на фортране, зато на С++"да, примерно так; достижение скорости фортрана в его области применения при помощи аналогичного (по сложности*) кода - неплохой результат, недостижимый на C.
*) извращения/сложности в идеале должны быть исключительно в библиотеке (пример - blitz++ а пользовательский код - по сложности аналогичен фортранному, т.е. совсем простой.
Я от этого давно отошёл, но судя по запущенности blitz++, желающих писать что-то численное на плюсах оказалось мало и все как писали на фортране, так и пишут.
Хотя, может я и недооцениваю развитие в этом направлении.
Тот же uBLAS теперь оказывается вошёл в boost, видимо неплохо поддерживается и развивается...
Eigen похоже активно развивается
Тот же uBLAS теперь оказывается вошёл в boost, видимо неплохо поддерживается и развивается...
Eigen похоже активно развивается
извиваешься как уж на сковородке. =)
достижение скорости фортрана в его области применения при помощи аналогичного (по сложности*) кода - неплохой результатС помощью не приспособленного инструмента добились нормального результата? Едва ли хороший предмет для гордости.
Правильный ответ тут скорее всего состоит в том, что статья написана в 1997 году, когда бытовало поверье, что программы на C++ принципиально медленнее, чем на фортране. Никаких оснований, почему им быть медленнее, вобщем-то нет, просто компилятор еще не дорос до того, чтобы распутывать то, что получается после раскрытия всех этих уровней абстракций. То есть данная статья является попыткой разрушить миф, а не предложение всем писать именно так.
недостижимый на CТак, а это откуда взялось?
*) извращения/сложности в идеале должны быть исключительно в библиотеке (пример - blitz++ а пользовательский код - по сложности аналогичен фортранному, т.е. совсем простой.Теоретически да... Но есть некоторые "но".
Например, чтобы эти expression templates работали, необходимо чтобы компилятор полностью заинлайнил рекурсию, в которую они раскроются (иначе отстрелишь себе ногу). Нетривиальная задача, не так ли? А сложность получившейся рекурсии напрямую зависит от выражения, которое написал пользователь библиотеки.
Они там пишут про некий tiling за ради улучшения использования кэша. Но это зависит от железа. Не понятно, откуда они берут эту информацию в библиотеке.
И так далее. В итоге абстракции обрастают крайне конкретными зависимостями от железа и компилятора, не понятно, как должно выглядеть сопровождение всего этого. Вероятно, все это можно как-то решить в библиотеке, но даже в этом случае у пользователей возникнут проблемы, если разработчики библиотеки бросят ее сопровождать.
Оставить комментарий
spensnp
что вы об этом думаете?http://blogerator.ru/page/oop_why-objects-have-failed