OberonCore

На мой взгляд, Иван Андреевич не смог достаточно хорошо ответить на вопрос о безопасности типов данных в Обероне в тусовке, где принято программировать на Си. Я думаю, это потому, что Иван Андреевич чувствует себя в обероне как рыба в воде и не часто задумывается над такими вопросами. А такой ответ должен быть наготове у любого оберонщика при выходе из гидросферы в другие сферы. В соседней теме было много слов и даже проклятий в адрес С++, но я попробую кратко сформулировать моё понимание отличий Оберона от Си/Си++, к-рые можно было бы назвать его преимуществами, и относящихся к надёжности/безопасности.

• присутствует безопасный тип данных "массив длины, неизвестной во время компиляции". Длина массива хранится вместе с массивом и обычно среда выполнения автоматически проверяет выход за пределы массива. В Си есть только указатели и массивы длины, известной во время компиляции. В С++ есть много разных контейнеров, но С++ слишком сложный язык и фактором ненадёжности выступает как сложность самого языка (ограниченность его понимания разработчиком), так и сложность его компиляторов, сред выполнения и библиотек (в них могут быть ошибки).
• конструкция WITH реализует безопасный аналог union-ов - в Си есть только опасные. В С++ есть объекты, но см. предыдущий пункт.
• понятие модуля изначально присутствует в языке - повышает надёжность на архитектурном уровне
• как правило, среда выполнения Оберона обнуляет локальные и глобальные переменные, при этом заполнение неинициализированных переменных случайными данными становится резко менее опасным.
• меньше неявных преобразований типов
• сборка мусора - резко снижает вероятность ошибок типа "висячий указатель" и "утечка памяти", хотя вносит и свои проблемы вида "утечка ресурсов", которые частично сглаживаются финализаторами. Существуют языки оберон-семейства с задачами реального времени, которые могут прерывать сборщик мусора. Для таких задач на уровне языка запрещено обращение к объектам из кучи, и это сглаживает противоречие между сборкой мусора и реальным временем без ущерба для надёжности.
• один язык - системы на Обероне зачастую являются однородными по языку, значит, в них нет FFI (интерфейс для вызова инородных функций), который является слабым местом с т.з. надёжности. Бывают ассемблерные вставки, но они есть и в Си/Си++
• простой язык - по сравнению с С++ - устраняет такой фактор ненадёжности, как недостаточное понимание языка разработчиком.
• простые компиляторы. Многие компиляторы Оберона достаточно просты, можно залезть и понять, какой машинный код будет сгенерирован и почему. Это позволяет выйти на понятие "доверенности". Популярные компиляторы Си достаточно сложны, поэтому создать доверенный компилятор Си сложно
• безопасность была одним из важнейших критериев для принятия решений при разработке языка. В том числе, роль безопасности поставлена выше роли производительности. Поэтому в Обероне зачастую никогда не отключаются проверки, аналогичные санитайзерам, а объём выполняемых оптимизаций ограничен. Это снижает подверженность таким вещам, как ошибки в оптимизаторах, удаление кода, важного для надёжности и безопасности, облегчают диагностику и отладку промышленного кода, который не отличается от отладочного. В случае Си, мы отлаживаем одну версию программы, а в промышленности используется другая, оптимизированная, между их поведением может быть существенный зазор, который снижает надёжность внедрения.
• стиль оберона - это копирование и адаптация кода вместо создания обобщённого кода. Хотя такой код является более трудоёмким в разработке и поддержке, этот код проще, а значит, более постижим и вследствие этого более надёжен.
• молниеносная компиляция и горячая замена модулей. Кратковременная память человека стирается через 30 секунд. Если процесс компиляции и перезапуска не укладывается в этот порог, то происходит скачкообразное снижение производительности труда программиста с одновременным снижением надёжности, поскольку модель разрабатываемого фрагмента приходится строить в голове заново после каждой перекомпиляции. В Обероне за счёт быстроты компиляции и за счёт горячей замены модулей довольно сложные программы
  можно перезапустить менее, чем за 30 секунд (хотя не знаю, как это относится к встраиваемым применениям, но если говорить вообще, то такой фактор есть).

Прошу добавлять, убавлять и т.п.

Можно также сказать, хотя это не относится к данному набору, что язык оберон-семейства сегодня вошёл в мейнстрим - это golang. Golang позиционируется как язык для написания сетевых сервисов. В этой роли он вытесняет Java и C++. А настоящий Оберон может использоваться и в других областях, в т.ч. в системном программировании - на нём написано несколько операционных систем. Поэтому, опираясь на успех golang, можно предсказать успех Оберона в более широкой области применения.

