OberonCore

Спасибо Илья Евгеньевич.

Илья Ермаков, спасибо!

В связи с ухудшением материального положения работы по создании версии компилятора ББ на русском языке приостанавливаются. Текущее состояние можно видеть в репозитории: https://gitlab.com/budden/nkp/tree/master/k/Ня/Mod

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

Для завершения работы нужно порядка 100 тыр. Работы ведутся в нашей сборке с текстовыми исходниками, но ничто не мешает потом использовать их в "традиционной" сборке. Интерфейс компилятора - отдельный модуль НяКомпилятор, который может сосуществовать с DevCompiler. Никаких изменений в язык не внесено (во всяком случае, я на это надеюсь).

Исполнители есть, ищем спонсоров.

Финансовое положение частично стабилизировалось, проект разморожен, продолжаю работать. Не ищем ни спонсоров, ни исполнителей, ни советчиков - никого не ищем

Проект переименован в «Обероня», репозиторий теперь находится здесь:

https://gitlab.com/budden/oberonja

Итоги на данный момент:

• Все файлы компилятора переназваны в русские аббревиатуры, в начало каждого поставлено краткое описание (в меру ограниченного понимания)
• Все магические числа в сообщениях об ошибках расшифрованы на русском
• object modes перевёл как части речи (чаРе) и к каждой написан комментарий (спасибо форумчанам за помощь)
• Все процедуры модуля НяПарсер названы по-русски и названия более подробны, чем исходные
• Частично переведены и другие модули
• Ещё пахать и пахать

Может ХаРе уже издеваться над русским языком и обероном?))

Спасибо на добром слове, Вам тоже творческих успехов

Отвратителен этот ваш КП. Язык неортогональный и почти полностью составленный из костылей. Поэтому очень много кода - сегодня было 3-4 переименования слов с 700 вхождениями. В нормальном языке с МП это было бы 300 вхождений, а то и 200. Я уж не говорю о том, что из-за хвалёного отсутствия инклюдов большие блоки кода копируются из одного файла в другой, причём иногда с ошибками! Так что это не я его мучаю, а он меня.

Может быть, когда-нибудь я напишу о том, что оптимальная сложность языка связана со сложностью программы, которая на нём пишется. Чем сложнее программа, тем сложнее должен быть и язык. Как должна расти сложность языка - я не знаю, может быть, логарифмически, но расти она должна. Поскольку развитый язык даёт способы повторного использования, которых в неразвитом (типа оберона) языке нет. Из-за отсутствия способов повторного использования возникает дублирование кода с присущими ему ошибками, а значит, общая надёжность системы из языка и написанной на нём программы будет для неразвитого языка ниже. При этом надёжность простого языка, если его рассматривать изолированно, будет, конечно же, выше. Но это лишь маркетинговая уловка. Потому что конечному пользователю нужен не надёжный язык, а надёжная программа. Это к вопросу о том, возможен ли маркетинг на лжи. Не только возможен, а даже очень хорошо на некоторых действует.

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

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

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

Вот тут немного об этом написано.

http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=84

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

Также нужно отличать типы времени компиляции (у меня это называется типы прообъектов) и типы времени исполнения (собственно типы). Потому что тип прообъекта ANYPTR существует, а вот типа объекта ANYPTR не существует. Опять же, если кто-то знает, как это лучше назвать - прошу примеров.

Правда, я сейчас понимаю, что я сначала хотел погрузить типы объектов в иерархию для прообъектов, поэтому типы прообъектов называются у меня видами (вид я принял считать старше типа). Но это ошибка - наверное, придётся её исправить.

Во-первых, способом повторного использования являются процедуры. И они есть.
Во-вторых, кажется, что для того, чтобы сделать универсальный алгоритма списка необходимы шаблоны как в C++ или других языка. Но это не верно. Есть несколько вариантов как реализовать универсальный список в Оберонах. Один из методов предложил я в прошлом году (Видео со Дня Оберона 2017). Суть в том, что можно вынести алгоритм в один модуль и он будет один на всю программу, а для создания разных типов списков, нужно будет написать немного кода, который будет подстраивать любой тип данных к тому с чем работает алгоритм. И таким образом, можно создать список целых, список строк, список произвольных структур. А также можно делать еще некоторые интересные вещи.

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

А главная проблема здесь - это как сделать, чтобы этот проект не стал работой в стол.

Работа идёт, но довольно медленно. Если моё текущее место работы не накроется в течение года (а скорее всего, оно накроется для меня гораздо раньше), то к концу года будет компилятор КП, в котором все структуры данных и процедуры будут описаны и переведены на русский. За рефакторинг поручиться не могу. И дальше что? Кому это нужно? Для практических применений, которые лично я мог бы монетизировать (т.е. для производства программ), я не вижу, как это использовать. Когда я использовал лисп, я писал на нём всевозможные InHouse поделки, от поддержки метаданных БД до метапрограммирования на Дельфи и серверов приложений. На лиспе это легко и я могу продолжить это - я это умею, это делается быстро и приятно. На Обероне я не возьмусь писать такие вещи - производительность моего труда на нём слишком низка. Дальше, допустим, новые программы на рынок. Но новые программы сейчас почти никому не нужны - у всех уже есть старые. Кроме того, язык слишком аскетичен, чтобы я захотел на нём писать. Даже если так, то есть аналогичный Golang, на который есть спрос на рынке. Внедриться в образование? Думается, хорошие шансы на это есть только у того, кто уже интегрирован в систему образования. Заявить, что Оберон подходит для безопасных приложений? Ну я же сам в это не особо верю. Так скажем, потенциально и тому подобное - он пригоден, да. Но вот сесть и прямо начать на переведённом КП писать отечественную защищённую ОС - ну не знаю. Даже если так, то нужно же как-то суметь направить на себя потоки государственных денег. Мои успехи в привлечении денег пока что крайне близки к нулю. Ожидать, что дальше всё волшебно поменяется, будет чрезмерным оптимизмом.

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

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

