[12:48:36] <ada_ru> (Максим) Да вроде SPARK для жтого и есть
[12:50:46] <ada_ru> (Максим) Из русских матерьялов по спарку есть пока только http://www.ada-ru.org/sssw/chapter_11
[12:51:14] <ada_ru> (Максим) Кто-то обещал сваять статью для ada-ru но так и не решился 😕
[14:42:06] <ada_ru> (Лекс) Так вроде Спарк для верификации? А это немного другое, верификация пишется на основе модели (спецификации) и сравнивает поведение программы с предсказанным по спецификации.

Но я не шарю в предметной области, поэтому и спросил можно ли на нём сразу всё решить, жизнь коротка и учить десяток разных инструментов слегка напрягает и собственно некогда
[14:55:20] <ada_ru> (Лекс) Насколько я понял из поиска в сети, ответ на мой вопрос: нет, это совершенно другой инструмент.
[17:31:46] <ada_ru> (sanyu) https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html
[17:33:37] <ada_ru> (sanyu) Как вам мнение Линуса, что Раст лучше чем два "убожества" - Ада и модула-2
[18:11:41] <ada_ru> (FROL256) мнение есть мнение
[18:15:11] <ada_ru> (Лекс) Это тот раст, в синтаксисе которого чёрт ногу сломит? 😏
[18:16:14] <ada_ru> (Лекс) И это тот самый Линус, который считается автором ядра, которое по сути с самого начала разрабатывало сообщество?
[18:18:04] <ada_ru> (Лекс) Который отвязал смену мажорного номера релиза от радикальных изменений в дань моде?
[18:18:31] <ada_ru> (Лекс) Ну не знаю даже, что-то почему оно вообще должно что-то значить?
[18:18:33] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Это тот раст, в синт…>
Придирки к синтаксису опять :-(
[18:18:55] <ada_ru> (I_vlxy_I) Точно также и про аду говорят. Придирки к синтаксису должны умереть
[18:19:23] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <Придирки к синтаксис…>
Это ж основа, и фишка Ады, прописываемая от момента её создания — синтакис должен быть понятным и не вызывать разночтений.
[18:20:00] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Это ж основа написан…>
Мне казалось, что семантика Ады важнее. Да и любого другого языка.
[18:20:27] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Это ж основа написан…>
А какое разночтение есть у синтакси Rust?
[18:20:48] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <Мне казалось, что се…>
Да что вы говорите? А зачем тогда при оздании Ады сделали упор на читаемость кода? ;)
[18:21:57] <ada_ru> (Лекс)  отвечает (Vinpuh) на <А какое разночтение …>
Зависит от того, какой опыт в программировании. А вообще читать его не сильно приятнее чем Си, какие-то конструкции из перла, из хаскела и бог знает откуда ещё
[18:22:08] <ada_ru> (sanyu) Я понимаю, что резкость Линуса это его стиль. Но громкое слово disaster и новости, что раст, возможно, будет в ядре мне не понятны.
[18:23:03] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Зависит от того, как…>
Если лексемы заменить станет ли лучше?
[18:23:17] <ada_ru> (I_vlxy_I) Не меняя при этом синтаксиса :-)
[18:23:50] <ada_ru> (sanyu) Чем раст, кроме маркетинга лучше?
[18:23:57] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Зависит от того, как…>
Да он просто другой, все привыкли к Си, и прочим, а так простой,  и в принципе если в него хоть чуточку погрузится то ничего страшного там нет. Ну да на первый взгляд там тарабарщина.
[18:24:35] <ada_ru> (Лекс)  отвечает (sanyu) на <Чем раст, кроме марк…>
Всё что там есть хорошего — это модель управления памятью и возможность иполнять код на baremetal :)
[18:24:40] <ada_ru> (Лекс) и всо
[18:24:42] <ada_ru> (Vinpuh)  отвечает (sanyu) на <Чем раст, кроме марк…>
Он простой, на нем сложно писать, но он простой.
[18:25:34] <ada_ru> (Anonymus62) Быть может, ему не понравились излишки от паскаль-подобного синтаксиса?
[18:25:41] <ada_ru> (Лекс)  отвечает (Vinpuh) на <Он простой, на нем с…>
на баш :D
[18:25:52] <ada_ru> (sanyu)  отвечает (Лекс) на <Всё что там есть хор…>
Вот. Спасибо
[18:27:17] <ada_ru> (Лекс)  отвечает (sanyu) на <Вот. Спасибо>
Причём это оказалось настолько не весомым аргументом, что среди некоторых ембеддеров родилась инициатива сделать уменьшенный го для микроконтроллеров...
[18:28:09] <ada_ru> (I_vlxy_I) У Си есть реальные проблемы с грамматикой. И лексемами это не лечится. И плюсами та же байда.

