Ответ на »сообщение 1095« (Илья Ермаков)
___________________________
Да и, в конце концов, уважаемый Гость, ни я, ни Вы (мне так кажется) не имеем отношения к созданию критичных систем.
Спросите у тех, кто имеет.
У НПО им. Решетнева, которые почему-то пишут ПО для наших спутников на Модула-2.
У разработчиков системы управления поездами парижского метро, которые использовали Ada.
У разработчиков системы управления дорожным движением Швейцарии - Оберон.
У консорциума ONBASS, выбравшего для европейской гражданской авиации Оберон.
У Пентагона, не к ночи помянут будет, использующего Ada.

Наверное, дурачки они, да? Ведь язык-то роли никакой не играет...

Ответ на »сообщение 1094« (гость)
___________________________
Если у нас есть диапазон допустимых скоростей для самолета, то мы так и определим тип Скорость. Однако, в отличие от Оберона или Паскаля, выход за границы типа будет отслеживаться и на этапе выполнения.

По поводу Студии - каким образом программист виноват в том, что в определенных местах исходника при вводе -> или . среда слетает? И что помогает только полное отключение Intellisence? Может быть, программист слишком быстро печатает, среда не успевает :-)

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

Опять же, поддержка метаинформации на этапе выполнения позволяет гораздо нагляднее анализировать состояние программы и быстрее находить ошибки в логике. Метаинформация поддерживается отнюдь не для всех языков. Вот еще о роли языка.

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

Ответ на »сообщение 1092« (Илья Ермаков)
___________________________
В высшей степени интересно узнать как язык Ада решит, должна скорость быть 20 или -20 м/c.

Ответ на »сообщение 1091« (Илья Ермаков)
___________________________
Следующая таблица указывает значение Errors per Function Point для некоторых языков:
Эта таблица не говорит ни о чём в данном случае.
Какие именно ошибки имелись в виду?
И в случае сравнения Оберона с другими языками речь идёт о двух типах ошибок: зависящих от языка, и от языка не зависящих.
Если вторые составляют (как я считаю) подавляющее большинство ошибок в программах, то супернадёжность собственно языка имеет роль совершенно мизерную.

Безопасные языки говорят НЕТ. Небезопасные - КАК ПОВЕЗЕТ. Отличие принципиальное.
В Обероне нельзя перепутать знак у скорости самолёта?

Работая в среде Visual Studio 6.0, я вижу, как каждые 40 минут сама среда разработки вылетает в трубу без всяких видимых причин.
Работая в частности в ней же, ничего подобного не наблюдаю.
Аналогично, в этой среде написана половина приложений под Windows - и тоже в большинстве ничего никуда не вылетает.
Может, в писавшем проект программисте всё дело?

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

Ответ на »сообщение 1090« (гость)
___________________________

Ответ на »сообщение 1088« (Илья Ермаков)
___________________________
Если язык обеспечивает гемрметичность типов и безопасность механизма указателей - это многократно повышает надежность.
Этот дурак может перепутать знак в числе и самолёт "взлетит" с ветикальной скоростью -20 м/с. Ни один язык этого не проверит.
Кто-то реально оценивал соотношение ошибок:
- потерянные указатели, неверное приведение типов и т.п. (т.е. зависящих от языка)
- не та переменная, не тот знак, ошибка в ф ормуле и т.п. (зависящих только от программиста)
?

Язык Ada поможет с высокой вероятностью избежать и таких ошибок, как неверный знак, и переполнение разрядности, и отследит на этапе компиляции ошибки типа сложения килограммов с поллитрами... Строгая типизация - и никаких гвоздей.

Ответ на »сообщение 1090« (гость)
___________________________
То, что ошибкоопасность языков может сильно различаться, подтверждалось исследованиями - считали число ошибок на функциональную единицу программы. Вот, например, у меня есть кусок с какого-то сайта:
Следующая таблица указывает значение Errors per Function Point для некоторых языков:
Smalltalk 0.14
SQL 0.18
Ada 95 0.50
Java 0.50
C++ 0.82
C 2.50
Как видим, влияние языка может быть значительным.

Что касается безопасности в работе с памятью - количественных оценок я не приведу... Но разве недостаточно качественного отличия? Нас волнует бинарный вопрос, подразумевающий ответ ДА или НЕТ: упадет ли компонентная система, работающая в едином адресном пространстве, при сбое в одном из компонентов?
Безопасные языки говорят НЕТ. Небезопасные - КАК ПОВЕЗЕТ. Отличие принципиальное.
Работая полтора года в BlackBox'е, я знаю, что эта среда работает с упрямством бронепоезда при любых ошибках в моем или чужом коде, который выполняется прямо в ней. Работая в среде Visual Studio 6.0, я вижу, как каждые 40 минут сама среда разработки вылетает в трубу без всяких видимых причин... А ведь в ней не выполняется никакого постороннего кода... Разработчиков Микрософта все-таки нельзя назвать дилетантами, просто это наглядная демонстрация того, к чему ведет стремление побыстрей сделать абы чего на абы каком языке...

Ответ на »сообщение 1088« (Илья Ермаков)
___________________________
Если язык обеспечивает гемрметичность типов и безопасность механизма указателей - это многократно повышает надежность.
Безо всяких подколок: "много" - это сколько?
Это - эмоционально-качественная оценка.
А может, надёжность от этого повысится совсем чуть-чуть?
А может, это "чуть-чуть" ещё и совсем порушится за счёт - чисто к примеру - меньшего удобства использования (например, отсутствия каких-нибудь не100%тно надёжных, но полезных наворотов)?
Какието объективные количественные оценки этого "много" в практических задачах кто-нибудь делал?

Получая некоторый закрытый модуль - "черный ящик", мы можем быть уверены, что он не уронит нам всю систему, если только он не помечен как использующий SYSTEM. Т.е. язык не защищает дурака от ошибок, но он не позволяет ошибке этого дурака фатально порушить всю систему из многих компонентов.
Этот дурак может перепутать знак в числе и самолёт "взлетит" с ветикальной скоростью -20 м/с. Ни один язык этого не проверит.

Кто-то реально оценивал соотношение ошибок:
- потерянные указатели, неверное приведение типов и т.п. (т.е. зависящих от языка)
- не та переменная, не тот знак, ошибка в ф ормуле и т.п. (зависящих только от программиста)
?

Ответ на »сообщение 1084« (Илья Ермаков)
___________________________
общие механизмы, такие как дескрипторы типов, безопасная работа в общем адресном пространстве и т.п. - чем плохо их начилие на аппаратном уровне?

Это лишние транзисторы и дополнительная сложность.
Это больше энергопотребление, больше тепловыделение, больше латентность, меньше достижимая тактовая частота.

Если всё может проверить программный компилятор, это всё лишнее.

Ответ на »сообщение 1086« (гость)
___________________________

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

(про необязательность использования директивы unsafe тоже как-то постепенно забылось)