Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Русский язык в ИТ » Возможны два разных вида перевода исходников - поверх и внутрь


Возможны два разных вида перевода исходников - поверх и внутрь

Сообщений 1 страница 30 из 42

1

И разнообразные сочетания их.
1. Перевод для чтения, когда  исходники не заменяются, а выполняются преобразования для их отображения
2. Перевод преобразованием работающих исходников

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

2

Сейчас в цейтноте. В целом идея сделать перевод "слово в слово", ничего не сливая и не раздваивая, интересна. Почему я до сих пор не сделал русские ключевые слова? Рано. Сейчас мы стоим на двух ногах - у нас есть старый компилятор и есть новый - они идентичны по функционалу (почти).
Т.е. можно из любой сборки ББ сделать Ня. Если Ня будет написан на Ня, то нельзя будет его раскрутить из любой сборки. А понадобится транспилятор Ня<->КП. Хотя бы такой простой, который заменяет только ключевые слова. Но кто его напишет? Он же на дереве не растёт? Мне некогда. В информатике-21 есть транспилятор в одну сторону. Т.е. нужно как минимум его сделать в две стороны и внешней программой.

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

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

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

В целом, если кто-то возьмётся написать транспилятор, заменяющий ключевые слова, я готов сделать такой перевод на 3/4. 400 слов мы руками как-нибудь переведём, не нужен тут ни гугл, ни какие другие инструменты. Только вот сами замены должны делаться автоматически программкой, которая лексит, заменяет и обратно разлексивает. 

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

P.S. И кстати, сейчас по границе рус-англ проходит и граница "понято-не понято". Это достаточно важно.

Отредактировано БудДен (2018-12-29 15:04:51)

3

Возможно, я начал понимать суть предложения.

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

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

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

Отредактировано БудДен (2018-12-29 16:18:38)

4

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

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

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

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

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

Отредактировано БудДен (2018-12-30 13:49:11)

5

Есть два пути. Первый сделать так как получится. Второй провести сравнительный анализ решений. 2-3  решения надо закодировать.

В языках есть куча артефактов доставшихся им в наследство от старых разраьотак. Досих пор находят баги в коде 60-годов.

Разработка библиотек это процесс на десятилетия.
Взять работу с файлами процесс кодирования можно улучшить если проработать семантику функций.

В виндоусе есть проблема с передачью потоков стандартного в/в данных между программами.

Или сокеты  нет ни одной нормальной библиотеке. И тоже самое с мультимедией.
Дедлоки потеря данных и фрагментация. Не детерменированная смена данных.

Проблема в том что разработка идёт годами. А может и десятилетиями. Это в последнии годы стали популярны тесты. А до этого был баг на баге.

Так что выход один приставить человека к каждой библиотеке. А лучше по 3. Один пишет другой проверяет а третий контроллирует жтиз двух умников.

6

Новичек он же читатель знает в 30 раз меньше разработчика. А переводчик раз в 6 меньше разработчика. Так что без вкладывание значительных рессурсов неполучится.

7

БудДен написал(а):

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

БудДен написал(а):

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

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

8

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

Отредактировано БудДен (2019-01-01 23:47:25)

9

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

10

БудДен написал(а):

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

Не, если не менять синтаксис и семантику, то для замены имен нужен простейший парсер.
По РБНФ там штук 40 обозначений. Это строк 300-400 на паскалевых языках. Либо можно вырезать из самого Обероновского компилятора.
На уровне лексем - тоже можно что-то делать, но это слишком грубо, много ручного контроля и тоже нужны средства разделения имен.
А парсер по РБНФ может уже классифицировать имена, разделять тезок и определять перекрытия.

11

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

При том, я сильно сомневаюсь в том, что реальный компилятор КП полностью соответствует документации. Например, были проблемы с некоторыми SYSFLAG-ами. Попытка написать свой парсер
на всё это напорется.

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

Лучшим вариантом было бы найти аналогичный оберону компилятор, но на лиспе. Более простой, чем Common Lisp. Что-то вроде Scheme. И к нему уже приделать «человеческий» синтаксис. Т.е.
план, которому я следовал в случае Яра, получается более правильным. Я свято верю в то, что ни один компилятор Scheme не так ужасен, как компилятор ББЦБ.
Я начал в фоновом режиме искать. Через некоторое время должен найтись, если он вообще есть в природе.

Или нужно сжать зубы и потерпеть.

