Воспоминания о языках программирования в авиации (и не только)

Вы таки будете смеяться, но на моей памяти настоящую конкурентную многопоточность в рамках одной программы под DOS обеспечивала только Ада. У Модулы-2 и Схемы были сопрограммы.

Но это если надо было прямо из бочки. А так - кто угодно мог сесть на INT 8 и вручную переключать контексты. Ну или на другое прерывание. Я (в силу специфики задачи) использовал прерывание от принтера.
 
Вот я и говорю, что доступных альтернатив не было. (А конкурентность, кстати, в системах реального времени скорее зло, чем преимущество.)

Я тогда наукой занимался, и результатом моей работы были публикации, но не открытого кода. А автоматизация эксперимента была побочной задачей, причём третьеочередной. Если бы я тратил время на ручное переключение контекстов опроса вольтметров и управления регуляторами температуры, мой руководитель меня бы совершенно справедливо убил.

Ну да ладно, раз уж соблазнили написать в эту ветку, вспомнив моё увлечение юности, покажу вам про мой любимый паскалеподобный Алгол-60-подобный язык:


На его первой версии (когда у меня ещё детей не было и времени свободного было полно) я программировал домашнюю автоматизацию под дешёвые 8-битные однокристаллки, которые можно спаять на коленке: управление разноцветной светодиодной подсветкой, поливом газона, зонами терморегулирования дома.

 
А вот есть ещё такой язык Brainfuck, относящийся к категории эзотерических языков программирования. Ну, т.е. типа прикол такой. Прикол-то прикол, но язык, состоящий всего из 8 команд, обладает тьюринговской полнотой, т.е. на нём можно теоретически запрограммировать практически всё.
Есть ещё Ook! - это язык программирования для орангутанов, ну и другие. И они, между прочим, работают.
 
Минск 22 кто-нибудь помнит?
 
Почему она должна быть мертва? Лет 10 для производства написал программу на Делфи. А спустя несколько лет другому инженеру нужно было добавить в нее небольшой функционал, и он довольно легко это сделал. . А парень был примерно 90х годов рождения.

Сегодня потребность рынка в скриптах гораздо выше. Очень часто нужна кроссплатформенность и запуск в браузере кажется более простым решением. И тут, конечно, Делфи не у дел.

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

Кто то конечно говорит, что вот структура вида if...elseif...elseif...else - это великое зло. А если в языке есть go-to, то это язык деклассирует. Но это, кажется, занудные бредни.

Качество же машинного кода, полученного из программы, оно, в значительно степени, зависит от качества компилятора. И сильные компиляторы где-то умеют серьёзно анализировать и оптимизировать, а где-то просто "переписывают".
 
И всё интересное, что на них можно было написать, уже написано - ещё в прошлом веке.
 
Реакции: SDA
Какое преимущество языка по сравнению с машинным кодом, если Вы пишете для единственного процессора, и программа нигде больше использована не будет? (Рабочая лошадь "Промiнь-М", курсовая и диплом для первой жены). "МИР" - для приколов. "Раздан" - для зачета по программированию.
Автоудаление.
 
Такое же, как у использования машины для вычислений вместо вычисления вручную - но уровнем выше.
 
Уверены ли Вы, что у Вас будет преимущество, если и компилятор и программу писать будете Вы?
Автоудаление.
 
Почему не взять имеющийся компилятор (и дописать ему кодогенератор, если машина почему-то действительно уникальна в наборе инструкций)?
 
Если понадобиться "Руководство разработчика ПО" от Интел (более 5 тысяч буржуйских страниц, март 2025 г.) то это у меня есть. Могу поделиться.
Автоудаление.
 
Последнее редактирование:
Надо было мне задействовать библиотеку (драйвер опроса ЦАП/АЦП), написанную на С++ и вызов шёл из Lazarus да ещё в Линуксе. Так вот обычная вроде бы задача - сделал вызов и всё, а не тут то было. Вызов процедуры был перегружаемым с разными входящими параметрами с одном именем. Так вот весь миф о стандартизации языка С++ для меня пошла прахом, ибо это полная фигня - и многие вещи реализованы в каждом компиляторе как на душу положено программистам и какая на небе была луна. Да, перевернул кучу литературы по С++ чтобы понять в чём фигня, хорошо была библиотека в исходнике, написал вызов процедуры черес чистый С и о чудо, всё заработало как надо! Так в чём дело было во мне или в чуде компиляторе? И таких проблем с библиотеками, когда не понимаешь как это работает, пока не вкуришь нюансы работы через одно ректальное место - вагон и маленькая тележка...
ЗЫ. Lazarus это надстройка над GCC, код пишется как на Паскале, так можно директивно перейти писать вставки на С и Ассемблере...
 
Может потому, что как в ++, так и во всех остальных слишком много вольностей, которые компилятор прощает и всё это компенсируется пожиранием ресурсов - памяти, скорости процессора и т.п.? Более строгие языки принуждают использовать ресурсы более разумно...
 
Если смотреть на результат, то есть у меня неприятные сравнения из опыта работы с разными программами:
1. ОС - Андроид - закрытая, местами ущербная система. У меня с автомагнитолой по BT работает как придётся. При этом ресурсов пожирает прилично. Вариант от китайцев Harmony 3.0 на планшете - меньше имеет доступа к ресурсам, работает стабильно и без нареканий. С той же магнитолой коннект 100 % из 100 %.
2. Надо было мне смонтировать видео ролик. Начал смотреть видеоредакторы для Windows ... Практически все шлак, кроме одного единственного - это от Sony Vegas Pro. Написано вот такими паркуристами, работает с минимальными затратами ресурсов всех видов, результат на выходе выше похвал.
3. Ну про варианты американского ИИ и китайского Дипсик - тоже великолепный пример разного подхода к организации работы...
 
Поэтому они летали исключительно только в ручном режиме . Не, ну хотя бы почитайте воспоминания тех, кто создавал Буран и разработал языки программирования для космической техники. Для начала язык Дракон, который помог структурировать задачу и сократить трудоёмкость написания кода до приемлемых объёмов. Для начала - такая задача (написание и отладка кода на Ассемблере для 8 (!!!) параллельно работающих и проверяющих работу друг друга бортовых ЭВМ) не хватало всех кадров со всего СССР (поэтому Америка и не потянула в своё время эту задачу). Да и далеко ходить не надо - современные самолёты и системы управления очень далеки до уровня Бурана, хотя имеют мощности намного больше чем у него. Вон Боинг навернулся в количестве 2-х штук из-за простейшей ошибки работы датчиков...
 
Шаттл может в автоматическую посадку.
??? Когда ему это прикрутили? Всё время сажали вручную... А для последних шатлов компьютерные комплектующие искали по распродажам, ибо никто их не модернизировал под свежие релизы...