IT в России и мире в реалиях мирового кризиса

Цитата: Oleg K. от 23.04.2020 21:31:08Прочитал и ответил. Ну что ж - у нас несколько разные взгляды на исходные причины. Вот вам, видимо, не кажется странным, что только кобол "сертифицирован" для бизнес-операций (правда я не знаю, действительно ли это так), а мне - кажется. И на засилье одного языка в течении полувека всегда есть причины, обычно никак не связанные с его потребительскими характеристиками.

Кобол сертифицирован не для бизнес-операций, а просто сертифицирован. Сертифицирован, как язык, обеспечивающий стабильное поведение написанных на нем программ и переносимость в рамках стандарта. Этих языков всег четыре – ada, c, cobol и fortran. Все остальное создано не для тех, кто использует программы, а для тех, кто их пишет. Т.е. они нарушают основной принцип организации технических систем – выбирается главное свойство, которое нужно обеспечить, и оно возводится в абсолют, а все остальное по остаточному принципу.

Цитата: TAU от 23.04.2020 21:39:41Распространенность языка Си - большая беда. Язык небезопасный, вероятность совершить ошибку в программе недопустимо высока.
Особливо усугубляет данное обстоятельство широкое использования языка Си в критически важных встроенных приложениях...

Причины здесь как раз, думаю - косность и инерция мышления.

Ну вот есть "безопасный" язык Java. Вы думаете, что на нем меньше ошибок допускают? Единственное отличие - ошибка на С приводит к сегфолту и падению всего приложения, а на Java - к ошибке в обработке одной операции. Вокруг всех языков программирования всегда строят леса и ставят флажки, чтобы максимально обезопасить программу от ошибок. И в С, и в Java, и в других языках.

Цитата: adolfus от 23.04.2020 21:43:58Кобол сертифицирован не для бизнес-операций, а просто сертифицирован. Сертифицирован, как язык, обеспечивающий стабильное поведение написанных на нем программ и переносимость в рамках стандарта. Этих языков всег четыре – ada, c, cobol и fortran. Все остальное создано не для тех, кто использует программы, а для тех, кто их пишет. Т.е. они нарушают основной принцип организации технических систем – выбирается главное свойство, которое нужно обеспечить, и оно возводится в абсолют, а все остальное по остаточному принципу.

А почему Java с её Languave Specification (довольно подробной и качественной) не в этом списке? Хотя, наверное, её скоро постигнет та же самая участь, что и КОБОЛ.
Обилие КОБОЛа в системах - это особенность исторического развития программных систем в США. Аналогичное обилию узкоспециализированного ПО только под windows.
Это не связано с потребительскими свойствами самих языков почти никак. Просто, кто раньше встал - того и тапки.
Вообще говоря, нельзя заменить одного монстра на другого (большую систему на КОБОЛе на другую такую же большую систему на С). Да и не нужно это. Жаловаться на протяжении 20 лет на нехватку специалистов для серьезных крупных компаний - это лишь оправдание собственной некомпетентности и нежелания брать ответственность за возможные проблемы. "Работает - не трогай, ничего не делай, ничего не меняй".

Цитата: TAU от 23.04.2020 21:39:41Распространенность языка Си - большая беда. Язык небезопасный, вероятность совершить ошибку в программе недопустимо высока.
Особливо усугубляет данное обстоятельство широкое использования языка Си в критически важных встроенных приложениях...
Причины здесь как раз, думаю - косность и инерция мышления.

Вы просто рассмешили. Я программирую на си почти тридцать лет и не вспомню уже, когда у меня была хоть какая-нибудь ошибка из тех, котороые относят к небезопасным. Простой язык, качественные компиляторы, ясно изложенный стандарт, великолепные отладчики, куча утилит, помогающих контролировать проблемы с использованием памяти – ну где там можно совершит ошибку? Может проблема в умении программировать?

