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

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

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

С си всё то же самое кроме скорости компиляции.

А про силу привычки я с самого начала и написал. Что си++ до сих пор язык общего назначения только благодаря наследию.

А про силу привычки я с самого начала и написал. Что си++ до сих пор язык общего назначения только благодаря наследию.

Альтернатив C++ по сути нет.

Альтернатив C++ по сути нет.

Если бы не наследие, то могла бы быть Ада.

Попробуй python. Синтаксис во многом похож.

«Кобол — такой хороший язык. Почему же на нем никто не пишет?»
«Лисп — замечательный выразительный язык, такая мощь метапрограммирования. Нужно срочно заменить им питон!»

Ада умерла по той же причине, по которой умрет Rust несмотря на то, что он настолько массово формится... то есть, Rust полностью повторит судьбу Ады. А именно — недостижимый идеал совершенно безопасной программы, ради которого приносится в жертву самое главное свойство ЯП — простота. Уже тогда, не обладая никакими встроенными ассоциативными массивами, async/await, шаблонами-макросами, Ада способна была утереть нос современному C++ по сложности.

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

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

Лисп еще из контрпримеров.

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

А это половина всего IT того времени. Ошметки сведений из TIOBE говорят, что Ada по популярности когда-то была на уровне C++.

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

Признавайся, как нашел эти тексты? Ну хорошо, вторую ссылку я сам находил, но «A Random Walk Through Ada» мне не удавалось находить, хотя ключевые слова по схожей тематике искал в гугле.

В крестах же вроде есть полуавтоматическое управление памятью, нет? Умные указатели, деструкторы, вот это все, чтоб без прямого вызова free на буфер

Попробуй python. Синтаксис во многом похож.

Смешно пошутил. Сравнил жёстко динамический язык с жёстко типизированным

чего ж ты на нем пишешь раз он тебе не нравится? у меня вот проблем на go писать нету, а любители обмазаться статическим говнецом, почему-то от «динамики» страдают. Как у вас там вообще выходит что утки с носорогами скрещиваются, что тупизация становится проблемой?

В крестах же вроде есть полуавтоматическое управление памятью, нет? Умные указатели, деструкторы, вот это все, чтоб без прямого вызова free на буфер

Оно не умеет разруливать взаимные ссылки вообще никак, даже с помощью кодера. Например, у тебя есть банальная связь на умных ссылках a <-> b. Как ее разрушить? Если ты в деструкторе a снимешь связь a -> b, то b снимет ссылку a <- b и грохнет a второй раз до того, как завершится деструктор a. Из-за этого приходится брать ссылку на один из объектов, чтобы явно задавать порядок уничтожения. Соответственно, если объекто больше, то во столько же раз усложняется процедура поэтапного взятия-снятия ссылок — фактически это уже ручное управление памятью, по недоразумению применяющее тупые «умные указатели».

Эта вся проблема решается одним махом, если сделать отдельные методы деинициализации, которые снимают ссылки, но не высвобождают памяти. Но это всё, опять же, придется делать полностью руками, прямо как в Си.

чего ж ты на нем пишешь раз он тебе не нравится? у меня вот проблем на go писать нету, а любители обмазаться статическим говнецом, почему-то от «динамики» страдают. Как у вас там вообще выходит что утки с носорогами скрещиваются, что тупизация становится проблемой?

Если спросить у меня, то лично я не вижу смысла в языках с динамической типизацией. Ну то есть мне приятно иметь ассоциативные массивы и десериализацию, но это делается и в языках со статической типизацией. PHP/Python/Ruby/Perl/JS получили популярность просто потому, что очень быстро реализовываются (питон писался три месяца), в отличие от компилируемых ЯП. А рыночек IT того времени, безоговорочно подчиняющийся умственно отсталым америкосам, никогда не принимал решения по техническим характеристикам, там решал только маркетинг и «застолбили нишу», а потом «мы уже привыкли» и «проверенное решение».

Например, JS выпущен в 1994, но эффективный оптимизирующий исполнитель для него создали только к 2015 году. А для питона вообще не могут таковой сделать. Сэкономил рубль в 90-х — сейчас нужно продавать почку, чтобы отдать техдолг. Я больно ударился об это, когда подумал, что неплохо было бы развить питон . Но на самом деле развитие его давно безнадежно стоит колом, а изменения происходят только косметические. Потому что техдолг там чудовищен, мой труд оказался каплей в море, какой-то весомый вклад может осуществить корпорация минимум уровня гугла, которая возьмется дорабатывать-перерабатывать все популярные питоньи расширения — именно расширения надежно гарантируют, что питон никогда не будет развиваться.

Тем временем, компиляторы ко всяким скалам и окамлям вполне себе делают маленькие групки людей. Потому что после преодоления некоторого серьезного начального барьера доработки становятся простыми — компилируемый язык хорошо СОЧЕТАЕМ с разными новшествами, будь то новые конструкции языка или другой бэкэнд генерации машинных кодов.

Ada используется Министерством обороны США при разработке заказного ПО.