Лайк!

Я вот не осознавал, что привычная выгрузка модулей - это по сути горячая замена. Буду хвастаться теперь - терминологически верно!

Денис, спасибо, ценная сводка.

Для кого?
Тут ДАЖЕ Эйфель , с его всеохватностью процесса разработки и простотой, 40 лет уже скоро как, где-то теряется в статистической погрешности использования...
Ну - не воспринимается программистами и - самое главное - МЕНЕДЖЕРАМИ больше ничего, что выходит за пределы фигурных скобок и вагона внешних средств и утилит! Как в качестве средств реализации, так и в качестве сопутствующих средств построения и ОЦЕНКИ ПРОГРЕССА проектов. У людей уже, худо-бедно, какое-то шкалирование производительности, с учётом знаний и скилов, по этим средствам, наработаны за десятилетия и приняты.
Мы сейчас оказались в положении, когда всё то, что было полулюбительским, похватным, практически "наколенным", временным, узкоспециализированным решением, стало стандартами в отрасли де факто. А то, что имело проработанную теоретическую академическую системную базу, переместилось в разряд чуть ли не маргинального, высмеиваемого, стало признаком дурного тона, "непрактичной мечтательности," и, даже, не совсем далёкого ума.
Вы понимаете, что большинством разработчиков и менеджеров, оберонщики, адисты и эйфелисты воспринимаются, как какие-то чудаки-одиночки, городские сумасшедшие?
Бог - на стороне больших батальонов.
И Вирт, и Мейер, и Ишбиа с Тефтом совершили одну и ту же ошибку. Они не открыли свои разработки и понадеялись на авторитет Высшей Школы. Но, самое главное, они были уверены, что людей можно убедить теоретическими выкладками и апеллированием к их здравому уму и к способности рационального рассуждения.

Так не только количество инженерных кадров в ИТ выросло взрывным образом (с просадкой их качества и образования).
С менеджментом тоже самое.

Менеджмент в отрасли наполнится так же людьми, не способными нормально вырабатывать и принимать решения.

"Только массовые дисквалификации спасут отрасль"?

Вы только посмотрите, например, на этот УЖАС: https://proglib.io/p/4-mifa-o-professii ... 2020-11-23
Это - нормальный человек мог такое сочинить?!
Тут - уже не кризис. Это - катастрофа.
Или, давайте определимся, О ПРОГРАММИРОВАНИИ ЛИ МЫ ВЕДЁМ, В ПОДОБНЫХ СЛУЧАЯХ, РЕЧЬ. Или ЭТО - уже нечто иное?

Давайте сузим тему.

Список появился как реакция на ответ, который Иван Андреевич дал на конференции. Т.е. уже был пробит какой-то лёд. Это во-первых. Во-вторых, Питон выходит за фигурные скобки и ничего, прижился. В-третьих, Хаскель тоже выходит, а среди высоколобой молодёжи популярен. В ОС Касперского приложения можно писать на двух языках: С/С++ и Хаскеле. И в связи с этим я сижу и не знаю, как мне писать продвигающий текст про A2, потому что Оберону против Хаскеля тяжело стоять. А на чём эта ОС внутри написана? Слухи разные ходили, про Хаскель тоже упоминалось. Если это так, то это может быть действительно шагом вперёд. Правда, Хаскель - это язык с большим элементом чёрной магии, но это сложно обосновать, у него есть своя мощная секта, и главное, в нём действительно есть хорошие выразительные средства, которых, в т.ч. в Оберонах на хватает, и по безопасности он Оберону не уступает, я так думаю (сам его недоучил и никогда ничего не писал на нём). В чётвертых, я ждал критики на то, что голанг относится к оберон-семейству. Ну абстрагируйтесь от фигурных скобок - это всего лишь синтаксис. И увидите, что если достаточно вложиться в рекламу, то и Оберон можно раскрутить. Не только можно - его _уже_ раскрутили. Просто это сделали не те люди, которых, возможно, нам с вами хотелось бы видеть в этой роли победителей.

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

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

WITH никаким боком не относится к объединениям (union). Эти понятия даже не параллельны/перпендикулярны - они вообще из разных вселенных. Кроме того, у реализации WITH есть фатальный недостаток, даже дыра- нет запрета на изменение переменной-указателя.