Цитата: Oleg K. от 23.04.2020 21:44:021. Ну вот есть "безопасный" язык Java. Вы думаете, что на нем меньше ошибок допускают?
2. Единственное отличие...
3. Вокруг всех языков программирования всегда строят леса и ставят флажки, чтобы максимально обезопасить программу от ошибок. И в С, и в Java, и в других языках.

1. Да, уверен, что меньше.
2. Нет, не единственное отличие.
3. Нет, не "вокруг всех" и не всегда.
P.S. Молодой человек, позволю себе пару слов, чтобы зуда писать чушь с "умным видом" было поменьше. Я учебник по языкам программирования написал, сейчас вот презентацию готовлю на тему "Языки программирования - прошлое, настоящее, будущее" для не самой маленькой аудитории в не самой маленькой компании страны.

Цитата: adolfus от 23.04.2020 21:52:471. Вы просто рассмешили.
2. Я программирую на си почти тридцать лет и не вспомню уже, когда у меня была хоть какая-нибудь ошибка из тех, котороые относят к небезопасным. Простой язык, качественные компиляторы, ясно изложенный стандарт, великолепные отладчики, куча утилит, помогающих контролировать проблемы с использованием памяти – ну где там можно совершит ошибку? Может проблема в умении программировать?

1. Смех без причины - ...
2. Вы - исключение, вот и все. Да, дело и в умении программировать. Но не все умеют программировать без ошибок, скорее - наоборот. Особенности языка напрямую влияют на возможность совершить ошибку в программе, надеюсь, не будете отрицать очевидное. В среднем число ошибок в программах одинаковой сложности на Си у средних программистов выше, чем на языках, где больше внимания уделено безопасности.

Цитата: TAU от 23.04.2020 22:09:161. Да, уверен, что меньше.
2. Нет, не единственное отличие.
3. Нет, не "вокруг всех" и не всегда.
P.S. Молодой человек, позволю себе пару слов, чтобы зуда писать чушь с "умным видом" было поменьше. Я учебник по языкам программирования написал, сейчас вот презентацию готовлю на тему "Языки программирования - прошлое, настоящее, будущее" для не самой маленькой аудитории в не самой маленькой компании страны.

Качество программы в первую очередь зависит от программиста, и только потом - от технологий (есть такие, на которых очень сложно разрабатывать).
И adolfus судя по всему согласен с тем, что и на С можно писать сложные программы (вряд ли он 30 лет "привет, мир" пишет).
Вы можете что-нибудь сказать, что есть в КОБОЛе, чего нет в С, Java или каком-нибудь другом языке программирования? Кроме того, что на для него когда-то был хороший, сертифицированный компилятор и в своё время (именно в нужное время) он был действительно удобен для разработки.


И не надо с аппломбом здесь писать о своём величии - аргументация в стиле "по моему опыту" в приличных спорах - моветон.
Я тоже могу сказать: "Я книжек по программированию не писал - я сами программы пишу, для бизнеса. И написал их немало, поэтому знаю, о чем говорю". И как это должно влиять на сам предмет спора? Так что давайте не будем продолжать в этом духе.

Цитата: TAU от 23.04.2020 22:12:311. Смех без причины - ...
2. Вы - исключение, вот и все. Да, дело и в умении программировать. Но не все умеют программировать без ошибок, скорее - наоборот. Особенности языка напрямую влияют на возможность совершить ошибку в программе, надеюсь, не будете отрицать очевидное. В среднем число ошибок в программах одинаковой сложности на Си у средних программистов выше, чем на языках, где больше внимания уделено безопасности.

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

Цитата: Oleg K. от 23.04.2020 21:51:07А почему Java с её Languave Specification (довольно подробной и качественной) не в этом списке? Хотя, наверное, её скоро постигнет та же самая участь, что и КОБОЛ.
Обилие КОБОЛа в системах - это особенность исторического развития программных систем в США. Аналогичное обилию узкоспециализированного ПО только под windows.
Это не связано с потребительскими свойствами самих языков почти никак. Просто, кто раньше встал - того и тапки.
Вообще говоря, нельзя заменить одного монстра на другого (большую систему на КОБОЛе на другую такую же большую систему на С). Да и не нужно это. Жаловаться на протяжении 20 лет на нехватку специалистов для серьезных крупных компаний - это лишь оправдание собственной некомпетентности и нежелания брать ответственность за возможные проблемы. "Работает - не трогай, ничего не делай, ничего не меняй".