Есть уже поучительный пример Глагола, который мало кому нужен, и так потихоньку и умер.

По сути дела - за сегодня ещё пару раз переделал терминологию.

из 68 процедур модуля НяФс (бывший DevCPT) 25 поняты (хотя бы на уровне понимания их предназначения) и названия переведены на русский. Также за последние дни перевёл названия ряда ключевых типов компилятора, таких как Obj, Structure, и ряда полей в них. Сегодня (уже вчера) перевёл все composite structure forms (их, правда, всего 4, но вхождений в сумме довольно много).

Уже 28 переведено, пора бы и спать. Всего в компиляторе 762 процедуры (поиск "PROCEDURE "), из них 622 подходят под рег.выр "PROCEDURE [a-zA-Z]" с учётом регистра, и 128 - под рег.выр "PROCEDURE [а-яА-Я]" с учётом регистра. Сумма не сходится, возможно, подчёркивания. Но, выбросив
то, что не попало ни в одну выборку, получаем что 17% названий процедур уже переведены. Проекту 2 месяца. Понятно, что дури надолго не хватит и плюс к тому не вся работа сделана лично мной. Но если дальше пойдёт так, то имена всех процедур будут расшифрованы и переведены за ~8 месяцев.

Помимо процедур, уже расшифровано и понято много констант и несколько имён полей, но их непонятно, как посчитать.

Ну ладно, можно на самом деле зафиксировать такую цель, как перевод всех названий процедур - она достижима. 20 процедур в неделю - за полгода всё будет переведено.

Только дело в том, что от такого перевода никакой пользы кроме вреда.
1) Обновится основной компилятор - и весь перевод сразу устарел
2) Качество вашего изделия тоже под большим вопросом. Может оказаться, что в процессе перевода где-нибудь опечатка закралась и используестя не та переменная
3) В Google/Яндекс по переведённым терминам ничего не найти. В книгах тоже.
И так далее.

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

1. Компилятор вряд ли будет сильно меняться в будущем, маленькие изменения будет несложно перенести.

2. Такое возможно. Я проверяю только тем, что постоянно пересобираю этим компилятором ББЦБ, но понятно, что этого недостаточно.

3. Хуже, чем есть сейчас, вряд ли удастся сделать. У Вирта абсолютно своя терминология. Вот несколько примеров реальных идентификаторов или комментариев из компилятора: structure forms, object modes, qualident, idfp, mno. Дальше, вообще существования общей терминологии компиляции я не наблюдаю (даже в английском), хотя прилагаю к этому некоторые усилия. Есть лишь отдельные термины, но полной терминологии на всё, которую можно было бы применить во всех модулях компилятора, я пока что не нашёл. Каждое понятие приходится придумывать, как перевести. Одни structure forms я уже 2-3 раза переименовывал.

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

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

С этой точки зрения пора начать отучаться называть «основным» компилятор, разработанный вне пределов России. Даже если он изначально был импортным, его нужно тщательно проверить и далее разрабатывать самостоятельно. Если у нас нет на это ресурсов, то безопасность нашей страны не обезпечена и суверенитет отсутствует.

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

Закладки в компиляторах появились почти одновременно с самими компиляторами, пруфлинк искать не буду, но я его видел.

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

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

Переведённых имён процедур стало 142 - 14 штук за полдня. Плюс к тому узнал смысл 4 полей в основных структурах данных. Такими темпами можно было бы уложиться за месяц, но отпуск подходит к концу.

Эта цель, возможно, и интересная, но каким образом она относится к переводу имён идентификаторов?
Правильно, никаким.
Перевод переменных это самый настоящий Сизифов труд.

Очевидно, что было бы гораздо больше пользы, если бы вы те же ресурсы потратили не на перевод переменных, а на какое-нибудь продвижение Оберона или чего у вас там. А так вы по сути тратите время впустую. Нравится вам -- мне без разницы. Но раз уж вы сами задались вопросом "а кому оно вообще нужно?", то я и ответил: ни-ко-му. Реально, никого не интересуют на каком языке называются переменные в компиляторе.

Ладно бы вы говорили об именах переменных в прикладном коде. Это ещё хоть как-то можно обсуждать. А уж имена переменных в компиляторе вообще никого не волнуют, т.к. никто не собирает компилятор из исходников. Кому какая разница как там переменные называются? Правильно, только вам разница и есть.


К сожалению, оно меня волнует. И проблема в том, что эта тема постоянно всплывает в перечне непрочитанных и приходится нажимать на неё, чтобы она не отображалась.

> Правильно, никаким.
Неправильно, каким. С точки зрения информационной безопасности нельзя пользоваться программой, устройство которой мы не знаем, в том числе и компилятором. Как устроен компилятор КП? Никто не знает. Может быть, отдельные люди разобрались, но результаты своего анализа никто не опубликовал.

> Перевод переменных это самый настоящий Сизифов труд.
Ненастоящий.

> т.к. никто не собирает компилятор из исходников


> эта тема постоянно всплывает в перечне непрочитанных и приходится нажимать на неё, чтобы она не отображалась.

Придётся потерпеть

Перевод переменных не имеет никакого отношения к пониманию. Можно понять исходный вариант, а можно и не понять переведённый.

Ну с чего вы взяли, что 'никто не понимает'?
С чего вы взяли, что перевод как-либо поспособствует пониманию?

Напрасная трата времени, не более.

Из-за дискуссий всплывает тема.