Если Ada такая хорошая, почему она такая мёртвая?

Сравнивать надо скорее с паскалем. В Go сборщик мусора есть.

Языки без автоматического управления памятью все мертвы, кроме C/C++. А те не мертвы только из-за огромного наследия.

Если Ada такая мёртвая, то почему ты считаешь её такой хорошей?

Потому что не пиарился. Все «немертвые» ЯП, которые мы сегодня знаем, являются таковыми исключительно по причине вбухивания неимоверного кол-ва бабла в пиар этих язычков.

Существует еще темная сторона программирования, где живут неизвестные ЯП и ада в их числе.

Она так не пиарилась что Nasa заставляла на ней писать прошивки для космоса. А ещё денег вбухивала.

Ну инженеры NASA и еще какие-то вояки ее использовали. Причем тут пиар в массы?

кроме C/C++. А те не мертвы только из-за огромного наследия

Как ты представляешь себе автоматическое выделение памяти и сборку мусора в условиях hard realtime?

Tiobe/pipl сообщают о новом росте популярности C, сомневаюсь, что только за счёт legacy.

Ну пиар был уровня «сверх надёжный яп что только его в космос пускают». Только вот эта сверх надёжность на Земле нафик никому не нужна.

Все равно не сравнить с тем же java или c++, где туча тучных (лол) амбассадоров ездили по конференциям и университетам и «продавали» свои поделия.

Еще за счет IoT. Хотя особо одаренные на питоне их программируют.

Как ты представляешь себе автоматическое выделение памяти и сборку мусора в условиях hard realtime?

JamaicaVM

Если мне не изменяет склероз, то там был не пиар, а приказной порядок. Ada был создан как язык для военных (и около того) разработок. И был обязателен к применению в таковых разработках.

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

Пример проплаченного пиара – это рекламная компания от Sun вокруг Java во второй половине 1990-х. Непроплаченного – это хайп вокруг Rust-а сейчас.

С Ada, емнип, ничего подобного не было.

Тут изредка появляются ораторы, которым умный мальчик Вовочка сказал, что Ada (Haskell, Lisp, Oberon) хороший изык, а взрослые дяди то и не знают о нем. Взрослые дяди на самом деле знают. А не применяют , потому что не нужны.

В мишон-критикал эмбеде дрочить память туда-сюда вообще-то антипаттерн :) итого: сборка мусора нужна лишь тем, кто «дуинг ит вронг»

Когда оно будет удовлетворять Do-178, тогда приходите :)

Только вот эта сверх надёжность на Земле нафик никому не нужна

Т.е. тебе не нужно стабильное электроснабжение хотя бы? Ок :) тред переписи ценных мнений

Так если динамически не получать память, то и сборщик мусора будет O(1) в любом языке.

Просмотрел, не понял, а чему именно оно в Do-178 не удовлетворяет?

А не применяют , потому что не нужны.

Так в этом и вопрос. Чем именно язык настолько хуже, что не нужен.

Не. Я сам пишу под мк по спартански. Без malloc и fpu. Ещё Misra-C применяю. Стараюсь писать мега надёжно.

Нашёл некоторые варианты ответа в комментах, например:

In the early 90’s I did a lot of Ada programming and grew to hate the language. It would have been Ada83 and it felt like the worst example of design by committee; it was packed with every half understood (at the time) programming language idea making it feel bloated and half arsed at the same time. It had objects, but no inheritance, bizarre parallelism that was practically unusable, and the most over the top numeric types ever. The compilers of the time were «certified» by listing all the many ways they failed to fully implement the standard.

However, its memory management (and verbosity when doing it) worries me a little for general use. While we all complain about Java’s verbosity or Go lack of features, you can use an unbounded string (and in Unicode!) anywhere just by typing a few characters. Ada, on the other hand… (Ada.Strings.Unbounded.Unbounded_String… whatever).

The language does show its age when most data types suppose you will be using fixed size data structures. I tried porting a small program and got stuck fairly early because I couldn’t understand how memory management was supposed to work with complex nested and unbounded data structures. I still don’t get it but your post gave me some ideas… memory pools could be the solution.