Отредактировано БудДен (2019-01-05 13:51:29)

12

Хреново получается. Потому что похоже, что я ошибся, выбрав блекбокс. Надо было брать А2 или проект Оберон. Потому что блекбокс - это всего лишь "среда", а иные упомянутые - это операционные системы. Если это подтвердится, то все переименовывания придётся повторить. У нас, правда, есть переводы в уголках, но они не слишком хорошо подтянуты к тем словам, которые они заменяют - надо было ставить их вплотную к переводимым словам. Их всего 156 на данный момент. Но теперь получается, что ручное переименование не имеет смысла, а нужно только автоматическое. Плохо, не нравится. Переводить потихоньку в хоббийном режиме по часу в день можно, а вот писать метапрограммное средство в таком режиме - это уже задача.

13

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

14

БудДен написал(а):

Потому что похоже, что я ошибся, выбрав блекбокс. Надо было брать А2 или проект Оберон

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

БудДен написал(а):

Но теперь получается, что ручное переименование не имеет смысла, а нужно только автоматическое. Плохо, не нравится.

Нужно не ручное и не автоматическое, а автоматизированное с простым и быстрым управлением.

БудДен написал(а):

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

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

из Обероновского компилятора ничего вырезать не надо

На это можно смотреть по-другому:
Рабочий? Да. Кодогенератор нужен? Нет. Дерево нужно? Нет. Парсер нужен? Да. Лексер нужен? Да, потому что на него завязан парсер.

15

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

Код:
НовоеРусскоеНазвание(* <OldEnglishName> *) 

там, где это имя определяется. Инструмент должен уметь собрать все такие комментарии и сделать «рокировочку», переводя русский в английский и наоборот. А ещё лучше хранить этот словарь отдельно от кода, например,

Код:
Модуль.Константы.НовоеРусскоеНазвание = OldEnglishName

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

Мы об одном и том же говорим?

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

16

БудДен написал(а):

парсер со свойствами линзы, понимание семантики, и понимание, откуда берутся зависимости

Там из семантики импорт/экспорт, типизация и правила перекрытия для определения правильных ссылок на имена. И все строгие.

БудДен написал(а):

А ещё лучше хранить этот словарь отдельно от кода

Несомненно.

17

В ходе проверки скрытых тем оказалось, что давно было  вот такое обероновское с русским языком

Предлагаемый   вариант   Оберон-07   с   полной   одновременной
поддержкой   русского   и   английского   языка   в   исходном   тексте
основан на разработке Антона Кротова (akron), исходные тексты
распространяется   под   лицензией  GPL   3,  файлы   за   редакцией
Валерия Шипкова (prospero78su),  которые распространяются под
лицензией  BSD-2
.

Но Антон сменил лицензию на BSD-2, насколько помнится.

Что там c лицензией A2OS?

18

> Но Антон сменил лицензию на BSD-2, насколько помнится.
Где? От этого всё зависит. В указанном русскоязычном компиляторе с лицензиями ад. Впрочем, есть мнение, что и GPL, и BSD, и Public domain в России ничтожны и можно всё это игнорировать.

> Что там c лицензией A2OS?
https://github.com/metacore/A2OS/blob/m … icense.txt

Как я понял, это пермиссивная лицензия. GPL там относится к отдельным приложениям.

19

БудДен написал(а):

Где?

Просто prospero78su делал русификацию форка компилятора Антона год-два назад.
А в последнее время он же делал форк того же компилятора уже под лицензией BSD-2:
https://github.com/prospero78/oberon-07-compiler
и в оригинале соответственно BSD-2 (видимо 3 месяца как):
https://github.com/AntKrotov/oberon-07-compiler

На форуме оберонщиков можно уточнить про статус старого форка с русификацией.

20

>    В отличие от многих Oberon-реализаций, сборщик мусора и динамическая  модульность отсутствуют
Если поменял лицензию, то ок. А так - неинтересно. Хотя пополнить словарь переводов теоретически можно.

21

Нашёл модули с интересными названиями в A2: ModuleTrees.Mod, ModuleParser.Mod. Внутрь не глядел - ищу другое, а именно - как перейти к исходнику процедуры, кликнув по ней. Пока не нахожу.

22

Module.GetProcedure - поиск процедуры по имени. Поможет ли для поиска исходника?

23

