Паспорта никто не заверяет ввиду бессмысленности самого действия. Копия паспорта теоретически может быть заверена, но нотариусы на это не соглашаются, поскольку формально не отменен закон советских времен, который это явно запрещает, а нового внятного закона об этом нет.
Даже если кто-то вдруг согласится копию паспорта заверить, то ее любое должностное лицо запросто может отправить в мусорное ведро по озвученной выше причине.
Заверить могут — без проблем — перевод иностранного паспорта. Но будет заверен именно перевод, а не паспорт.
Здесь сказано, что для выполнения операция над boolean-данными используются значения типа int. Как я и сказал.
Здесь сказано, что JVM не поддерживает булевы массивы. И в следующем фрагменте, который Вы благородно поскипали, а я, в свою очередь, процитировал выше, сказано, что они реализуются как массивы байтов.
Из этого никак не следует, что int — «родное» представление, а «byte» — оптимизация.
В документации нигде не сказано, что это оптимизация, а не исходное решение. Скорее наоборот: для оптимизации скорости вычисления выражений в них используется 4-байтовое представление boolean.
Рассмотрим распространённую Sun JVM и прочтем в спецификации виртуальной машины, что boolean типа в ней нет как такового, вместо него используется int!
Если все же прочитать текст по приведенной ссылке, то можно узнать, что int используется только для операций (для вычислений выражений), а при создании массива boolean'ов будет создан массив байтов (как и в подавляющем большинстве языков, кстати).
The Java virtual machine does directly support boolean arrays. Its newarray instruction enables creation of boolean arrays. Arrays of type boolean are accessed and modified using the byte array instructions baload and bastore. <.blockquote>
Без разницы, произойдёт сбой оборудования, или пользователь-ламер введёт в программу набор случайных значений. В итоге программный продукт может выдать неправильный результат, а уж разбираться, что же случилось, приходится… конечно же в 90% случаев разработчикам! :)
В истории с самолетом никакая программа не давала неправильных результатов и не получала неправильных входных данных.
Причиной стали организационные проблемы — не была проработана схема внесения изменений в полетные планы.
получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты
В действительности датчики сработали корректно и передали ДОСТОВЕРНУЮ информацию. Но программа не смогла ее правильно обработать. И четко указана причина:
Ariane 5's flight path was considerably different and beyond the range for which the reused computer program had been designed
Вы читали невнимательно. Были введены ПРАВИЛЬНЫЕ координаты. Просто экипажу забыли сообщить, что сегодня они летят фактически другим маршрутом. Теоретически, это наверняка прошло бы никем не замеченным, если бы не наложились другие факторы.
Unknown to them, the coordinates had been modified earlier that morning to correct the error introduced years previously and undetected until now
Тот факт. что координаты, которые использовались ДО этого были с ошибкой, значения не имеет — проблема не в наличии ошибки в прошлом, а в том, что экипаж не информировали об изменении. В точности то же самое произошло бы при любой другой причине изменения координат.
Сама ошибка — пока ее не исправили — никому годами не мешала.
Неправильный вопрос. Правильный вопрос: как вообще это попало в статью о программистских ошибках? Я не знаю подробностей об этом случае, но согласно описанию, которое дано выше, программа отработала корректно.
К сожалению, выбор есть только между тестами и верификацией валидности программ. Первое более-менее успешно используется на практике, тогда как второе показало себя экономически нежизнеспособным на реальных программах еще в семидесятых годах.
Языки, на которых труднее писать неправильные программы (та же Ada), на практике сейчас сдают позиции и уступают место языкам, на которых проще писать правильные программы, сопровождаемые тестами. Обращаю внимание: та же Ada при достаточно высоком уровне жесткости на уровне языка никак не решает проблему дефектов алгоритмического уровня.
Я не буду спорить с оценкой того, насколько программирование с хорошими тестами (не модульными, а тестами вообще — полного спектра) дороже, чем программирование без тестирования — просто потому, что ни я, ни лично мне известные люди никогда не видели ни одной системы, стоящей упоминания, которая была бы сделана без тестирования. Возможно, без тестирования дешевле. Но таких систем, доведенный до внедрения, в природе нет.
IMHO, здесь тоже хватает исторических анекдотов. К примеру, вот об этом случае я читал ранее:
Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся “вверх ногами”.
Байка. В действительности сбой наблюдался на имитаторе во время штатной программы испытаний. Причем, там были и более неприятные — но также найденные на имитаторе — сбои. Например, в первой версии бортовая система разрешала убирать шасси самолету, который стоит на полосе.
Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» :)
Байка. Реальность такова: 5.10.1960 Луна действительно попала в поле зрения одного из радаров BMEWS, и выданные системой данные изумили операторов. Никакой тревоги поднято не было. И это не было первое дежурство ни данного радара, ни, тем более, всей системы. По результатам систему скорректировали, чтобы она игнорировала слишком далекие объекты.
Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.
На эту тему я не встречал внятных публикаций, но предположительно заражен вирусом был компьютер, где хранились оцифрованные диагностические изображения. Причем вроде как нет особой уверенности, что это вообще был вирус, а не сбой оборудования.
Даже если кто-то вдруг согласится копию паспорта заверить, то ее любое должностное лицо запросто может отправить в мусорное ведро по озвученной выше причине.
Заверить могут — без проблем — перевод иностранного паспорта. Но будет заверен именно перевод, а не паспорт.
А вот юридичская бессмысленность отмечена совершенно справедливо. Это больше похоже на попытку сделать умное и серьезное лицо.
Здесь сказано, что JVM не поддерживает булевы массивы. И в следующем фрагменте, который Вы благородно поскипали, а я, в свою очередь, процитировал выше, сказано, что они реализуются как массивы байтов.
Из этого никак не следует, что int — «родное» представление, а «byte» — оптимизация.
Если все же прочитать текст по приведенной ссылке, то можно узнать, что int используется только для операций (для вычислений выражений), а при создании массива boolean'ов будет создан массив байтов (как и в подавляющем большинстве языков, кстати).
В истории с самолетом никакая программа не давала неправильных результатов и не получала неправильных входных данных.
Причиной стали организационные проблемы — не была проработана схема внесения изменений в полетные планы.
В действительности датчики сработали корректно и передали ДОСТОВЕРНУЮ информацию. Но программа не смогла ее правильно обработать. И четко указана причина:
Тот факт. что координаты, которые использовались ДО этого были с ошибкой, значения не имеет — проблема не в наличии ошибки в прошлом, а в том, что экипаж не информировали об изменении. В точности то же самое произошло бы при любой другой причине изменения координат.
Сама ошибка — пока ее не исправили — никому годами не мешала.
Языки, на которых труднее писать неправильные программы (та же Ada), на практике сейчас сдают позиции и уступают место языкам, на которых проще писать правильные программы, сопровождаемые тестами. Обращаю внимание: та же Ada при достаточно высоком уровне жесткости на уровне языка никак не решает проблему дефектов алгоритмического уровня.
Я не буду спорить с оценкой того, насколько программирование с хорошими тестами (не модульными, а тестами вообще — полного спектра) дороже, чем программирование без тестирования — просто потому, что ни я, ни лично мне известные люди никогда не видели ни одной системы, стоящей упоминания, которая была бы сделана без тестирования. Возможно, без тестирования дешевле. Но таких систем, доведенный до внедрения, в природе нет.
Байка. В действительности сбой наблюдался на имитаторе во время штатной программы испытаний. Причем, там были и более неприятные — но также найденные на имитаторе — сбои. Например, в первой версии бортовая система разрешала убирать шасси самолету, который стоит на полосе.
Соответственно, вспоминаем про закон 13-го удара…
В действительности причиной катастрофы стал комплекс причин, которые давно известны.
Байка. Реальность такова: 5.10.1960 Луна действительно попала в поле зрения одного из радаров BMEWS, и выданные системой данные изумили операторов. Никакой тревоги поднято не было. И это не было первое дежурство ни данного радара, ни, тем более, всей системы. По результатам систему скорректировали, чтобы она игнорировала слишком далекие объекты.
На эту тему я не встречал внятных публикаций, но предположительно заражен вирусом был компьютер, где хранились оцифрованные диагностические изображения. Причем вроде как нет особой уверенности, что это вообще был вирус, а не сбой оборудования.