С грамматикой есть нюансы и к js.

А вот у остальных - раста, свифта, го, джавы и так далее, все принципиально иное. Вообще ничего общего с Си нет.

А невежественные фанатики с обоих сторон фронта замечают только лексемы.
[18:28:57] <ada_ru> (I_vlxy_I) Как только кто-то на уровне лексем начинает придираться к синтаксису, значит он вообще не знает обсуждаемого языка, он невежественный и у него кончились аргументы.
[18:29:13] <ada_ru> (Лекс) У js с семантикой одна большая проблема, по сути это лисп, только довольно недоделанный что ли...
[18:29:22] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <У js с семантикой од…>
Да
[18:30:00] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Причём это оказалось…>
Тогда какие аргументы за Ада?:)
[18:30:03] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <У Си есть реальные п…>
Ещё раз — синтаксис важен. Понятный и читаемые синтаксис повышает продуктивность при длительном жизненном цикле программы.
[18:30:41] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Причём это оказалось…>
Сделали уже
[18:30:53] <ada_ru> (Лекс) И минимализирует число логических ошибок, типа как в js == и ===
[18:31:36] <ada_ru> (Лекс)  отвечает (Vinpuh) на <Тогда какие аргумент…>
А вы собственно находясь в комьюнити Ады не стесняетесь задавать такие вопросы? ;]
[18:32:12] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Ещё раз — синтаксис …>
Любые лексемы мгновенно распознаются. Прочитать и понять 10 лексем одинаково просто вне зависимости от того как они называются при условии что это все влезло в одну строку.
[18:32:36] <ada_ru> (I_vlxy_I) Название лексем в Аде не несут никакого смысла пока не изучишь язык.
[18:32:43] <ada_ru> (I_vlxy_I) Названия не помогают
[18:33:42] <ada_ru> (I_vlxy_I) Поэтому на уровне лексем я не прибираюсь ни к Аде ни к расту. Это незначимые отличия.
[18:33:51] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <Любые лексемы мгнове…>
Любопытно, что как раз с синтаксисом у Ады проблем нет, он в ней спроектирован достаточно математично.
[18:34:32] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Ещё раз — синтаксис …>
У Rust очень минималистичный синтаксис, и он простой понятный.
[18:35:13] <ada_ru> (Лекс)  отвечает (Vinpuh) на <У Rust очень минимал…>
Вы давно на Аде программируете?
[18:35:17] <ada_ru> (I_vlxy_I) Это работает в обе стороны, в том числе в диспутах на C++ встречах в Москве в которых я принимаю участие и где регулярно кто-то что-то начинает набрасывать  на другие языки. Любой наброс обычно начинает и заканчивается синтаксисом.
[18:37:13] <ada_ru> (I_vlxy_I) Если замена лексем что-то даёт, то я реквестую исследование на эту тему. Статью в научном рецензируемом журнале.

Пока ее нет, буду считать, что лексемы не решают.
[18:37:38] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Вы давно на Аде прог…>
Я все пытаюсь на ней что-то подписать, но на Раст я уже написал больше чем на Ада. 😁😎
[18:42:15] <ada_ru> (Лекс)  отвечает (Vinpuh) на <Я все пытаюсь на ней…>
Может это вкусовщина и Ада просто не ваше?
Ада проектировалась с простой идеей: решать сложные задачи в таком виде, чтобы дальнейшая поддержка вызывала наименьшее количество усилий, нужно отметить, что под сложными задачами подразумевались совсем не REST API или микросервисы, а например управление желедорожным траффиком в режиме реального времени.
Я бы хотел посмотреть на код решающий подобную задачу на расте и на человек поддерживающих его, а далее можно провести сравнительную аналитику с решением такой же задачи но на Аде.
[18:45:18] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Может это вкусовщина…>
А чем эта задача столь сложна? И почему она ортогональна микросервисам?
[18:45:44] <ada_ru> (I_vlxy_I) Вон, QNX целиком на микросервисах построен :-)
[18:47:48] <ada_ru> (Лекс) Логистика железнодорожных сообщений это ведь так просто... действительно.
[18:48:29] <ada_ru> (I_vlxy_I) Математически это может и интересная задача, но при чем тут программирование?
[18:48:44] <ada_ru> (I_vlxy_I) Основная задача решается на бумаге.
[18:49:13] <ada_ru> (Vinpuh)  отвечает (Лекс) на <Может это вкусовщина…>
Мы то с вами пишем проекты не управления трафиком, а конкретные приземлённые задачи те же микросервисы, а вот с ними у ада так скажем не очень, с тем же го и Раст проще.
[18:51:33] <ada_ru> (Лекс)  отвечает (Vinpuh) на <Мы то с вами пишем п…>
Знаете, ещё Керниган когда-то писал, что под задачу нужно выбирать соответствующий инструмент, а не как-то иначе.
[18:55:39] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <Математически это мо…>
Да что вы говорите, как всё просто :)
А система реального времени, получение данных со счётчиков, пересчёт в процессе, отсылка сигналов на триггеры, и т.д. и всё это в условиях жёсткого реального времени (допуск на исполнение в микросекундах)? При этом код не должен быть шпаггети-монстром и не должен вызвать случайной встречи 30 тонного товарного состава и скоростного сообщения ебенёво-новоебенёво, только потому что вдруг пошёл дождь и это как-то повлияло на один из датчиков 😏