Начал ругать очередного корреспондента на оберонцоре и понял, что в связи с открытием нового, более хорошо написанного компилятора актуальность задачи перевода компилятора теряет актуальность. Создание исходника компилятора на РЯ не было самоцелью, а было побочным продуктом - раз уж осознавать и расшифровывать - то сразу над на РЯ переводить. Раз не надо расшифровывать, то не надо и переводить. Лис же не собирается нам помогать, а значит, спроса на РЯ нет. Будет спрос - тогда переведём. С ней теряет актуальность и задача создания данного инструмента (рефакторинга «переименуй переменную»). Т.е. рефакторинги и умная ИСР всё равно нужны, но уже не так критичны. Актуальной становится задача освоения A2 и создания полноценного набора рабочих инструментов для неё. Здесь нужно понять, как правильно поставить приоритеты. Например, с т.з отладки представляется интересной отладка не "изнутри" системы, а "извне" эмулятора, или удалённая отладка системы, которая находится на устройстве. Поскольку отлаживать систему с кооперативной мультизадачностью из неё самой же - это дело стрёмное.

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

Отредактировано БудДен (2019-01-11 01:10:35)

24

AO2 - в папке Source в файлах Mod 100тыс. латиносочетаний, половина массы - 640, 3/4 - 5700.

в связи с открытием нового, более хорошо написанного компилятора

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

25

БудДен
Чем новый компилятор лучше старого?
И тоже самое касается среды?  А то я так понял вас поразило умение прыгать по функциям. Это же не трудна прикрутить.

26

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

> А то я так понял вас поразило умение прыгать по функциям.
Нет, меня скорее поражает его отсутствие. Среда там хороша раскраской и показом структуры кода. Там нет команды "перейти к определению",
это очень плохо.

> AO2 - в папке Source в файлах Mod 100тыс. латиносочетаний, половина массы - 640, 3/4 - 5700.
В случае A2 перевод не так актуален. Актуальнее разобраться, что к чему. Не хватает (лично мне) отладочных средств. Там есть aosdebug.exe,
который, как я и хотел, отлаживает весь эмулятор целиком под виндой. Но как он работает, и работает ли - я пока не понял.

Отредактировано БудДен (2019-01-11 17:15:18)

27

БудДен написал(а):

количеством комментариев

В AO2/Source на заметки в в Mod-файлах 17% латиномассы против, 12,5% в BBCB%.
Также там 15% уникальных буквосочетаний, которых нет в коде.
Кое-что написано по-немецки.
Без комментов половина латмассы это 500 сочетаний, 3/4 - 5400. Из 85 тыс.
В BBCB 50 тыс. уникальных буквосочетаний латиницы, в 4 раза меньше по ее объему (и по строкам кода тоже).
В AO2 надо смотреть долю GPL.

Вики про оберон-проекты ETH

28

По-моему там GPL только какой-то сторонний проект про статистику. Да, кода там намного больше, но он зато намного понятнее. Совмещение этапов компиляции никак не способствует простоте компилятора.

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

В общем, я пока не понимаю, куда дальше двигаться. У меня изначально была цель "сделать для себя и работать на рынке разработки ПО в одно лицо", потом потянуло в гигантоманию. Но поскольку гигантские проекты зависят от чужих больших денег, которых почему-то никто не дал, то и надо снова вернуться к соразмерному себе. Язык программирования я сделать могу. Собственно, Яр в большой степени готов как транспилятор, можно на JS или Golang перенацелить. Но рынок разработки ПО теперь совсем другой. И я уже не хочу заниматься разработкой в одно лицо. Я не вижу, честно говоря, сбыта своих услуг. В общем, я как-то приуныл, если честно сказать.

29

МихалНик написал(а):

В AO2/Source на заметки в в Mod-файлах 17% латиномассы против, 12,5% в BBCB

Не учтена доля возможно закомменченного исходного кода. А значит сравнение некорректно.

30

В принципе есть вариант транслировать компилятор Fox на КП и встроить его в ББЦБ. Трансляция, скорее всего, будет достаточно простой, т.к. оберон - он и в африке оберон, а никакие там AWAITы в компиляторе не нужны. Так получится ББЦБ с хорошим компилятором. Впрочем, ББЦБ ужасен и во многих других отношениях, так что не знаю, насколько это надо. Но неохота возиться со спецификой ОС от слова "совсем".

Отредактировано БудДен (2019-01-12 00:23:06)


Вы здесь » Ремесло программиста » Русский язык в ИТ » Возможны два разных вида перевода исходников - поверх и внутрь