Язык программирования Картарика.

Кто и где ответил? Из разработчков «однонацональных языков в многонациональной стране» никто не ответил, были только лозунги и манифесты (которые не требуют доказательства)

Сертификация это и есть надзор/контроль, который был упомянут в той аналогии. Сертификация это не скрепы, очнись.

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

нужно во всём мире внедрить программирование на русском языке

Нет, не нужно. Никому, кроме тебя.

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

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

Спасибо, анон, ты сэкономил мне несколько минут писанины

Опять ты? Тот, который моделирует реальность на основе фантастических художственных произведений.

Поискал уже удалили. Поэтому остаемся каждый при своём. Но 1С-ники не очень любят английский код.

Ясно дело не любят, у них и шаблоны в конфигураторе, и привычка комплита на русском. Зачем писать на языке Х, если весь код, примеры, библиотеки и опыт на языке У?

Язык 1С существует в вариантах на русском и английском языке. И при переходе на англоязычный вариант 1С, скорость разработки падает в 2 раза. Примерно так описывалось. Здесь именно что на одном языке программирования всё происходит.

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

Public Domain - это вообще переход в общественное достояние. То есть передача имущественных прав, которые никогда не существовали или истекли. Денис своевольно декларирует передачу имущественных прав в общественное пользование, не будучи автором. И буквально нарушает закон.

Согласно ГК РФ не 50 лет после смерти, а 70 лет. В случае если произведение было опубликовано анонимно, то просто 70 лет с момента его публикации (никто же не знает, когда автор умрёт). Ну и еще по ГК исходные коды ПО - это литературные произведения, и на них действуют все те же ограничения и правила. В остальном все верно.

Абстракции абстракциями, а опыт никто не отменял.

Дело не в опыте, а в том, что СчётФактура.Контрагент.ИНН читается сразу и интуитивно, а Invoice.Customer.TIN заставляет задуматься, Invoice - это счёт-фактура или ТОРГ-12. Customer - это Контрагент или Партнёр. TIN, вообще, если не помнишь, то и словарик не поможет (пишет «жесть»), надо идти в интерфейс и смотреть, как же он там называется.

Поискал уже удалили.

Я не могу проверить это утверждение. «Поэтому остаемся каждый при своём.»

Но 1С-ники не очень любят английский код.

1С - это замкнутая ограниченнная среда (начиналась как). Там не надо взимодействовать с окружением. И то они не начинали на «единственно верном национальном языке в многонациональной стране». Был у меня опыт с 1С когда-то давно, одной русской раскладкой там далеко не уедешь, сейчас - не знаю.

А вы же, разработчки «единственно верного национального языка в многонациональной стране», декларируете универсальность. Что автоматом заставляет думать о взамодействии окружением, которое не одноязычное.

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

Я не декларирую универсальность.

Где узнать про предметную область применения языка: алгебра, геометрия, нотное письмо, бухгалтерия, складской учет, язык асемблера для zx spectrum?

Проведи эксперимент. Напиши на кириллическом языке 1С тетрис, ну или на своем Картарике. И напиши эквивалентный код тетриса на любом современном латинском языке программирования - java/python/js/php/rust/go/c# И потом запили публичный опрос на тему, какой из двух исходных кодов будет понятнее для окружающих.

Почесывание ЧСВ и вниманиеблядствование.

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

Пока как разработка корпоративных приложений.

Ты знаешь, что означает «корпорация»? Это объединение разных предприятий, это объединение разных предметных областей.

Ты ничего не понимаешь.

Можно. Можно даже не пилить, а готовое взять. Наверняка есть куча реализованных тетрисов/змеек и т.п. Вопрос а что это даст?

Если 10% скажут что им понятнее на 1С чем на Python. Значит, я просто пишу свой ЯП для этих 10%. А если 90% будут «за», тем более хорошо. Возможен, конечно, вариант менее 10% «за», но не думаю, что он такой большой.

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

Тот, который моделирует реальность на основе фантастических художственных произведений.

При чём тут моделирование реальности? Это всего лишь мнение одного не самого глупого американца.

Можно либо сделаться бледной тенью США, как согласились Япония и Индия, либо идти своим путём как делает КНР, КНДР, Тайланд и МО РФ.

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

