OberonCore

Не вижу повода для смеха.

Вполне оправданный подход для ответственных систем.

Что же, тоже вполне понятный и обоснованный подход.
Кстати, встречается не только в медицинском оборудовании

+1!

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

Я же упомянул зачем - гонка за эффективностью.

Тем не менее, вероятность собрать какую-нибудь плюсовую либу на другой платформе с первого раза (без доточки напильником разной величины) стремится к нулю С жабой, ИМХО, несколько проще, во всяком случая на популярных платформах. Впрочем на непопулярных C++ все равно отдыхает - там обычно нормальный компилятор сложно найти. Так что реально с жабой может поспорить только Си без плюсов на экзотических платформах

Языков, могущих компилировать в машинный код (без дополнительных извращений) осталось не так уж и много. Потому что для ширпотребных задач это никому не надо, а проблем много (начиная с этой самой верификации кода).

Ну, во-первых ява работает только на одной платформе -- JVM. Какова вероятность собрать/запустить JVM с первого раза на другой платформе? Вот возьмем скажем какую-нибудь BeOS/Haiku. Мне думается что плюсатую программу я туда "портирую" существенно быстрее нежели явовую.

Во-вторых, не видел пока платформ (быть может у меня кругозор слишком маленький) где бы была нормальная JVM/JRE но небыло бы хорошего компилятора для С++. Обратное наблюдал неоднократно. Взять ту же BeOS&Haiku. Взять AmigaOS, или, скажем, MorphOS. Да даже симбиан если взять -- приличный компилятор C++ имеется (и даже две штуки), JVM приличной не имеется. Только огрызок в виде j2me.

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

Давайте не будем в терминологию углубляться. Понятно, что под другой платформой я имел ввиду другой комп с другой ОС. А под популярными платформами я имел ввиду Win-Linux-Mac.



M$ Zune Там .NET и реально писать можно только на шарпе. На плюсах тоже можно, но оно там не запускается, если сборка unmanaged Понятно, что это искусственное ограничение и сама M$ колбасит системный софт для него на собственном VC++. Но тем не менее - факт, заюзать C++ у меня не получилось

Ну, судя по всему, заюзать Java у тебя там получилось. Берешь нетбинзу или иное java-приложение и спокойненько компилишь её под Zune...

Дался Вам этот "закон тождества"...


Я не защищаю Си++ и предпочитаю плюсам Оберон.
Но http://ru.wikipedia.org/wiki/Неопределённое_поведение -- вполне разумная стратегия в ряде ситуаций. Причем именно в тех, когда оно и по смыслу неопределено.
Т.е. в корректной программе проблем с UB не возникает.
Возьмем какой-нибудь простой пример. Скажем, поведение операции битового сдвига в Си/Си++ определено только для значения правого операнда в диапазоне от нуля до числа битов в левом операнде. Это позволяет (как правило) реализовать эту операцию одной машинной инструкцией.
За корректностью приходится следить программисту.
Другой подход -- проверять допустимость операндов для всех операций -- приводит к большим накладным расходам.
Разумный компромисс, IMHO, -- ограничиться гарантиями инвариантов памяти (как в Обероне).

Я не совсем точно сформулировал.

QA, по идее, должен контролировать не только (и не столько!) стиль написания программ, сколько то, как организованы рабочие процессы жизненного цикла - а там не только собственно написание текстов программ, но и отладка, и тестирование, и проектирование, и документирование, и т.д., и т.п.

Не путайте отделы QA и SQM (System Quality Managment: ISO9000,9001,9004)

Долго не был.. извиняюсь..
Я когда запостил эту новость в чат, мне ответили:
- непредсказуемое окружение это юзеры?

А заявление представителей компаний производящих свои собственные ОС, что это "непредсказуемое окружение" это расписываться в собственной несостоятельности.
Я максималист?

Вон Apple решили даже чипы сами проектировать.
Будут контролировать от и до.

Логично -- top-down.

Непредсказуемое окружение -- это другие программы (включая вредоносные).


Утопист

Логично.
Только как с этим совместить мысль Вирта, что программная система "растет" (снизу вверх, за счет новых модулей)?
А книгу Пфистера "Компонентное ПО", видимо, пора выбрасывать на свалку. (Там написано, что компоненты могут быть от разных производителей.)
И каждый в своем отдельном огородике -- top-down. Почти натуральное хозяйство.

Не вижу в это ничего хорошего. Вот захотите вы туда свой любимый ББ портировать, а вам скажут: на нашей платформе в качестве ЯП допустимо использование только Apple ObjectiveC (c) и AppleScript (c).

P.S. Если не верите - посмотрите что уже сейчас творится в производстве софта для iPhone.

Вы путаете разные вещи.


Речь о разработке системы. Топ-даун, как и положено.
Но в проект системы можно заложить требование ее расширяемости модулями "от разных производителей".
Нет противоречия.
Есть путаница.