Опыт самостоятельного развития средства программирования в РКК «Энергия»
В
ведение
ВведениеВ настоящее время все острее стоит вопрос о независимом развитии российских средств разработки программного обеспечения (ПО), поскольку в ряде отраслей, в том числе и в космической, этот вопрос тесно связан с безопасностью страны. Помимо прямой опасности в виде возможного эмбарго на поставки таких средств, «закладок», сокрытия протоколов и т.п. доводов в пользу введения отечественных средств, существует и другая важная негативная сторона отказа от собственных разработок – отстранение российских специалистов от самого процесса развития средств программирования и возможности влиять на вектор этого развития. Нельзя сказать, что этих проблем не замечают. Например, 22 июня 2016 года межведомственной группой обсуждался проект подготовленной Агентством стратегических инициатив программы «Национальной технологической инициативы», в которой предполагается и создание в течение 2–3 лет собственного языка программирования для «безопасного и эффективного параллельного программирования». Однако, создание и независимое развитие средств программирования в масштабах всей страны это такой сложный и многоплановый вопрос, что очевидно его невозможно решить в короткое время и только созданием одного или даже нескольких новых языков программирования. Скорее, вопрос отечественных средств разработки ПО может быть решен постепенно, добавлением все новых и новых программных инструментов, не обязательно созданных «с нуля», но независимых от зарубежных разработчиков. Разумеется, еще в большей степени это же относится и к аппаратным средствам. В РКК «Энергия» имеется такой инструмент и более чем 25-летний опыт его использования. Эта система программирования главным образом применялась для создания ПО комплекса средств поддержки экипажа сначала «Мира», а затем Российского сегмента Международной космической станции (РС МКС). В комплекс входят программы баллистико-навигационного отображения экипажу полетной обстановки, а также программные средства межкомпьютерного обмена (т.е. позволяющие осуществлять передачу данных между компьютером экипажа и наземным компьютером в ЦУПе). Эти же средства программирования используются на предприятии и при моделировании стыковок, а также при обработке снимков, полученных с борта РС МКС. Т.е. в самых разных инженерных задачах применяется инструмент, давно не зависящий от зарубежных разработчиков, но, правда, зависящий от постоянно развивающихся персональных компьютеров и их системного ПО и прошедший вместе с ними весь этот путь изменений от 16-разрядной MS DOS до 64-разрядной Windows. В статье рассматриваются исторические причины появления (по мнению автора) зависимости от зарубежных средств разработки, и на примере развития собственной системы программирования в одном из подразделений РКК «Энергия» описывается, как было реализовано преодоление такой зависимости. Следует подчеркнуть, что все работы проводились своими силами, т.е. сами пользователи этих средств выступали и как их разработчики. Тем не менее, удалось добиться хороших результатов и получить продукт, не уступающий зарубежным аналогам, а по некоторым параметрам и превосходящий их. Исторические причины зависимости от западных средств программированияЕсли не рассматривать специализированные вычислительные средства (например, ЭВМ 5Э26), для которых, разумеется, всегда создавались все необходимые инструменты разработки ПО, то можно утверждать, что независимая разработка средств программирования общего назначения сильно сократилась после успешного создания системного ПО для ЭВМ БЭСМ-6 и вычислительного комплекса «Эльбрус». Есть мнение, что решающую роль в этом сыграло принятое еще в 1969 году решение разрабатывать семейство ЭВМ следующего поколения, совместимое по командам с американской ЭВМ IBM/360. Одним из доводов для принятия этого решения было получение сразу готового системного ПО, включая трансляторы с языков Фортран, Кобол и PL/1. В тогдашних условиях эмбарго на лицензию производства и поставок IBM/360 и отсутствия прямых контактов с IBM, получение готового ПО (через третьи страны) считалось допустимым и позволяло сэкономить большие человеческие и финансовые ресурсы. Якобы именно после этого отечественных программистов заставили перейти на американские средства, и именно вследствие этого в нашей стране свернулись собственные направления, и появилась зависимость от зарубежных разработчиков, неустранимая до сих пор. Однако само по себе создание функционального аналога IBM/360 не могло бы сократить отечественных разработок, как, например, первоначальное копирование немецких разработок в ракетной отрасли не сделало Советский Союз зависимым, а наоборот, сэкономило время и вывело на передовые позиции. В данном случае стратегический просчет был не в решении использовать готовое ПО, а в том, что после этого не было выделено достаточно сил и средств, чтобы создать свои аналоги, на базе имеющихся работающих образцов, а затем развивать их и, тем самым, обеспечить независимость в будущем. И если для комплекса «Эльбрус» были разработаны превосходные собственные средства программирования, причем «с нуля», т.е. решена гораздо более сложная задача, то для ЕС ЭВМ не была выполнена даже более простая задача самостоятельного развития средств разработки после изучения существующего системного ПО. Но «Эльбрусы» выпускались единичными экземплярами, а ЕС ЭВМ – тысячами. Поэтому большинство программистов стало иметь дело только с операционной системами (ОС) и трансляторами фирмы IBM, а не с отечественными разработками. После массового распространения американских персональных компьютеров той же IBM положение еще ухудшилась. Разумеется, сразу и не могло быть создано своего системного ПО для этих новых компьютеров. Но затем повторилась ситуация с ПО для ЕС ЭВМ. Кроме попытки поставок с ЕС-1840 некоторого доработанного системного ПО, автору неизвестны разработки собственных средств, хотя бы на основе уже существующих. Тем временем в страну хлынул поток всевозможного ПО, в том числе и средств разработки, к тому же сопровождаемый безудержной рекламой, превозносящей тот или иной продукт. Постоянно создавались новые «модные» языки и системы программирования и каждая из них объявлялась свободной от недостатков, хотя сам факт их непрерывной смены говорит об обратном. В таких условиях, усугубленных распадом Советского Союза, было чрезвычайно трудно организовать собственные направления развития средств программирования для становящихся де-факто стандартом персональных компьютеров и используемого в них зарубежного ПО. Средства программирования с открытым исходным кодомЗависимость от нескольких крупных фирм-разработчиков систем программирования и недовольство их технической и коммерческой политикой иногда заставляла сообщества программистов искать выход в виде создания собственных «общих» продуктов, имевших исходные тексты в свободном доступе. Формально, любой желающий мог присоединиться к проекту и внести свой вклад в развитие существующей системы. У такого подхода есть свои достоинства, и он снижает монополизм крупных фирм. Однако коллективная ответственность за работоспособность и качество продукта часто приводит к отсутствию какой-либо ответственности вообще. Обычно подобные проекты неформально держатся на энтузиазме одного-двух человек и с их уходом дальнейшее развитие прекращается. Вряд ли программную независимость целой страны и жесткие требования к безопасности можно обеспечить только на основе подобных программных продуктов, хотя участие российских программистов в таких проектах помогает получить им ценный опыт. Кроме этого, большинство проектов с открытым исходным кодом изначально также являются зарубежными. Начало использования персональных компьютеров в РКК «Энергия»В РКК «Энергия» персональные компьютеры IBM-PC/XT, во-первых, появились рано по меркам нашей страны – еще в 1985 году, а, во-вторых, вместе с первыми компьютерами была получена система программирования на языке PL/1. Казалось бы, так и должно быть, поскольку, выпуская персональную ЭВМ под своей маркой, IBM, чтобы обеспечить себе монопольные преимущества, должна была бы поставлять вместе с ней и систему программирования. И, конечно же, на языке, на создание и внедрение которого ею уже были потрачены большие средства (и который уже давно поставлялся вместе с IBM/360). Однако на тот момент был готов только транслятор с PL/1 одного из лучших американских специалистов по микропроцессорам Гарри Килдэла (Gary Kildall). Из-за трений по поводу MS DOS (Килдэл – ее настоящий автор), MicroSoft и IBM не включили его транслятор в состав ПО, продаваемого вместе с компьютерами. В результате самим Килдэлом было продано лишь несколько сот экземпляров своего транслятора, один из которых (при содействии Института радио) вместе с компьютерами и попал в РКК «Энергия». Первым программистам, осваивающим персональные компьютеры, было предложено делать это с использованием PL/1. Тем более, что при этом можно было перенести свои программные заделы с ЕС ЭВМ, в то время широко использующимися на предприятии. По мере получения все новых и новых компьютеров и появления «простых» языков для них, на предприятии стали отказываться от программ для ЕС ЭВМ и PL/1. Лишь одно подразделение в РКК «Энергия» решило сохранить на персональных компьютерах первоначально использованную систему программирования. Решение о поддержке системы программированияРешение о сохранении и собственном сопровождении имеющейся системы программирования на языке PL/1 определялось высокой оценкой качества этого продукта. На фоне тогдашних примитивных средств он выглядел наиболее развитым и профессиональным. Кроме этого, сам язык отлично подходил для выражения широкого спектра инженерных задач, решаемых подразделением, был хорошо знаком, и, изначально имея большой потенциал, выглядел перспективно в части последующего развития своими силами. И, конечно, при этом принималось во внимание, что имеющийся транслятор скоро морально устареет, а новых поставок может не быть. Как собственно, с учетом гибели самого Килдэла в 1994 году, и произошло. Поэтому именно собственное и независимое развитие системы по мере прогресса персональных компьютеров и их ОС изначально определялось как главная задача на длительную перспективу. Хотя попутно и быстро должны были быть решены мелкие проблемы вроде «русификации» или устранения ряда ошибок и ограничений, затрудняющих эксплуатацию системы. Реализация этой задачи осложнялась отсутствием профильных и специально выделенных для этого специалистов. Поэтому все работы велись имеющимися сотрудниками и в «фоновом» режиме, параллельно основной деятельности. Но при этом все новые результаты развития системы немедленно внедрялись в проектах, разрабатываемых в подразделении. Получение копии работающей системыНа первом этапе была выполнена самая простая и формальная часть работ по получению собственной системы программирования – дисассемблирование и получение исходного текста на языке ассемблера, трансляция которого позволяла восстановить точную копию исходного продукта. Несмотря на примитивность средств, существовавших тогда для подобной обработки, эта работа не заняла много времени и не потребовала высокой квалификации исполнителей. Полученный формально ассемблерный текст позволял после некоторого анализа уже вводить незначительные исправления, вроде разрешения символов кириллицы, которые в исходном варианте воспринимались как управляющие символы, из-за чего в программах по-русски нельзя было писать даже комментарии. Первые же изменения, которые меняли размер исходных программ, становились заодно и комплексной проверкой правильности дисассемблирования, поскольку меняли всю относительную адресацию внутри программ. После этого полученные копии уже нельзя было формально сравнивать с исходными вариантами на строгое совпадение. Правильность работы копий теперь стала проверяться на коллекции тестов, составленных в основном из реальных программ подразделения, причем написанных в разное время и разными программистами с разными стилями. В результате все созданные копии транслятора и других утилит, получаемые трансляцией ассемблерных текстов, стали тщательно проверенными полными функциональными аналогами исходных продуктов и сами транслировали систему тестов точно так же, хотя уже имели внутри себя несколько отличий от исходных и не совпадали с ними строго в двоичных кодах. Таким образом, был построен только фундамент для получения собственной системы программирования. Считать ее уже реально своей было нельзя, поскольку основная часть транслятора и утилит, входящих в средства программирования, по-прежнему оставались «черными ящиками», для которых были понятны лишь входные и выходные данные. Анализ ассемблерного текстаОсновной объем работ по созданию собственной системы программирования пришелся на анализ и составление комментариев к дисассемблированным текстам. Для удобства и повышения производительности такой анализ тогда происходил по распечаткам, без необходимости постоянно находиться за компьютером. На распечатках делались пометки к проанализированным фрагментам, после чего эти пометки переносились в файлы с ассемблерными текстами как комментарии и сами становились частью ассемблерного текста. По мере получения новых распечаток на них становилось все больше и больше комментариев, которые, в свою очередь, облегчали последующий анализ.
Важную часть комментариев составляли не собственно описания выполняемых действий, выделение структуры программ, т.е. заголовки частей, подпрограмм и т.п. По мере накопления числа таких комментариев структура транслятора и остальных компонент становилась все более ясной. Будущие исправления становились также все более безопасными с точки зрения возможности внесения ошибок, поскольку становились все более понятными границы фрагментов, которые затрагивали вносимые исправления. Работы по анализу и написанию комментариев велись постепенно и в «фоновом» режиме, растянувшись на несколько лет. В результате было получено детальное описание на русском языке (примерно 30 тысяч строк) транслятора с такого развитого и сложного языка как PL/1. Пример фрагмента текста с комментариями приведен на рис. 1. Даже нельзя было определить момент времени, когда система программирования стала настолько понятной, что ее справедливо уже можно было считать собственной. Формально это произошло тогда, когда в ассемблерном тексте не осталось необъясненных мест, но реально можно считать таким моментом успешное проведение существенных доработок, радикально меняющих исходный вариант. К таким доработкам относятся, например, переход с 16 разрядов на 32 (а затем и на 64) или переход от MS DOS к Windows 98, и затем к Windows-7 и 10. Такой длительный, детальный и аккумулируемый анализ построения транслятора позволил достаточно быстро найти и исправить ряд ошибок и ограничений исходного варианта, перевести тексты сообщений на русский язык, а затем приступить к выполнению главной задачи – продолжить развитие исходного транслятора применительно к уже новым условиям. Но при этом процесс внесения комментариев не прекратился. Основное внимание теперь стало уделяться четкости формулировок, исправлению неудачных комментариев, и, конечно, комментированию новых возможностей. Чтобы сохранить детальность описания, было решено не переводить текст с ассемблера на язык высокого уровня (например, на тот же PL/1), но постоянно проводить упрощение структуры и приведение ее к линейному виду за счет «раскрытия» вызовов подпрограмм, исключения передачи параметров не через регистры и т.п. улучшений. «Исходный» ассемблерный текст продолжал постоянно проясняться, упрощаться и сокращаться, что приводило к уменьшению размеров транслятора и одновременно к увеличению скорости его работы и получению более эффективного кода транслируемых программ. В результате получился такой совершенный исходный текст, который невозможно было бы получить трансляцией ни с одного языка программирования. С другой стороны, этот текст невозможно было бы в таком виде написать «с нуля» на ассемблере, поскольку тогда пришлось бы продумать сразу огромное число взаимосвязанных деталей. Исходный вариант позволил избежать таких работ «с нуля», т.е. на самом сложном и трудоемком начальном этапе освоения. Точно такой же подход был применен и к системной библиотеке, она также была дисассемблирована. Системную библиотеку можно считать неотъемлемой частью и продолжением языка, для удобства анализа ее текст даже печатался как единый вместе с текстом транслятора. Все приемы анализа и оптимизации, примененные к транслятору и утилитам, использовались и для системной библиотеки. Развитие возможностейБыстрый рост вычислительной мощи и объема памяти персональных компьютеров, постоянное появление новых возможностей в виде многоядерности или 64-разрядной адресации потребовали и соответствующего развития системы программирования. Поскольку уже давно не поддерживаемый исходный вариант предполагал работу лишь на процессорах 8086 под управлением MS DOS 1.0, принципиально новые расширения могли быть выполнены только самостоятельно. Именно в этом проявилась независимость, ради которой и были проведены описанные выше работы. С каждым появлением в подразделении компьютеров и ОС следующего поколения проводились соответствующие доработки программных инструментов. В существенной мере развитие облегчалось потенциальными возможностями самого языка программирования. Например, в нем можно прямо указать разрядность используемых объектов, поэтому, в частности, перевод с 16-ти разрядной на 32-х и на 64-х разрядную среду не требует ввода новых понятий, поскольку такая возможность увеличения разрядности предусматривалась с самого начала. С другой стороны, процесс развития потребовал внесения изменений и в сам язык программирования. И в этом была проявлена независимость, поскольку обычно российские программисты не могут повлиять своими предложениями на изменение зарубежной системы программирования, а тем более языка. Всегда необходимость внесения тех или иных изменений определялась не умозрительно, а в процессе разрешения конкретных проблем, возникающих при создании и эксплуатации программ, разрабатываемых в подразделении. Для оптимизации и постоянного повышения эффективности уже существующих программ, периодически анализировался на разных программах генерируемый данной системой код и сравнивается с кодом похожих программ из других систем программирования. Некоторые удачные приемы, обнаруженные в других системах, были успешно внедрены в сопровождаемый транслятор. Отдельно следует отметить русификацию системы, как одну из важных и необходимых доработок в процессе развития отечественных средств. В данном случае стало можно пользоваться кириллицей в программах совершенно свободно. А поскольку в языке ключевые слова не зарезервированы, стало поддерживаться одновременно и русское и латинское их написание. В результате уже существующие программные тексты можно не менять, а новые программы можно писать, в принципе не переключаясь с кириллицы на латиницу (см. рис.2.). На результат трансляции это не влияет.
Перечень доработок языка в процессе развития системы программирования приведен в статье «К вопросу о совершенствовании языка программирования». Проблемы стандартизацииСтандартизация языка программирования зачастую вступает в противоречие с процессом его развития, поскольку требуются изменения и дополнения, изначально не учтенные в стандарте. Иногда это даже побуждает создавать новые языки программирования, которые после принятия их стандарта сами могут становиться тормозом на пути дальнейшего развития программирования. Обычно законодателем мод является ANSI (American National Standarts Institute), несмотря на наличие формально более представительной ISO (International Organization for Standartization). У отечественных программистов практически нет механизмов влияния на эти организации. Еще сложнее обстоит дело с выпуском отечественных стандартов. При отсутствии собственных разработок, даже если ГОСТы и были бы выпущены, то могли бы быть только кальками с западных, иначе формально получится, что все используемые зарубежные средства (а своих нет) не соответствуют ГОСТам. Но стандарт, копирующий западный, по определению не предполагает независимого отечественного развития. Поэтому появление отечественных ГОСТов, не совпадающих с западными, будет признаком восстановления собственных разработок. В конкретном случае развития системы на языке PL/1, старались учитывать уже существующий стандарт языка ANSI X3.74 (он же ISO 6160), но больше придерживаться «духа», чем «буквы» стандарта. Это можно проиллюстрировать на примере даже незначительных изменений, внесенных в транслятор, в рамках его развития. Например, в стандарте языка есть две формы встроенной обратной тригонометрической функции арктангенса: возвращающей результат в радианах (ATAN) и в градусах (ATAND). Но две другие встроенные функции арксинуса и арккосинуса имеют только одну форму ответа – в радианах, что и неудобно и выглядит нелогично. В транслятор были добавлены две дополнительные встроенные функции, имеющие по аналогии с ATAND имена ASIND и ACOSD. Формально эти функции нарушают стандарт. Но, во-первых, программы, написанные в строгом соответствии со стандартом, продолжают транслироваться без ошибок (если в программе уже были использованы такие имена – новые функции «отключатся»), а во-вторых, легко догадаться, что делают эти «нестандартные» функции. В результате стало меньше исключений из правил. Не требуется ждать, будут ли введены такие функции в стандарт ANSI. Причем в этом конкретном случае, большинство программистов интуитивно считают, что у каждой тригонометрической функции и должно быть обязательно две формы, поэтому никаких трудностей и недоразумений от внесения этого изменения не происходит. Преимущества и недостаткиГлавное преимущество и главный недостаток собственной системы программирования тесно связаны и вытекают друг из друга. Это необходимость работ по сопровождению. С одной стороны, сопровождение и дает возможность независимого развития программного инструмента в соответствии с собственными представлениями и применительно к конкретным задачам, стоящим перед подразделением. С другой стороны, требуется иногда трудоемкий поиск ошибок и отслеживание постоянно меняющейся программной среды (ОС), причем на самом низком ассемблерном уровне, для которого часто нет доступной документации. Появление ошибок также связано с внесением все новых и новых возможностей. Обычно после устранения ошибки, программа, выявившая эту ошибку в трансляторе, вносится в систему тестов, чтобы в дальнейшем автоматически проверять проблемное место при очередных изменениях транслятора. Решение сохранить текст в виде ассемблерных команд закрепило зависимость от одной архитектуры процессора – Х86. Однако, эта архитектура оказалась настолько популярной, что вот уже более 25 лет такая зависимость не вызывает особых проблем. Например, даже в отечественный микропроцессор «Эльбрус» введен аппаратный блок перевода команд архитектуры Х86. В отличие от зарубежных систем, генерируемый код незнаком создателям компьютерных «вирусов», что является даже некоторой дополнительной защитой. С другой стороны, он также незнаком и создателям антивирусов, что иногда приводит ложному обнаружению «зараженности». Имея хорошие стартовые условия в виде грамотно созданного транслятора и языка с богатыми возможностями, удалось добиться того, что поддерживаемая система программирования на протяжении уже длительного времени развивается, не уступая, а по некоторым параметрам и превосходя зарубежные системы. Например, результаты выполнения известного теста Д. Кнута у данной системы оказались наилучшими. Связь с операционной системойСохранение исходных текстов на низком ассемблерном уровне сделало систему явно зависимой от типа используемой ОС. Однако в реальности такая зависимость оказалась сравнительно небольшой. Так, для операторов языка связь с ОС происходит не прямо, а через системную библиотеку, которая имеет внутри себя всего полтора десятка вызовов системных функций вроде чтения или записи файла, запроса времени часов компьютера и т.п. Поскольку эти вызовы у разных ОС (например, у Windows и Linux) весьма схожи, не представляет затруднений изменение в нескольких местах системной библиотеки. Т.е. при сохранении архитектуры х86 смена ОС сводится всего лишь к нескольким исправлениям в ассемблерном тексте системной библиотеки. Разумеется, и в самих программах может быть явное обращение к функциям ОС, в таком случае при смене ОС необходимо менять и тексты программ и, возможно, генерацию в трансляторе команд передачи параметров, а не только системную библиотеку. Но это случай явной зависимости от ОС, одинаковый для любых систем программирования. Сам транслятор и утилиты как выполняемые программы также имеют внутри себя несколько вызовов системных функций и точно так же могут быть переведены на другую ОС, при условии сохранения архитектуры х86-64. ЗаключениеОписанная выше система программирования может считаться примером отечественной разработки, несмотря на то, что первоначально была создана в США. По мнению автора, работы, подобные приведенным в статье, должны были бы быть проведены в Советском Союзе еще в середине 70-х в части системного ПО ЕС ЭВМ для возможности дальнейшего уже независимого развития в следующие 10—15 лет. Однако этого сделано не было, что привело фактически к отказу от развития собственных средств и к все увеличивающейся зависимости от зарубежных разработчиков. Массовое внедрение американских персональных компьютеров в мировом масштабе, а затем и распад Советского Союза еще больше осложнил процесс независимого развития средств программирования, хотя необходимость такой независимости становилась все более очевидной. Объективно, в середине 80-х независимость средств разработки и не могла быть создана в нашей стране. Однако впоследствии оказалось, что по классической схеме копирования можно сравнительно небольшими силами создать и развивать свой продукт. В данном случае «копирование» — это условное обозначение дизассемблирования и анализа выполняемых команд. Именно письменно зафиксированные (в виде комментариев) результаты детального анализа постепенно позволили настолько полно изучить работающую систему, что стало возможно вносить любые, в том числе принципиальные изменения. Именно множество детальных комментариев стало тем барьером, преодолев который «чужой» продукт стал «своим». Далее можно было уже не оглядываясь на зарубежных разработчиков (но, постоянно находясь в курсе современного развития средств программирования) отслеживать прогресс аппаратной части и системного ПО применительно к конкретным прикладным задачам. Успешное выполнение данным инструментом всех программных проектов подтвердило правильность выбранного подхода. Разумеется, только лишь один удачный инструмент в одной организации не сделает нашу страну независимой в части средств разработки ПО. Он может и должен стать лишь одним из «кирпичиков» в трудном процессе создания по настоящему независимой отрасли информационных технологий. Автор: Д.Ю.Караваев. 2016 год. Опубликовано: 2022.02.17, последняя правка: 2022.02.18 18:39
Отзывы
независимая разработка средств программирования общего назначения сильно сократилась после успешного создания системного ПО для ЭВМ БЭСМ-6 и вычислительного комплекса «Эльбрус». БЭСМ-6 и «Эльбрус» (и ПО для них) создавались в разное время. Это сокращение происходило в 2 этапа, одно — после БЭСМ-6, второе — после "Эльбруса"? Но "Эльбрус" начали разрабатывать после начала внедрения ЕС! Одно другому не мешало!решающую роль в этом сыграло принятое ещё в 1969 году решение разрабатывать семейство ЭВМ следующего поколения, совместимое по командам с американской ЭВМ IBM/360. получение готового ПО … считалось допустимым и позволяло сэкономить большие человеческие и финансовые ресурсы. Это действительно было так. В американской экономике было на порядок больше денег, чем в СССР. И количество программистов тоже было больше на порядок. Тяжело было тягаться.Надо сказать, задача «догнать и перегнать», по большому счёту, была сформулирована даже не Хрущёвым, а Петром I. Уже с тех времён начали заимствовать западные наработки. Да что там Пётр? Ещё раньше русские князья нанимали китайских специалистов по осадной артиллерии. стратегический просчет был не в решении использовать готовое ПО, а в том, что после этого не было выделено достаточно сил и средств, чтобы создать свои аналоги Всё по тем же причинам, перечисленным выше.И если для комплекса «Эльбрус» были разработаны превосходные собственные средства программирования, причем «с нуля», т.е. решена гораздо более сложная задача, то для ЕС ЭВМ не была выполнена даже более простая задача самостоятельного развития средств разработки после изучения существующего системного ПО. Неправда ваша. В стенах ЛГУ был разработан транслятор Алгол-68, первый в мире, если не ошибаюсь, соответствующий стандарту этого языка. Чисто наши пакеты прикладных программ «Примус» и «Фокус» — «Нортон-коммандер» на наши деньги. Лисп, Форт собственной разработки. Свои самобытные языки и системы программирования типа Рефал, Эпсилон и Сигма. Это то, что знаю я, не будучи цифровым археологом.Просто разработок было мало в силу бедности (см. выше). Деньги уходили на содержание Африки (сколько советских долгов простили странам «некапиталистического пути развития»?), на поворот сибирских рек в Среднюю Азию, на постройку «Бурана», слетавшего всего один раз. А вот на ИТ денег в нужном количестве не нашлось. На «Военном обозрении» есть целый цикл статей, посвящённый истории развития отечественной ВТ. Автор — Алексей Ерёменко. В его материалах есть существенный недостаток — они пропитаны антикоммунизмом, такая идеологическая заряженность порою раздражает и отвлекает от собственно истории ВТ. Так же чувствуется, что он специалист по «железу», но надо отметить, что очень хороший специалист. Но вот о софте пишет крайне мало, видно, что это не его. Не меньше десятка академиков попали в его материалы, но все они — «железячники», а вот о «главном по софту» академике Ершове — ни слова. Так вот история появления ЕС ЭВМ там хорошо описана. Эх, чешутся руки прошерстить материалы по «предательству века» — переходу на ЕС ЭВМ. Жаль тратить время на это. Ведь в этом «предательстве» зачастую герои и антигерои — одни и те же лица. Например, Пржиялковский, главный конструктор ряда ЭВМ серии «Минск», стал генеральным конструктором ЕС ЭВМ. Ну что тут говорить?
Например, в стандарте языка есть две формы встроенной обратной тригонометрической функции арктангенса: возвращающей результат в радианах (ATAN) и в градусах (ATAND). Но две другие встроенные функции арксинуса и арккосинуса имеют только одну форму ответа — в радианах, что и неудобно и выглядит нелогично. В транслятор были добавлены две дополнительные встроенные функции, имеющие по аналогии с ATAND имена ASIND и ACOSD. Да среди библиотек есть стандартные, которые скорее всего понадобятся. Но всё равно котлеты и мух лучше разделить. Когда-то существовало деление языков на «язык-ядро» и «язык-оболочка». К первой категории относили языки, в которых язык был отделён от библиотек. Ну а PL/1, Бейсик относили ко второй категории. Сейчас такая классификация не в ходу, поскольку практически все современные языки можно отнести к «языкам-ядро». Поскольку эти вызовы у разных ОС (например, у Windows и Linux) весьма схожи, не представляет затруднений изменение в нескольких местах системной библиотеки. А не ставится задача перевести наш сегмент МКС на «импортозамещающую» ОС?
Важно иметь не только собственные средства разработки. Надо ещё обладать компетенциями в их создании. У нас ведь с развалом науки и промышленности СССР исчезли компетенции вместе с их носителями. Поэтому по-хорошему надо бы дотировать или финансировать через госзаказ как разработки, так и разработчиков. Ну вот и славно, крайних назначили, можно идти халтурить дальше.
А не ставится задача перевести наш сегмент МКС на «импортозамещающую» ОС? А зачем? Это специализированный компьютер со специализированной ОС (по-моему, на базе Соляриса). Он все 20 лет не меняется. Другое дело — т.н. компьютеры экипажа (обычные ноутбуки для повседневных работ). Первый вариант ПО был собран в октябре 2000 года. Вспомните, какие компьютеры (мощность и интерфейсы) были тогда и какие — сейчас. Все изменилось и многое радикально. Поэтому и приходится регулярно менять ПО.Бурановскому дедушке Сложный вопрос про трудоемкость. Я впервые сел за ПК 12 февраля 1987 года (35 лет прошло). Можно сказать, что потрачено не менее 35 человеко-лет. Но на самом деле это был фоновый и иногда почти незаметный процесс. Первые 2-3 года не ставилась задача развития компилятора. Требовалось эффективно решать задачи, а для этого нужно было устранять ошибки, а для этого нужно было разбираться в трансляторе. Сначала пришло понимание, что новой версии транслятора от Килдэла мы никогда не получим. Затем решение сделать ассемблерный текст и вносить исправления по-человечески, а не в нулях и единицах. И только, когда исправлений накопилось много — решение все взять в свои руки. В сумме за эти 35 лет, наверное, 3 человеко-года. Сколько потратил Килдэл? Из его книги следует, что около человеко-года на PL/I-80 для 8080 и ещё столько же, на мой вгзляд, на PL/I-86 для 8086. Но у меня есть сомнения, что он все делал с нуля. До этого около 5 лет он сопровождал компилятор IBM в военно-морском институте, а может быть даже что-то имел и из текстов. Во всяком случае, он имел опыт создания компилятора PL/M, Выделение в самостоятельное подразделение в наших условия было совершенно невозможно. Просто профиль НПО, а затем РКК не позволял. Безубыточность — это что-то эфемерное. Как вообще можно оценить безубыточность конструкторского бюро? Зато мы имели самую сильную обратную связь, поскольку сами и являлись (сначала единственными) пользователями своего транслятора. Ошибки исправлялись быстрее всего (не на базар несем, а для себя стараемся). Так как наше подразделение формально не имеет отношение к программированию (тем более, к средствам программирования, хотя в штатном расписании есть и инженеры-программисты и инженеры-математики), руководство никогда не интересовалось и не вмешивалось в эти дела. Ему и без этого забот хватает. А результат мы даем, поэтому можно считать эти работы безубыточными.
Но на самом деле это был фоновый и иногда почти незаметный процесс...
16 февраля был опубликован тендер на сумму 510 000 000 рублей на разработку отечественной унифицированной среды, заявки принимаются до 4 марта, итоги будут подведены 11 марта. Начало работы — апрель 2022 г., окончание работы — декабрь 2024 г. Цитирую техническое задание:Набор инструментов для обеспечения разработки безопасного ПО должен поддерживать языки С, С++, Java. В ходе определения номенклатуры базового набора должен быть выбран хотя бы один интерпретируемый язык программирования с динамической типизацией, разработка на котором должна быть поддержана Унифицированной средой.
Непонятно, на основании чего было решено выбрать именно эти языки. Это-то понятно. Ведь, результатом этого попила всяко будет очередная пиратская сборка LINUX.
А ведь следующий тендер на полмиллиарда рублей, где бы мог получить свой шанс тот же компилятор PL/1-KT, будет нескоро. Да ведь PL/1-KT и не требует полмиллиарда и 2024 года ))На мой взгляд, это беда нынешних управленцев. Они искренне уверены, что если дать "много денег", то все будет сделано. А ведь кроме денег ещё много чего требуется
На мой взгляд, это беда нынешних управленцев. Они искренне уверены, что если дать "много денег", то все будет сделано. Важна лишь как раз возможность дать "много денег" кому нужно и сгенерировать много отчетов. Проекты как сэкономить бюджет у них очень непопулярны. Можно сравнить с проектами, на которые тратит деньги DARPA.Непонятно, на основании чего было решено выбрать именно эти языки. Когда был тендер, на котором победили именно эти языки? Вполне логично для импортозамещения на основе GNUсной копипасты.
«Пиратская сборка LINUX» звучит как «ворованный воздух». И воздух, и Linux дармовые. kt Они искренне уверены, что если дать "много денег", то всё будет сделано. Чтобы вырастить культурный слой, нужно много времени. Деньги хорошее удобрение, но недостаточное. Как говорят англичане: для того, чтобы стать интеллигентом, надо получить три высших образования: тебе, твоему отцу и твоему деду.
«Пиратская сборка LINUX» звучит как «ворованный воздух» Однако, как ни слабы ограничения GPL, "создатели" МСВС умудрились их нарушить.Чтобы вырастить культурный слой, нужно много времени Думаю, без этого обойдется. Еще немного и программирование будет признано уголовным преступлением. И будем паять свои нелегальные палмы и подключать их втихаря к офисным станциям, домашним кинозалам и домашним телефонам.
И на каждом шагу автор восклицает: простые паяльники! Даже не паяльные станции! Как будто все было завалено паяльными станциями и вот только ЗЭМЗу не подвезли. И посыл таких статей всегда один: главный предмет статьи (в этом случае Эльбрус) фуфло, а вот другие (Сетунь, БЭСМ-10, М13, нужное подчеркнуть) ого-го. И вообще всё строго содрали по американской документации, кто технический английский освоил — тот и разработчик. А новое в совке приходится искать методом проб и ошибок. Как будто новое можно найти другим способом.
А вот когда Гусев показывал фото, где он и другие разработчики советской супер-ЭВМ убирает на полях картофель, работает на овощебазе и участвует в сенокосе, то тут всё по Станиславскому: «Верю!». Из песни слова не выкинешь. Сам участвовал в битвах за урожай, есть собственные фотографии. Такая кривая экономика обречена, если квалифицированные специалисты занимаются чужой неквалифицированной работой.
Такая кривая экономика обречена, если квалифицированные специалисты занимаются чужой неквалифицированной работой. Наоборот. Как говорили в армии: "Если отдых, то активный, если праздник, то спортивный". Теперешнее поколение диванных IT-шников, неспособных поднять ведро картошки, и не понимающих прелести коллективного ковыряния в грязи под дождем, просто потеряло связь с реальной жизнью.
этот вопрос тесно связан с безопасностью страны Год назад я держал в руках процессор отечественного стартапа Maltsystem, произведённого TSMC по нормам 28 нм. Его директор с энтузиазмом мне говорил, что скоро они перейдут на 16 нм. Теперь это накрылось медным тазом, TSMC присоединяется к санкциям. Что хорошо предсказывалось и просчитывалось. На одном из каналов Яндекс Дзена как-то писали, что ВВП так просчитывает свои действия, что санкции вводятся только тогда, когда мы становимся к ним готовы. Увы, и «Байкалы», и «Эльбрусы» с фабрик TSMC к нам больше не придут. Вывод: в электронике тоже необходимо самостоятельное развитие. Это тоже безопасность страны.
Такая кривая экономика обречена, если квалифицированные специалисты занимаются чужой неквалифицированной работой. Такова, видима, была квалификация тех инженеров, неспособных эффективно автоматизировать или хотя бы механизировать элементарный труд.В том-то и дело, что это не было отдыхом. И даже не субботником. Инженеры, вместо того, чтобы начать производство «Эльбруса», которое многократно срывалось и переносилось и в итоге началось на несколько лет позже запланированного, — делали работу, которую может выполнить каждый. Разбрасывались людьми дефицитнейших специальностей! Нет, если в выходной день, с хорошим настроением — то что в этом плохого? А вот если это было вместо инженерной работы, то увы — это не красит советский строй. В капиталистическом принято разрушать какие-нибудь страны, чтобы получать готовых собирать урожай. Красота!
Да, неприязни им высказано много. Пришлось обходить такие места при чтении. Но чувствуется, что он специалист в своём деле. Я в этой отрасли знаний противопоставить ему ничего не могу, оспорить не в состоянии, за исключением нескольких моментов. Но с другой стороны, если он такой специалист, то почему о нём ничего не известно? Я специально гуглил его имя и фамилию, но результатов ноль. Человек в памяти человечества следа не оставил. Вот и возникает вопрос: если ты так смело критикуешь Лебедева, Бурцева, Бабаяна, то ты сам-то чем известен? Где твои творения, которые можно было бы разглядеть и покритиковать, найти соринку в глазу? Да он не столько «Сетунь» хвалит да 5э53, сколько американские Burroughs, Cray, IBM. И их политическую систему, которая вроде как инновации стимулирует, а совок гнобит. Поэтому в его статьях больше интересны исторические факты и технические детали. А вот склоки, кто кого подсидел, лучше пропускать мимо ушей.
Конец подачи заявок — 4 марта. За день до этого была подана одна-единственная заявка за 423 миллиона. Она и признана победителем. Кто это — неизвестно. Вероятно, по условиям тендера сразу нельзя объявлять имя счастливого победителя. Интересно не имя победителя, а что он реально предложил в части языков ))
Но вот наступило время второго прочтения. В новой реальности JetBrains покидает нас вслед за другими. Теперь ясно, что это не JetBrains. Ждём имя победителя и его предложение.
Интересно не имя победителя, а что он реально предложил в части языков )) Список языков вполне предсказуем. Неужели Вы рассчитывали увидеть в нём PL/1, Modula-2, или ADA?
Написать автору можно на электронную почту |
2022/02/17 23:50, Автор сайта