Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Следующим шагом мы вставляем XML в межмодульный интерфейс и пишем язык описания всего-что-угодно. И ничего хорошего не выходит.
Да, если довести до абсурда, то так и произойдет. А иногда и происходит, что характерно
ГВ>Такая сигнатура позволяет засунуть под интерфейс "событие" всё, что угодно, включая схему приоретизации событий, очередь событий, анализ на одновременность, анализ характеристик и т.п., а клиенту требуется только слушать некоторый интерфейс.
Имхо, если под event_listener-ами будет пониматься такой широкий спектр понятий, то some_event будет всего лишь напоминать тот же самый wait_event_traits_map_t из моего примера. Только в моем случае some_event может быть скрыт от программиста и программист будет знать, что ему нужно сделать своего event_listener-а и поместить его в traits_map. Собственно то же самое, только traits_map, имхо, остается все же более гибким подходом. Чем-то напоминающим динамические языки программирования.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Бесполезно. AVC>Как сказал Вирт: AVC>
AVC>некоторые вещи следует продумывать до, а не после.
Это много кто говорил. Собственно, C++ как раз этой парадигме соответствует: вместо конкретных решений даётся инструмент создания решений. Т.е., варианты применения продуманы "до" и выведена некая более или менее общая языковая основа. Что не так?
[skip про проверки] AVC>>>Существует понятие программирования по контракту. (Мейер) AVC>>>Главный принцип: не доверяй клиенту (вызывающему коду). ГВ>>Всё хорошо в своём месте и в своё время. ООП само по себе тоже не всегда адекватно задачам. Так что, принцип программирования по контракту тоже не стоит распространять на все случаи программирования. AVC>Разве принцип программирования по контракту применим только к ООП? AVC>Это универсальный принцип, развитие идеи защитного программирования.
Да, он применим где угодно. Вопрос только в конечной цене применения.
AVC>>>В самом первом виртовском Обероне не было присоединенных процедур (=виртуальных функций). AVC>>>Полиморфизм работал исключительно благодаря динамическому приведению типа. AVC>>>Наверное, поэтому динамическое приведение типа реализовано так эффективно. AVC>>>Например (опустив все лишнее): ГВ>>[...]
ГВ>>Ну, я так понимаю, здесь влияет ещё и модель объектов паскаля, конкретно — строго одиночное наследование.
AVC>В Обероне (и других модульных языках) единица инкапсуляции не класс, а модуль. AVC>Это существенно влияет на проектные решения. AVC>Множественное наследование в Обероне просто не нужно (и рассматривается как вредное).
ИМХО — это глобальная парадигматическая ошибка. В ДНК.
AVC>Модули позволяют естественно реализовывать целые паттерны проектирования. AVC>Множественное наследование в Си++ — заплата на отсутствии нормальных модулей. AVC>Вот и пишут на Си++ программы, обращаясь сразу к "человеку и пароходу". (c) Маяковский
Э... высокая риторика, спору нет. Слог хорош! Кратко напоминаю содержание предыдущих серий: динамическое приведение типов в Обероне эффективно работает отчасти из-за строго одиночного наследования.
AVC>>>Опять-таки оптимизатор может устранить некоторые лишние проверки. ГВ>>Здесь согласен. Хотя я бы не стал полагаться на оптимизатор... AVC>В руководстве по компилятору XDS (в разделе об оптимизации) говорится: AVC>
AVC>It is possible not to turn run-time checks off in the product versions of your programs,
AVC>because the code generator usually removes redundant checks. A typical
AVC>program runs only 10-15% faster with all run-time checks turned off (but the code
AVC>size is usually significantly smaller).
AVC>Здесь указана цена проверок: программа на 10-15% медленнее. AVC>Разница в размере кода больше.
Ключевая фраза вот эта: "A typical program". Можно это загадочное определение раскрыть полнее? Почему цепляюсь — потому что уже где-то слышал про эти пресловутые 10-15%, вот и стало интересно.
ГВ>>>>Средствами C++ можно обойти type safety. Разумность такого решения — отдельный вопрос. Если голова на плечах есть — всмё будет в порядке, если с этим проблема, то runtime проверками дела не поправишь. Приведённый пример с NASA свидетельствует, скорее, не о бенефитах типобезопасности, а о том, что всем в NASA было настолько страшно взять ответственность на себя, что спихнули всё на "неправильную" фичу языка. Т.е., проблема не в языке, а в головах. AVC>>>Согласен, что проблема — в головах. AVC>>>Потому что именно из голов она попадает в языки. ГВ>>В огороде бузина, а в трюме акулы... AVC>Которые съели дядьку в Киеве? AVC>А что, я сказал глупость?
Ага.
AVC>Может, я чего не знаю, и Си++ создавался не посредством головы?
И ещё одну. Потому что попытался применить "передёргивание". Вернее — приведение аргументов на основании одной только лексической аналогии (голова — голова). Забавно, спору нет, но это уже надоедает.
AVC>>>Забавно читать, что "средствами C++ можно обойти type safety". AVC>>>Где бы найти в Си++ эту самую type safety... ГВ>>Да есть она там, что тут можно сказать... AVC>Ну разве что правду — что ее там нет.
Хм. Всё чудесатее и чудесатее. От повторения тезиса его истинность увеличивается? Не знал.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
ГВ>>Такая сигнатура позволяет засунуть под интерфейс "событие" всё, что угодно, включая схему приоретизации событий, очередь событий, анализ на одновременность, анализ характеристик и т.п., а клиенту требуется только слушать некоторый интерфейс. E>Имхо, если под event_listener-ами будет пониматься такой широкий спектр понятий, то some_event будет всего лишь напоминать тот же самый wait_event_traits_map_t из моего примера. Только в моем случае some_event может быть скрыт от программиста и программист будет знать, что ему нужно сделать своего event_listener-а и поместить его в traits_map. Собственно то же самое, только traits_map, имхо, остается все же более гибким подходом. Чем-то напоминающим динамические языки программирования.
Я бы резюимровал так: нужно покопаться в самой задаче и постановочных документах. Иной раз появление таких архитектурных решений позволяет найти глубокие глюки в постановочной части.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
ГВ>>>Такая сигнатура позволяет засунуть под интерфейс "событие" всё, что угодно, включая схему приоретизации событий, очередь событий, анализ на одновременность, анализ характеристик и т.п., а клиенту требуется только слушать некоторый интерфейс. E>>Имхо, если под event_listener-ами будет пониматься такой широкий спектр понятий, то some_event будет всего лишь напоминать тот же самый wait_event_traits_map_t из моего примера. Только в моем случае some_event может быть скрыт от программиста и программист будет знать, что ему нужно сделать своего event_listener-а и поместить его в traits_map. Собственно то же самое, только traits_map, имхо, остается все же более гибким подходом. Чем-то напоминающим динамические языки программирования.
ГВ>Я бы резюимровал так: нужно покопаться в самой задаче и постановочных документах. Иной раз появление таких архитектурных решений позволяет найти глубокие глюки в постановочной части.
Да, Геннадий, в принципе, все так и есть. Это очень здавый подход, когда при достижении органичений текущей версии архитектуры происходит перепроектирование и появляется новый набор согласованных, понятных, минималистических интерфейсов. Очень здорово, когда такая возможность есть. Тут главное, что появление новой архитектуры, как правило, делает старый код несовместимым с новыми версиями. Если затраты на правку старого кода вполне приемлимы, то перепроектирование -- самый разумный выход.
Но мне вот что интересно в последнее время. Мы у себя активно используем собственную технологию агентно-ориентированного программирования, в которой взаимодействие между агентами проиходит за счет обмена сообщениями. Причем отправитель сообщения даже не знает, какой точно интерфейс у агента-получателя сообщения. Чем-то это напоминает Smalltalk. Так же, после небольшого опыта использования Ruby, мне понравилась возможность, которую предоставляют динамические языки: в метод объекта нужно передать строгоопределенное количество аргументов, но их типы фикированны. Поэтому со временем, можно научить объект получать совсем другие аргументы, но и поддержать старую функциональность одновременно. Да, при разаботке такого метода трудозатраты несколько увеличиваются (хотя это сильно зависит, как говорится). Но вот у пользователей такого метода никакой головной боли -- очень прозрачный переход на новые версии. Частично эту тему я затрагивал вот здесь: Re[51]: Почему нельзя преподавать C#
Здравствуйте, AVC, Вы писали:
AVC>В отношении непригодности языка для "масс" (или "масс" для языка?) мы, кажется, пришли к "консенсусу". AVC>А ведь, между тем, что-то я не видел на книжках по Си++ надписей вроде: "Минздрав предупреждает". AVC>Напротив: от "Освой Си++ за 21 день" до "Си++ для чайников".
Ключевое слово "Маркетинг".
AVC>>>Ведь в Оберон-системе информация о типах доступна в рантайме. ПК>>Ключевым для меня здесь является смещение контроля на время исполнения. Естественно, это дело личных предпочтений, но я отношусь как раз к той части программистов, которые предпочитают максимум проверок во время компиляции. AVC>Это я давно заметил. AVC>Возможно, это и правда вопрос личных предпочтений. AVC>У меня это вызывает впечатление, что народ пытается исключить потенциальные ошибки из простого кода, нагромоздив гору сложного. А отсюда у меня сомнения в логической состоятельности такого подхода.
На самом деле, глубокая логическая ошибка зарыта в такой оценке самой по себе. Её суть — использование примитивного противопоставления "простой код — сложный код". Прикол здесь в том, что "простые вещи" зачастую оказываются простыми только на поверхностный взгляд. Ну, вот такой, отвлечённый пример. Возбмём стакан. Казалось бы, что может быть проще? Однако, артефакт стакан удовлетворяет таким требованиям:
— емкость;
— прочность стенок;
— вес в пределах от ... до ...;
— термостойкость;
— безопасность в смысле химической инертности.
И т.д., и т.п.
И когда дело доходит до "простейшего стакана" в коде, то выясняется, что представления о, например, параметре "прочность стенок" находятся у разных людей в разных, иной раз не пересекающихся областях. Всё бы ничего, об этом можно договориться. Но всё становится много хуже, когда под высказыванием "какой-нибудь стакан" подразумевается вполне конкретный набор допусков и ограничений. Ergo, их нужно уметь оговаривать, вот отсюда и "сложности". Вернее — вагоны конструкторской документации на простейшие, казалось бы, вещи.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[32]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, Геннадий Васильев, Вы писали:
AVC>>В отношении непригодности языка для "масс" (или "масс" для языка?) мы, кажется, пришли к "консенсусу". AVC>>А ведь, между тем, что-то я не видел на книжках по Си++ надписей вроде: "Минздрав предупреждает". AVC>>Напротив: от "Освой Си++ за 21 день" до "Си++ для чайников".
ГВ>Ключевое слово "Маркетинг".
Ключевое слово — "вранье" (в данном случае — маркетологов и издателей).
Я ничего не имею против авторов таких книг. Ясно, что начинающим Си++программистам тоже нужны книги.
К сожалению, современная цивилизация во многом стоит на вранье.
Конечно, сказанное — мое ИМХО. Но, черт побери, мне уже 41 год! Я могу еще многому научиться, но вряд ли сильно поумнею...
Я вырос в другой политической системе, пережил ряд политических и экономических потрясений, растил детей при пустых прилавках.
У меня есть своя точка зрениях на эти вопросы.
(Прошу прощения за, может быть, излишнюю эмоциональность. Но иначе я бы врал.)
Вот уже далекие студенческие годы. Гайдар пишет в своих воспоминаниях, что он ходил разгружать вагоны за деньги.
А к нам приходили в общежитие (ВМиК МГУ) и говорили: ребята, кто может, в Москве вагоны стоят неразгруженные, помогите. И мы шли и разгружали ночью вагоны бесплатно и считали, что это нормально. (Возможно, деньги шли Универу?)
И кто выручал Москву — "единоличники", вроде Гайдара, за деньги, или те, кто приходили целым курсом, бесплатно?
А, получается, Гайдар в своих воспоминаииях ставит себя в пример: вот я мужик, зарабатывал копейку, спасал Москву.
Сам не знаю, зачем я о наболевшем, очевидна ли связь? Просто вранье — везде вранье. Самые страшные беды — от вранья.
Никакой безопасности (ни ПО, ни в "большом мире") не будет, пока всякие там "маркетологи" будут врать.
AVC>>>>Ведь в Оберон-системе информация о типах доступна в рантайме. ПК>>>Ключевым для меня здесь является смещение контроля на время исполнения. Естественно, это дело личных предпочтений, но я отношусь как раз к той части программистов, которые предпочитают максимум проверок во время компиляции. AVC>>Это я давно заметил. AVC>>Возможно, это и правда вопрос личных предпочтений. AVC>>У меня это вызывает впечатление, что народ пытается исключить потенциальные ошибки из простого кода, нагромоздив гору сложного. А отсюда у меня сомнения в логической состоятельности такого подхода.
ГВ>На самом деле, глубокая логическая ошибка зарыта в такой оценке самой по себе. Её суть — использование примитивного противопоставления "простой код — сложный код". Прикол здесь в том, что "простые вещи" зачастую оказываются простыми только на поверхностный взгляд. Ну, вот такой, отвлечённый пример. Возбмём стакан. Казалось бы, что может быть проще? Однако, артефакт стакан удовлетворяет таким требованиям: ГВ>- емкость; ГВ>- прочность стенок; ГВ>- вес в пределах от ... до ...; ГВ>- термостойкость; ГВ>- безопасность в смысле химической инертности. ГВ>И т.д., и т.п.
ГВ>И когда дело доходит до "простейшего стакана" в коде, то выясняется, что представления о, например, параметре "прочность стенок" находятся у разных людей в разных, иной раз не пересекающихся областях. Всё бы ничего, об этом можно договориться. Но всё становится много хуже, когда под высказыванием "какой-нибудь стакан" подразумевается вполне конкретный набор допусков и ограничений. Ergo, их нужно уметь оговаривать, вот отсюда и "сложности". Вернее — вагоны конструкторской документации на простейшие, казалось бы, вещи.
Во многом Вы правы.
Не всегда простое "просто".
Именно к обсуждению этих вопросов и хочется, наконец, перейти.
Что мы все "ломаем копья" вокруг явных дефектов Си++?!
Я не спорю с тем, что в Си++ много интересных идей. Но на базе совместимости с Си никогда не получится надежного языка. А тема legacy code — почти сплошное вранье. Старый код на Си и Си++ (если он действительно ценный, что редко) вполне можно использовать в DLL.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[34]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, CrystaX, Вы писали:
CX>Если для тебя так принципиально, чтобы указатель был проинициализирован нулем, обертка с нулевым оверхедом, которая просто при инициализации заносит 0 в инкапсулируемый указатель, пишется за 1 минуту и потом используется сколько угодно раз. Это, кстати, относится все к той же теме — не используй голые указатели, если только это тебе не нужно. Ты же все равно пытаешся их использовать. Вот скажи мне, какая разница для меня как программиста — использовать голый указатель или использовать объект с семантикой указателя, но обладающий дополнительными проверками/иницализацией? Почему нужно обязательно использовать именно голый указатель везде, где только вздумается? Только потому, что такая возможность есть в языке? Топором, например, можно себе ногу отрубить, но ведь нормальный человек никогда не станет этого делать. Откуда же это стремление использовать язык максимально опасным способом?
Дмитрий, помнишь, как у Чехова?
Если в первом акте на сцене висит ружье, в последнем оно выстрелит.
P.S. Моя "аська", оказывается, 228-705-993.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[12]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, Геннадий Васильев, Вы писали:
AVC>>Бесполезно. AVC>>Как сказал Вирт: AVC>>
AVC>>некоторые вещи следует продумывать до, а не после.
ГВ>Это много кто говорил. Собственно, C++ как раз этой парадигме соответствует: вместо конкретных решений даётся инструмент создания решений. Т.е., варианты применения продуманы "до" и выведена некая более или менее общая языковая основа. Что не так?
Да все не так. Не было продумывания "до", а был язык Си, Страуструпу ничем не обязанный.
Или его он тоже продумал "до" его создания?
ГВ>[skip про проверки] AVC>>>>Существует понятие программирования по контракту. (Мейер) AVC>>>>Главный принцип: не доверяй клиенту (вызывающему коду). ГВ>>>Всё хорошо в своём месте и в своё время. ООП само по себе тоже не всегда адекватно задачам. Так что, принцип программирования по контракту тоже не стоит распространять на все случаи программирования. AVC>>Разве принцип программирования по контракту применим только к ООП? AVC>>Это универсальный принцип, развитие идеи защитного программирования.
ГВ>Да, он применим где угодно. Вопрос только в конечной цене применения.
Насчет цены. За годы с 1998 по 2002 годы число ЧП, вызванных ненадежностью ПО, выросло в 20 раз.
AVC>>>>В самом первом виртовском Обероне не было присоединенных процедур (=виртуальных функций). AVC>>>>Полиморфизм работал исключительно благодаря динамическому приведению типа. AVC>>>>Наверное, поэтому динамическое приведение типа реализовано так эффективно. AVC>>>>Например (опустив все лишнее): ГВ>>>[...]
ГВ>>>Ну, я так понимаю, здесь влияет ещё и модель объектов паскаля, конкретно — строго одиночное наследование.
AVC>>В Обероне (и других модульных языках) единица инкапсуляции не класс, а модуль. AVC>>Это существенно влияет на проектные решения. AVC>>Множественное наследование в Обероне просто не нужно (и рассматривается как вредное).
ГВ>ИМХО — это глобальная парадигматическая ошибка. В ДНК.
В разных местах на RSDN я говорил, что Си++программисты все объясняют двумя причинами: "кривыми ручками" и "ошибками в ДНК".
Вот очередное подтверждение.
AVC>>Модули позволяют естественно реализовывать целые паттерны проектирования. AVC>>Множественное наследование в Си++ — заплата на отсутствии нормальных модулей. AVC>>Вот и пишут на Си++ программы, обращаясь сразу к "человеку и пароходу". (c) Маяковский
ГВ>Э... высокая риторика, спору нет. Слог хорош! Кратко напоминаю содержание предыдущих серий: динамическое приведение типов в Обероне эффективно работает отчасти из-за строго одиночного наследования.
А еще в Обероне есть модульность, которой нет в Си++.
И поэтому нет кентавров.
AVC>>>>Опять-таки оптимизатор может устранить некоторые лишние проверки. ГВ>>>Здесь согласен. Хотя я бы не стал полагаться на оптимизатор... AVC>>В руководстве по компилятору XDS (в разделе об оптимизации) говорится: AVC>>
AVC>>It is possible not to turn run-time checks off in the product versions of your programs,
AVC>>because the code generator usually removes redundant checks. A typical
AVC>>program runs only 10-15% faster with all run-time checks turned off (but the code
AVC>>size is usually significantly smaller).
AVC>>Здесь указана цена проверок: программа на 10-15% медленнее. AVC>>Разница в размере кода больше.
ГВ>Ключевая фраза вот эта: "A typical program". Можно это загадочное определение раскрыть полнее? Почему цепляюсь — потому что уже где-то слышал про эти пресловутые 10-15%, вот и стало интересно.
Вопрос разумный.
Если Вы не доверяете данным Excelsior (XDS), то надо заниматься измерениями самостоятельно.
Найду время — "погоняю" разные программы, откомпилированные с разными опциями.
Пока что лично у меня получалось, что при полной оптимизации XDS (90-х годов) в три раза крыл Visual C++ 6.0.
Предположим, в "нетипичном" случае на проверки уйдет не 10-15%, а 20-30%. Это принципиально?
ГВ>>>>>Средствами C++ можно обойти type safety. Разумность такого решения — отдельный вопрос. Если голова на плечах есть — всмё будет в порядке, если с этим проблема, то runtime проверками дела не поправишь. Приведённый пример с NASA свидетельствует, скорее, не о бенефитах типобезопасности, а о том, что всем в NASA было настолько страшно взять ответственность на себя, что спихнули всё на "неправильную" фичу языка. Т.е., проблема не в языке, а в головах. AVC>>>>Согласен, что проблема — в головах. AVC>>>>Потому что именно из голов она попадает в языки. ГВ>>>В огороде бузина, а в трюме акулы... AVC>>Которые съели дядьку в Киеве? AVC>>А что, я сказал глупость? ГВ>Ага.
Выбор языка — уже проектное решение.
Проектные решения, надеюсь, предполагают наличие головы?
В чем же глупость?
AVC>>Может, я чего не знаю, и Си++ создавался не посредством головы? ГВ>И ещё одну. Потому что попытался применить "передёргивание". Вернее — приведение аргументов на основании одной только лексической аналогии (голова — голова). Забавно, спору нет, но это уже надоедает.
Ну, тогда "акулы в трюме" — неотразимый аргумент.
Поздравляю, Вас, Геннадий, с заслуженной победой.
AVC>>>>Забавно читать, что "средствами C++ можно обойти type safety". AVC>>>>Где бы найти в Си++ эту самую type safety... ГВ>>>Да есть она там, что тут можно сказать... AVC>>Ну разве что правду — что ее там нет.
ГВ>Хм. Всё чудесатее и чудесатее. От повторения тезиса его истинность увеличивается? Не знал.
Это Вы о своем утверждении, что в Си++ есть (а не может быть при некоторых исключительных обстоятельствах) type safety?
А пока что самые разные источники твердят одно: в программах на Си++ ошибок больше, чем в программах на Си.
Уж если в Си++ есть type safety, то Си, наверное, — просто скала!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[33]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Во многом Вы правы. AVC>Не всегда простое "просто". AVC>Именно к обсуждению этих вопросов и хочется, наконец, перейти. AVC>Что мы все "ломаем копья" вокруг явных дефектов Си++?! AVC>Я не спорю с тем, что в Си++ много интересных идей. Но на базе совместимости с Си никогда не получится надежного языка. А тема legacy code — почти сплошное вранье. Старый код на Си и Си++ (если он действительно ценный, что редко) вполне можно использовать в DLL.
+1000
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, eao197, Вы писали:
E>Проблема в ASSERT-ах в том, что их видит автор f. Но не пользователь f! А предложенный Пашей подход как раз позволяет показать клиенту, что такой ASSERT внутри f присутствует.
Вот на столь важные вопросы и тратят время С++-программисты.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, CrystaX, Вы писали:
CX>Видимо, ты все-таки невнимательно прочитал. C++ противопоставлялся в этой ветке языкам C#, Java, Oberon, Ada. Не лиспу! Вот еще один линк
Ну, почему же? В области типобезопасности действительно C#, Java, Oberon, Ada, а в области метапрограммирования ему противопоставляются R#, Java Syntactic Extender... и как раз ФЯ с мощьными препроцессорами вроде Lisp-а или Ocaml-а.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Да все не так. AVC>Не было продумывания "до", а был язык Си, Страуструпу ничем не обязанный. AVC>Или его он тоже продумал "до" его создания?
Согласен. Но 20 лет назад, когда С был на пике популярности обратная совместимость с С был очень здравый шаг.
Глупосью было завоевав олимп придерживаться этой совместимости и дальше. Разумным шагом было бы выделение опасных конструкций в уровень совместимости, и развитие языка в русло упрощения и типобезопасности.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, Павел Кузнецов, Вы писали:
F>> Безотносительно к тому, о чем идет речь, и оправдано ли было такое решение, хочу сказать, что такие примеры меня всегда умиляют. Решения о включении того или иного свойства в язык принимают на основе того, что кто-то когда-то где-то смотрел на какие-то проекты "из полмиллиона строк" <...>
ПК>Ну, все-таки use cases анализировать надо... Если use case для некоторой языковой возможности не находится, то я слабо представляю, как ее можно спроектировать так, чтоб она в итоге оказалась удобной в использовании. По-моему, лучше отложить включение этой возможности до того, когда возникнет конкретный use case, не покрывающийся/покрывающийся плохо существующими возможностями языка, и вот тогда уже спроектировать ее как следует, чтоб она, действительно, выполняла свое предназначение.
Когда "use case" возникнет, может быть уже поздно. Вспоминается в связи с этим история с утилитой make. (Ссылку сейчас не найду). Автор изначальной версии make написал ее "на коленке" для друзей. Он спешил, и поэтому принял простое решение — использовать символы табуляции для обозначения начала команд (синтаксис Makefile'ов все знают и, надеюсь, понимают, о чем идет речь). Буквально через несколько дней он избавился от этого "хака" — но было уже поздно. Пользователи (их было не больше десятка) уже успели написать Makefile'ы с табуляциями и поленились переписывать их. И вот до сих пор, спустя десятиления, все ругаются, разбираясь, почему make собирает что-нибудь неправильно и обнаружив, что дело в том, что вместо табуляции каким-то образом оказались пробелы.
Что касается конкретной темы обсуждения, то речь о той странной ситуации, когда "use cases" из какого-либо языка программирования рассматриваются как аксиомы для совсем другого языка программирования. При этом совершенно неизвестно, насколько правильны и всеобъемлющи эти "use cases".
PS. А все-таки, неужели это правда, что в C++ могли быть Лисповские condition'ы?
Re[13]: Что толку в Ада если Ариан 5 все равно упал
ГВ>>Ключевая фраза вот эта: "A typical program". Можно это загадочное определение раскрыть полнее? Почему цепляюсь — потому что уже где-то слышал про эти пресловутые 10-15%, вот и стало интересно.
AVC>Вопрос разумный. AVC>Если Вы не доверяете данным Excelsior (XDS), то надо заниматься измерениями самостоятельно. AVC>Найду время — "погоняю" разные программы, откомпилированные с разными опциями. AVC>Пока что лично у меня получалось, что при полной оптимизации XDS (90-х годов) в три раза крыл Visual C++ 6.0.
А можно посмотреть на этот пример где оберон в три раза обгоняет плюсы?
Re[19]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CrystaX, Вы писали:
CX>>Видимо, ты все-таки невнимательно прочитал. C++ противопоставлялся в этой ветке языкам C#, Java, Oberon, Ada. Не лиспу! Вот еще один линк
. На этом тему считаю закрытой.
VD>Ну, почему же? В области типобезопасности действительно C#, Java, Oberon, Ada, а в области метапрограммирования ему противопоставляются R#, Java Syntactic Extender... и как раз ФЯ с мощьными препроцессорами вроде Lisp-а или Ocaml-а.
Угу семеро на одного.
Re[14]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, FR, Вы писали:
ГВ>>>Ключевая фраза вот эта: "A typical program". Можно это загадочное определение раскрыть полнее? Почему цепляюсь — потому что уже где-то слышал про эти пресловутые 10-15%, вот и стало интересно.
AVC>>Вопрос разумный. AVC>>Если Вы не доверяете данным Excelsior (XDS), то надо заниматься измерениями самостоятельно. AVC>>Найду время — "погоняю" разные программы, откомпилированные с разными опциями. AVC>>Пока что лично у меня получалось, что при полной оптимизации XDS (90-х годов) в три раза крыл Visual C++ 6.0.
FR>А можно посмотреть на этот пример где оберон в три раза обгоняет плюсы?
и был удивлен (потому что в литературе где-то указывались 40% преимущества XDS над Visual C++ и 15% — над Watcom.).
Затем на вопрос, который задал Cyberax я дал ссылку, где взять XDS и тест drystone(это и есть ответ на Ваш вопрос, можно ли посмотреть и где): http://www.rsdn.ru/Forum/Message.aspx?mid=994783&only=1
Если у Вас дойдут руки проверить этот пример на Вашем компьютере и на Вашем компиляторе Си++, сообщите мне о результатах, пожалуйста.
А то они меня самого смущают (3 раза все-таки! ), но неизменно подтверждаются при запуске drystone.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[15]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Если у Вас дойдут руки проверить этот пример на Вашем компьютере и на Вашем компиляторе Си++, сообщите мне о результатах, пожалуйста. AVC>А то они меня самого смущают (3 раза все-таки! ), но неизменно подтверждаются при запуске drystone.
3 раза — это слишком . Просто XDS слишком уж оптимизирует — выбрасывает нафиг большую часть кода. Весь смысл теста теряется.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
FR>>А можно посмотреть на этот пример где оберон в три раза обгоняет плюсы?
AVC>Уф! Специально прошелся по старым постам, чтобы вспомнить, откуда "ноги растут". AVC>На этот факт я случайно наткнулся еще в январе: AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=994706&only=1
AVC>и был удивлен (потому что в литературе где-то указывались 40% преимущества XDS над Visual C++ и 15% — над Watcom.). AVC>Затем на вопрос, который задал Cyberax я дал ссылку, где взять XDS и тест drystone(это и есть ответ на Ваш вопрос, можно ли посмотреть и где): AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=994783&only=1
AVC>Если у Вас дойдут руки проверить этот пример на Вашем компьютере и на Вашем компиляторе Си++, сообщите мне о результатах, пожалуйста. AVC>А то они меня самого смущают (3 раза все-таки! ), но неизменно подтверждаются при запуске drystone.
В общем я посмотрел этот dry.c кошмар какой-то, написан на K&R си, много вещей (типа пустых циклов) которые просто выкидываются современными компиляторами в общем результаты тестирования такие:
XDS:
Dhrystone time for 40000000 passes = 12
This machine benchmarks at 3333333 dhrystones/second
vc6(cl /GX /O2 Dry_c.c):
Dhrystone time for 40000000 passes = 24
This machine benchmarks at 1666666 dhrystones/second
vc7.1(cl /GX /O2 Dry_c.c + #pragma auto_inline(on)):
Dhrystone time for 40000000 passes = 16
This machine benchmarks at 2500000 dhrystones/second
Два раза есть, но мне кажется тест полная подстава, меня очень смущают сообщения которые в процессе компиляции выдает XDS компилятор redundant code eliminated (к тому же внутри циклов). Мое мнение этот тест подстава, реально он не выполняет работу для которой предназначен. Вообще конечно я восхищен умением XDS выкидывать не влияющие на результат куски кода, но для реальных приложений которые все таки что-то считают это не дает преимуществ, что показывает рядом лежащий тест LINPACK на котором XDS уже немного отстает от VC.
Re[20]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, CrystaX, Вы писали:
CX>>>Видимо, ты все-таки невнимательно прочитал. C++ противопоставлялся в этой ветке языкам C#, Java, Oberon, Ada. Не лиспу! Вот еще один линк
. На этом тему считаю закрытой.
VD>>Ну, почему же? В области типобезопасности действительно C#, Java, Oberon, Ada, а в области метапрограммирования ему противопоставляются R#, Java Syntactic Extender... и как раз ФЯ с мощьными препроцессорами вроде Lisp-а или Ocaml-а.
FR>Угу семеро на одного.
А что делать — приходится шапками закидвать — с Лиспом или Диланом вы почему-то тягаться отказываетесь принципиально . И что интересно, даже про "низкую производительность" в этот раз никто не вспомнил — сразу кверху лапками.
Видимо, ты все-таки невнимательно прочитал. C++ противопоставлялся в этой ветке языкам C#, Java, Oberon, Ada. Не лиспу!
Собственно, C++ как раз этой парадигме соответствует: вместо конкретных решений даётся инструмент создания решений. Т.е., варианты применения продуманы "до" и выведена некая более или менее общая языковая основа. Что не так?
. Просто XDS слишком уж оптимизирует — выбрасывает нафиг большую часть кода. Весь смысл теста теряется.
