Интересно.

Госзаказ госзаказу рознь.
Можно сайт для службы делать, а можно ракетные комплексы прогать.
За последнее - там куча гостов.

Видимо касается проблемы переполнения памяти. И я с этим согласен на 100%.

Кто-нибудь встречался с/читал о том, что в госпрограммах нельзя использовать какие-то конкретные языки или технологии?

Требования к языку программирования и стилю, это достаточно обычная вещь для «серьёзных» проектов, нет?

Из недавнего, тот же Curiosity запрограммирован на, емнип, подмножестве Си.

Требования к языку программирования и стилю, это достаточно обычная вещь для «серьёзных» проектов, нет?

Ну так мне и интересны примеры таких требований для госпроектов.

Может смущать, например, размер рантайма. Или, может быть, там просто скрипт с открытым наружу кодом.

Знаю только про фортран vs NASA.

<fat>

Не хотят, что б с синтаксической ошибкой упало.

Синтаксис в динамических языках обычно на этапе компиляции всегда проверяется.

хаха! Значит COMMOH LNCP это ещё и самый демократичный язык в мире

На лоре не так давно проскальзывало мнение экспертов, что бинарники, скомпиленные из ООП-языков, не удовлетворяют каким-то ГОСТам безопасности выше какого-то уровня, например.

То что связано с баллистическими ракетами можно писать только на ассемблере, форте, фортране, с и плюсах. По очевидным причинам.

А я думал, у них там уже давно ada во все поля.

Когда-то устраивался на работу в одну контору, там сказали, что часть кода, отвечающая за авторизацию пользователей у них написана на Java (при том, что весь проект на PHP) по требованию сертифицирующих органов. Именно из-за того, что PHP — интерпретируемый язык. Уж не знаю, насколько это не бред.

Правильно.

Для надежных проектов нужен язык, поддерживающий одну парадигму и типизацию:

1) строгую;

2) статическую;

3) безопасную;

4) именованную;

5) явную.

А малолетние кульхацкеры-нищеброды могут много и долго умничать на собеседованиях.

дык прикинь пулемёт с утиной типизацией, ты крякнешь, а он тебя подстрелит :)

Слишком много степеней свободы, военам это не нужно. Чем поведение ПО проще, тем лучше.

«все что связано с баллистическими ракетами можно писать только на Фортране с такими-то библиотеками таких-то версий».

ты хотел сказать на Ada?

Видимо касается проблемы переполнения памяти. И я с этим согласен на 100%.

проблема не с переполнением а с безопасностью и верификацией кода на этапе разработки/трансляции.

Синтаксис в динамических языках обычно на этапе компиляции всегда проверяется.

он в _любых_ ЯП проверяется. Разница в том, что код на сишечке у тебя скорее всего не соберётся, а вот код на php заработает. Но потом рухнет, или, что ещё хуже, будет работать непредсказуемо. Конечно такой быдлокод возможен и в сишечке, но он хорошо известен и программистам и компилятору.

Именно из-за того, что PHP — интерпретируемый язык. Уж не знаю, насколько это не бред.

требования исходят из возможности легко и непринужденно модифицировать код в plain text. вот если бы использовали трансляцию из PHP в какой нить байткод то обошлись бы и без жабы.

ЯННП, поясни на пальцах.

проблема не с переполнением а с безопасностью и верификацией кода

В проекте, в котором мне довелось участвовать, код необходимо было не верифицировать, а доказывать.

требования исходят из возможности легко и непринужденно модифицировать код в plain text. вот если бы использовали трансляцию из PHP в какой нить байткод то обошлись бы и без жабы.

В упор не понимаю, как это влияет на безопасность. Если можно модифицировать код PHP, точно также можно модифицировать и байт код. Это конечно чуть сложнее, но принципиально ничего не меняет.

В упор не понимаю, как это влияет на безопасность. Если можно модифицировать код PHP, точно также можно модифицировать и байт код. Это конечно чуть сложнее, но принципиально ничего не меняет.

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

ну требования такие

Я, собственно, пытаюсь понять, это требования маразматические или в этом есть какой-то смысл.

при сертификации например требуют доказательств что байт/двоичный т.е. непосредственно исполняемый код был получен именно из проверенных и утвержденных исходников

Ну а если интерпретатор работает непосредственно с исходниками, ничего этого вообще не нужно, соответственно все становится проще и прозрачнее.

Отлично, Java в пролёте.

Ну а если интерпретатор работает непосредственно с исходниками, ничего этого вообще не нужно, соответственно все становится проще и прозрачнее.

plain text проще модифицировать. в том числе и на лету.

проще модифицировать

Это даже не security throw obscurity.