Надо. Это надо делать в обоих случаях. Просто в случае нового ЯП добавляется стоимость создания самого ЯП и инструментария для него. Так вот, моя мысль в том, что на фоне написания библиотек она не слишком заметна. Зато оглядки на существующие решения потребуется куда меньше.

Вот если бы программы писались в натуральной семантике

Предлагаешь в очередной раз переизобрести COBOL?

Зато оглядки на существующие решения потребуется куда меньше.

И при реализации проще исправлять коды исключений, сообщения стандартных утилит и прочее.

Я сейчас пишу свой язык поверх Racket. В плюсе полная совместимость и возможность использовать готовые библиотеки и IDE. В минусе, например, тип exn (аналог C++ std::exception): с одной стороны, надо его заменять на русифицированный, с другой стороны все библиотечные функции ожидают, что на типовые ошибки будут возвращены наследники этого типа. Можно внутри оставить exn, и отлавливать только сообщения, но тогда будет протечка абстракции при рефлексии. Можно переписать все функции стандартной библиотеки со своим типом, но это много и может быть проблема взаимодействия с внешними библиотеками.

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

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

Что будет? Будет форк, имеющий потенциально куда большую базу, чем оригинальная версия. И, в самом лучшем случае, разработчикам придется тащить два форка. В худшем — форки разойдутся и русскоязычная версия перестанет со временем использоваться. Потому что слишком дорого всё это.

В мире идет языковая конвергенция. А ты предлагаешь сделать silo, и сидеть в нем.

Упаси меня Здравый Смысл! Я просто хотел сказать, что мы не пишем программы в натуральной семантике)) В ней мы постим на LOR))

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

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

В мире идет языковая конвергенция. А ты предлагаешь сделать silo, и сидеть в нем.

Где? Если раньше был хотя бы сишный фактический стандарт, то теперь подружить библиотеки на C#, Java, Rust, JS, C++ и Haskell в один бинарник практически невозможно.

Если 10% скажут что им понятнее на 1С чем на Python. Значит, я просто пишу свой ЯП для этих 10%

Не правильный вывод, и эксперимент не совсем правильный. Сравнивай на схожих языках. 1С RU vs 1С EN. Или свой язык с питоносинтаксисом против питона. Тогда ты сможешь увидеть кому понятнее именно кириллица.

А то сравнение, что ты описал, показывает не востребованность языка с кириллицей, а то на сколько выбранный тобой синтаксис и стиль понятен людям. И с устраивающими тебя 10% в таком эксперименте надо что-то менять, ибо люди не понимают, что там написано.

Про языковую конвергенцию. Да, в настоящее время количество языков уменьшается, особенно гибнут малые языки. Но лингвисты говорят, что до единого языка всё равно не дойдёт. Процессы распада языков тоже никуда не делись. Например, очень вероятна ситуация что лет через 500 может появиться отдельный американский, британский и австралийский языки (родственные языки примерно, как современный русский, белорусский и украинский), а современный английский будет примерно как латынь в средневековой Европе или церковнославянский в средневековой России. Вариантов вообще большое количество, и то что сейчас английский шагает по планете вообще не говорит о том, что дальше будет также.

Про проблему silo. Тоже много думаю над ней. Так как есть куча библиотек на английском и при разработке не хотелось бы изобретать велосипеды с написанием библиотек, то можно делать перевод интерфейса. То есть есть библиотека с функцией

int GetCount()

У нас есть заголовочный файл, в котором описан интерфейс библиотеки

целое GetCount/ПолучитьЧисло()

И в Картарике уже пишется просто ПолучитьЧисло(). Тут я сразу могу вопрос задать, который меня мучает. Можно ли подобрать лаконичный перевод для пары слов Get/Set. В 3 или 4 буквы длиной ну и идеально, если будут рифмоваться. Важно, так как такие пары используются очень часто.

И вторая проблема сообщения на английском внутри этих библиотек. Ошибки и прочая информация. Решать можно по-разному в зависимости от нужности библиотеки и её объема. Можно просто забить, а можно заморочить форкнуть и перевести.

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

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