Also, many of the features that we consider essential today were added recently, in 2005 or 2012. For example, auto-growable containers, the «i in 3 | 5 | 7 | 9 .. 11» syntax, conditional expressions, and maybe others. It’s 2019 now so I guess we can forget how the language was before 2005, but I can see how Ada was simply not there when PHP/Python/Ruby/Java/C# exploded in popularity.

А первые версии и вовсе вошли в фольклор так (jargon.net):

endorsement by fiat; designed by committee, crockish, difficult to use, and overall a disastrous, multi-billion-dollar boondoggle

Хоар в своей речи даже рассказал историю про голого короля, который извлёк урок и с тех пор все новые наряды нашивались на старый (в конце ему стало жарко и он вылез из под горы одежды, став свинопасом в другой истории).

Просто выделяешь всю, которая нужна и все :) Никакой сборщик не нужен вообще.

Когда Misra Go напишут, будет наверное удовлетворять :) «Не пользуйтесь вот этим и вон тем... А про это вообще забудьте!»

Просто выделяешь всю, которая нужна и все

Это понятно. Но если надо в памяти, например, дерево разбора хранить, то заранее под него память не выделить (структура ведь неизвестна).

У операционки-то память можно заранее забрать (например статическим массивом или calloc при запуске), но потом в этой арене всё равно придётся либо писать свой malloc/free либо свой сборщик мусора.

Ну у арены как раз сложность О(1). Во многих случаях её + статической аллокации всего остального может хватить.

Можно сделать аллокатор тупо на инкременте указателя и его сбросу в начальное состояние.

Например, пришёл пакет. Разобрали его на части, обработали. Больше нам результаты разбора не нужны, освободили всё разом вернув указатель на исходное положение.

Проблемы будут только если у нас есть структуры динамического размера со слишком разным временем жизни. Но это нужно ещё реже, чем динамические структуры вообще. Надо понимать, что embedded часто содержит не очень сложные алгоритмы, так как и памяти мало, и проц слабый.

Или не надо, или не придется :) Т.к. некоторый переиспользуемый пул — это чаще всего тривиально. Выделяется не произвольными, а заданными блоками под заранее известные вещи — «ноды» или «хэндлы» известных ресурсов (графические движки, например, можно так же программировать, просто муторно — «поддерживается вот стока объектов при таком объеме памяти, хочешь больше? правь конфиг сборки, но на меньшем объеме памяти не запустится, ибо нефиг» — да и буферы видеопамяти похожим образом выделяются, юзеру возвращается только хэндл, просто позволена слишком большая вольница с разметкой буферов в рантайме :)).

Ну и вот... в «пуле» ничего не удаляется, просто помечается как свободное.

Но чаще дешевле обсчитать все что требует обсчетов заранее — например, даже ракетам некая БЦВМ для приближения некой целевой функции не факт чо нужна (раньше-то обходились с известным набором оговорок и компромиссов), достаточно посчитанного хоть на логарифмических линейках «аналогового вычислителя» с обратной связью, «логика» в который зашита паяльником («лети вон за тем зайчиком от лазера»), а система управления вся вообще на земле в трех грузовиках или в «центре управления» с мощным передатчиком, если модель обсчета адекватная :)

А у встройки «задачи» вообще могут быть одним целым с OS (или тем что ее заменяет) в общем бинаре, каждая со своими заранее заданными ресурсами. Т.е. «произвольницы» общего назначения не предусмотрено вообще :)

Отказ от дрочки памяти взад-назад просто исключает предпосылки к «обычным» проблемам плохого проектирования — подпирание сложными (но недостаточно «умными») распределителями ресурсов «общего назначения» — т.е. того, что нельзя адекватно решить простыми средствами в общем случае, только в типовом наборе тривиальных, а для заранее известных случаев применения — там слишком много оверхэда, который можно выкинуть и заменить более простыми средствами вроде заранее посчитанного всего что можно заранее посчитать :)