Действительно. Тогда вот и ответ на вопрос в теме.

вообще-то я реулярно смотрю исходники стандартной либы, там постоянно что-то меняется. в языке появились плейсхолдеры, чтобы облегчить работу IDE по автокомплиту, появилось asyncio как надстройка над генераторами и синтаксический сахар в виде async/await. из последнего завезли паттерн матчинг… а вскоре обещают выкинуть GIL его причина популярности как и любых других скриптовых языках в том, что для того чтобы прочитать данных из сокета и записать их туда же в виде json не нужно много ресурсов - тут уже латентность памяти/диска решает… мы дольше ожидаем ответа от сервера, чем что-то полезное делаем, тратя такты впустую. поэтому go, rust появились и так не сыскали популярности в вебне… первый только для различных сканеров портов и прочих сетевых инструментов идеально зашел (примеры: httpx, subfinder, nuclei…)… в вебе прижились только джава и сишарп. да и то - это результат пиара двух этих параш на которых в основном легаси теперь поддерживают

Мы видим их только в дорогущих специализированных системах да всяких полурабочих исследованиях

Мы тут и говорим про ответственные применения, а не про быстро вкинуть и съебаться в туман.

«adalang sucks» в утке -> первый результат -> срач к комментах -> ссылки на другие тексты.

Ada используется Министерством обороны США при разработке заказного ПО.

Использовалось. Ссылки под рукой нет, но IIRC дропнули её в 99м. Ряд проектов на C переписали.

поэтому go, rust появились и так не сыскали популярности в вебне…

Rust не сыскал, потому что заметно сложнее среднестатистического PHP. В Go причина исключительно в философии авторов (и сообществе). Более токсичная только у автора Elm, который батхертит от любого кода написанного не им.

Да что там, меня во ВТУЗе учили рулить многозадачностью именно на аде. В 2010 году. И это в европе. Вот не в курсе, толи профессор отбитый был толи это было правильным решением. К жизни меня это не подготовило вообще никак, досихпор плаваю в вопросах мультитрединга, а ада так и не воскресла. В сейфти критикал сейчас misra C.

Нульчую этого оратора. Кому интересно - видосик на тему: https://www.youtube.com/watch?v=s1i-dnAH9Y4

the computer continuously and instantly solves the problem…

but a computer cannot do this without men

obviously computer accuracy depends on the quality of information it received…

and that depends on the skill and understanding of the men

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

Например, у тебя есть банальная связь на умных ссылках a <-> b

От такого и в жабе память течёт, каноничный пример две мапы со ссылками друг на друга. Для таких вещей надо юзать слабые указатели, и судя по ману в крестах они есть.

П.с. я не настоящий крестоед, если что, кроме кусков ллвм я на крестах ничего толкового не писал, только читал если надо было

«adalang sucks» в утке -> первый результат -> срач к комментах -> ссылки на другие тексты

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

Примерно такие же кваливицированные, как для ввода данных в ПЕКА.

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

Данные координат, скоростей, ускорений корабля вычисляются механикой: инерциалка + механический вычислитель.

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

В этом случае человекам останется сопровождать цель оптическим дальномером: один человек на угол места, один на азимут, один на дальность.

вообще-то я реулярно смотрю исходники стандартной либы, там постоянно что-то меняется. в языке появились плейсхолдеры, чтобы облегчить работу IDE по автокомплиту, появилось asyncio как надстройка над генераторами и синтаксический сахар в виде async/await. из последнего завезли паттерн матчинг

Это и есть «косметика».

вскоре обещают выкинуть GIL

А вот это не косметика и уже почти тридцать лет обещают. Но давай не забывать, что ты общаешься с автором проекта:
https://github.com/byko3y/python-shared-objects
И потому я авторитетно заявляю: GIL не выкинут никогда, просто потому что весь CPython = расширения + немножко синтаксиса + GIL, выкидываешь что-то одно — получаешь совершенно новый язык.

Rust не сыскал, потому что заметно сложнее среднестатистического PHP

Причем, не только в вебне. Он сложнее, чем решительно любой мейнстримовый язык.

Ряд проектов на C переписали

Тогда я спокоен за нашу страну.

Да что там, меня во ВТУЗе учили рулить многозадачностью именно на аде. В 2010 году. И это в европе. Вот не в курсе, толи профессор отбитый был толи это было правильным решением. К жизни меня это не подготовило вообще никак, досихпор плаваю в вопросах мультитрединга, а ада так и не воскресла

А у кого-то есть сомнения по поводу того, что ВУЗ-ы во всём мире набиты только старыми пердунами? Я пока что исключений не встречал. Сама система отбора и подготовки преподавателей исключяет любую обучаемость и новаторство.

В сейфти критикал сейчас misra C

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

От такого и в жабе память течёт, каноничный пример две мапы со ссылками друг на друга. Для таких вещей надо юзать слабые указатели, и судя по ману в крестах они есть

Это чуть менее радикальный путь к ручному управлению памятью, но по сути движение в том же направлении — я руками объясняю ,как правильно компьютеру работать с памятью, а не он это делает за меня. А нынче труд человечка сильно дороже труда машины.