Даже математическая модель задачи отнюдь не простая, и просто на бумаге не решается, потребуется построение, верификация и динамическая проверка модели на корректность.
[18:57:33] <ada_ru> (Лекс) И это не 10 поездов в месяц, а 30-100 в день, а если станция транзитная и находится в центре пересечения нескольких магистралей...
[19:03:11] <ada_ru> (Лекс) Добавим сюда бухого оператора на пульте, случайное выгорание подстанции, и вауля — получаем ещё и допуски на случайные сбои. Что должно быть учтено в мат модели, а следовательно найдёт место и в программно-аппаратной реализации.
[19:54:08] <ada_ru> (vivian) картинка https://www.ada-ru.org/files/bot/2019-08-31-x1.jpg
[19:54:16] <ada_ru> (vivian) a yarvhh i gocgylgcng j
[20:19:43] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <И это не 10 поездов …>
Чем это отличается от управления, скажем, автоматизированным роботизированным производством (заводом)?
[20:20:35] <ada_ru> (Лекс) Ценой ошибки, в основном
[20:20:41] <ada_ru> (I_vlxy_I) Или например от робота для операций на сердце
[20:22:38] <ada_ru> (Лекс) Если что-то написали на C++, только потому что под рукой были C++ разработчики, то это не значит что этому там место.
А в мед оборудовании вообще баг на баге, если следите за новостями ИБ, область ответственная — а подход кустарный, продукты часто в духе спагетти-монстра, знаем мы парочку ембеддеров, жить страшно
[20:22:41] <ada_ru> (I_vlxy_I) Который позволяет делать операции на движущемся сердце, то есть скальпель удерживается в неинерционной системе координат поверхности бьющегося сердца
[20:22:46] <ada_ru> (I_vlxy_I) И позволяет доктору не отвлекаться на то, что сердце бьется
[20:25:04] <ada_ru> (I_vlxy_I) ИБ и корректность кода - разные штуки. Проблема мед. дивайсов в плане ИБ в основном в том, что они проектировались тогда, когда мир в плане ИБ был другим
[20:25:48] <ada_ru> (Лекс) ха-ха
[20:26:00] <ada_ru> (Лекс) другим он был, конечно
[20:26:02] <ada_ru> (I_vlxy_I) Там просто медикал трайл и получение от FDA разрешения занимает очень много времени. Поэтому все мед. устройства защищены по стандартам 20 летней давности
[20:26:14] <ada_ru> (I_vlxy_I) А тогда и ms-dos был ещё ок.
[20:27:22] <ada_ru> (I_vlxy_I) Та же фигня в автомотив - CAN шина уязвима (в современном понимании этого слова) бай дизайн. Вне зависимости от ЯП на котором реализовывать.
[20:27:59] <ada_ru> (I_vlxy_I) Просто потому, что оно древнее. Ошибки не в реализациях а в спеках и устаревших теперь требованиях
[20:28:05] <ada_ru> (Лекс) Тогда между прочим и Ada уже во всю была. И было и хорошее оборудование, с жёсткими спеками и реализацией.
[20:28:53] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Тогда между прочим и…>
Ада тут не поможет. Санки на CAN жёсткие. Но никто не думал о этих поверхностях атаки и что вообще кому то это будет нужно.
[20:29:32] <ada_ru> (I_vlxy_I) Авионика тоже уязвима, кстати.
[20:29:46] <ada_ru> (I_vlxy_I) Хоть ада там хоть не ада
[20:30:10] <ada_ru> (I_vlxy_I) Просто в спеках не было этого требования
[20:30:55] <ada_ru> (I_vlxy_I) Никто 20-30 лет назад не думал что каждый человек будет в кармане иметь мощный компьютер, грубо говоря.
[20:31:30] <ada_ru> (I_vlxy_I) Болезни роста индустрии и болезни зарегулированности и консерватизма некоторых областей
[20:31:43] <ada_ru> (I_vlxy_I) Но это вылечится
[20:45:13] <ada_ru> (Лекс) Мы сейчас отлично перекатились с темы ЯП на тему чистого браинваря, ещё и латентно делаем меня не правым, в вопросе который я изначально не затрагивал как основной.

