Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???
Можно ли разработать ещё более экономичные языки?
Re: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???
FDS>Можно ли разработать ещё более экономичные языки?
Признаюсь, доку не читал. Но подозреваю, что ошибки всё-таки делает программист, а не язык Код на Ада может быть в среднем менее "ошибочным" хотя бы потому, что на Ada пишут гораздо меньше, чем на C++, Ada-спецов меньше и, как следствие, они качественнее
Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".
Re[2]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Oyster, Вы писали:
O>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".
1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).
2.Речб идёт о сравнении аналогичных проектов. Вплоть до версий одного и того же проекта на C++ и Ада, при этом количество C-кода то же больше при той же функциональности. Разработка ведётся примерно одинаковыми командами, как по квалификации (что, впрочем, можно подвергнуть сомнению), так и по количеству программистов.
3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?
Re: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
> Слышал, что при написании программ на C++ количество допущенных ошибок > на порядок больше, чем при написании их же в "АДА", стоимость выше на > 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
такая статистика неудивительна.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[2]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote:
>> Слышал, что при написании программ на C++ количество допущенных ошибок >> на порядок больше, чем при написании их же в "АДА", стоимость выше на >> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что C>такая статистика неудивительна.
Прочитай по внимательней, там есть раздел по исследованиям по C++. Говорят, что C++ не исправил ошибок в C.
Re[3]: Частота ошибок в зависимости от языка: что делать?
Кстати, речь ведь не только о C++ и есть ещё много других статей по сравнению языков (привести сей-час честно говоря не могу).
Кстати обращаю внимание на другое:
Язык Ада, между прочим, предназначен для приложений реального времени. Цитата: "Технология Java не является устойчивой к сбоям и не предназначена ... для использования в рамках управляющих систем реального времени...."
Я собственно больше хотел узнать мнения "почему так" и "как сделать ещё лучше", может если все начнут на Аде программировать станут более квалифицированными? Написать новый компилятор для C++ или, вообще, придумать другой язык... Чтоб ошибок в 100 раз меньше было, ведь от средства разработки то же многое зависит.
Re: Частота ошибок в зависимости от языка: что делать?
Порадовало следующее:
Coding standards for C have been aimed at avoiding the known problems with the C language. A partial list is:
· dangling "else"s
Это что ли "if( condition ) { block } else"?
Это в каком наркотическом бреду такое может стать ТАКОЙ проблемой,
что надо специально этот случай оговаривать в стандарте кодирования ?
· use of "=" for "==", especially in conditional statements
Гы Новички от этого страдают. Но компиляторы как правило на такое
ругаются ворнингами. А программеров что игнорируют ворнинги — кастрировать
без права обжалования.
· use of "/=" for "!="
Гм... А в каком это языке "не равно" пишется как "/="?
· overuse of macros
Да, это грех. Полностью согласен.
· use of "cute programming" that sacrifices comprehension for brevity
...Вообще-то это дело вкуса...
· use of integer for pointer
Ну, это возможно только в С, но не в C++
Вот еще:
Will C++ Change The Picture?
Some may look at this study and conclude that C++ will tame C's problems.
Our early experience does not support that conclusion.
Bug rates in C++ are running higher even than C, although we have no where near the ideal comparison platform that we have had with VADS for C and Ada. We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products. Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants; also, existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions; finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate. We have had long experience with Object Oriented Software, and believe that OO approaches can yield great benefit if tools can fully support the OO process, and if inheritance complexity can be minimized.
Мое резюме: Ребята, возможно, неплохо знают Аду, но знают C очень поверхностно.
С++ они не знают совершенно. Короче, еще одно сборище адвокатов пытающихся давать советы космического масштаба и космичексой же глупости. Фтопку.
__________
16.There is no cause so right that one cannot find a fool following it.
Re[3]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Oyster, Вы писали:
O>>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".
FDS>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).
Великая страна Индия всеми силами опровергает данный постулат
FDS>2.Речб идёт о сравнении аналогичных проектов. Вплоть до версий одного и того же проекта на C++ и Ада, при этом количество C-кода то же больше при той же функциональности. Разработка ведётся примерно одинаковыми командами, как по квалификации (что, впрочем, можно подвергнуть сомнению), так и по количеству программистов.
(т.е. статистика собиралась именно по C vs Ada). А во-вторых, можно ли говорить об объективности и достаточном количестве статистических данных в пределах одного проекта?
FDS>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?
Предполагаю, что чем распространённее язык, тем больше вероятность нарваться на неквалифицированного программиста. В контексте нашей страны (пост-СССР) такие языки, как Ада, Форт или Оберон не очень широко распространены, поэтому часто люди используют их из любви к искусству, а не только из-за требований тимлида, что влечёт за собой более высокую квалификацию таких людей "за те же деньги"
Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"
PS: в общем-то, я к тому, что серебрянной пули нет...
Re[2]: Частота ошибок в зависимости от языка: что делать?
Эти ребята очень неплохо знают C++, просто 1995 статья написана. Я уже немного раньше сказал, что речь идёт не только о C++ и Аде и есть множество различных мнений по этому вопросу.
Мне, кажется, что от языка всё-таки очень много зависит; я хотел бы узнать мнение других не только по поводу Ады, это просто как пример. Ада и С++ даже не вынесены в заголовок...
Re[4]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, Oyster, Вы писали:
O>Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"
O>PS: в общем-то, я к тому, что серебрянной пули нет...
Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).
Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.
Re[3]: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
>>> Слышал, что при написании программ на C++ количество допущенных ошибок >>> на порядок больше, чем при написании их же в "АДА", стоимость выше на >>> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html). > C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что > C>такая статистика неудивительна. > Прочитай по внимательней, там есть раздел по исследованиям по C++. > Говорят, что C++ не исправил ошибок в C.
Совсем странно:
================
Bug rates in C++ are running higher even than C, although we have no
where near the ideal comparison platform that we have had with VADS for
C and Ada. We do not yet have a large mix of people programming in both
C++ and Ada for similar difficulty programs and with history as released
products. Our theoretical views of our C++ problems indicate that C++
may allow "run-away inheritance", where many very similar classes are
created from a substrate without care to design a smaller number of
re-usable classes without many variants; also, existing C++ programs
have not yet made good use of templates and so have become cluttered
with "container classes" and attendant conversions; finally, so much of
C++ goes unseen, hidden behind the notational convenience of the
language, that the code can become difficult to understand and navigate.
We have had long experience with Object Oriented Software, and believe
that OO approaches can yield great benefit if tools can fully support
the OO process, and if inheritance complexity can be minimized.
================
Скорее всего они:
1. Использовали малоопытных С++ников.
2. Использовали древнюю (даже для 1994г.) версию С++.
3. Пункты 2 и 1 вместе взятые.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Cyberax, Вы писали:
C>Скорее всего они: C>1. Использовали малоопытных С++ников. C>2. Использовали древнюю (даже для 1994г.) версию С++. C>3. Пункты 2 и 1 вместе взятые.
Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).
В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).
Re[5]: Частота ошибок в зависимости от языка: что делать?
[... skipped ...]
O>>PS: в общем-то, я к тому, что серебрянной пули нет...
FDS>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).
Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).
А в чём смысл сравнивания? Найти наиболее экономный язык? Дык это невозможно — всё зависит от задачи. Для обычного индустриального кода одни требования, для систем реального времени — совсем другие. Императивные языки как правило быстры, зато функциональные — лаконичны. В общем, повторюсь — нет серебрянной пули. Нет и всё тут.
FDS>Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.
Так Java вроде и не для систем реального времени предназначалась imho. Основная задумка была в кросспратформенности. Ну и в мегафичах вроде "всё есть объект", "всегда есть GC" и т.д.
А насчёт Managed C++ — да ничем он не лучше C#. И вообще, наиболее эффективный .NET-код можно написать только на IL Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).
[... skipped ...]
O>А насчёт Managed C++ — да ничем он не хуже C#. И вообще, наиболее эффективный .NET-код можно написать только на IL Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).
Вечно тороплюсь и опечатываюсь
Re[6]: Частота ошибок в зависимости от языка: что делать?
Вы писали:
O>Здравствуйте, FDSC, Вы писали:
O>[... skipped ...]
O>>>PS: в общем-то, я к тому, что серебрянной пули нет...
FDS>>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).
O>Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).
Извини, я не знал.
O>А в чём смысл сравнивания? Найти наиболее экономный язык? Дык это невозможно — всё зависит от задачи. Для обычного индустриального кода одни требования, для систем реального времени — совсем другие. Императивные языки как правило быстры, зато функциональные — лаконичны. В общем, повторюсь — нет серебрянной пули. Нет и всё тут.
Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.
Я не предлагаю искать с.п. Ведь удачный при проектировании языка подход может быть применён к языкам других отраслей.
Смысл сравнения найти новую идею и улучшить текущие языки. У них ведь нет, например, поддержки автоматической проверки ошибок — приходится писать ещё и языки, которые декларируют правила написания кода, а затем код на таких языках используют системы проверки — не удобно, да и системы проверки не так уж и распространены.
Re[7]: Частота ошибок в зависимости от языка: что делать?
[... skipped ...]
FDS>Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.
FDS>Я не предлагаю искать с.п. Ведь удачный при проектировании языка подход может быть применён к языкам других отраслей.
FDS>Смысл сравнения найти новую идею и улучшить текущие языки. У них ведь нет, например, поддержки автоматической проверки ошибок — приходится писать ещё и языки, которые декларируют правила написания кода, а затем код на таких языках используют системы проверки — не удобно, да и системы проверки не так уж и распространены.
Эволюция языков и так происходит. Посмотри на широко применяемые индустриальные языки (C++, Java, C#) — и увидишь то, что прижилось. Излишне нагружать язык "синтаксическим сахаром" (для проверок валидности на этапе компиляции, например) тоже не есть хорошо (потому как листинги становятся более ... запутанными, что ли, и продуктивность программиста падает), поэтому в индустриальных языках прижились только действительно необходимые фичи.
Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec#
Здравствуйте, FDSC, Вы писали:
FDS>Эти ребята очень неплохо знают C++, FDS>просто 1995 статья написана.
Обоснуй! Из статьи видно полностью противоположное.
Раз:
We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products
Сами признаются что опыта — йок.
Два:
Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants;
Жалобы на то что C++ "много позволяет". Если им мама в детсве не вбила в бошку что не все что позволено можно делать... Клиника.
Три:
existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions;
Звиздеж чистейшей воды. Я юзал шаблоны (BIDS) в Borland C++ 3.1 начиная с 1992-го года. В 1994-м вышел HP STL.
Четыре (всем рыдать):
finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate.
А это вообще перл: жалуются что на C++ трудно программировать потому что на нем удобно писать! Что из-за этого трудно разобраться в коде!
Короче, мозги у них под Аду заточены и ничего кроме своей распрекрасной Ады они видеть не хотят.
FDS>Мне, кажется, что от языка всё-таки очень много зависит;
Зависит.
Но данная статья нерепрезентативна тк в одном из сравниваемых языков (C) авторы явно некомпетентны — их "стандарт кодирования" для C — явный билет на газенваген.
Мне кажется старались перенести модель программирования ADA на C и у них это не получилось. Крайне бы удивился случись наоборот.
__________
16.There is no cause so right that one cannot find a fool following it.
Re[8]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Oyster, Вы писали:
O>Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec#
(это касательно compile-time assert) или Comega (асинхронные методы, элементы ФП, ...).
За ссылки спасибо.
По поводу работ: они ещё сто лет будут вестись: фирмам, у которых есть свои компиляторы не выгодно их принципиально менять, разрабатываются в основном примочки.
O>Излишне нагружать язык "синтаксическим сахаром" (для проверок валидности на этапе компиляции, например) тоже не есть хорошо (потому как листинги становятся более ... запутанными, что ли, и продуктивность программиста падает), поэтому в индустриальных языках прижились только действительно необходимые фичи.
Я говорю в том числе и об этом: может быть стоит вообще сделать компилятор, что бы в зависимости от надобности можно было видеть сам алгоритм, контроль ошибок, отладочные проверки и т.п. (по моему что-то подобное уже даже на этом форуме обсуждалось).
Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.
Re: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???
FDS>Можно ли разработать ещё более экономичные языки?
Вполне возможно, что Ада замечательный язык. Но в этом мире очень редко получает распространение то, что является лучшим вообще или по каким-то критериям. Предсказать какой язык получит распространение в будущем за редким исключением также тяжело. Вопрос стоит по другому: какой язык лучше изучать отдельно взятому человеку или на каком языке разрабатывать конкретный проект. При этом опираться лучше не на статистистические исследования, а на мнение коллег и знакомых. В этом случае вы по крайней мере не будете ощущать себя, как на необитаемом острове.