Но чаще дешевле обсчитать все что требует обсчетов заранее

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

А в каком месте Ада хорошая?

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

Например, пришёл пакет. Разобрали его на части, обработали. Больше нам результаты разбора не нужны, освободили всё разом вернув указатель на исходное положение.

Это и на стеке работает. Но бывает, что пришёл пакет и целиком результаты разбора в память не помещаются. Тогда приходится освобождать частями по ходу разбора. И здесь уже свой менеджер памяти на арене с отметкой свободных блоков. А если момент освобождения не очевиден (на часть пакета могут быть ссылки из разных мест), то уже придётся делать свой сборщик мусора или на счётчиках в объектах (+ число в каждом объекте) или полноценный (+ проход по памяти раз в сколько-то итераций цикла).

Надо понимать, что embedded часто содержит не очень сложные алгоритмы, так как и памяти мало, и проц слабый.

Даже на 128 КБ можно написать достаточно сложную логику.

поддерживается вот стока объектов при таком объеме памяти, хочешь больше? правь конфиг сборки, но на меньшем объеме памяти не запустится, ибо нефиг

После появления чрезмерного выделения памяти (overcommit) запускается, но падает. Это, конечно, не про встройку, но всё таки.

Но чаще дешевле обсчитать все что требует обсчетов заранее

Это естественно. Если есть возможность заранее.

Отказ от дрочки памяти взад-назад просто исключает предпосылки к «обычным» проблемам плохого проектирования

Исключает. Но также исключает и решение значительного класса задач в фиксированном объёме памяти.

там слишком много оверхэда, который можно выкинуть и заменить более простыми средствами

Можно. Но эти средства имеют свой оверхед. Сам выбираешь, что важнее: потребление памяти или скорость. Заранее посчитанное почти всегда занимает гораздо больше памяти, чем алгоритм расчёта.

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

Если этого не наблюдается, то и особой надобности в инструменте нет. Пусть он трижды хороший и красивый

Даже на 128 КБ можно написать достаточно сложную логику.

Маргарет Гамильтон подтверждает.

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

Есть высокая скорость скомпилированного кода и отсутствие UB. Строго определённая семантика кода. Высокая скорость компиляции (по сравнению с Си++).

В 128к, даже в 32к атмеги лезет логика 3д принтера. Я не знаю что вы расцениваете как сложную логику но думаю что она частично там.

Всмысле rust непроплаченный? Его мозилла пиарила во все щели и как только деньги на пиар закончились, выкинула.

Тогда, возможно, придётся пожертвовать строгими гарантиями риалтайма. Или докинуть памяти.

Это как быстро, качественно, недорого. Или как CAP теорема. Всё и сразу получить не всегда можно, но и не всегда нужно. Нужно смотреть задачу реального мира.

Если это mission critical по то сервер должен быть в курсе что пакет не больше такого то размера, а если больше то будет или игнорирование пакета или спутник слетит с орбиты(условно говоря).

Даже без mission critical я бы так делал. Вот у меня stm8 с 8к флеша и 1к рамы. Я точно не буду пытаться впихнуть невпихуемое в память за счёт вело gc и при этом иметь шанс всё равно не влезть в печальными результатами. Протоколы попроще, пакеты поменьше.

Misra вообще запрещает malloc в любом виде. Только статическая аллокация

Это как быстро, качественно, недорого. Или как CAP теорема.

Именно так.

Даже без mission critical я бы так делал. Вот у меня stm8 с 8к флеша и 1к рамы.

Есть у тебя пакеты по 800 байт. Из каждого получается 500 байт нужной информации. Варианты действий:

а) при разборе надо память, занятую уже разобранной частью пакета, переиспользовать под результат разбора (типа сбор мусора вручную);

б) заменить микросхему на ту, у которой хотя бы 2К ОЗУ;

в) писать промежуточные данные на флеш.

Хотя при 1к рамы какой-то автоматизированный сборщик, конечно, не впихнуть.

Misra вообще запрещает malloc в любом виде. Только статическая аллокация