Среда выполнения Оберона, как правило, не обнуляет локальные переменные, и не всегда обнуляет глобальные.

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

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

То, что безопасность была поставлена выше роли производительности это просто не правда. Оберон изначально разрабатывался как учебный язык, компилятор которого студенты могут реализовать за обозримое время. Много чего полезного было принесено в жертву - у академиков свои приоритеты. Но никто не запрещал студентам/аспирантам/... разрабатывать оптимизаторы, дженерики, обработку исключений и т.д. Наоборот, всячески поддерживали. И насколько я помню, SSA-оптимизатор впервые был реализован именно для Оберона.

Горячей замены модулей в Оберонах нет, а то что есть (динамическая загрузка/выгрузка) нельзя использовать в промышленности. За такое нужно сразу отправлять на лесоповалы. Но такая реализация замечательно подходит для разработки и отладки.
В общем, не нужно желаемое выдавать за действительное.

Притом, если уж говорить о наукоёмкости, и даже о наукообразном псевдофилософском тумане, то вокруг Хаскеля это сделано прямо профессионально! Одна теория категорий чего стоит. Практически сделали новую религию. Правда, в промышленности язык не особо блистает. Я пользовался только одним приложением на Хаскеле - darcs, в нём были глюки, а потом оно вообще сошло на нет. Но против энтузиазма сектантов, особенно, если они уже захватили целые отделы в Касперском, имеют финансирование и выкатили целую ОС, тяжело будет стоять.

На внедрениях готовых продуктов и интеграциях есть, конечно, огромное количество задач, которые не инженерные, а уровня "цифрового слесаря". Доконфигурирование, развёртывание в кластерах, интеграционные скрипты... Тут и правда можно обучать за полгода - а дальше на опыте сам донабирается.

Проблема в том, что никто не разделяет одно от другого. В образовании вообще всё стало ещё большим бессистемным комом.

Всё-таки какие-то хорошие практики в небольшие компании проникают потихоньку, по моим наблюдениям. Культура работы.

Если в плане языков - ну на фронтэнде, наконец, идёт строгая типизация (TypeScript, Dart) - всё шире. И как только пошло "сверху", "от гигантов" - все хипстеры со смузи, кричавшие о свободе скриптов и самовыражения, как-то стихли.

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

Чем аккуратный приостанов, перезагрузка части модулей - и продолжение работы - отличаются от helm upgrade в Kubernetes?

Кстати, горячая замена кодовой секции модуля тоже делается легко (у меня есть). Единственное, надо докрутить стопор на изменения определений. Запрещать такое при изменении дескрипторов типов. А изменения в логике накатывать - нет проблем.

> WITH никаким боком не относится к объединениям (union).

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

> Среда выполнения Оберона, как правило, не обнуляет локальные переменные, и не всегда обнуляет глобальные.

Можно посчитать, только вопрос, как считать, и оценить правомерность этого "как правило". Я не знаток оберонов, возможно и ошибся. Более знающие товарищи пусть поправят.

> Сборщик мусора не означает, что не нужно думать о памяти, как раз думать нужно.
Если уж призываете не врать, так и сами не передёргивайте. Я не говорил, что не нужно думать о памяти, утверждение совершенно конкретное.

> То, что безопасность была поставлена выше роли производительности это просто не правда.

Ну ладно, здесь я, наверное, действительно занялся мифотворчеством. Хотя я не первый, ведь это же не я давал рекламу о том, что оберон - это безопасный язык. Однако, если мы поставим безопасность выше производительности, то у нас получится нечто похожее на оберон и можно было бы попытаться задним числом это так изобразить.

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

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

> Горячей замены модулей в Оберонах нет, а то что есть (динамическая загрузка/выгрузка) нельзя использовать в промышленности.

Я думаю, Вы имеете в виду всякие ситуации типа обратных связей, когда объект из выгружаемого модуля остаётся бесхозным, будучи полученным по указателю типа из невыгружаемого модуля. Во всяком случае, дайте ссылку на каноническое и общепризнанное определение горячей замены модулей, тогда и будет основание говорить о том, есть они или нет. Касаемо применения - я о промышленности и не писал. Если проводить аналогию с горячей заменой, к примеру, флешки, то флешку тоже надо сначала размонтировать, а если неизвестное приложение её не отпускает, то её и вытащить нельзя без того, чтобы поиметь проблем. Т.е. горячая замена производится всегда по каким-то правилам и является ограниченной по применению. В случае ББ или A2 тоже можно описать ограничения, при которых она будет работать как часы. Хотя может быть тут ещё какие-то скелеты в шкафу, о которых я пока не знаю.

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