У java и ее инфраструктуры проблема с патентами, поэтому ей принципиально не светит попасть в список сертификации.
Второе – потребительские свойства языка полностью определяются потребительскими свойствами программ, на них написанных, а не мнениями, желаниями и умениями программистов. Как сказал, забыл кто, "если вы не можете выразить идею в прграмме на языке высокого уровня, пишите ее на ассемблере, если и на ассемблере у вас есть проблемы с задачей, пишите прямо в машинных кодах (db, dw, dd  в секции .text)? Ну уж если и это вам не помогает, то скорее всего вы неправильно сформулировали задачу".
В документе о переносимости, где четко упоминаются четыре сертифицированных языка, есть раздел, как следует (will) выбирать языки, технолгии и даже компоненты третьих сторон (если это разрешено) при работе над проектом. Там два разделы – один, что учитывается, а второй, что учитываться не должно. В частности, на решение об используемых языках не должны влиять факторы, связанные с существующими навыками и предпочтениями членов коллектива. Зато там упоминается такие факторы, как возможность формальной верификации корректности кода и возможность пошаговой символьной отладки. Т.е. если язык не императивный, вы его не можете использовать для программирования приложений. Достаточно, чтобы при пошаговой отладке была возможность пропустить хоть маленький кусочек кода, чтобы язык был исключен из рассмотрения (привет вам, конструкторы/деструкторы языка C++).

Цитата: Oleg K. от 23.04.2020 22:25:191. Вы можете что-нибудь сказать, что есть в КОБОЛе, чего нет в С, Java или каком-нибудь другом языке программирования?
2. И не надо с аппломбом здесь писать о своём величии - аргументация в стиле "по моему опыту" в приличных спорах - моветон.
Я тоже могу сказать: "Я книжек по программированию не писал - я сами программы пишу, для бизнеса. И написал их немало, поэтому знаю, о чем говорю"

1. Да, запросто. И это будет всего одна небольшая особенность. Читайте, просвещайтесь. Да, и даже здесь другие участники обсуждения приводили выше примеры.


2. Видите ли, вы, "написавший немало", не замечаете за деревьями леса. И, увы, не знаете, о чем говорите. Демонстрируя, увы, воинствующее невежество. Чтобы судить по праву о разных языках и сравнивать их, нужно бы для начала испробовать:
- разные ассемблеры
- Фортран, желательно "посконный", изначальный
- Форт
- Лисп
- Хаскель
- Смоллток
- наследников APL - К и/или J
- Пролог
- Рефал
- скриптовые вещицы вроде Tcl/Tk, PHP и пр.
- неплохо бы Рапиру
- систему ПРИЗ с языком Утопист
- Алмир/Аналитик
- С/С++ в его развитии вплоть до современных стандартов
- обязательно визуальные языки, например, система Р-схем, Графсет и HiAsm
- Бефунг и Трефунг (будьте осторожны, нервных просят не читать!)
- Пиет (я предупреждал)
Я уж не говорю об Аде (особенно Ада12), Алголе 68, Эйфеле, Обероне, Эрланге, и прочая, и прочая, и прочая...

Успехов в изучении материалов по ссылкам! Без шуток, много найдете необычного, расширяющего горизонты и взгляды на многие вещи.