Угу. char pool[…] и mymalloc, который поверх этого массива данные размещает.

Тут ниже должна быть история с выкладками по деньгам, чтоб это твое голословное утверждение не было таковым, что там показала история кроме заднего ума «потому что так случилось» :) А причины коротких буферов были изначально другие: ограничения материально-технической базы и инженерные компромиссы. В 32Кб ты хоть усрись не сможешь воткнуть «безопасно запрограммированный» код со всеми проверками и зощитой от хакиров... Да и зачем? Особенно не актуальны переполнения буферов в отсутствие интернета и произвольного обмена данными в непредсказуемых количествах — по протоколам, которые не опубликованы где попало и добраться до которых могут или шпионы, или диверсанты, со всеми входящмими рисками быть схваченными и отхуяченными.

Заранее посчитанное почти всегда занимает гораздо больше памяти, чем алгоритм расчёта.

Нет :) Оно посчитано перед изготовлением в металле - как крыло самолета или ствол пушки. И не хавает ничего после изготовления :) Память и скорость обсчета — во внешней ЭВМ, которая все это посчитала на основе какой-то мат. модели :) Тут проблемка только в сроках пересчета и переизготовления. Но в изготовленном серийном образце никаких этих накладных расходов уже нет :)

Где гарантия что в процессе разбора ты не вылезешь за пределы пула? Статически доказать что памяти хватит элементарно. А если идут такие фокусы то функция разбора упадёт с oom и пакет проигнорируется. А вдруг там было что-то важное без чего дальнейшая работа невозможна?

Оно посчитано перед изготовлением в металле - как крыло самолета или ствол пушки.

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

А так понятно, что если есть возможность заменить микроконтроллер на аппаратное решение, то всегда лучше заменять.

Где гарантия что в процессе разбора ты не вылезешь за пределы пула?

Нет гарантий. Поэтому этот пункт в MISRA ничем не помогает. Разве что вместо NULL от malloc у тебя счётчик дойдёт до края этого пула.

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

Не понял. В каком случае?

Со стеком могут быть сложности. Нужно анализировать максимум занятого стека при наихудшем исходе.

Вроде мы при микроконтроллеры?

Они всего лишь облегчают некоторые производственные процессы :) Например, можно сделать дальномер для танка в N килограммов — танк этого почти не заметит, пока проект не войдет в «смертельную спираль», когда любое увеличение массы приводит к бессмысленности апгрейдов на этом инженерном уровне :) Но можно сделать в полкило «за счет современной элементной базы». Пока в ее виде выступает электроника. Однако если думать вне «ойти бутылки», электроникой возможные замены не исчерпываются. Просто сейчас экономически выгодно при возможности использовать именно ее. «Таблица решений» реализованная в аналоговой схеме в виде «целевой функции» не занимает ничего кроме блоков, которые эту функцию апроксимируют между входом и выходом в виде какого-нибудь контура обратной связи, с сигнальным процессором в виде микросхемы или... без нее. Просто «цифру» перенастроить легче при уточнении модели и места она может занимать меньше... Да и тут кому проще запрограммировать ширпотреб «общего назначения» просто потому что он есть... А кому — ASIC выпечь под задачу, потому что может.

Они должны давать набор реакций на набор входящих сигналов.

Это может любая автоматика, включая чисто механическую и пневматическую :) В некоторых местах электронику применять не получается — т.к. она быстро из строя выходит. А на чем делать логику с т.з. «вычислений» или «апроксимаций» монопенисуально. Просто «железную схему» делать (и считать) дольше чем прожечь какую-нибудь прошивку.

Можно втыкать алгоритм обработки сигнала, а можно просто таблицу решений. Таблица решений быстрее, но больше занимает.