Ну слушай, от кросс-ссылок тебя никакой гц нормально не спасёт, всегда можно придумать ситуацию когда он слажает. Ну либо гц будет настолько дорогим что будут шутки про «640гб хватит всем» и прочее, и будет полный блок исполнения пока он не прожует всю память, при том возможно что несколько раз подряд.

А с чего ты взял, что GC должен спасать от кольцевых ссылок? GC спасает от доступа по некорректным указателям — чего по какой-то причине не умеет делать C++, хотя в той или иной степени умели все языки до и после него, статически и динамически типизированные (кроме, очевидно, Си). Причем, давай не забывать про GC с моделью памяти аля JS или Go, где ссылка берется не на каждый отдельный элемент, а на целый контейнер или его блок, так что никаких миллионов элементов сканить не нужно.

А с чего ты взял, что GC должен спасать от кольцевых ссылок

Ты только что приводил этот пример для крестов с формулировкой «не может». Тогда приведи пример языка который может, при том для всех случаев (прямая ссылка, вложенность, контейнеры и прочее)

Ты только что приводил этот пример для крестов с формулировкой «не может». Тогда приведи пример языка который может, при том для всех случаев (прямая ссылка, вложенность, контейнеры и прочее)

Go? Я не совсем поняло, что ты здесь спросил, но в любом раскладе Go на голову выше C++ по управлению памятью, причем, прекрасно это делает даже на сотнях гигабайтов.

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

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

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

Если за каждое падение твоей софтины тебе будут срезать половину ЗП, то ты первым побежишь учить жаву. Так-то комфортно сидеть с позиции «мою софтину поломали? это просто тестеры плохо тестировали».

Если за каждое падение твоей софтины тебе будут срезать половину ЗП, то ты первым побежишь учить жаву.

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

P.S. Не противник Java.

насколько я помню, падение программы на жаве отличается от падения программы на Си только наличием стектрейса (поправьте, если ошибаюсь)

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

Но насколько я помню, падение программы на жаве отличается от падения программы на Си только наличием стектрейса (поправьте, если ошибаюсь).

На жаве оно упадёт только там, где ошибка (и её можно всегда завернуть в try/catch), на Си++ где угодно. Потому что есть UB.

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

Ты что-то выдумываешь. Во-первых, нечего работать по схеме «я написал а разбирайтесь сами». Во-вторых, мой софт память не бьёт. Джаву я немного учил (в развлекательных целях - моддить майнкрафт) и даже делал к ней декомпилятор (на Си, разумеется), но писать на ней своё желания так и не появилось.

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

ну вот пожалуйста, на земле:

NEW YORK and TAMPA, Fl., June 19, 2007 - Systems & Software Technology Conference – AdaCore, provider of the highest quality Ada tools and support services, today announced that Praxis has selected AdaCore’s GNAT Pro for the implementation of the UK’s next-generation Interim Future Area Control Tools Support (iFACTS) air traffic control system for its client NATS.

https://www.adacore.com/press/adacore-gnat-pro-chosen-for-uk-next-generation

Так-то стектрейс дело полезное (для программиста), но вот если мы говорим про падение программы в продакшене — разницы нет, там его всё равно зарисовывать некому.

Нет, не так. Если необходимо предусмотреть подсистему учета падения в системе, все эти стек трейсы забираются и сохраняются для дальнейшего анализа. Другое дело, что от упавшего кода на C/C++ забирается кордамп, из которого можно (не всегда в полной мере) восстановить стек трейс, но это уже другой вопрос.

Во-вторых, мой софт память не бьёт.

На Си? Готов продавать свой софт с денежной гарантией в на это утверждение? Для того, чтобы твой софт побил память, достаточно единичного использования после освобождения или выхода за пределы массива.

Да, на Си, конечно. Нет, ввязываться во всякие обязательства я не собираюсь.

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

Спасибо за информацию.

единичного

Особенно за эту.

Да, на Си, конечно.

Я бы не поручился, что я в своих программах всюду абсолютно внимателен.

Разве что писать без динамической памяти вообще (и, на всякий случай, и без массивов). Тогда, действительно, программа память не испортит.

Дело не во внимательности, а в подходе. В ходе черновой разработки, когда только набрасываешь алгоритм, могут быть «невнимательности» и описанные проблемы, да. У некоторых после этой стадии сразу идёт публикация, что и приводит к мифам о Си-проблемах. Но на деле после неё должна быть трассировка всех путей выполнения кода в уме, с проверкой что состояние, которое ты ожидаешь, совпадает с тем, которое получается в ходе трассировки. Если где-то ты считаешь качество проведённого тобой анализа недостаточным - как минимум ставить assert-ы со строгими проверками (проверки не на предбаговое состояние, а вообще на любое отклонение от мысленного плана, даже если оно не нарушает логику). Ну и разумеется, абсолютно каждую арифметическую операцию надо писать со держанием случаев переполнения в уме.