Эх, навеяли воспоминания. Немного лирики. Лично я уже после пятого класса школы писал на ассемблере К580ИК80А, Фортране, Бэйсике и Рапире. Позже самому пришлось приложить руку к реализации трех проблемно-ориентированных языков. На первом курсе на PDP-11 совместимом ассемблере написал игру Super Pacman, преподавать приходилось предметы "Спецкурс по С++", "Логическое программирование", "Языки программирования", "Основы программирования", "Машинно-ориентированное программирование", "Компьютерная алгебра" в не самых худших университетах страны. Зарабатывать программированием начал со школьной скамьи, помню первые деньги от продажи своих игр - "Каратека" и "Удав" для БК-0010. После - автоматизация деятельности самых разных организаций, и в качестве программиста, и "мастера на все руки" - сетевика/сисадмина/консультанта, и руководителя проектов разработки ПО для коммерческих и госконтор, и ИТ-директора. Помню, собственную оконную систему по образу TurboVision я накропал тоже на младших курсах в 1989, когда автоматизировал бухгалтерию одной конторки малого бизнеса... Не забуду и первое знакомство с Питоном в стартапе в Силиконовой Долине в 2000, где меня привлекали к проекту создания IDE под Linux...

Цитата: TAU от 23.04.2020 23:06:341. Да, запросто. И это будет всего одна небольшая особенность. Читайте, просвещайтесь. Да, и даже здесь другие участники обсуждения приводили выше примеры.

И вы ошибочно (как и автор) предполагает, что в Java всё ограничивается типом данных double? Деньги вообще не обрабатывают алгоритмами с плавающей точкой при фиксальном учете.

В этих "миллиардах строк на КОБОЛе" не банальные расчеты сумм и налогов по ним + документооборот, а сплошь да рядом вычисления рекурретного соотношения мюллера. Зачем натягивать сову на глобус? Что, в России слабая автоматизация процессов? И где же этот ваш хвалённый язык - что-то я по нему не вижу вакансий. Так что ваш аргумент здесь не играет. А вот в пользу моего аргумента "в нужное время" - обратите внимание на платформу 1С и в скольких компаниях она используется. И это не смотря на серьезные сложности с разработкой (отсутствие модульности, хранение исходных кодов в бинарном виде), от которых они сейчас постепенно избавляются (пытаются).

Цитата: TAU от 23.04.2020 23:06:342. Видите ли, вы, "написавший немало", не замечаете за деревьями леса. И, увы, не знаете, о чем говорите. Демонстрируя, увы, воинствующее невежество. Чтобы судить по праву о разных языках и сравнивать их, нужно бы для начала испробовать...

И снова вы пытаетесь взлететь на воздух возвыситься над спором. Давайте лучше вернемся к предмету спора - "незаменимый и великий (здесь можно подставить любой язык программирования на ваше усмотрение)". Итак, КОБОЛ.

Цитата: adolfus от 23.04.2020 23:02:08У java и ее инфраструктуры проблема с патентами, поэтому ей принципиально не светит попасть в список сертификации.

Наверное, вы правы.

Цитата: adolfus от 23.04.2020 23:02:08Второе – потребительские свойства языка полностью определяются потребительскими свойствами программ, на них написанных, а не мнениями, желаниями и умениями программистов.

Категорически не согласен. Из-за чего программа для пользователя обязана быть удобной и быстрой в настройке, если она написана на "удобном и быстром в настройке" (для программиста) языке программирования?

Цитата: adolfus от 23.04.2020 23:02:08В документе о переносимости, где четко упоминаются четыре сертифицированных языка, есть раздел, как следует (will) выбирать языки, технолгии и даже компоненты третьих сторон (если это разрешено) при работе над проектом. Там два разделы – один, что учитывается, а второй, что учитываться не должно. В частности, на решение об используемых языках не должны влиять факторы, связанные с существующими навыками и предпочтениями членов коллектива. Зато там упоминается такие факторы, как возможность формальной верификации корректности кода и возможность пошаговой символьной отладки. Т.е. если язык не императивный, вы его не можете использовать для программирования приложений. Достаточно, чтобы при пошаговой отладке была возможность пропустить хоть маленький кусочек кода, чтобы язык был исключен из рассмотрения (привет вам, конструкторы/деструкторы языка C++).

