Алексей, если так пойдет и дальше, то мы не столько спорить, сколько поддакивать друг другу будем
AVC>Причем ты делаешь акцент на мощности, а я — на сложности.
В C++ это почти одно и то же
AVC>Давай, я приму твой довод о мощности Си++, и посмотрим, что из этого получится. AVC>Я думаю, что сложность Си++ во многом вытекает из попыток решения реальных проблем программирования при сохранении старого фундамента. AVC>В силу уже одного этого фактора язык становится сложнее. (Причем "сложнее" — не то слово.) AVC>Казалось бы, такой сложный (и, конечно, мощный тоже) язык теперь предназначается все меньшему числу "истинных профессионалов", так как остальные программиисты ("похуже" ) неизбежно будут путаться и совершать множество ошибок, как "грубых", так и "тонких". AVC>Т.е. Си++ должен был бы позиционироваться как "язык для немногих". AVC>Ведь вряд ли ты ожидаешь увидеть рекламу вроде: "В широкую продажу поступила новая партия машин класса Формула-1, еще более мощных и опасных."
+1
Пока я полностью со всем согласен.
AVC>Но вот из "поразившей" тебя цитаты Страуструпа следует, что он гордится безудержным ростом числа Си++программистов (а ведь кому захочется признать себя "лохом", не способным породить высококачественный код на Си++ ). Он пишет, что еще не было года, чтобы в "его полку не прибыло".
Я бы просто добавил здесь, что рост числа C++ программистов происходит на фоне еще большего роста числа Java/C#/Perl/Python/Ruby/PHP программистов. Т.е. Страуструп гордиться тем, что несмотря на широко рекламируемые панацеии от всех бед и все более и более безопасные языки, которые, вроде бы должны были собрать под свои знамена оставшихся C++ отщепенцев, прирост C++ программистов все равно происходит. Т.е. пока жизнь доказывает, что мощность C++ востребована даже не смотря на сложность.
AVC>Ответственная ли это позиция, учитывая, что подавляющее большинство новоявленных Си++программистов напишет ужасный код?
Я думаю, что объективности от Страуструпа ожидать тяжело. Ведь C++ -- это его детище, а какой родитель к своим детям объективно относится?
Что же касается плохого кода, который выдают начинающие C++ программисты, то это, во многом организационный вопрос. Нельзя давать новичку ответственные задачи и нельзя принимать от него код без строго code-review. Но ведь "не боги горшки обжигают"! Если нормально построить процесс обучения, то со временем и опытом они начнут писать нормальный код и контроль можно будет постепенно ослаблять.
Я вот у себя на работе занимаюсь тремя студентами-практикантами. Началось все с факультативных лекций о C++, о наших инструментах. Сейчас они подключены на поддержку некоторых наших внутренних библиотек. Не скажу, что результаты поразительные, но прогресс виден. Ребята вполне вменяемые и нормально осваиваются. Глядишь через год-полтора, после окончания ВУЗа будут вполне пристойно программировать. И их можно будет без особой опаски привлекать к реальным коммерческим проектам. По крайней мере я на это надеюсь.
Гораздо хуже бывает обучать C++ уже опытных программистов, приходящих с других технологий. Вот здесь действительно проблемы.
E>>Собственно, такое длинное вступление я делаю для того, чтобы поделиться своим субъективным мнением. Язык C++ слишком сложен для того, чтобы применяться в большой команде (может быть даже в условиях т.н. промышленной разработки). Подобными выводами я уже делился вот здесь: Re[44]: Почему нельзя преподавать C#
.
AVC>Хочу привести пример в подкрепление твоей точки зрения. AVC>Есть у меня один знакомый Си++программист высочайшего уровня. AVC>(Я даже назову его имя, так как страна должна знать своих героев: Иван Жиганов.) AVC>В одиночку он сопровождает огромный код, обслуживающий целую отрасль нашего города. AVC>Но работать в команде он практически неспособен. (Потому и делает все сам.)
Почти как я
AVC>Его код труден для понимания, настолько там все закручено на ООП.
Да, такое бывает. И я такими вещами грешу. Хотя практика показывает, что наиболее удачный и долгоживущий код -- это самый простой код (хотя на разном уровне квалификации под простотой понимаешь разные вещи).
AVC>Добавим сюда, что программирование для него — образ жизни, а не "просто работа". AVC>Вот таким я и вижу настоящего Си++программиста. AVC>Образ притягивающий и отталкивающий одновременно.
Опять про меня
Наверное, это объективно так и есть. Вероятно в C++ постоянно находится какая-то неизведанная область, в которую, если есть к этому призвание, всегда хочется заглянуть. Поэтому замшелых C++ программистов так тяжело в другую веру перетянуть. Я сам попробовал на Java поработать. Удобно, просто и скучно пока решаешь типовые задачи для которых готовые framework-и есть. Не удобно, сложно, еще более скучно, если требуется сделать что-то нестандартное. Иное дело C++. Вот придет в голову такая идея: Re: Aka Tuple
Здравствуйте, eao197, Вы писали:
E>Алексей, если так пойдет и дальше, то мы не столько спорить, сколько поддакивать друг другу будем
Дожили...
Надо исправлять положение.
AVC>>Ответственная ли это позиция, учитывая, что подавляющее большинство новоявленных Си++программистов напишет ужасный код?
E>Я думаю, что объективности от Страуструпа ожидать тяжело. Ведь C++ -- это его детище, а какой родитель к своим детям объективно относится?
Трудно сказать, я никогда не был на месте других родителей.
Мне просто повезло с детьми.
По ассоциации вспомнил капрала Шовинэ. Всем известно страшное слово "шовинизм"; но, кажется, доблестный капрал сказал примерно следующее:
"Не могу понять этих бесконечных споров, какая нация храбрее. Солдаты всех армий примерно одинаковы; за исключением, разве что, французов, которые в этом отношении и правда несколько превосходят всех прочих."
E>Что же касается плохого кода, который выдают начинающие C++ программисты, то это, во многом организационный вопрос. Нельзя давать новичку ответственные задачи и нельзя принимать от него код без строго code-review. Но ведь "не боги горшки обжигают"! Если нормально построить процесс обучения, то со временем и опытом они начнут писать нормальный код и контроль можно будет постепенно ослаблять.
E>Я вот у себя на работе занимаюсь тремя студентами-практикантами. Началось все с факультативных лекций о C++, о наших инструментах. Сейчас они подключены на поддержку некоторых наших внутренних библиотек. Не скажу, что результаты поразительные, но прогресс виден. Ребята вполне вменяемые и нормально осваиваются. Глядишь через год-полтора, после окончания ВУЗа будут вполне пристойно программировать. И их можно будет без особой опаски привлекать к реальным коммерческим проектам. По крайней мере я на это надеюсь.
BTW, это интересная тема (хотя уже и не моя ): как передавать в разумные сроки практический навык программирования на Си++?
Возможно, это позволило бы несколько уменьшить ущерб цивилизации от Си++.
E>Гораздо хуже бывает обучать C++ уже опытных программистов, приходящих с других технологий. Вот здесь действительно проблемы.
Наверное, приходится многое менять в их конструкции: пересаживать руки из заднего места, исправлять ошибки в ДНК?
E>Наверное, это объективно так и есть. Вероятно в C++ постоянно находится какая-то неизведанная область, в которую, если есть к этому призвание, всегда хочется заглянуть. Поэтому замшелых C++ программистов так тяжело в другую веру перетянуть. Я сам попробовал на Java поработать. Удобно, просто и скучно пока решаешь типовые задачи для которых готовые framework-и есть. Не удобно, сложно, еще более скучно, если требуется сделать что-то нестандартное. Иное дело C++. Вот придет в голову такая идея: Re: Aka Tuple
Понимаю.
Собственно, на предыдущей работе я "прославился" жизнерадостным воплем в 9 вечера: "День пропал не зря!"
(Этой оговоркой я всегда тихо гордился. )
Но все же страсть к минимализму не позволяет моей душе принять Си++.
E>На эту тему здесь хорошая статья была: С++ulture
Помню. Когда я ссылался на нее в одном из своих особо критических постов о Си++, перепутал автора.
Было неудобно. Извинялся потом перед обоими оклеветанными мной программистами: автором и тем, кому я это авторство приписал.
E>Если попробовать сделать кратенькое резюме этому абзацу, то C++ для тех, у кого шило в заднице.
Вспоминая уже названного мной программиста И.Ж.: выражение наивысшего торжества я видел у него, когда в книге, которую внимательно прочитали несколько человек (увы, я в том числе ; это был "Христос" Морозова, издания еще 20-х годов) он нашел неразрезанные страницы.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[32]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Меня это тоже удивляет. AVC>Вероятно, прав Трурль: во многом причина в беспечности, связанной с "кодреюзом" (это код многократно тестировался и использовался до того, blah-blah-blah, зачем его тестировать заново?).
И что интересно, даже самый захудалый 1С-программист в самой завалящей конторе не станет использовать позапрошлогодний модуль расчета налогов.
Re[31]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, eao197, Вы писали:
E>Вот чего я в этой аварии не понимаю, так это то, что данную ошибку не смогли обнаружить во время тестовых прогонов на Земле! Такое чувство, что разные модули вообще не сопрягали в тестовом режиме! Имхо, здесь проблема была в организации тестирования (хотя мне легко об этом говорить).
Во-первых, что там говроили классики о возможностях тестирования?
Во-вторых, для того только чтобы иметь возможность проводить более-менее адекватные тестовые прогоны, необходимо смоделировать объективную реальность. Возможно, слетать на Марс дешевле.
Re[21]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, Cyberax, Вы писали:
C>В Обероне что, совсем НЕТ кастов? Тогда его как язык можно в утиль C>отправить.
Component Pascal:
MODULE Test;
IMPORT StdLog;
PROCEDURE Do*;
VAR i16: SHORTINT; i64: LONGINT;
BEGIN
i64 := 1000000000000001L;
i16 := SHORT(SHORT(i64)); (* Вот так кастуются от LONGINT к SHORTINT *)
StdLog.Int(i64); StdLog.Ln;
StdLog.Int(i16); StdLog.Ln
END Do;
END Test.
Здравствуйте, Cyberax, Вы писали:
>> При этом, в отличие от Java и C#, это эффективный язык, на котором >> пишут операционные системы.
C>На Яве тоже пишут операционные системы (причем распространенные больше, C>чем BlueBottle).
Если вдруг Вы случайно под операционками на Java имели в виду ОС реального времени для встраиваемых систем от Esmertec, то как раз эти самые операционки написаны на обероне-компонентном паскале. С самого сайта информация об этом убрана, но в web.archive.org ее отыскать можно: http://web.archive.org/web/19970227054908/www.oberon.ch/denia/index.html
(не удивляйтесь что сайт oberon microsystems-кий, ведь esmertec ее дочерняя компания). Для BlackBox есть много компонентов от Esmertec для этой "операционки на Java":
Java Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: target hardware with the Jbed operating system
Provides: Library components of Jbed's Java library. They are needed on the target hardware when running Java code on Jbed, in addition to the Jbed modules.
Javae Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Tool and glue components for turning BlackBox into a Java cross-development environment. Glue to a Java byte-code compiler. Only needed for cross-developing Jbed applications.
Jbed Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: target hardware with the Jbed operating system
Provides: OS components that implement the Jbed real-time operating system. They are needed on the target hardware that runs Jbed.
Jbede Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Tool components for turning BlackBox into a (Component Pascal and Java) cross-development environment. Only needed for cross-developing Jbed applications.
JComm Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Glue components for the communication between Windows PCs and Jbed systems. Only needed for developing or communicating with Jbed applications.
Что же касается Java, то это не ОСь на Java, а приложения для этих операционок можно писать на Java. Опять же совершенно случайно, в Esmertec работает Питер Мюллер создатель BlueBottle, о которой Вы сами упомянули.
Ежели Вы говоря о так называемых операционках на Java имели в виду вовсе не компанию Esmertec, то было бы интересно узнать, а что тогда?
Сергей Губанов wrote:
> Если вдруг Вы случайно под операционками на Java имели в виду ОС > реального времени для встраиваемых систем от Esmertec > <http://www.esmertec.ch/>, то как раз эти самые операционки написаны > на обероне-компонентном паскале.
Вообще, две лидирующие (QNX и VxWorks) hard realtime OS написапы на С.
На остальные ОСки приходится всего несколько процентов рынка.
> Ежели Вы говоря о так называемых операционках на Java имели в виду > вовсе не компанию Esmertec, то было бы интересно узнать, а что тогда?
Здравствуйте, Сергей Губанов, Вы писали:
В>>Что ты будешь делать на Обероне, если при преобразовании длинного целого в короткое возникнет ошибка? СГ>Какая ошибка?
Ошибка невозможности представления преобразовываемого значения в виде короткого целого.
Как все запущенно...
Re[34]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
E>>Я вот у себя на работе занимаюсь тремя студентами-практикантами. Началось все с факультативных лекций о C++, о наших инструментах. Сейчас они подключены на поддержку некоторых наших внутренних библиотек. Не скажу, что результаты поразительные, но прогресс виден. Ребята вполне вменяемые и нормально осваиваются. Глядишь через год-полтора, после окончания ВУЗа будут вполне пристойно программировать. И их можно будет без особой опаски привлекать к реальным коммерческим проектам. По крайней мере я на это надеюсь.
AVC>BTW, это интересная тема (хотя уже и не моя ): как передавать в разумные сроки практический навык программирования на Си++? AVC>Возможно, это позволило бы несколько уменьшить ущерб цивилизации от Си++.
А ведь это действительно серьезная тема. Причем, когда речь идет о C++, то все как бы понимают, что язык сложный и нормального уровня программирования достичь сложно. Хотя сложность C++ именно в языке. Но в других языках, например, Java, с которой мне самому довелось столкнуться, ситуация-то такая же. Только там сложность не в языке, а в огромном количестве framework-ом и постоянно плодящихся стандартов. Но из-за того, что сам по себе язык Java проще, кажется, что обучить нормального Java программиста проще. Имхо, это не так.
E>>Гораздо хуже бывает обучать C++ уже опытных программистов, приходящих с других технологий. Вот здесь действительно проблемы.
AVC>Наверное, приходится многое менять в их конструкции: пересаживать руки из заднего места, исправлять ошибки в ДНК?
Нет. Но проблема, имхо, действительно существует.
Во-первых, человек имеет опыт и ему трудно привыкнуть думать по-другому и решать теже задачи, но по другому. В результате, если смены сознания не происходит, человек начинает писать на C++ как на своем предыдущем языке. Что и приводит к проблемам. Например, люди, приходящие с Java ожидают, что у вектора можно узнать его размерность. Или возвращают объекты по значению. Или не думают об операторах копирования для классов с указателями. Или забывают оборачивать указатели в std::auto_ptr или другие умные указатели. Или не используют шаблонов, предпочитая им макросы для генерации кода. И т.д. и т.п. И хорошо, если человек отдает себе отчет, что в C++ можно сильно облегчить себе жизнь, если к таким нюансам привыкнуть. Но бывает, что вместо изучения C++ производится постоянное сравнение C++ с хорошо знакомыми альтернативами. Не в пользу C++ естественно.
Во-вторых, когда на работу приходит опытный программист, но без знания C++, то возникают вопросы по его нагрузке. Вроде бы и нужно ему задачу реальную дать, но и на уровень его мастерства оглядываться приходится. И тут еще вопросы оплаты могут встать (если он не выдает такого же качества код, как его колеги)...
Так что я видел случаи, когда C++ программисты успешно переходили на Java. А вот обратно -- ни разу.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, prVovik, Вы писали:
MN>>А вот что-то не умирает он и до сих пор носится по двору без башки... Или даже я сказал бы так — одну отрубили, а 2 выросло... V>Ага, осталось только определиться с разрядностью счетчика голов
long long, однако.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>>Как правильно обрабатывать сбои: когда проигнорировать и продолжить как будто ничего не случилось, когда упасть с предсметрным воплем, а когда поправить положение и повторить операцию — вот интересная проблема и тема для дискуссии. А на каком языке писать, чтобы избежать переполнения, — нет.
AVC>Я думаю, что Вы правильно сформулировали один из главных вопросов, на которые хотелось бы найти ответ. AVC>Что делать с ошибками и сбоями (раз уж они случились)? AVC>Как выстроить вторую (третью, четвертую, пятую) линию обороны в mission-critical системах?
АПВС привел вам диссертацию Армстронга. В ней идет речь о разработке надежного ПО в условиях присутствия программных и аппаратных ошибок. Если вы интересуетесь ответами на эти вопросы — то диссертация must read сама по себе, и к тому же имеет набор библиографических ссылок в конце.
AVC>Конечно, я не согласен с Вами насчет роли языка. Я уверен, что язык имеет значение, как один из факторов, влияющих на надежность системы. Я думаю, что type-safe язык является хотя и недостаточным, но все же необходимым требованием для создания надежных систем большой сложности. AVC>Но на эту тему было уже много как дискуссий, так и откровенного флейма.
Диссертация особенно интересна тем, что Джо Армстронг не теоретик, а инженер, благодаря которому создан программно-аппаратный комплекс высокой сложности (Ericsson AXD 301 softswitch) с фактическим процентом отказов девять девяток. В нем были ошибки? Да, безусловно. Кроме всего прочего, в нем ядро написано на динамически типизированном языке. Более того, этот язык специально разработан для написания отказоустойчивых систем, и имеет динамическую типизацию не случайно, а вполне намеренно. Хотите знать как такое возможно? Читайте диссертацию.
AVC>Поэтому я думаю, что обсудить Ваш вопрос будет сейчас гораздо полезнее, чем спорить на тему языка.
AVC>Все же тема языка должна навести нас и на другую тему: предотвращение ошибок.
Все достаточно просто.
Ошибку нельзя предотвратить. Количество вносимых ошибок постоянно на сотню строк кода и почти не зависит от используемого языка. Далее, на разных стадиях разработки некий процент ошибок вылавливается. Цена исправления ошибки в среднем пропорциональна времени с ее внесения до обнаружения/исправления. Т. е. чем раньше находится ошибка, тем меньше ее цена.
Языки типа Ады разработаны с целью максимально увеличить процент ошибок, выловленных на этапе компиляции. Языки вроде Erlang, который, в противовес Аде, динамически типизирован, разработаны с целью облегчить написание отказоустойчивых систем в условиях присутствия любого рода (в т.ч. и аппаратных) ошибок.
При этом, раннему вылавливанию ошибок также способствуют:
1) методы формальных спецификаций.
2) юнит-тесты, автоматическое тестирование, и инструменты измерения покрытия тестами.
3) Ручное тестирование.
4) Процедуры review и самые разнообразные процессы, ориентированные на качество. Команда Бурана приманяла, например, в числе прочих, такой процесс: отдельная группа восстанавливала по ассемблерному коду фортрановский. Другая группа сличала его с оригиналом, ищя различия. Зачем? Они в результате нашли 2 ошибки в компиляторе фортрана, из-за которых Буран должен был упасть. Ордена дали за эти ошибки.
Надо понимать, что каждая из подобных процедур позволяет отлавливать только некоторый достаточно стабильный процент дефектов от имеющихся в системе до применения процедуры. Поэтому ошибки все равно попадут в систему, и тут уже вам поможет диссертация Армстронга.
Re[28]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, Gaperton, Вы писали:
G>Диссертация особенно интересна тем, что Джо Армстронг не теоретик, а инженер, благодаря которому создан программно-аппаратный комплекс высокой сложности (Ericsson AXD 301 softswitch) с фактическим процентом отказов девять девяток. В нем были ошибки? Да, безусловно. Кроме всего прочего, в нем ядро написано на динамически типизированном языке. Более того, этот язык специально разработан для написания отказоустойчивых систем, и имеет динамическую типизацию не случайно, а вполне намеренно. Хотите знать как такое возможно? Читайте диссертацию.
Пара замечаний:
1) AXD 301 — не софтсвитч. Это мультисервисный коммутатор: TDM, Frame Relay, ATM, IP/MPLS.
2) Насчет девяти девяток есть определенные сомнения. См. стр. 203 упомянутой диссертации. Другие материалы говорят о пяти девятках, что тоже очень неплохой результат.
Re[29]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Здравствуйте, Gaperton, Вы писали:
G>>Диссертация особенно интересна тем, что Джо Армстронг не теоретик, а инженер, благодаря которому создан программно-аппаратный комплекс высокой сложности (Ericsson AXD 301 softswitch) с фактическим процентом отказов девять девяток. В нем были ошибки? Да, безусловно. Кроме всего прочего, в нем ядро написано на динамически типизированном языке. Более того, этот язык специально разработан для написания отказоустойчивых систем, и имеет динамическую типизацию не случайно, а вполне намеренно. Хотите знать как такое возможно? Читайте диссертацию.
АПВ>Пара замечаний: АПВ>1) AXD 301 — не софтсвитч. Это мультисервисный коммутатор: TDM, Frame Relay, ATM, IP/MPLS.
Ну, это тебе как CCIE видней .
АПВ>2) Насчет девяти девяток есть определенные сомнения. См. стр. 203 упомянутой диссертации. Другие материалы говорят о пяти девятках, что тоже очень неплохой результат. пять девяток (что означает, кстати, 99.999%) — это требование из requirement spec к AXD 301. Потом они замерили фактическое время отказов и оно оказалось сильно меньше требуемого, т.е. на момент написания диссертации — девять девяток, о чем и написано в диссертации на странице 203. Девять их потому, что я считаю первые две девятки до запятой — так принято.
Здравствуйте, Gaperton, Вы писали:
АПВ>>2) Насчет девяти девяток есть определенные сомнения. См. стр. 203 упомянутой диссертации. Другие материалы говорят о пяти девятках, что тоже очень неплохой результат. G>пять девяток (что означает, кстати, 99.999%) — это требование из requirement spec к AXD 301. Потом они замерили фактическое время отказов и оно оказалось сильно меньше требуемого, т.е. на момент написания диссертации — девять девяток, о чем и написано в диссертации на странице 203. Девять их потому, что я считаю первые две девятки до запятой — так принято.
Ну конечно же, сколько девяток есть, столько и надо считать.
Ты прочти внимательней, что там написано.
For the Ericsson AXD301 the only information on the long-term stability of the system came from a power-point presentation showing some figures claiming that a major customer had run an 11 node system with a 99.9999999% reliability, though how these figure had been obtained was not documented.
Спасибо, я в курсе . Это правда, бОльшая часть разговоров про девятки — маркетинговый булшыт, что еще более подрывает доверие к словам "девять девяток". Если б ты себе представлял, насколько это умопомрачительно дофига — девять девяток.
Re[31]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Ты прочти внимательней, что там написано. АПВ>
АПВ>For the Ericsson AXD301 the only information on the long-term stability of the system came from a power-point presentation showing some figures claiming that a major customer had run an 11 node system with a 99.9999999% reliability, though how these figure had been obtained was not documented.
АПВ>Эти девять девяток намеряли на одной системе, что совсем неинтересно.
Ну, в общем, ты прав. Это совсем не средняя цифра, я на это внимания не обратил — приводил по памяти. Цифру я вспомнил отсюда.
G>>С этими процентами, кстати, не все так просто. While everyone in telecom has been using the term "five-nines" for decades, I'm willing to bet that few actually know what 99.999 percent really means
АПВ>Спасибо, я в курсе .
Дык мне слабо верится в то, что ты не в курсе . Я эту ссылку в основном дал для тех, кто будет читать нашу ветку. Штоб вопросы снять.
АПВ>Это правда, бОльшая часть разговоров про девятки — маркетинговый булшыт, что еще более подрывает доверие к словам "девять девяток". Если б ты себе представлял, насколько это умопомрачительно дофига — девять девяток.
Ну, вот Армстронг говорит, что это "31 ms. year!" Я представляю себе, что это такое.
Раз это действительно дофига, то в чем проблема . Их сложно добиться в программном комплексе такого объема? Да, это практически невозможно. Это имеет отношение к качеству софта? Да, прямое. Ну так что? Пусть там не 32 ms а например секунда — по мне так все равно хорошо.
Re[24]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Трурль, Вы писали:
AVC>>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.
Т>>Нет, первопричина — в пресловутом кодреюзе.
AVC>Наверное, Вы имеете в виду, что код во многом унаследован от Ариана-4 (если не раньше)? AVC>Вырисовывается такая картина: код во многом остался прежним, а вот траектория полета изменилась. AVC>Можно подумать, что в этом и есть причина катастрофы. AVC>Но мне так не кажется. AVC>Если бы код, унаследованный от Ариана-4, был действительно корректным, то и с Арианом-5 беды бы не случилось.
AVC>Возможно, мое мнение покажется Вам спорным. AVC>Все упирается в понятие ошибки; вопрос почти философский.
Ошибка — это несоответствие требованиям. Требования могут быть выражены конструктивно в виде набора тестов (т.е. она в некотором смысле существует даже тогда, когда вы о ней не думаете), на котором тестируется система, а могут быть представлены и декларативной спецификацией. Спецификация может быть неполна, а набор тестов — не покрывать все возможные варианты исполнения (а для неразделяемого кода все и не нужны). Собственно, все.
Язык вас практически не спасет. Объясняю почему. С требованиями часто происходит такая засада — поведение в граничных ситуациях не покрывается спецификацией, и в коде происходит неявная закладка на фактическое поведение в такой ситуации. Т. е. нечто подразумевается "само собой очевидным", и на это закрываются глаза. И это в принципе нормально для неразделяемого кода.
Далее, как только код становится разделяемым (используется повторно), вылезают два вида грабель. Во-первых, если в него внести изменения или дополнения, может запросто отвалиться старый код. Во-вторых, может не получится написать новый из-за того, что требуемый сценарий взаимодействия не оттестирован в старой системе, так как никогда в ней не возникал.
Чтобы с этим бороться, необходимо
1) Тщательно специфицировать интерфейсы, предназначеные для повторного использования, регламентируя поведение для всего диапазона возможных параметров. Полуформальной спецификации достаточно. Пред/пост — условия и инварианты из спецификаций вбиваются прямо в код в виде ассертов.
2) Составлять unit-test на основе анализа спецификации (есть правила, как это делать), покрывающий все классы сценариев использования.
3) Применять автоматическое регрессионное тестирование — само собой разумеется.
Это слишком дорого, чтобы делать так для каждой функции/класса. Так что в реальной жизни ищут компромисс — выполняют приведенные процедуры для более-менее крупных и наиболее критичных модулей. И все будет хокей — но только для модулей, которые планируется в будущем повторно использовать.
Re[30]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, AVC, Вы писали:
AVC>Си++ расчитан на "старую" модель монолитной (stand-alone) программы. AVC>Отсюда — трудности с компонентным программированием, чрезмерные навороты с COM и т.д. AVC>Грубо говоря, Си++ — доживший до наших времен динозавр. AVC>У динозавров несомненно были свои преимущества и особые эволюционные приспособления. AVC>Но они вымерли. Все, кроме Си++.
Все, что здесь перечислено является следствием некоторых других факторов, о которых речь пойдет ниже. Но не о расчете C++ на какую-то модель или о невозможность "гладкой" реализации компонентности в C++. Я продолжаю оставаться на той позиции, что C++ -- это универсальный язык, на котором можно сказать все что угодно. Ведь ни английский язык, ни русский, еще сто лет назад не были предназначены для описания компонентной модели программного обеспечения. И ничего, справляется. Так же и с C++.
AVC>Другой подход, более "современный" (конечно, все относительно) был реализован в Обероне еще в середине 1980-х. AVC>Там вообще нет монолитных программ. (Разумеется, вне обероновской среды компиляторы предоставляют возможность создания и обычных exe-шек.) AVC>Процесс инициируется не загрузкой программы, а вызовом команды (экспортируемой модулем процедуры). AVC>Модули подгружаются автоматически, если они указаны в списке импорта загружаемого модуля (и не были загружены раньше). AVC>При этом компонентное программирование получается просто само собой — и совершенно бесплатно. Просто пишешь свой модуль, и ни о чем плохом не думаешь. AVC>Нет нужды читать умные книги, с названиями вроде "Сущность технологии COM". (Книга неплохая, но даже в ней написано, что COM возник из-за неспособности Си++ поддержать компонентное программирование напрямую. Т.е. на одну кучу избыточной сложности уже громоздится другая.) AVC>Компонентная модель потребовала дополнительной безопасности типов (поэтому в Обероне, если не указывать в списке импорта SYSTEM, с переменной можно обращаться только в соответствии с его типом) и централизованной сборки мусора, что, кстати, является дополнительным удобством для программиста. AVC>Через десяток лет возникла Java, через полтора — С# и .NET. Основные идеи были заимствованы из Оберона. Как принято в мире языков с Си-подобным синтаксисом — неявно .
Вероятно, начать можно с того, что компонентная модель и интроперабильность начали появляться и применяться еще до того, как были придуманы хитрые технологии типа COM, Corba, XPCOM, SOM, DCOP и платформы .Net, главной целью которой является интероперабильность. Простые примеры:
Unix pipes и, как следствие, unix way (один компонент делает только одну вещь, но делает ее хорошо). Сложный результат получается путем перенаправления выхода одной программы на вход другой программе. Например:
Берем суточные логи за июнь, выбираем оттуда все записи о каком-то событии, удаляем оттуда записи о неудачных событиях и подсчитываем результат. Вполне нормальное объединение нескольких компонентов
Средства коммуникаций: e-mail, ftp, http. Интероперабильность в чистом виде. Где-то, на другом краю Земли, на неизвестно какой платформе крутится web-сервер, написанный на непонятно каком языке. Но я получаю от него html-странички и смотрю их на Wintel платформе в написанном на C++ браузере.
Но аппетит приходит во время еды. Хочется большего. Хочется встроить чужой браузер в свой контейнер. Или подключить в своего почтового клиента PGP модуль для шифрования своей почты. Или еще чего. А фактически, встроить чужой код в свою программу. Но вот проблема: безболезненно можно сделать это только, если и свой и чужой код построены на общем базисе: общем соглашении о вызовах и базовых библиотеках. И здесь Java показывает поразительный результат, т.к. она без проблем позволяет объединять произвольный Java-код. Дейсвительно, а что здесь сложного, если везде один и тот же байт-код и один и тот же JRE? (Похожая картина и с .Net с его IL, CRL и всем прочим).
Принято думать, что в C++ это недостижимо. Но ведь это не так. Прежде всего, из-за чего такое мнение возникло? Да из-за того, что C++ компиляторов всегда было больше, чем Java или C# компиляторов вместе взятых. Но никогда не было общего формата объектных или библиотечных файлов (можно ли винить в этом C++?). Так же, как никогда и не было общих стандартных библиотек. Особенно на x86 архитектуре. Вот и получилось, что связать вместе dll-ку, скомпилированную Borland-ом, exe-шник, скомпилированный Visual-ом, ой как не просто. Более того, нужно много поизвращаться, чтобы передать C++ объект из DLL в exe-шник или наоборот. А отчего нужно было объединять чужой exe-шник с чьей-то dll-кой. А оттого, что исходников-то их нет, нужно пробовать объединить то, что есть.
Но что, если отказаться от использования зоопарка языков и компиляторов? А взять всего один C++ компилятор. И компилировать все одним компилятором с одинаковыми настройками (release, multithreading shared rtl)? Можно ли тогда получать в C++ компонентность?
Да. И без особых проблем. И тому есть примеры.
Вот на Linux-ах и *BSD есть только GNU C++. И есть KDE, в котором есть такая интересная штука, как KParts. Позволяет делать тоже, что и OLE/COM под Windows. Но на нормальном C++.
Или вот агентная технология в разработке которой я сам принимал участие. На обычном C++ описываются классы агентов, затем добавляется специальное описание агентов для run-time и все. Нужно только запрограммировать взаимодействие агентов путем отсылки/приема сообщений. Причем так можно прозрачно распределенные приложения строить (что мы и делаем). И, что важно, агенты знают только имена друг друга и типы сообщений. Но не знают реальных типов друг-друга. Что позволят заменять одного агента другим.
Все реальные комплексы у нас представляют из себя небольшой exe-загрузчик, который использует маленький framework для подгрузки dll с агентами и динамической регистрацией агентов по специальному скрипту (я чуть-чуть говорил об этом здесь: Re[46]: Почему нельзя преподавать C#
). В результате приложение строится из dll с агентами как из кирпичиков.
А удалось достичь этого благодоря тому, что инструмент был расчитан только на C++ и на то, что все компоненты будут создаваться с использованием именно этого инструмента (как я понимаю, в Обероне и Зононе точно такая же ситуация). Конечно, наша технология не позволит создать инструменты типа Януса, Ворда или Konquerer-а. Но вот построить несколько черных ящиков, обрабатывающих какие-то события и обменивающихся данными между собой -- легко. А все остальное можно с помощью KParts в KDE сделать (Linux forever! )
Собственно резюмируюя хочу сказать, что успех Java (как и .Net) в области интероперабельности связан с тем, что Java не платформенно-независимый язык, а платформа. А в рамках единой платформы можно делать все, что угодно. C++ -- это действительно платформенно-независимый язык. Он не зависит ни от .Net, ни от Windows, ни от Unix. Но его пытаются притянуть на чуждые ему платформы (имеется в виду OLE/COM/.Net), потому и результат получается такой, как получается. Но вот если платформу сделать родной для C++ (как в KDE или в нашей агентной технологии), то компонентность на C++ вполне достижима. Однако такая компонентность будет являться вещью в себе (как Java со своими Java-технологиями сейчас), а это, вероятно, в настоящий момент не слишком востребованно
PS.
Алексей мне будет очень интересно узнать твое мнение о нашем SObjectizer. Если найдешь время, глянь краем глаза, пожалуйста (равно как и другие читатели, если таковые доберутся до этого постсриптума) -- я буду признателен любому мнению.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Что толку в Ада если Ариан 5 все равно упал
Здравствуйте, eao197, Вы писали:
E>А ведь это действительно серьезная тема. Причем, когда речь идет о C++, то все как бы понимают, что язык сложный и нормального уровня программирования достичь сложно. Хотя сложность C++ именно в языке. Но в других языках, например, Java, с которой мне самому довелось столкнуться, ситуация-то такая же. Только там сложность не в языке, а в огромном количестве framework-ом и постоянно плодящихся стандартов. Но из-за того, что сам по себе язык Java проще, кажется, что обучить нормального Java программиста проще. Имхо, это не так.
Имхо, джава все же проще.
1. в него пвстроено значительно меньше концепций: нет множественного наследования, перегрузки операторов, шаблонов.
2. Сборка мусора дает не только отсутствие оператора delete, но и избавляет от всяческих smart_ptr, auto_ptr, и прочих средств управления памятью, которые замусоривают код.
В итоге, научить читать джава-программы можно очень-очень быстро. Да, уменьшение выразительности приводит к увеличению объема кодирования в сложных и интересных случаях. Зато меньше шансов не понять код. А ведь мудрые люди говорят: код гораздо чаще читается, чем пишется.
3. Фреймворки — это да. А вот насчет стандартов ты совершенно прав! Причем стандарты эти придумывают не самые тупые люди, и придумывают их с дивной оперативностью. Для плюсов пока что (за столько-то лет!) стандартизовали STL. Теперь вот, по слухам, скоро boost застандартизуют. Обалдеть. Каков должен быть интерфейс XML-парсера? Как выводить графику? Чем пользоваться для работы с сетью? Нет ответа. Тишина. Гуглим, читаем, качаем, ставим, выбрасываем. А в джаве что? Есть задача. Я вот не могу сходу изобрести задачу, для которой нет стандарта и референс реализации!
Что это означает?
— все API подчиняются более-менее одному стилю. Большинство конвенций кочует из одного API в другой, снижая время на освоение
— все API стандартизуются централизованно. Есть авторитативный центр, который может дать четкий ответ на вопрос "какие стандарты действуют в этой области".
— поэтому можно просто пойти туда, скачать доку, и начать разработку
— можно тестироваться и даже запуститься на бесплатной reference implementation
— когда не хватит reference implementation, можно выбрать из двух-трех взаимозаменяемых производителей.
Это опять же резко снижает стоимость разработчиков, которые владеют. Потому как магии нет. E>Так что я видел случаи, когда C++ программисты успешно переходили на Java. А вот обратно -- ни разу.
Точно. Очень уж тяжело приходится. Вот, говорят, в Канаде так же — вроде тебе и березки, и водка есть... А все — не Россия!
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
)