Я вообще считаю, что как раз игнорирование англоязычных библиотек было бы большой ошибкой. Я программирую на С++ и в последние лет 10 куда не прихожу на проекте обязательно будет штук 5 сторонних библиотек. Сейчас без этого никак и с нуля разрабатывать библиотеки это глупость. Где в этой ветке звучала мысль, что мы просто смещаем границу для перевода. Если говорить в этих терминах, то сейчас каждый программист является параллельно и переводчиком, а я хочу перенести переводы на интерфейсы библиотек.

Можно либо сделаться бледной тенью США, как согласились Япония и Индия, либо идти своим путём как делает КНР, КНДР, Тайланд и МО РФ.

Япония очень сильно отличается от США. РФ тут больше походит на бледную тень

Да согласен, 1С RU vs 1С EN был бы намного лучше.

Qt, например, ведь никто не форкает

Если не считать патченные для разных дистрибутивов версии форками, то существует как минимум еще 2 форка Qt3 и Qt5. Первый форкнули для TDE, а второй для избавления от MOC-генератора и использования фичей современных плюсов. К сожалению я не смог вспомнить название второго, что бы дать ссылку, но может EXL поможет, кажется это именно он о нем писал ранее на лоре

К сожалению я не смог вспомнить название второго

https://www.copperspice.com/

Они кстати переписали под BSD и вычленили часть функциональности из Qt.

Можно пользоваться отдельно сигналами/слотами:

https://github.com/copperspice/cs_signal

Или строками с поддержкой utf:

https://github.com/copperspice/cs_string

Не таща целиком copperspice (или Qt)

https://www.copperspice.com/

Я тебя понимаю. Если интернационализировать саму кодовую базу и язык через языковой оверлей над промежуточным представлением кода программы, примерно как l10n/i18n работают для UI, то это годно. Если так, то я желаю тебе удачи!

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

Я про конвергенцию разговорного языка. КАк заметил zx_90, сейчас лучше говорить не о конвергенции, а о вытеснении языков. Так как, например, английский просто вытесняет все остальные языки. Но на длительной перспективе конвергенция будет.

Что же касается языков программирования, у Oracle есть неплохой результат с GraalVM. Там стоятся динамические мосты между различными рантаймами. В результате чего можно просто обмениваться объектами (не всегда). Python, Java, JavaScript просто работают вместе. Там есть заморочки, но оно работает.

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

Вот смотри. Была такая швейцарская фирма Crypto AG, она делала шифровальные машинки. Весь цивилизованный мир их покупал, в т.ч., к примеру, арабы и Аргентина. Их использовали правительства. Но СССР и Китай не покупали, ибо железный занавес и отвратительное тебе поведение. И так длилось порядка 40-60 лет (есть статьи об этой истории, почитай их, я не помню такой конкретики, дело не в ней).

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

В прошлом или позапрошлом году внезапно выяснилось, что Crypto AG то ли изначально была создана ЦРУ, то ли быстро куплена ЦРУ и что все машинки были скомпрометированы. Соответственно, во время Фолклендской войны США знали, что обсуждают в правительстве Аргентины и т.п.

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

Можно также посмотреть на судьбу МКС - проект распадается. Почему-то США не хотят глобалистично объединяться с Россией и летать на Союзах, а построили свои КК.

Т.е. атмосфера сейчас такая, что рушатся ранее достигнутые договоры, а не заключаются новые. И естественно, Линукс, как один из столпов технологии, эта проблема обойти стороной не может. Как именно это будет происходить - я пока не знаю. Например, ты вдруг можешь оказаться хайли лайкели российским шпионом и тебя выгонят из Федоры, хорошо если не посадят.

Можно ли подобрать лаконичный перевод для пары слов Get/Set. В 3 или 4 буквы длиной ну и идеально, если будут рифмоваться.

Только префиксы. Типа Пол/Уст или Вз/Уст. Или в стиле переводов Дэна ДайЧисло(), НаЧисло()/БериЧисло().

Если не считать патченные для разных дистрибутивов версии форками, то существует как минимум еще 2 форка Qt3 и Qt5.

Я имел в виду, нет реализаций на Python, C#, Lisp, Java, … Но есть обёртки для доступа.