А можно этот документ где-то посмотреть? 
P.S. Если подразумевать под пошаговой отладкой реальное исполнение - то формальная верификация исполняемого кода закончилась давным давно - сначала её пошатнул защищённый режим, а потом добили регистры управления виртуализацией. Байт код джавы точно так же можно спокойно просматривать под микроскопом, исполнять пошагово и всё остальное. Но по ней спор закончили - она вся в патентах. Пусть будет С.

Цитата: adolfus от 23.04.2020 21:12:361) Конечно перестали – мертвым не платят, а живые съехали. К началу 2000-х на просторах СНГ их практически не осталось. На EC ЭВМ стоял компилятор кобола и он достаточно активно использовался. По крайней мере, в середине 80-х каждый третий из моих знакомых программистов с ним имел дело на регулярной основе. Последний из тех, кого я знал, уехал в начале 2000-х. До этого он десять лет работал "на удаленке" через представительство IBM в Минске. Модем хайес аккура + америка онлайн = 9600 бод. Как только дети школу закончили, так он всей семьей и уехал.

Платить не перестали, а они сами уехали. "Самонасралося", пнятно. А в штатах тоже "уехали"?

Цитата: adolfus от 23.04.2020 21:12:363) Что такое "транзакция"? Это атомарно выполняемая инструкция (команда или операция, если хотите) любого уровня, который выше архитектуры набора инструкций (ISA). Например, захват мютекса. Или поперечная ACID-транзакция СУБД, обновляющая все потомки в первичном ключе и все чвязанные с этим вторичные ключи. Или элементарная продольная, вычисляющая какой-нибудь агрегат, типа статистики. Или бекап/восстановление всей БД. Или гарантированная передача пакета. По шине, по сети... Многое из этого транзакцией не называют, тем не менее, понятно что это такое – что угодно, изменяющее состояние вычислительной системы, какой бы она не была, не нарушающее  принципа ACID в отношении этой самой системы (соответсвенно, и задействованной подсистемы, какой бы она не была) в целом. Очень перегруженное понятие, тем не менее, абсолютно идентифицируемое на любом из уровней, где это понятие имеет смысл. 
В отношении обмена ресурсами, если грубо посмотреть, это атомарное списание некоторого количества ресурса с одного счета и зачисление этого количества на другой таким образом, что время на эту процедуру  во временном пространстве соотвествующего бизнеса равно нулю. У одного хевисайд упал, у другого поднялся, причем одно и другое совершилось в один и тот же момент времени.

Очень интересно, но ничего не понятно. Упоминалась некая "цена транзакции", которая "меньше" у "мейнфреймов", чем у "других". Вот я и спрашиваю, "цена" чего именно. Чтобы уяснить, а не для спора.

Цитата: adolfus от 23.04.2020 21:12:362) Если быть точным, то соременные платформы – это, в том числе, и мæйнфреймы. Но Вы, как я понимаю, за "современные" держите исключительно те, что имеют архитектуру набора команд x86.

Неверно понимаете. Я вполне осознаю, что х86 не везде оптимален, и его основной плюс - наличие туевой хучи кода под него написаного. А остальное - минусы "Современные" в моей понимании и есть "современные", т.е. выпускаются, поддерживаются производителями, у которых есть для этого специалисты, которые, в свою очередь, магическим образом не закончатся как только помре Петрович.

Цитата: adolfus от 23.04.2020 21:12:36Ну хорошо, есть не последние x86_64 сервера Supermicro c инфинибэндом и SAS-дисками. Или что-то есть лучшее? Скорее всего все это лучшее – такое же.

Меня угораздило работать в местах "побогаче". Впрочем, железки не показатель богатства. Вот акамай, нопример, для своих CDN-кешей не заморачивается крутожелезками, а юзает откровенный шлак, которому и до супермикро как раком до китая. И ниче. Как так можо? Да просто - за счет архитектуры собственно системы выползают. Лохи не лохи, а отгрохали вона какой CDN'чик.