Ну допустим я догадался до одного отличия, которое в пользу юнионов - у них одинаковый размер и поэтому их можно делать элементами массива или передавать по значению. В случае записей оберона и наследования, если я правильно понимаю, то можно засунуть в массив только указатели на запись, но не сами записи (но это не точно). Слово "аналогия" не подразумевает 100%-й заменяемости. Во многих применениях спокойно можно заменить юнионы на записи Оберона и наследование.

Записи тоже можно.

Тебя даже не смущает тот факт, что union это тип, а with это оператор. Но ты продолюаешь утверждать, что они похожи.
Вирт выпилил вариантные записи из Оберона. Теперь люди думают, как впилить их обратно.

разных типов? В один массив?

Пардон, мне клинит мозг от такого вопроса.

Нужно иногда немного домысливать, а не только придираться к форме. union - это совокупность из декларации типа и способов доступа к нему. В Си способы доступа почти не имеют синтаксиса, но это не значит, что их нет. В Обероне синтаксис более явный и он включает в т.ч. слово WITH.

Но в целом идея впилить обратно вариантные записи может иметь смысл именно для массивов. Хотя это частность, она не критична. Если целью языка является минимализм, то очевидно, что в представлении данных будут какие-то особенности, которые не позволят сделать его всегда оптимальным. Сами по себе теги типа дают неустранимые накладные расходы. Т.е. конечно может быть где-то и есть докторская о том, как их убрать, но мне не попадалась и в реальных языках я вижу, что теги типа есть, их нужно инициализировать и это стоит определённого количества тактов и байт кода. В Си без этого можно обойтись, зато небезопасно. Кому это не нравится - тот может выбрать язык без сборки мусора или использовать небезопасные конструкции. Отличие между "истинными" вариантными записями и их реализацией через наследование вполне можно уместить в категорию "выборы автора языка для минимализма и надёжности, накладывающие ограничения на эффективность".

На мой взгляд, оберонщини недостаточно глубоко знают мир С++, поэтому позволю себе, как "пограничник", внести ясность в некоторые вопросы.
Отвечаем по пунктам.
Давно уже не так.
Обычными массивами в профессиональной разработке фактически не пользуются. А пользуются контейнерами.
В том числе для всех индексируемых контейнеров реализовано два метода доступа по индексу: неохраняемый и охраняемый, который генерит исключения при "вылете за границу".
Юнионами в профессиональной разработке тоже давно уже не пользуются. В стандартной библиотеке реализовано несколько безопасных видов подобной структуры (variant, optional...)
Вот это - КРУПНЫЙ недостаток языка. В С++20 модули введены, но мне, знакомому с виртовскими языками с 70-х годов, эти модули представляются безобразной заплатой. Модули в Компонентном Паскале просты и понятны, и являются практически идеальной конструкцией.
Особенно в среде БлэкБокса, где они фактически заменяют любые динамические библиотеки как в Винде, так и в Лине.
Глобальные переменные - обнуляются. Локальные - нет. С другой стороны, неинициализированная локальная переменная у профи отсутствует как класс. В этом смысле отсутствие инициализации по месту в Обероне сильно раздражает.
Проблема, собственно, не столько в неявных преобразованиях, сколько в вызовах конструкторов по умолчанию. И некоьторых других специальных методов, реализованных в классе. Тут - реальная засада.
Недаром мы в семантике вообще отменили ЛЮБЫЕ умолчания.
Если сравнивать Оберон и С++, то ГЛАВНАЯ разница заключается именно в подходе к умолчаниям.
В С++: все, что не запрещено - разрешено.
В Обероне ровно наоборот: все, что не разрешено - запрещено.
Даже наследование. И это, с моей колокольни, абсолютно правильное решение.
В стандартной библиотеке С++ реализовано несколько видов интеллектуальных указателей, которые вполне надежно защищают от утечек памяти. Все контейнеры пользуются стандартным аллокатором, который тоже вполне надежно обеспечивает отсутствие утечек. Все это работает достаточно быстро.
Существуют и сборщики мусора для С++, но я их не использовал.
Это - дискуссионное утверждение. Например, если мы делаем веб-систему, и интерфейс у нас уже на другом языке, хотя бы и того же семейства.
Так и я могу веб интерфейс написать на С++ - смотрим библиотеку Wt.
В принципе ЛЮБУЮ систему можно написать на ОДНОМ языке. Примером тому является node.js, которая обеспечивает на сервере среду для разработки серверной части на js.
Писать ПРОСТО можно на ЛЮБОМ языке. Только на С++ для этого нужна самодисциплина... )))))
С этим согласен абсолютно. Только речь не о Си, а о С++. Компилятор Си я могу написать довольно быстро. И даже студент под моим управлением. И всегда можно посмотреть, какие команды сгенерированы - достаточно включить выдачу ассемблерного листинга.
С этим никто не спорит. Целью С++ была именно высокая производительность.
Вот здесь могу отметить интересность С++.
На С++ можно писать в 4 стилях: процедурном, объектно-ориентированном, функциональном, и обобщенном. Ничего подобного в любых других языках нет.
В том числе и в Обероне.