Я про конвергенцию разговорного языка. КАк заметил zx_90, сейчас лучше говорить не о конвергенции, а о вытеснении языков. Так как, например, английский просто вытесняет все остальные языки. Но на длительной перспективе конвергенция будет.

Тоже спорно. На фоне единой латыни несколько веков назад сейчас конвергенцией и не пахнет. Английский на должности «вытеснителя» тоже не первый: в 19 веке был французский, потом немецкий.

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

Тоже спорно.

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

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

Идея такая, что единый язык энергетически более выгоден.

Эта идея ещё во времена Эсперанто была. Не работает. По той же причине, по которой нельзя сделать единый язык программирования. Между ними тоже есть заимствования (лямбды в C++, макросы в Rust, …), есть вытеснение (PL/I, COBOL), но конвергенция так и остаётся мечтой. При том, что эмоциональных факторов при выборе языка программирования гораздо меньше.

Не работает.

Так сколько того времени прошло-то?)

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

Вот как появятся практичные полиморфные рантаймы, вот тогда конвергенция языков программирования станет практически возможной. А пока они даже не соприкасаются, чтобы как-то конвергировать естественным образом. Живут каждый — в своей silo.

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

PS. Добавлю во избежание возражений. GraalVM умеет компилироваться в екзешник (буквально), причем эта функция работает для основных поддерживаемых рантаймом языков. Т.е. технически можно иметь в одном экзешнике и питон, и джава-скрипт, и джава, и даже си++. И все они будут неплохо друг с другом дружить. И не будет избыточности JIT-а в рантайме. Я только не знаю, какие ограничения при этом наложатся на AOT-компилируемые таким образом многоязыковые программы.

Вот, кстати, еще про универсальный язык...

Все языки программирования (даже data-parallel), сейчас с точки зрения человека — control flow. Особняком стоит Prolog и некоторые родственные функционально-логические ЯП, но они погоды не делают. Почему так? Потому что data flow (и особенно — «широкий» data flow) мы программировать уже не можем. Оно не вписывается в наш лингвистический аппарат и возможности кратковременной памяти. Для data flow уже нужны методы индуктивного программирования, являющиеся частью машинного обучения.

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

Когда же мы переходим на уровень ML, то «языки программирования» просто обобщаются до уровня априорных распределений. Для каждого распределения характерен свой «язык программирования» в генеративной модели. И вот тут оказывается, что универсальное априорное распределение таки существует (Ахтунг! Впереди — матан). И, соответственно, «универсальный язык программирования» тоже может существовать. Только выглядеть он может совсем не так, как мы (жалкие людишки) ожидаем. И уж точно быть вне наших возможностей программирования.

Что, в прочем, не означает, что мы не будем к нему стремиться. Поскольку последнее — энергетически выгодно (но это уже другая тема).

потому что надо полностью переписывать - теряется смысл форка. Но на этих языках есть свои аналогичные проекты

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

Java, Scala, Clojure, … - почему-то одной Java не ограничились.

Так и с естественными языками. Любой перевод теряет часть информации. И на разных языках разные мыслительные категории.

И все они будут неплохо друг с другом дружить.

Как из си++ будешь вызывать питоновский yield? В смысле, какой у него тип? Или как будешь отображать прототипные объекты JS на классы Java? У разных языков разная семантика и без потерь перевод не происходит.

Почему так? Потому что data flow (и особенно — «широкий» data flow) мы программировать уже не можем.

А конвейеры UNIX shell не то?

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

Звучит умно, но смысле не понял. Как априорным распределением описать, например, Haskell (одноаргументные функции, ленивость, чистота) и Rust (времена жизни, макросы)?

потому что надо полностью переписывать - теряется смысл форка

Вот именно. Поэтому если что-то будет для русскоязычного языка, форкать не будут. Это к ответу на:

Язык программирования Картарика. (комментарий)

Китайцы 1С сопровождали на русском. Потому что проще выучить русский в объёме 1С, чем переписать всю конфигурацию на английский (или английские ключевые слова с китайскими идентификаторами).

P.S. Кто-нибудь знает куда tkLOR делся? Там вроде было удобно ветки видеть.

Это к ответу на

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