Цитата: adolfus от 23.04.2020 21:12:36Однако между железом и приложениями есть прослойка в виде сами понимаете чего. Миддлварь, называется. Именно эта прослойка чут менее, чем полностью определяет юзабилити всей системы, в том числе и стоимость этой самой транзакции. Ну там еще есть и такой параметр, как полная стоимость владения технологическим решением ... например, в течение сорока лет. Так уж случилось, что эта самая миддлварь в приличном с точки зрения бизнес-затрат виде имеется в наличии только у IBM, как и то, что у них стоимость владения технологическим решением на круг самая низкая. Банкиры не дадут соврать.

Мда Ну мы не настолько богатые. Хотя стремимся. А про банки - тоже разные бывают. Я вот знаю более двух, где междельмаш имеет место быть лишь во влажных мечтах тамошних админов.

Цитата: adolfus от 23.04.2020 21:12:36Вы спросите – а что же будут кушать программисты для платформ с пятидлетним сроком существования, а также их  IT-пастухи, если руководство решит, что нужно спланировать на 40 лет вперед и закупиться IBM System z? Тридцать лет назад некто Sosha, автор двухпанельника Norton Commander, сказал  - они будут есть картофельные очистки.

СистемЗю в каждую хату? Я только за Где записаться на светлое будущее?

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

Цитата: Andrew Carleet от 24.04.2020 02:14:41Я думаю, основная проблема не в переписывании программ с COBOL на любой другой язык/платформу. Проблема в стоимости переноса и цене ошибки при переносе.
...
Да, чем дальше в лес, тем толще партизаны, но, похоже, никто и никогда не начнет переход на другое программное обеспечение. Самоубийц нет.

Ну примерно про это я тоже и говорю - пока петух не клюнет - причин переходить на другое ПО нет
Причем в целом такой подход правилен и выгоден. Просто если долго "затягивать" (по-моему - больше 20 лет в ИТ оставаться на одной платформе - это "долго").
Никто не предлагает гнаться за модой и два раза в день менять платформу разработки, но в остальном... Наши компании, у которых серьезная часть документооборота прибита к 1С может постичь аналогичная участь.
P.S. В крупной компании того, кто предложит что-то там обновить в ПО заклюют сразу, проект сделать ему не дадут и выживут из компании, поэтому - "дураков нет", никто таскать каштаны из огня не будет. Таковы реальные законы развития крупных компаний.

Цитата: Oleg K. от 24.04.2020 15:55:46Ну примерно про это я тоже и говорю - пока петух не клюнет - причин переходить на другое ПО нет
Причем в целом такой подход правилен и выгоден. Просто если долго "затягивать" (по-моему - больше 20 лет в ИТ оставаться на одной платформе - это "долго").
Никто не предлагает гнаться за модой и два раза в день менять платформу разработки, но в остальном... Наши компании, у которых серьезная часть документооборота прибита к 1С может постичь аналогичная участь.
P.S. В крупной компании того, кто предложит что-то там обновить в ПО заклюют сразу, проект сделать ему не дадут и выживут из компании, поэтому - "дураков нет", никто таскать каштаны из огня не будет. Таковы реальные законы развития крупных компаний.

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

Цитата: Oleg K. от 24.04.2020 00:54:28P.S. Если подразумевать под пошаговой отладкой реальное исполнение - то формальная верификация исполняемого кода закончилась давным давно - сначала её пошатнул защищённый режим, а потом добили регистры управления виртуализацией. Байт код джавы точно так же можно спокойно просматривать под микроскопом, исполнять пошагово и всё остальное. Но по ней спор закончили - она вся в патентах. Пусть будет С.

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

Проблема с пошаговой отладкой и существует у тех языков и технологий, которые допускают неявное исполнение неконтролируемого кода на прикладном уровне. В их число, кстати,  попадает язык c++ с его дурацкими конструкторами/деструкторами по умолчанию, виртуальными методами, перегрузкой, полиморфизмом и обработкой исключений. И пока в языке будет существовать хоть что-нибудь неявное, чего невозможно избежать, ему не светит попасть в сертифицированные.
С конструкторами/деструкторами в C++ проблема решается просто и скорее всего мы это скоро увидим в стандарте. Т.е. все конструкторы объектов должны (will) объявляться d программе явно. Остальное, к счатью, реализуется только при явном его использовании и может быть заложено в требования как "не допускается использование ...".
Что касается явы, то там еще более страшное присутствует – невозможность из программы управления кучей.