Ну, наверное, зависит от объема компилируемого кода.

Можно привести примеры операционных систем на обероне?
А то в мейнстриме только винда и линукс.

Валерий Викторович, спасибо за отзыв. Я понял, что нужно отдельно сравнивать Оберон с Си - тогда на стороне оберона наличие безопасных юнионов, и отдельно сравнивать Оберон с Си++, тогда на стороне Оберона простота. Сравнение с обоими языками сразу не имеет большого смысла.

Насчёт не обнуления локальных - ну это трагедия. В A2 для x86 и x64 обнуляются, для ARM, как я понял, зависит от флагов. Нужно либо обнулять, как сделано в голанге, либо должна быть ошибка компиляции, если компилятор не смог доказать, что переменная инициализирована до использования. В Активном Обероне 2018 есть инициализаторы переменных и определение переменных в коде, но некоторые считают это ересью.

Насчёт неявности, есть же всякие copy constructor и оператор =, ЕМНИП. Перегрузка операций тоже позволяет создавать неявные преобразования и достигнуть уровня JS, когда 2+2=22.

> В стандартной библиотеке С++ реализовано несколько видов интеллектуальных указателей, которые вполне надежно защищают от утечек памяти

Здесь недостаточно в курсе, но мне казалось, что это всё же костыли, которые по результату хуже, чем сборка мусора. Давно не писал на C++. Во всяком случае, как-то я пил с пареньком из Яндекса и он сказал, что они не могут справиться с некоторыми багами в их сервисах. При том, что культура производства там наверняка на высоком уровне.

> . Например, если мы делаем веб-систему, и интерфейс у нас уже на другом языке, хотя бы и того же семейства.

Утверждение может быть и дискуссионное. Но сейчас настаёт эпоха webasm и веб-приложений, которые скачиваются и устанавливаются. У js уже нет монополии как у языка веб-клиентов. Да и вся вот эта технология SPA и веб-фреймворков - на самом деле это какой-то ужас. Поэтому вполне можно (и нужно) ставить вопрос о написании и клиента, и сервера веб-систем на одном и том же языке. Другое дело, что передача js по сети в исходных кодах, а jar - в виде байт-кода решает проблемы с безопасностью, т.к. на стороне клиента можно провести входной контроль и ограничить возможности кода. Если передавать машкод, то провести входной контроль, наверное, становится сложнее, хотя я не настолько в этой теме.

> Вот здесь могу отметить интересность С++.
На С++ можно писать в 4 стилях: процедурном, объектно-ориентированном, функциональном, и обобщенном. Ничего подобного в любых других языках нет.
В том числе и в Обероне.

Ну, это не совсем правда, но не будем о запретном

На обероне написана система Оберон, естественно. A2, и ещё какие-то ОС в школе Вирта - я никогда не осиливал досмотреть все генеалогическое дерево до конца. Ну и прошивки, о которых Иван Андреевич рассказывал. A2 не в мейнстриме, но как минимум 2 посететиля данного форума зарабатывают на ней деньги.

> Писать ПРОСТО можно на ЛЮБОМ языке. Только на С++ для этого нужна самодисциплина... )))))
Когда берётся реальный проект на С++ с зависимостями, то нужна самодисциплина у авторов всех используемых библиотек, причём одинаковая. Иначе бедному автору проекта придётся иметь дело с 5 реализациями контейнеров, 5 видами строк и т.п. И знать все те подмножества языка, которые использовали авторы всех библиотек.