Относительно природы браинваря я лишь упомянул, что на уровне мат модели система отнюдь не простецкая и требует значительного умственного труда, а не как вы сказали — на бумажке решил.

А относительно кода — некоторые языки, в частности Ада, проектировались именно под нужды больших сложных/распределённых систем, а некоторые нет. Соответственно и код на одних будет как логичная инженерная конструкция — на других сделать таковое будет чертовски сложно и в разы дороже, но часто дороговизна всплывает в результате регулярных доработок, переработок и вообще в сложности поддержки.

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

Глупо думать, что легаси вылечится. Человек по своей природе таков: инертен и ленив, даже интуитивно понимая, что за сегодняшнюю халтуру придётся разгребать в течении нескольких лет через год, он всё равно предпочтёт вариант с халтурой и "простым решеним", вместо "сложного". В массовости так было, есть и я думаю останется.

Ада как пример инженерного творения, это как раз были годы "доса", но к проектированию языка подошли основательно инженерно и логично. И конечно предполагалось такое же логичное использование языка, что увы не совсем вышло.
Сложные проблемы требуют сложных решений, решая сложную проблему "простым способом", разработчик обычно усложняет проблему в разы и в последствии это самое "простое решение" разрастается в довольно не простое, а порой и в спаггети-монстра которого сложно поддерживать и уж боже упаси — радикально модифицировать.
[20:54:07] <ada_ru> (Лекс)  отвечает (I_vlxy_I) на <Там просто медикал т…>
Если бы баги были только в алгоритмах.
[22:27:27] <ada_ru> (Oleg) Микро Go на встраиваемых системах - это Си :-). Кстати о медиках, сегодня как раз читал исходники медицинского софта на Go. Подход у товарища основательный но я не понял зачем так делать, очень понравилась функция возвращающая константу , точнее функции.
[23:11:40] <ada_ru> (I_vlxy_I)  отвечает (Лекс) на <Если бы баги были то…>
дык FDA проверяет не алгоритмы
[23:23:53] <ada_ru> (I_vlxy_I) "А относительно кода — некоторые языки, в частности Ада, проектировались именно под нужды больших сложных/распределённых систем, а некоторые нет. Соответственно и код на одних будет как логичная инженерная конструкция — на других сделать таковое будет чертовски сложно и в разы дороже, но часто дороговизна всплывает в результате регулярных доработок, переработок и вообще в сложности поддержки."

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

То есть не факт, что получилось хорошо.

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

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

Поэтому моя гипотеза пока такая: DoD захотел язык, профинансировал Аду, потом всей мощью DoDа её пихали в соответствующую нишу (а это embedded и реалтайм, авионика и прочее подобное). Естественно запихали (ибо административный ресурс и деньги).

Потом пихать перестали, но Ада там осталась, так как области очень консервативные, ну и индустрия в основном выбирает язык для проекта исходя их того, что обычно используется в подобных проектах (если это веб и там принят сейчас js - будет js, если это ядро операционки и там принят Си - будет Си).

ВОЗМОЖНО Ада в этих областях всё еще остается и из за её каких-то специфических качеств. Но я не вижу однозначных свидетельств в пользу этой гипотезы.

Зато я вижу свидетельства в пользу того, что Ада там по инерции - например F-35 который уже на С++ по большей части. То есть эта традиционная и консервативная индустрия всё равно плавно мигрирует от Ады в сторону других языков.

Также есть свидетельства в пользу SPARK - вот на нем начинаются новые проекты, и в новых областях. Этот язык вероятно сможет захватывать рынки без специального пропихивания его тоннами бабла и административного ресурса DoD'a.
[23:24:33] <ada_ru> (I_vlxy_I) Поймите меня правильно - я нахожу Аду очень интерсным и классным языком. Но я говорю то, что вижу. Личные симпатии не должны мешать мыслить рационально.