Цитата: Oleg K. от 24.04.2020 00:54:28А можно этот документ где-то посмотреть?

Интересный вопрос. Попробую поискать в своих авгиевых конюшнях. В начале 2000-х документ и его изменения всегда попадали в верхнюю десятку выдачи поисковика ftpsearch.com по запросу "program portability requirements and certification". Документ лежал на серверах правительства США и был обязателен к использованию в любых работах для государственных институтов и организаций федерального уровня. Сегодня поиск по ftp пришел в полный упадок и документ не ловится.
Но попробую поискать в бекапах и был еще  печатный экземпляр. Быстро не обещаю – в связи с пандемией появляюсь на рабочем месте раз в неделю

Цитата: adolfus от 25.04.2020 02:15:37Проблема с пошаговой отладкой и существует у тех языков и технологий, которые допускают неявное исполнение неконтролируемого кода на прикладном уровне. В их число, кстати,  попадает язык c++ с его дурацкими конструкторами/деструкторами по умолчанию, виртуальными методами, перегрузкой, полиморфизмом и обработкой исключений. И пока в языке будет существовать хоть что-нибудь неявное, чего невозможно избежать, ему не светит попасть в сертифицированные.
С конструкторами/деструкторами в C++ проблема решается просто и скорее всего мы это скоро увидим в стандарте. Т.е. все конструкторы объектов должны (will) объявляться d программе явно. Остальное, к счатью, реализуется только при явном его использовании и может быть заложено в требования как "не допускается использование ...".

ОК. С поведением, которое добавляется компилятором или средой исполнения разобрались.

Цитата: adolfus от 25.04.2020 02:15:37Что касается явы, то там еще более страшное присутствует – невозможность из программы управления кучей.

Сейчас динамическое управление памятью практически везде - самая сложная задача. Управляет ли ей сам программист (malloc / free) или же "сборщик мусора" (привет, Java, Go, python или какой-нибудь ещё язык программирования). И в сложных системах всё равно проскакивают ошибки (вроде той же use after free). Конечно, несколько удивительно мне слышать о том, что ни один такой язык/среда исполнения в принципе не может быть сертифицирован. Тем интереснее взглянуть на документ. Время на его поиски есть - дискуссия эта не вчера началась и не завтра закончится. Сам я сразу попробовал что-нибудь подобное найти в поисковике, но потерпел неудачу.
Если рассуждать в целом - то просто надо разделять системы на составляющие - что является критичным, что - важным, а на что можно почти не обращать внимания. И в разных подсистемах просто использовать разные средства - композиционные системы всегда будут более конкурретноспособными по сравнению с однообразными в изменяющемся мире. Если всё вокруг стабильно - картина другая.

Цитата: AndreyK-AV от 24.04.2020 13:08:03Ну и...
Много слов, да и дел немало в области цифровизации отечественной, это если говорить вообщем, а конкретно?
Образование народное
- он-лайн, ну и ???
- ОС ну и ???
- железо (хард)  ну и ???
- софт ну и ???
- гаджеты ну и ???
- мебель под это, ну и ???
Рынок огромен, рынок обеспечен финансами а) госфинансированием б) муниципальными финансами в) родителями учеников, ну и.... 
ИТ-отрасль ау, где отечественное, где импортозамещение в конце концов???

Ну и...
Какая или какие платформа ВКС ведущая  для проведения он-лайн уроков в в России? Чьего производства???
Ну и...
Чьего производство хард  на котором живёт образование в России?
Ну и...
Чьего производство ОС  на котором живёт образование в России?
это так, вопросы крупными мазками? 
Или вы думаете что доходы разработчиков всего этого много меньше программистов на Коболе?
Или вы считаете что на это тратятся копейки? Ну.... ну.....