Таблица решений во многих случаях не занимает ничего. Для иллюстрации подхода, чтоб именно выйти из контейнера, в котором привыкли думать ойтишнеги: электронику во многих местах можно заменить оптикой например :) результат «вычислений» будет происходить «со скоростью света» в соответствующем оптическом канале с заранее посчитанными («со скоростью калькулятора», зато один раз) свойствами, для которых не нужно хранить таблицы — просто отполировать линзы и нарисовать сетку на окуляре — банальный пример это сетка в прицеле или риски на лимбах микроскопа, свойства которой банально не зависят от электронного противодействия или наличия у оператора знаний о таблицах по которым посчитаны деления на лимбе (есть другие нюансы, конечно) :)

При вот такой начальной скорости (которая зависит вот от такой массы вышибного заряда или вот такой скорости носителя), при вот таком боковом ветре, с учетом силы Кориолиса на этих координатах, с вот такой поправкой (список коэффициентов)... которые все просто уже учтены в сетке на оптике — снаряд или бонба упадет вот в такой круг с вот такой вероятностью :) С микроскопом еще банальнее — крути вот это, пока на резкость не наведешь. Не навелось? Поменяй окуляр. Не видно ничего? Включи подсветку. Тебе же не требуются таблицы для включения лампочки?

Можно повышать точность этого подхода (электроника БИУС подсказывает когда пулять, называется «огневое решение»). Можно подсвечивать лазером для управляемого снаряда (у которого очень простая схема управления — по сигналам с носителя, а система управления с алгоритмами и/или таблицами собственно на нем или вообще в штабе, выдающем целеуказание). Можно читерить с GPSом и «высокоточным целеуказанием», пока его не заглушили или упарываться по «новой компонентной базе», пока не поломалась логистика :) Но если БИУС в отказе, а жопоэс недоступен — никто не мешает пользоваться бэкапом в виде таблиц которые посчитаны заранее и нанесены в виде сеток и делений на шкалах, которые тебе тупо подскажут, что произойдет при заданных условиях (эти верньеры вот сюда — вот такой расклад, вот сюда — другой) без каких-то там сложных щей и без необходимости считать это в уме, т.к. оно уже посчитано и никаких таблиц не хранится на борту.

Аналогично в невоенных применениях. Смотришь на график, видишь где пересекаются риски с осей на реализуемом аппаратурой целевой функции — зашло за вот это деление? А чего это на манометре или счетчике оборотов или уровне технической жидкости красный сектор? Загорается красная лампочка :) Звучит звуковое оповещение. «Оператор, проснись» «А я и не сплю».

Цифровые станки — это например никто не скажет что что-то плохое. Но деления на лимбе которые посчитаны заранее не мешают творить «чудеса» и на обычном станке и даже с кое-какой механической автоматизацией процессов (нарезание резьб, например). Просто дольше и дороже, и требования к оператору станка выше — но он тоже будет пользоваться вычислениями, которые сделаны за него и до него.

Так вот... даже эти «сетки» и «шкалы» можно реализовать без каких-то там сложных таблиц в памяти БЦВМ, хранимых на самом изделии. И без необходимости оператору лично смотреть в окуляр. Не нужно ничего хранить — нужно изготовить фильтр сигнала, физика которого подчиняется таблицам, которые посчитаны и распечатаны в виде справочников, но в самом регуляторе не хранятся нигде :) Именно так работают простые регуляторы начиная с паровых машин, там где человеку скушно или нужна реакция побыстрее и почаще. Все таблицы — в инженерных справочниках и во внешней ЭВМ, которые посчитали модель бортового блока обратной связи, реализующего целевую функцию с достаточной точностью и скоростью (возможность считать это на ЭВМ вообще просто удобство, никак не исключенное отсутствием ЭВМ, КБ раньше обходились. Внутре аппаратной части только вентили, мосты и операционные усилители, и не факт что электронные :) Называется «АВМ», отличается тем что делается под задачу, но уж задачу решает порой побыстрее ЭВМ, просто потому что нет задержек на обсчеты и преобразования в ЦАПах. Для фильтров сигналов уровня «стимул-реакция» — этого достаточно. Вот если интерактивность нужна, да скорость перенастройки, да еще интерфейс для не очень подготовленного оператора — ну вот имеем сейчас приправленный коммерцией хлебушек для программистов в исконной нише инженеров :)