Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Энтузиасты-разработчики компиляторов и их проекты

Перечень

(в алфавитном порядке, по ссылке — подробнее)

Подробнее

  • Безымянный язык программирования.
    Автор: Олександр Каленюк.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования 11l.
    Автор: Александр Третьяк.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования .
    Разработчик: компания "1С".
    Трудно представить успех одноимённой программы с англоязычным языком программирования.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Эзотерический Lisp-подобный язык программирования ALLang
    Автор: Геннадий Коваленко.
    Статус: разработка окончена.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования AL-IV (АЛФОР)
    Автор: Владимир Кладов.
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Animo, описание на английском.
    Авторы: Дмитрий Шабанов, Евгений Газдовский
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Argentum
    Автор: пользователь с ником @kotan-11 на Хабре
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования BAYRELL Language
    Автор: Ильдар «vistoyn».
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Cine
    Автор: Александр «Taetricus».
    Статус: проект закрыт.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Cj
    Автор: «sitev_ru»
    Статус: проект развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования COLAMO
    Автор: Научно-исследовательский центр супер-ЭВМ и нейрокомпьютеров, г. Таганрог.
    Статус: проект развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Context
    Автор: Андрей Хохлов.
    Статус: проект не развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Delavar
    Автор: Роман Пристинский
    Статус: проект не развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования DEmbro
    Автор: некто, называющий себя Дож.
    Форто-подобный язык.
    Статус: проект не развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования ELENA
    Автор: Alex Rakov.
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования GAZ
    Автор: Иван Горчаков
    Статус: развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Gentee
    Автор: Алексей Кривоногов
    Последняя версия: 28 октября 2010 г., довольно-таки активен форум.
    Статус: проект не развивается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Языки программирования Jam и Si
    Автор: Игорь ?
    Компилируются в Java.
    Статус: проект заморожен, сайт ishir.ru не работает.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Jancy
    Разработчик: компания Tibbo.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Jpho (или Jfo)
    Автор: Игорь Томасов
    Прототипом языка Jfo является язык Forth. Это скриптовый язык, интегрированный с Java и оперирующий объектам Java.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования K++
    Авторы: Дмитрий Кашицын, Дмитрий Роот.
    Работает поверх собственной виртуальной машины, декларируется кроссплатформенность.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Kotlin
    Разработчики: компания «JetBrains», Андрей Бреслав и коллеги по «JetBrains».
    Единственный из отечественных языков, который в ближайшее время имеет шансы стать «мировым».

    Хотя о том, что Kotlin будет официально использоваться для разработки под Android сообщили только весной 2017 года, на конференции Google I/O 2017, он уже обрел немалую популярность и полюбился разработчикам. Ещё прошлой осенью аналитики компании Realm сообщали, что Kotlin набирает популярность с огромной скоростью. К примеру, в мае 2017 года, до проведения конференции Google I/O, Kotlin использовали 7,4% девелоперов, а к концу сентября 2017 года этот показатель удвоился и составил 14,7%.

    Исследователи Realm полагали, что если темпы роста сохранятся на таком же уровне, то уже к декабрю 2018 года доля Kotlin составит 51% рынка, то есть Java потеряет свое лидерство. В настоящее время Kotlin наиболее популярен в Германии, Японии, Индии, США и Бразилии.

    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования LN
    Автор: пользователь Хабра с ником «Icon0clast»
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования LUX
    Автор: В.М.Паньков
    Статус: проект заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Lviv (Львов, Украина)
    Автор: неизвестен.
    Статус: проект заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Mash
    Автор: Павел Чернов
    Статус: проект заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования NewLang
    Автор: Александр Рябиков
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования o42a
    Автор: Руслан Лопатин
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования ObjectScript
    Автор: Евгений Головин
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования OneScript
    Автор: Андрей Овсянкин.
    Статус: развивается, поддерживается.
    Разработчики декларируют совместимость с языком 1С, при этом OneScript не привязан к платформе 1С, что даёт возможность не связываться с вопросами лицензирования и избежать покупки 1С.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Orion
    Автор: Дмитрий Зайцев
    Статус: проект заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Parser
    Разработчики: студия Артемия Лебедева
    Даже бывают вакансии со знанием этого языка.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Диалект языка программирования PL/1 с оригинальным расширением стандарта.
    Автор: Караваев Дмитрий Юрьевич
    Статус: развивается и поддерживается с 1987 года..
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования PL2
    Автор: Алексей Подоров
    Статус: проект заморожен.
    Кириллические идентификаторы и/или ключевые слова: поддерживается.

  • Язык программирования Rave
    Автор: Ttimofeyka
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Relax
    Автор: Данил «Lofectr».
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Shar
    Автор: Александр «Taetricus».
    развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования SLang
    Авторы: Алексей Канатов, Евгений Зуев.
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Sound
    Автор: Юлий Лапкин.
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования TIScript
    Автор: Andrew Fedoniouk.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Umka
    Автор: Василий Терешков.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Una
    Автор: Сергей Шпадырев.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Ü
    Автор: под ником «Panzerschrek».
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования V
    Автор: Александр Медведников.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования vkacl
    Автор: Виктор Кон.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Yalgol
    Автор: Алексей Яковлев.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Адина
    Автор: Роман Клочков.
    Статус: развивается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Алгоритм-2
    Автор: неизвестен.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Валентина-2
    Автор: под псевдонимом «Уткин».
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Визуальная Р-технология программирования
    Автор: Игорь Вельбицкий, Фонд Глушкова, Киев.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Глагол
    Автор языка предпочитал себя не называть, скромно именуясь "Издателем". Популяризацией этого языка чаще всего занимался программист под ником "Сый". Он же писал программы на Глаголе и являлся его знатоком. По всей видимости, проект заброшен в 2008 году; в 2013 году прекратил работу сайт "Сыя", затем сайт "Издателя". Нашлись продолжатели Глагола: сайт Тимофеева.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Гонец
    Автор: Роман Цованян.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Дизель-паскаль.
    Автор: Юрий Копнин.
    Является продолжением языка Суржи после переноса его на платформу Lazarus. После перевода LCL на Юникод планируется возобновление поддержки кириллицы при программировании.
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Интерпретатор Алгоритмического Языка
    Автор: Владимир Мальцев.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Кантор
    Автор: Канторовы системы, Владислав Джавадов
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: в перспектве — да.

  • Язык программирования Картарика
    Автор: Евгений Зайцев
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Клаус
    Автор: Константин Захаров
    Статус: в разработке.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Концепт
    Автор: Дмитрий В.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Ксерион
    Автор: Денис Гаев
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования Лися
    Разработчик: Андрей Шпагин
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования КуМир
    Разработчик: научно-исследовательский институт системных исследований РАН.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Перфолента
    Разработчик: Частное предприятие «ПРОМКОД» (Украина).
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Пифагор
    Разработчик: Институт Космических и Информационных Технологий Сибирского Федерального Университета.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования ПОП
    Автор: Иван Павлов.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Язык программирования ПРОФТ
    Автор: Фёдор Тюленев.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Рапира
    Автор: академик Ершов, Школьный Cектор Ассоциации RELARN.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Рефал

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

    Рефал-2 был когда-то написан для ЭВМ, позже перенесён на PC, поддерживается Леонидом Белоусом из Харькова. Эта реализация Рефала-2 поддерживает русскоязычные идентификаторы.

    Рефал-5 был изначально разработан Турчиным в Нью-Йоркском Сити-колледже, сейчас поддерживается Андреем Немытых из Переславля-Залесского (Институт программных систем РАН). Русскоязычные идентификаторы не поддерживаются.

    Рефал-6 когда-то был написан в Институте программных систем РАН (Переславль-Залесский), потом его передали Аркадию Климову, который его основательно доработал. Русскоязычные идентификаторы не поддерживаются.

    FLAC — разновидность Рефала, ориентированная на компьютерную алгебру. Разрабатывалась в Институте программных систем РАН. Про русскоязычные в документации ничего не говорится.

    Рефал Плюс — тоже разрабатывался в Институте программных систем РАН. Русскоязычные имена функций, вроде, можно использовать, но только их придётся заключать в кавычки. Русскоязычные имена переменных использовать вроде нельзя.

    Это как бы «официальные» Рефалы. Есть неофициальные.

    Рефал/2 Василия Стеллецкого. Василий Стеллецкий в начале 90-х заметил, что Рефала под ПК нет и сам себе его написал. Получился немного ограниченный по возможностям рабочий инструмент — для нужд Василия его достаточно. Поддерживает русскоязычные идентификаторы (в кодировке 866). Даже более того, вызовы функций у него оформляются как k/имя/ аргумент. (в конце точка) — букву «k» в начале можно делать и русскую, и латинскую.

    Рефал-5λ — компилятор надмножества Рефала-5 (со вложенными функциями и другими удобствами) в Си++, написан Александром Коноваловым (МГТУ им. Баумана). Русскоязычные идентификаторы пока не поддерживаются. Поддержка планируется с началом поддержки Юникода.

    Интерпретатор Рефал-2 — разработка МГУ.

    Все Рефалы, кроме последнего — компиляторы, большинство — компиляторы в байткод.


  • Язык программирования Рефлекс (Си с процессами)
    Автор: Владимир Зюбин.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования РС/Б
    Автор: под ником «AlexCab».
    Статус: закрыт.
    Кириллические идентификаторы и/или ключевые слова: да.

  • РуСи
  • Диалект Си — РуСи
    Автор: Андрей Николаевич Терехов.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: нет.

  • Русский язык программирования, он же RuSL (Russian Scripting Language)
    Автор: Егор Замахов.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • РЯП (русский язык программирования, он же Солуни)
    Доступен архив РЯП.
    Автор: Алексей Соломеин.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Санда
    Автор: Владимир Соколов.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Проект Таметко
    Автор: Данил Харитонов.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Тривиль
    Автор: Алексей Недоря.
    Статус: начало разработки.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Проект Эллочка
    Автор: Эрих Гаузер.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Яр, диалект Оберона-2 с оригинальными расширенями.
    Автор: Денис Будяк.
    Статус: развивается, поддерживается.
    Кириллические идентификаторы и/или ключевые слова: да.

  • Язык программирования Яр (старая версия)
    Автор: Денис Будяк.
    Статус: заморожен.
    Кириллические идентификаторы и/или ключевые слова: да.


            Выше перечислены оригинальные языки программирования. Здесь нет перечня компиляторов к языкам, придуманным «не у нас». В качестве исключения только хотелось бы отметить интересный проект Андрея Андреева «Странник»  — компилятор с общей семантической базой языков Паскаль, Модула-2 и Си.

Смотри так же:

Опубликовано: 2012.09.25, последняя правка: 2024.04.28    14:45

ОценитеОценки посетителей
   ██████████████████████████ 42 (61.7%)
   ████ 5 (7.35%)
   █████ 8 (11.7%)
   ████████ 13 (19.1%)

Отзывы

     2013/05/04 01:03, DIBOX          # 

В чём я смогу написать собственный язык программирования ?

     2013/05/04 13:07, Автор сайта          # 

Как-то слишком общо поставлен вопрос. Что Вы имели в виду под «в чём»? Разработку языка желательно закончить формальным описанием грамматики и описанием семантики. А дальше — разработка компилятора, на этот есть счёт много литературы. На Ваш вопрос трудно ответить двумя предложениями.

     2013/05/09 05:57, newGentee          # 

Gentee автор бросил в 2010, вчера он это подтвердил (8 мая 2013) на форуме, форум смешанный, англо-русский.

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

По одной из ссылок нашёл HomeLisp, недавно было обновление, проект жив. Буду смотреть, что это такое.

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

     2013/05/12 22:46, Автор сайта          # 

Разбил список на активные/замороженные проекты. Отметил неактуальные ссылки.

Здесь перечислены языки отечественных авторов. Список компиляторов/интерпретаторов к готовым языкам можно поискать в других местах, я их уже указывал: Ресурсы, посвящённые созданию языков программирования и компиляторов. Там можно найти и Бейсик, и Паскаль, и Форт... Немало проектов, в том числе международных.

     2013/12/20 16:59, Alexandre Minoshi (Almin-Soft)          # 

http://alminsoft.nx0.ru/ переехал на новую площадку. Теперь его можно найти по ссылке almin-soft.ru

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

Но последняя версия Валентины у меня все таки есть, если интересно пишите на almin-soft(собака)yandex(тчк)ru

     2014/01/17 08:33, Сергей          # 

В языке Delavar английские служебные слова. Наверное, стоит его переместить в иной раздел — без кириллицы.

     2014/03/27 21:39, Слава          # 

еще забыт язык vkACL, у него русский автор и я в нем усматриваю аналогию с шитым кодом.

     2014/04/30 02:33, Utkin          # 

еще забыт язык vkACL, у него русский автор и я в нем усматриваю аналогию с шитым кодом.

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

     2014/04/30 02:36, Utkin          # 

Последнее хранилище Валентины

     2014/08/14 18:31, Виктор Кон          # 

Хочу уточнить про язык vkACL. Он не забыт, я его делал для себя, и я постоянно им пользуюсь. У него был сайт vkacl.narod.ru, он до сих пор в строю, хотя и переехал на юкоз. Язык называется ACL (advanced command language), а приставка vk указывает на автора. В многочисленных каталогах программ стоят старые версии, а на сайте есть новые. Язык реально не компилируется, а интерпретируется программой, написанной на Java. Он очень простой по структуре, но из-за наличия огромного количества команд и их параметров все сразу усвоить сложно. На языке можно писать программы любой степени сложности, но в ограниченных областях. В основном это работа с файлами, текстом, расчеты, графики, картинки, постскрипт, можно делать анимации, презентации, работать с pdf файлами. Короче все то, что мне необходимо. Базами данных я не занимаюсь, этого нет (то есть sql, xml). На сайте все написано. Главная цель языка была в том, чтобы писать программы очень быстро и сразу их исполнять. В самой программе есть и среда разработки и набор готовых программ. Среди готовых программ есть в частности программы быстрого создания вэб сайтов из текста и создание электронных книг в формате fb2.

     2014/08/21 11:05, Эрих Гаузер          # 

Есть ещё один язык. Создан он мной, называется он «Ellochka» («Эллочка»), его описание находится на этой странице.

Язык интерпретируемый, на том же сайте есть интерпретатор и есть набор утилит на этом языке. Поскольку создавался он ещё в среде ДОС (последняя версия транслятора — 2001 год) и я так и не собрался перевести его под окна, сейчас, конечно. Его применение затруднительно и не так актуально. Однако, я сам до сих пор использую некоторые полезные утилиты на этом языке.

Кроме того, на Эллочке были написаны интерпретатор и компилятор(!) известного языка "brainfuck". Их тоже можно скачать на указанном сайте.

     2015/03/02 08:52, Александр          # 

Привет всем! Сайт классный. Я недавно начал писать собственный интерпретатор скриптового языка, но знаний мало, а книг толковых нет, много воды. Поэтому решил начать что-то сам. Предлагаю энтузиастам-программистам С# объединиться и создать полноценный скриптовый язык, котоорый будет работать как на стороне сервера, так и на строне клиента. Чтобы не было разбиения на языки типа php, javascript, ajax, jquery и тому подобные. Чтобы был один язык, но был двузадачным (для клиента и сервера). Кому это интересно, пишите на почту: almp@i.ua или skype: avmpapus

     2015/04/07 08:53, misha_shar53          # 

Понравился этот сайт. Вопрос создания нового языка программирования меня сильно интересует. Но обсуждение на этом сайте носит несколько однобокий характер. Из рассмотрения выпал язык MUMPS. По-моему, незаслуженно. Он, конечно, малопопулярен, но, в отличие от многих других языков, работоспособен. На нем работают с 70-х годов до нашего времени. И здесь есть чем гордится. В 80-90-е годы Игорем Фетисовым была создана MUMPS-система NTSM. Которая использовалась на территории бывшего СССР. У меня на этой системе был разработан бух.учет который работает до сих пор. Сейчас активно разрабатывается и функционирует очень интересная система MUMPS MiniM. Разработчик — Евгений Каратаев. Есть его книги по MUMPS. Вышла книжка про MUMPS: http://www.solon-press.ru/shop.html?id=845. Со временем должна попасть в самые различные книжные магазины.

     2015/04/07 16:30, Автор сайта          # 

обсуждение на этом сайте носит несколько однобокий характер

Да тут немало языков рассматривалось. Или однобокость заключается в том, что не рассматривался MUMPS?

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

Не могли бы привести примеры неработоспособных языков? C/C++? Java? C#? Pascal? PHP? Oberon? Ruby? D? Javascript? 1С, в конце концов?

     2015/07/08 16:54, ibzh          # 

Я тоже в некотором роде энтузиаст программирования на русском языке. Свой компилятор я, правда, не пишу, зато русифицирую систему литературного программирования web, разработанную Д. Кнутом. Русифицированные файлы этой системы позволяют как определять русские имена переменных, так и переопределять стандартные ключевые слова языка Паскаль на русские.

Посмотреть это можно здесь.

     2015/09/21 23:11, Igor Tomassov          # 

Jpho может использовать любой язык (language) для определения слов, констант, переменных и т.д. Обычно это кодировка UTF-8.
Поэтому определения слова:
: prepare ... ;
или
: подготовить ... ;
или
: bereiten ... ;
Никакой разницы не имеет.

     2015/09/22 13:30, Автор сайта          # 

Если у вас будет поддерживаться 200 языков, то ключевые слова на одном языке могут повторять другие ключевые слова на другом языке. Т.е. возможны противоречия. Или идентификатор на одном языке может быть воспринят как ключевое слово на другом языке.

     2015/09/22 20:08, Igor Tomassov          # 

Вопрос интересный. В Jpho, как в FORTH, используются словари. Словарь может быть определен в виде Java-файла (JphoVocabulary, слово extends) или в обычном коде Jpho (слово voc). По второму варианту используется слово import для загрузки Jpho-файла, интерпретация которого может быть осуществлена в соответствующий словарь.

Например:
"RU" voc
import: ru_voc.jfo
Далее компиляция (интерпретация) пойдет в словарь RU, который станет текущим словарем.

В Jpho в системном словаре JFO более 500 предопределенных слов, но если мы хотим переопределить слова в другом языке, то следует создать файл-словарь, в котором будут определены слова на необходимом языке.

Например:
: дублировать dup ;
Это значит, что вместо стандартного слова dup аналогично будет работать слово "дублировать".

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

     2015/09/22 20:34, Igor Tomassov          # 

Еще хотел бы добавить. Jpho (как и FORTH) — стековый язык: все параметры приходят из стека и возвращаются в стек. Поэтому в Jpho нет функций, есть только слова или код, который сразу выполняется при интерпретации (в том числе условные переходы и циклы). Большинство слов перегружено, например, слово "+" работает с числами, строками, списками и т.д. Если есть необходимость, то в коде Jpho можно ещё "перегрузить" слово. Как в FORTH, Jpho поддерживает правило — минимальное количество символов для выполнения операции (слова). Поэтому вывод в выходной поток из стека просто точка «.».
Обратная (польская) запись:
100 300 +
На вершину стека положили число 100, потом 300 (100 ушло в позицию 1 стека, в положение 0 попало число 300), слово "+" складывает два объекта в стеке с положением 0 и 1, и возвращает сумму на вершину стека.
Т.е. на вершине стека будет 400.
100 300 + .
А это все сложит и выведет результат в выходной поток.

Определим слово "возведение_в_квадрат"
// n — n2
: возведение_в_квадрат dup * ;
Дублируем число в стеке, а потом перемножаем, результат в стек.

     2015/09/22 20:40, Автор сайта          # 

Т.е. расхождения с Фортом на грани стилистических? Ну и выполнение не на реальной машине, а на JVM.

     2015/09/22 21:06, Igor Tomassov          # 

Еще дополнение.
1. Язык Jpho предназначен не для написания приложений (хотя это возможно), а для интеграции с Java и Java EE технологиями.
(понятно, что изменения Java-кода требуется перекомпиляцию проекта, в основном это в работающей системе невозможно).
2. Изменение Jpho-скрипта возможно без переустановки систем (тем более, что коды мы храним в БД).
3. Jpho может обратиться к любому Bean, менеджеру, к БД или Web-сервису.
4. Jpho, в отличии от FORTH, использует префиксы и постфиксы, например, создание переменной:
100 Моя_переменная!
Получить значение из переменной - Моя_переменная@
Получить значение из атрибута (используется префикс):
@name
Т.е. получить из объекта в стеке значение геттера getName.
!name - тоже установить setName.
Остальное можно прочитать в документации.

     2015/09/22 21:46, Igor Tomassov          # 

Да, скажем идея Чака Мура с Фортом (а он создал язык для управления телескопом), которую я абсолютно не понял (зная Lisp, Fortran, Algol, PL и т.д) в конечном итоге привела к тому, что это все очень логично и лаконично. На FORTH можно было реализовать ОС для компьютера, или включить его в телефонную станцию (менее 6 кБ оперативной памяти), или программировать машинные автоматы.
Сейчас запросы другие, но остаются в приоритете:
1. Интеграция с приложениями
2. Быстрая обучаемость
3. Замена кода без перекомпиляции проекта
4. Бесконечное количество отчетов в HTML/Excel/PDF
5. Работа Web-сервисов и клиентов.

     2015/09/22 20:55, Автор сайта          # 

Плюсы, которыми обладает Форт, появились более 40 лет назад. И до сих пор этот потенциал не раскрыт. Что побудило написать вот такое пессимистическое: Почему обречён язык Форт.

     2015/09/22 22:02, Igor Tomassov          # 

Не ответил на вопросы:

1. Расхождения с Фортом стилистические и не только (например, префиксы, постфиксы).
Например, в FORTH строка должна начинаться со слова «" »: " Это строка". Слово «"» прочитает из входного потока слово «" » и поймет, что это строка. В Jpho используется префикс " и никаких пробелов не нужно

2. Да, Jpho работает на JVM. Другие реализации возможны: PHP, JavaScript (который и так используется в Web-технологии), C++.

     2015/09/22 22:21, Igor Tomassov          # 

Но язык никому не нужен, если он не дает конечные результаты для пользователей. Это мы с Вами можем рассуждать о красивости/некрасивости конструкций в языке программирования. Для Заказчика/Конечного пользователя есть только набор интерфейсов, функционала и отчетов. В данной конкретной ситуации, Jpho мы используем, как скрипт для Java EE технологии, со всеми его возможностями.

     2016/07/17 11:14, mahairod          # 

Теперь есть и ещё один язык программирования на основе кириллицы — Ява, кириллизованная версия Java. Сайт с базовым описанием: http://wiki.elliptica.net/вики/Ява. Код классов взаимодействует с нативным кодом через кириллические сигнатуры методов в бинарных библиотеках (собраны с поддержкой расширенных международных идентификаторов).

Для поддержки языка (кодирование и сборка) осуществлена адаптация интегрированной среды разработки Netbeans. Основной набор инструментов, доступных для Java, теперь доступен и для нового диалекта Ява.

Также в рамках поддержки этого проекта осуществлено добавление кириллических аналогов ключевых слов языков C/C++/ObjC/ObjC++ в компиляторе GCC. Получившийся компилятор предполагается назвать RuCC/Ru++.

В планах есть оборачивание стандартной библиотеки C кириллическими именами и примерно такой же подход для стандартной библиотеки C++.

     2017/10/24 15:29, no1          # 

Euphoria — интерпретируемый язык с очень быстрым интерпретатором. Распространяется public domain с середины 90-х, до этого была платная версия, затем был форк.

Cайт проекта http://www.rapideuphoria.com/news.htm

http://openeuphoria.org/wiki/view/DownloadEuphoria.wc — новые версии 4.0, старые legacy, форки

альтернативный форк с доработками http://phix.x10.mx/ репозиторий https://bitbucket.org/petelomax/phix/src

Есть *большое* множество библиотек, привязок к библиотекам и примеров кода http://www.rapideuphoria.com/archive.htm

Встречаются и необычные, например привязки в ассемблеру fasm
http://www.rapideuphoria.com/fasm4eu.zip http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.TgsFlatAssembler

В phix встроена инструкция #ilasm, и более продвинутый отладчик и оптимизатор

Поддерживаются кириллические идентификаторы и unicode в новых версиях, операторы на английском

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

http://www.private.peterlink.ru/kinz/3.2ru/index.html

http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.BilingualEuphoria25

http://www.rapideuphoria.com/lan.htm -> http://www.rapideuphoria.com/ru_eu_11.zip


Автор порта И. Н. Качан
http://www.private.peterlink.ru/kinz/ , есть примеры и описание языка.

     2017/10/24 15:33, no1          # 

Полиглот: Смоллток на русском языке (портированный Squeak 3.9) + книга А. Голдберг "Смоллток. Язык и его реализация" https://sites.google.com/site/polyglotsqueak/

Сборка содержит модули OMeta, SmaCC — компиляторы компиляторов (с примерами грамматик готовых языков в SmaCC) которые могут быть использованы для разработки своего транслятора или полуавтоматической трансляции в/из свой язык программирования.

     2017/10/25 13:20, Автор сайта          # 

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

     2017/10/28 23:34, no1          # 

Тезис понятен, но иногда разделить не так-то просто.

Вот Глагол — русский язык программирования, уникальный? По-моему, нет — это просто Оберон-2 с русским синтаксисом.

Концептуально Глагол, Оберон-2 и какой-нибудь BlackBox Component Pascal, школьная сборка http://www.inr.ac.ru/~info21/software.htm http://inf.1september.ru/article.php?ID=200800100 — это один и тот же язык, семантически. Небольшие отличия в синтаксисе и переводе — не существенны.

А например Рапира и Оберон — разные языки, ибо в Рапире кортежи есть, а в Обероне — нет.

     2017/10/29 19:14, Автор сайта          # 

Раз Глагол был назван его автором именно Глаголом, а не русским Обероном, значит у него было какое-то видение самобытности или уникальности собственного творения. Я с ним не спорю и не провожу экспертиз на идентичность, просто верю на слово. Но если разработка компилятора какого-то языка, появившегося за рубежом, производится какой-то отечественной компанией, то можно подправить другой список: Отечественные компании-разработчики компиляторов. Почему компаниям «можно» быть упомянутым, а отдельным людям нет? Потому что этот список может помочь кому-то найти работу, совпадающую с хобби.

     2017/12/15 01:46, SIMPLETON          # 

К сожалению, вижу в новостях на сайте КОНЦЕПТа, что проект завершён. Хотя шикарная вещь, ей бы только библиотек побольше — и в школы/вузы.

Мечтаю увидеть русский LOLCODE :)
ПРИВ
ТУТ П = 0
ВИРА П ДО 10
ПОКАЖ П
ХОРОШ
ПОКЕД

     2018/03/25 21:14, Денис Будяк          # 

Не помешает добавить школьную сборку info21 (aka школьная сборка блэкбокс)

     2020/07/29 10:00, Тимофей          # 

Добавьте языки: Ü, Umka. Про него есть на Хабре.

     2020/10/07 17:34, NuShaman          # 

Алгоритм-2 уже не поддерживается (заморожен). Сайт перенесён в архив http://web-arhive.ru

     2021/04/23 12:58, Автор сайта          # 

Пополнил список языками Cine, Ü, Картарика, Санда.

     2021/05/09 00:35, Владимир Соколов          # 

Благодарю за упоминание Санды.

     2021/05/13 23:43, Денис Будяк          # 

Здравствуйте! Добавьте, пожалуйста, ссылку на ЯОС. Там есть уже полностью готовый язык программирования с русскими ключевыми словами, со средой разработки (перевод языка "Активный Оберон"). Сейчас идёт перевод компилятора на русский язык и вставка русских ключевых слов в описание языка.

https://gitlab.com/budden/ja-o-s

     2021/05/14 13:20, Денис Будяк          # 

А "Яр" уже давно заморожен. Я понял, у вас не считаются отечественными переводы, хотя если Глагол тут есть, то и язык ЯОС тоже по логике имеет право быть. Тем более, что язык ЯОС уже имеет как минимум одно существенное отличие от Активного Оберна, например, в нём есть модификатор override/перекрыта, который является обязательным в русскоязычном варианте. Также там доделан тип SET64, который в оригинале не работает.

     2021/05/16 14:13, Автор сайта          # 

Посмотрел описание на Вашем сайте. Сайт убедил меня в том, что ЯОС — это и язык, и операционная система. Аббревиатура «ЯОС» может так и расшифровывается — Язык и Операционная Система? И где провести границу между языком и ОС?

Глагол позиционировался автором как отдельный язык. А как Вы позиционируете свой язык? Если как отдельный, то тогда нужна ссылка, где бы описывался именно язык.

     2021/05/18 11:35, Денис Будяк          # 

Пока что это всё же русскоязычная версия Активного Оберона, отличия недостаточные, чтобы считать новым языком. Считать ли перевод ключевых слов созданием отдельного языка? С точки зрения совместимости — да, потому что другой компилятор АО этот код не скомпилирует. С точки зрения дизайна языка — вряд ли. Описание языка здесь: https://gitlab.com/budden/ja-o-s/-/blob/главная/док/яп-активный-оберон/описание-языка.md — пока оно запаздывает и в нём только англоязычные ключевые слова, но переделка слов на русскоязычные ожидается буквально на днях.

ЯОС никак не расшифровывается, просто название ОС с кириллицей в явном виде. Это рабочее название, может ещё смениться.

     2021/05/18 11:37, Денис Будяк          # 

Граница между языком и ОС проводится, думаю, как обычно. Единственное, что тут линковщик, по сути дела, не оставляет выбор — писать под эту ОС на данный момент можно только на этом языке (если не сделать интерпретатор или иной компилятор).

     2021/05/18 22:58, Денис Будяк          # 

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

https://gitlab.com/budden/ja-o-s/-/blob/главная/док/яп-активный-оберон/описание-языка.md

     2021/05/19 10:43, Автор сайта          # 

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

Автор Глагола назвал свой язык Глаголом. Я ему поверил и включил в этот список. Вы же называете Обероном, я Вам тоже верю, и поэтому не включаю. Хотя желаю успехов в работе.

     2021/05/19 21:54, Денис Будяк          # 

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

     2021/05/19 22:54, Автор сайта          # 

Ещё не вечер :) Может быть, Вы когда-нибудь внесёте в язык что-то своё, чего Вам не хватает. Не может быть, чтобы у Вас не было идей. Тем более, что Оберон — аскетичный язык. Чересчур лаконичный. Вот тогда вернёмся к разговору :)

     2021/05/19 23:15, Денис Будяк          # 

Угу. Только активный Оберон уже не такой лаконичный. Оберонщики объявили его ересью и мимикрией :) Идеи есть, конечно, но вряд ли в этом году что-нибудь реализую.

     2022/04/24 22:20, Автор сайта          # 

Добавил 3 новых языка в список:Проверил ссылки, обновил информацию по остальным.

     2022/04/26 00:35, Неслучайный читатель          # 

Знакомлюсь не с первым «самодельным» языком программирования. И знаете, что заметил? Интересная закономерность — многие разработчики находят, что подходящая ниша для их творений — это обучение (как правило, школьников) программированию. И действительно, для серьёзного программирования они не пригодны — не «обросли мясом». Серьёзные организации будут выбирать серьёзные инструменты. И куда тогда пристроить своё творение? Конечно туда, где публика невзыскательна. В школу!

Но, простите, эта ниша уже занята. Для школы уже написаны учебники. При этом очередной новый язык не обладает обратной совместимостью этими книгами. В учебнике написано одно, а в новом языке — совсем другое. Учителя информатики его не знают. Гороно/районо инициативу, скорее всего пресечёт. Остаются школьные кружки, и то если эти кружки будет вести автор языка.

     2022/04/26 13:33, Gudleifr          # 

Для школы уже написаны учебники.

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

     2022/04/27 16:13, Неслучайный читатель          # 

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

     2022/04/27 16:26, Gudleifr          # 

Существенно то, что язык с ними не совместим

Хороший учебник вообще не должен быть ориентирован на язык. А язык должен быть совместим только с практическими(!) задачами, которые учащиеся могут решить.

     2022/04/27 16:43, Неслучайный читатель          # 

Главный герой моих мыслей — не учебник, а язык. И разработчик языка, который питает надежды сделать свой язык главным героем школьного урока по информатике. Так вот надежды несбыточны. Бизнес-план хромает: переиздать учебник разработчик не может и переучить учителей не в силах.

     2022/04/27 16:47, Gudleifr          # 

Так вот надежды несбыточны

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

     2022/04/27 17:26, Неслучайный читатель          # 

Да нет, с первоклассниками не придумывают азбуку или правила арифметики. С больными не изобретают рецептуру лекарств. Задача учителя — принести знания, но как ученики, не обладая знаниями, будут помогать учителю формулировать эти знания? Как стадо может отобрать кнут у пастуха и гнать себя в нужном направлении? Это заблуждение, что мнение дилетантов полезно в отрасли с высоким порогом вхождения. Если это не так, то пусть школьники для начала сконструируют процессор с конвейером, кэшами, виртуальной памятью и прочими шахматами и поэтессами.

     2022/04/27 17:32, Gudleifr          # 

Да нет, с первоклассниками не придумывают азбуку или правила арифметики

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

     2022/04/27 21:14, Автор сайта          # 

Знаком с одним преподавателем информатики в колледже. Он заодно ведёт кружки программирования и робототехники. Уроки по информатике он ведёт по школьной программе. А вот на кружках у него свобода рук. Поэтому в ограниченных масштабах чей-то язык может попасть в школу.

     2022/04/27 21:48, Gudleifr          # 

Уроки по информатике он ведёт по школьной программе. А вот на кружках у него свобода рук

Я обходил эту проблему внедрением программированного обучения.

     2022/04/27 23:06, Неслучайный читатель          # 

Программирование — это отрасль знаний. Печатать на клавиатуре, в том числе «if», «else», «do» — это навык, а вот писать их в нужном порядке и с нужными параметрами — это требует знаний. Навыков тут недостаточно.

     2022/05/11 18:18, Автор сайта          # 

Обнаружил NewLang — новый язык программирования. Один из немногих, который не имеет некоторых признаков устаревшего языка. В нём нет ключевых слов. В этом сперва увиделось сходство с PL/1, однако сходства на самом деле нет. Ибо ключевые слова заменены на некие комбинации спецсимволов. Например, условный оператор:
(условие) -> {действие} -> {действие иначе};
Цикл:
(условие) <--> {тело цикла};

     2022/06/29 16:21, Автор сайта          # 

Добавил в в перечень язык программирования Перфолента, в котором идентификаторы записывают на русском языке. Разработчик — частное предприятие «ПРОМКОД» (Украина). Да, на Украине тоже программируют на русском.

     2022/08/27 21:25, Автор сайта          # 

Пополнил список языком LN. Этот язык основан на Нормальных Алгоритмах Маркова (НАМ), которые, по словам автора языка LN, стали основой для продукционной парадигмы, о которой, по сути, нет качественных материалов. НАМ ранее были воплощены в языке Рефал. Язык LN — ещё одно воплощение, автором которой является пользователь Хабра с ником «Icon0clast».

     2022/09/23 22:16, Денис Будяк          # 

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

Т.е. невключение моего проекта в данный список начинает уже выглядеть несколько искусственным.

Также неясно, чем ЯОС хуже Глагола. Компилятор Глагола вроде бы закрыт, поэтому Вы не можете утверждать, что он написан Издателем. А значит, нельзя отказать ЯОС во включении в список. Неясно, чем он хуже OneScript, который является клоном 1С, в точки зрения языка. В ЯОС есть отличия и нововведения. Что ещё мешает?

     2022/09/24 15:09, Автор сайта          # 

Ну хорошо, я поступился принципами и пошёл Вам на уступки. Но что я должен написать? «ЯОС» — это не очень понятный симбиоз языка и ОС, как я понял. Но фраза с Вашего сайта «реализация ШАЯ в ЯОС» (ШАЯ — школьный алгоритмический язык, «Кумир») говорит о том, что это не язык, а операционная система, обо язык в языке не реализуется, он реализуется в ОС. Название «ЯОС» отпадает. Что тогда я должен написать? Какое имя собственное? «Русифицированный Оберон-2»?

Ещё нужно вспомнить о компиляторе Оберона «Восток», который написал Comdiv. В отличие от Вашего, у него компилятор собственной разработки. Вполне резонно Comdiv может меня спросить, почему я обошёл его проект вниманием. Есть и другие разработки компиляторов «ненаших» языков, например, Си Алексея Мандрыкина.

А вообще роль и важность этого списка для меня не слишком очевидна :)

     2022/09/24 16:43, Денис Будяк          # 

Список важный и уникальный, на мой взгляд. Как минимум, он является предостережением каждому, кому взбредёт в голову его пополнить собой :) Язык пока не имеет названия, но можно назвать "Яр", т.к. это название в принципе было зарезервировано, и оно отражено в стандартном расширении модуля "ярм". А старый Яр тогда надо называть "старый Яр". Яр так же относится к Активному Оберону, как Глагол к обычному Оберону, т.е. это русский перевод + внесённые изменения. А ЯОС — это не только ОС, но и среда разработки приложений, поэтому Яр может исполняться и под Linux/Windows. Спасибо!

     2022/09/24 16:47, Денис Будяк          # 

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

     2022/09/27 22:57, Автор сайта          # 

Поддавшись на уговоры, дополняю принципы формирования перечня отечественных языков программирования. Теперь он может так же включать в себя отечественные оригинальные расширения языков зарубежного происхождения. Поэтому пополнил список языками Яр и PL/1.

     2022/09/28 19:20, Денис Будяк          # 

Отлично, даже не знаю, за кого больше радоваться — за свой проект или за PL/1. Спасибо!

     2022/12/03 20:41, Автор сайта          # 

Добавил в свой список два языка программирования: ALLang и Тривиль. На втором хотелось бы остановиться подробнее. Ведь его автор — Алексей Недоря, известный всей стране по проекту «Кронос» в средине 1980-х. Для меня — это «тяжеловес» из мира языков и компиляторов, «глыба и матёрый человечище». Сравнительно недавно обнаружил его сайт и прочёл анонс: Алексей в сотрудничестве с Huawei разрабатывает новый язык программирования. Сайт долго не обновлялся, потом Huawei и вовсе втихую ушла из России. Это давало повод думать, что проект накрылся. Но тут новость! Язык всё-таки создаётся. И даже не язык, а целая экосистема из семейства языков разного назначения с кроссплатформенностью. Ну а язык Тривиль — это отправная точка. Обнаружил некоторое созвучие в идеях, а именно в идентификаторах, которые, по мнению Алексея, могут был на кириллице, содержать в себе пробелы, и даже могут вообще содержать произвольный текст, если заключены в кавычки. Это соответствует тому, что было в русификаторе Си уже несколько лет назад, однако у меня сейчас есть некоторое продвижение вперёд, о котором скоро будет рассказано. Есть моменты, которые не понравились. Но у каждого своя правда, свой собственный опыт.

     2022/12/06 23:00, Неслучайный читатель          # 

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

Нашёл («Тривиль — вопросы и уточнения») у Недори это «созвучие»:

4) Идентификатор
Расписал идентификатор с пробелами, ‘-‘, ‘№’ и вопросительным, восклицательным знаком в конце. Примеры:

Паниковать!
Делится на три?
проверка-массива
пока № > 0 { №— }
Я бы даже назвал это не созвучием, а прямым заимствованием (если не сказать больше). Лично я не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. Только на этом сайте. Вот фрагменты Вашего кода («Вычисление определителя матрицы. Программа на русском Си»):
    _31  №;
для (№ = Y; № < РАЗМЕР; ++№) {
э = & M [X * РАЗМЕР + №];
в = & M [Y * РАЗМЕР + №];
. . .
}
. . .
для (слева направо = 0; слева направо < РАЗМЕР; ++слева направо) {
для (сверху вниз = слева направо; сверху вниз < РАЗМЕР; ++сверху вниз) {
делитель = * Элемент (M, сверху вниз, слева направо);
детерминант *= делитель;
делить и вычесть строку (M, сверху вниз, слева направо, делитель);
}
}
Тут и кириллица, и пробелы, и «№» в идентификаторах. Так что Ваши идеи уже находят место в других языках.

     2022/12/07 10:45, Автор сайта          # 

На языки программирования копирайт не распространяется.

     2022/12/07 11:57, Бурановский дедушка          # 

А то бы авторы Фортрана и Алгола до сих пор собирали дань :)

     2022/12/12 16:53, void          # 

Неслучайный читатель

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

А я знаю. Например, язык "1" или Адина, автор — Клочков Роман (monk). Документация и описание языка и примеров: https://docs.racket-lang.org/russian-lang/index.html. Анонс на Linux.org.ru: https://www.linux.org.ru/forum/development/15794630/page20#comments. Там есть примеры кода. Недавняя новость: https://www.linux.org.ru/news/development/16988270. Там тоже есть примеры кода.

"Синтаксис от Хаскеля, семантика от Ракета" — диалект Лиспа с русским синтаксисом. Можно добавить в список. Реализован как DSL на Racket. На Racket вообще удобно разрабатывать собственные диалекты языков. Вот например, создают диалект с поддержкой IDE и отладчика: https://shmat-razum.blogspot.com/2011/11/racket.html, а вот краткий обзор https://shmat-razum.blogspot.com/2011/09/dsl.html

В Лиспах, кстати, могут быть в идентификаторах пробелы и Unicode символы. Только нужно оборачивать литералы соответствующими символами, конец/начало идентификатора. В Unicode, кстати, могут быть символы пробел и разные виды скобок. То есть, можно было бы просто реализовать несколько видов пробелов — стандартный, разрывный и неразрывный с другим кодом.

Кстати, вот ещё недавняя находка на Racket, книга Beautiful Racket: https://beautifulracket.com, написана на средстве документирования/поддержки грамотного программирования Pollen: https://docs.racket-lang.org/pollen/

«Зачем Racket? Зачем Лисп? Зачем языково-ориентированное программирование?»: https://habr.com/ru/post/445822/ Это ещё в тему "Устарел ли текст как форма представления программы", проект языка CURL; https://en.wikipedia.org/wiki/Curl_(programming_language), предлагал единый язык для разработки "программируемой документации" (в отличие от набора диалектов вроде различных версий HTML, CSS, JS в типичном браузере). Это по сути диалект Лиспа (ближе к Dylan, Thomas, goo и идее "функциональных объектов", то есть объекты и их интерфейсы в духе метаобъектного протокола как first-class objects на уровне языка.

Если CURL сейчас представляет собой инфраструктуру и IDE, плагины и фреймворки (например, MVC), написанные на таком языке для реализации Rich Application как гипертекстового программируемого документа — но реализованные как набор диалектов с единым синтаксисом, у которого текст документа — это полноценный литерал типа текст, типа объект; есть и другие типы объектов представленные выражениями форм в фигурных скобках.

То в Pollen реализована по сути та же самая идея, только как диалект Лиспа, встроенного в Racket: документация, то есть, текстовый литерал может быть в разметке Markdown или любой другой, для которой написан парсер; публикация в выходной формат — также настраиваема (изначально есть поддержка HTML и PDF, но можно добавить и свои собственные).

При этом реализуется всё та же идея — "программируемой документации". Книга — это программа, с некоторыми объектами динамически вычисляемыми. Как я понял, к этой же идее — компонентная сборка программ, документов, приложеньиц обновляемых Rich Application Dashboard, "Автопрограммирование — программирование без программистов": https://chuzhakin.com/программирование-без-программистов/ идёт и А. Е. Недоря в языках Вир, Вир-2, Тривиль.

     2022/12/12 22:12, Автор сайта          # 

Язык добавил в свой список.

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

А я знаю.

Процитирую описание языка с сайта:

2.4 Идентификаторы
Синтаксис для идентификаторов ... В них могут быть использованы любые символы кроме пробелов ...

Тут и комментировать нечего. Но даже если не верить этому, то вопрос о «первородстве» легко устанавливается: впервые в архив Интернета archive.org этот сайт попал 1 октября 2020 г. Но не стоит на этом зацикливаться. Не впервые такое случается.

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

     2022/12/13 22:49, void          # 

Более того, можно вводить идентификатор между вертикальным чертами, тогда допустимы вообще любые символы кроме вертикальной черты. Примеры идентификаторов:
не-печётся
<...>
|идентификатор со спецсимволами ( ) [ ] { } " , ' ` ; # \|

но вообще в Лиспах принято несколько слов писать через минус, а не пробел.

В контексте "Natural Language Programming" — интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем. Например, падежей, склонений, спряжений, наречий, причастий и т.п. различных суффиксов при одинаковом корне.

Например, есть японский язык программирования Nadesico с поддержкой падежей (в остальном он примерно похож на бейсик). Но там иероглифы, и форма записи вообще слоговая. Для благозвучия "программирования на русском" было бы разумно не только поддерживать пробелы в идентификаторах, но и задавать флексии, например те же падежи: родительный — некий класс имярек, творительный — порождающий интерфейс, один из нескольких, скорее генератор с yield чем просто какой-то из конструкторов винительный — resonsibility (основная функция, ответственность, которую класс реализует самостоятельно) предложный — concern или collaboration (прочие обязанности, делегируемые другим классам).

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

     2022/12/14 00:48, Автор сайта          # 

можно вводить идентификатор между вертикальным чертами

Это весьма непродуманный вариант. Это не просто вертикальные черты, это обозначение операции «или». Если изъять из этот символ из перечня операций, то что взамен? Ничего лучшего для «или» не придумаешь. В русификаторе C/C++ более десятка лет используются обратные апострофы. Между ними могут быть любые символы:
`это идентификатор из любых символов !@#$%^&*()_+`
Вариант с обратными апострофами хорош тем, что этот символ на клавиатуре есть, а вот традиции использовать его в языках программированя — нет. Поэтому он свободен для применения в новинках.

вообще в Лиспах принято несколько слов писать через минус, а не пробел.

И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше. Но и он проигрывает самому обычному пробелу, который придаёт естественность многословным идентификаторам. Не правда ли
не печётся
это лучше, чем
не-печётся
?

интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем.

Совсем не интересно. Думаю, она появится тогда, когда программированием займутся нейронные сети. И как бы мы ни упирались, нас отправят на заслуженный отдых. Именно поэтому неинтересно.

задавать флексии, например те же падежи

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

Но Вы можете опровергнуть. Просто реализуйте всё то, что предлагаете. Останется тогда признать Вашу правоту.

     2022/12/14 16:10, MihalNik          # 

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

А зачем придумывать что-то для "или"? Знака нет на русской раскладке, т.е. набирать неудобно. Хотя раскладку можно настроить, но тогда уже странно объяснять какой-либо выбор наличием или отсутствием чего-то на ней — получается, что взбрело в голову, то и хорошо. Хорошо, что что-то туда взбрело)

задавать флексии, например те же падежи

Считаю пустой тратой времени.

однако:

Не правда ли

"не печётся"

это лучше, чем

"не-печётся"

?

Не правда ли, "ширина окна" лучше чем "окно.ширина" или "окно->ширина", а "10 чисел" лучше чем "число[10]"?

для начала, описать правила русского языка в БНФ

Зачем, если можно просто спросить падеж с исходной формой в словаре?

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

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

     2022/12/14 18:31, Автор сайта          # 

Не правда ли, "ширина окна" лучше чем "окно.ширина" или "окно->ширина", а "10 чисел" лучше чем "число[10]"?

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

Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее.

Зачем, если можно просто спросить падеж с исходной формой в словаре?

А если в словаре нет специфичных терминов? Как видоизменять «IP-адрес» (которого нет в словарях!) по числам и падежам? Ведь есть просто безграмотные люди (меня сегодня повеселили словами «борщь» и «пильмени»), тогда вместе с программированием будет происходить и «отладка» русского текста?

Конечно, могу ошибаться. Просто продемонстрируйте работающее решение со словарями. И я перейду на светлую сторону :)

Наше обсуждение отклонилось от темы статьи. Но куда перенести комментарии?

     2022/12/14 19:45, MihalNik          # 

Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее.

Ну также как к подчеркам/дефисам в идентификаторах. Ведь "пр-к" короче чем "прямоугольник". То есть и в естественных языках и в ЯП дефис также может быть очень полезен.

Достичь более-менее терпимой естественности в рамках одного идентификатора нетрудно.

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

     2022/12/14 20:22, MihalNik          # 

И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше.

Дефис-то набирается одним пальцем, а подчерк — двумя, потому что в верхнем регистре. Этим он хуже.

     2022/12/17 11:49, Автор сайта          # 

Неслучайный читатель

Прочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку.
идентификаторы в языке ЯРМО

Подчеркнул многословные идентификаторы для наглядности. Так что забирайте свои слова назад.

     2022/12/17 12:29, Gudleifr          # 

А как же каноническое FORTRAN-овское

В программе на Фортране, вместо "DO 3 I = 1,3" было набрано "DO 3 I = 1.3", что было воспринято компилятором как присвоение значения 1.3 переменной DO3I

Все ещё хотите пробелы?

     2022/12/17 14:08, Автор сайта          # 

Во-первых, «DO 3 I» и «DO3I» и — это разные идентификаторы. Они отличаются как визуально (разрывы между символами отчётливо видны, для того и пишут текст программы моноширинными шрифтами), так и на уровне двоичного представления: в первом идентификаторе в третьей и пятой позиции — символ с кодом 32, то есть пробел.

Во-вторых, очень странно, что в Фортране допускаются идентификаторы в пробелах. Вот читаю документацию по языку:

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

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

Ну и в-третьих, ключевые слова, идущие впереди идентификатора, не должны входить в этот идентификатор. Например,
if i > 0

     2022/12/19 22:16, Неслучайный читатель          # 

забирайте свои слова назад

Забираю :) Ну надо же, в таких древних языках такое уже было. Ходим по кругу, можно сказать. А ведь такая узкая прослойка программистов была! Однажды мне одна дама задала вопрос, отчего я с компьютерами «на ты». Ответил, что получил образование в этой области. Удивилась: «Неужели этому учат?». А ведь учат уже более полувека. Дольше, чем ей было лет тогда.

     2023/01/19 16:17, void          # 

Прочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку.

Спасибо за наглядный пример кода. Вот по этому тексту вопрос: "многословные идентификаторы", или "идентификаторы с пробелами" все в именительном падеже.
ПОИСК В ТИ(ДАННОЕ ИМЯ)
логично было бы просклонять в родительном или винительном:
ПОИСК В ТАБЛИЦЕ ИДЕНТИФИКАТОРОВ (ДАННОГО ИМЕНИ)
Можно также придумать искусственный случай, когда спряжения или разные времена тоже будут иметь смысл — то есть, будут значащими, а не просто синонимами. И удобнее всего было бы читать нормальный русскоязычный текст с корректными склонениями, спряжениями, именами, залогами и т.п. словоформами. Как это реализовано сейчас:

1. В языке 1С, например. Ява-подобные идентификаторы типа СтаршийПомощникМладшегоДворника МенеджерОбъектовДекораторАбстрактнойФабрикиМостаСинглтонаКомпозитораВивисектора и прочие "немецкоязычные" идентификаторы на четыре строки одним словопредложениемсинтетическогословотворчествамокроходовсоснегоступами. ///RTFM: Марк Твен, "Почему немецкий не мой любимый язык". Читается это всё нелепо, не по-русски: никакой лепоты. Например, потому что искусствено навязывается именительный падеж строго везде, даже там где невместно сие.

2. В языке RInform, русский Inform6. Здесь просто отбрасываются окончания. Ну и задаются все словоформы в разных падежах как синонимы.

3. Любопытно, как это было реализовано в русском Алгол-68, есть ли тут какая-то информация. В общем, насколько я понимаю — никто специально не следит за корректностью спряжений, склонений, падежей, времён и прочих словоформ, все либо ограничиваются именительным падежом либо таблицей синонимов. А между тем, можно сделать эту информацию значащей.
  • Например, страдательный пассивный залог — когда действует не объект по собственной инициативе, а действуют с несчастным объектом.
  • Например, выделение объектной декомпозиции OOA&OOD : Class-Responsibility-Concern или Entity-Boundary-Control.
  • Например, такие объекты среды как метаклассы или мультиметоды — и напрашивающиеся на них части речи: прилагательные, наречия, депричастные обороты.
В целом, кажется, что корректно транслировать "многословные идентификаторы" нужно именно как выделение именной группы. Для проверки корректности например в этом алгоритме http://opencorpora.org/wiki/Инструкция_по_определению_именных_групп (а также в Википедии) заменить именную группу местоимением "Предложение содержит именную группу."<=>"Оно её содержит." здесь "многословный идентификатор" составной "предложение ... именную группу", глагол посреди к именной группе не относится. То есть, они получаются не просто "с пробелами", а ещё с синтаксическими паттернами.

Также анафоры типа "оно её", "того на этого","это самое","вот эта фиговина" — тоже можно выводить в раскрытие означаемого полуавтоматически (типа макроса "анафорического if" в лиспе, подставляющего нужное вместо it).

Попытаюсь продолжить пример Алгол-68 из Википедии в гипотетический "русский Алгол":
# Next day date - english variant
mode date = struct(Int day, string month, Int year);
proc the day following = (date x) date:
If day of x < length of month (month of x, year of x)
then (day of x + 1, month of x, year of x)
elif month of x = "December"
then (1, "January", year of x + 1)
else (1, successor of month (month of x), year of x)
fi;

# Nachfolgetag - Deutsche Variante
menge datum = tupel(ganz tag, wort monat, ganz Jahr);
funktion naechster tag nach = (datum x) datum:
wenn tag von x < monatslaenge(monat von x, jahr von x)
dann (tag von x + 1, monat von x, jahr von x)
wennaber monat von x = "Dezember"
dann (1, "Januar", jahr von x + 1)
ansonsten (1, nachfolgemonat(monat von x), jahr von x)
endewenn;


#дата следующего дня - по-русски
тип дата = структура (целый день, строкой месяц, целый год);
проц следующий день = (дата ъ) дата:
ежели день из ъ меньше длины месяца (месяца из ъ, года из ъ)
тогда (день из ъ +1, месяц из ъ, год из ъ)
вдругорядь месяц из ъ большеЛибоРавен "Мартобрь"
тогда (1, "Января", год из ъ +1)
иначе (1, после от месяца (месяца из ъ), года из ъ)
ужеВсё;
Не правда ли, с синонимами, падежами, склонениями стало легче читаться?

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

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

Хватит нам уже одной Явы или ихнего хтонично тевтонского ABAP-а.

     2023/01/19 16:32, void          # 

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

Запрограммируйте "падение редуцированных гласных" и чередование гласных в БНФ, слабо? То-то же. То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше.

     2023/01/19 17:00, void          # 

Пример кода на ABC, определение функции:

Functions may return any type. Note that indentation is significant — there are no BEGIN-END's or { }'s:

        HOW TO RETURN inverse t:
PUT {} IN inv
FOR k IN keys t:
PUT k IN inv[t[k]]
RETURN inv

Пример кода на ЛОГО, определение функции:

TO HELLO
PRINT [Hello, World!]
END
В русской версии языка Лого:
ДЛЯ ПРИВЕТСТВИЯ
ПИШИ [Привет, мир!]
КОНЕЦ

(Болгарская болгаро- и русскоязычная версия ЛОГО 2.0 для Правец 8).

Видите, что было в этих языках? Человекочитаемость! Лексемы были подобраны так, чтобы не компьютеру было удобно это парсить, а человеку писать задуманное. Допустим, развивался бы Алгол-68 с первичным синтаксисом (лиспоподобным, который там уже был) и вторичным, синонимами (примерно так же, как реализовали многоязычность). А потом к этому бы добавили синтаксических макросов в духе языка Dylan и D-expressions. И можно было бы невозбранно добавлять себе всякие синонимы, чтобы писать и читать было удобно — а не вмещаться в прокрустово ложе ограничений искусственного языка. Например, вместо
проц следующий день = (дата ъ) дата:                    
...
введём функцию следующий день это (дата ъ) дата, такая, что:
.... if-выражение ....
то есть, помимо паттернов в макросах D-expressions добавлять многословные идентификаторы и синонимы, роды, падежи, склонения и спряжения для повышения человекочитаемости. Вообще, любопытно было возродить Алгол-68 на Dylan (или наоборот).

     2023/01/21 17:38, Автор сайта          # 

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

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

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

Если кто-то добьётся успехов на этом пути, то я буду рад пользоваться такой продвинутой технологией. Но сам я не филолог, не лингвист и не корифей всех наук. Поэтому буду браться только за то, что мне по силам.

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

На данный момент у нас два варианта.
  • Мы, русские люди, продолжаем писать на английском. Треть своего буднего дня погружаемся в чужую культуру, отключаемся от родной. Утешаем себя мыслями, что зато не коверкаем родной язык, не пишем именительный падеж там, где нужен родительный.
  • Второй вариант: если нет системы, определяющей правильность русской речи, то что остаётся? Пишем идентификаторы переменных, в которых главное слово — существительное в именительном падеже. И идентификаторы функций, где главное слово — глагол в повелительном наклонении. «За неимением гербовой пишем на простой».
Сообщите, когда появится третий вариант.

Русский язык богат и выразителен. Велик и могуч.

Так не портьте его. Я очень много времени провожу, исправляя за Вами ошибки. А то Вы радеете, чтоб в языке программирования комар носа не подточил, а сами пишете тяп-ляп. Могу сказать, что если появится безупречный с Вашей точки зрения русский Алгол, то Вам придётся исправлять за собой много ошибок: там пунктуация страдает, сям Вы не любите писать с большой буквы имена собственные или начало предложения и т.д. Вы будете несовместимы с таким совершенным инструментом.

То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше.

Значит, надо перейти от слов к делу и написать W-грамматику для русского языка.

«ДЛЯ ПРИВЕТСТВИЯ» — это укладывается в один идентификатор. А раз так, то ничего сложного, здесь никто не контролирует падежи. «ПИШИ [Привет, мир!]» — а вот это не по-русски! Правильно писать так: «Пиши: "Привет, мир!"». После «Пиши» необходимо двоеточие. Квадратные скобки в русском языке играют совсем другую роль.

прокрустово ложе ограничений искусственного языка

Николай Лобачевский, русский математик: «Чему одолжены своими блестящими успехами науки, слава нынешних времен, торжество ума человеческого? Без сомнения, искусственному языку своему!»

Вообще, любопытно было возродить Алгол-68 на Dylan (или наоборот).

Это праздное любопытство или побуждающее засучить рукава?

     2023/01/30 23:16, Автор сайта          # 

Добавил в список язык программирования с многообещающим названием Rave , что в переводе с английского означает «бред». Авторами языка (согласно Гитхабу) являются 4 человека.

     2023/03/15 00:30, Автор сайта          # 

Добавил язык COLAMO разработки Научно-исследовательского центра супер-ЭВМ и нейрокомпьютеров, г. Таганрог.

     2023/06/06 00:31, Автор сайта          # 

Пополнил список уже не новыми языками Cj и ПОП.

     2023/07/26 00:06, Автор сайта          # 

Пополнил список новым языком Argentum и довольно старым GAZ.

     2023/10/18 13:52, Автор сайта          # 

Дополнил список языком Клаус, который назван в честь Никлауса Вирта. Правда, название языка не уникально, в энциклопедии эзотерических языков программирования esolangs.org можно найти точно так же названный язык. Предположу, что "Клаус" отличается от "Никлаус" тем же, чем "Коля" от "Николай".

     2023/10/19 22:30, Деньги на WWWетер          # 

Когда же назовут какой-нибудь язык в честь Вильяма нашего Шекспира Денниса Ритчи? Его вклад в языки ничуть не меньший, чем у Вирта. На его языке написали больше, чем на всех виртовских вместе взятых. Получается, что культ Вирта есть, а культа виртовских языков нет. А с Си всё наоборот: есть культ языка, но нет культа его автора.

Любопытно, как пополняется Ваш список? О некоторых языках вообще был ни слухом, ни духом. Откуда?!

     2023/10/19 23:49, Автор сайта          # 

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

Его язык нравится честностью, если это можно так назвать. Программа на нём делает ровно то, что предписано.

Мне много подсказывают. Мои читатели и соавтор по написанию статей Д. Ю. Караваев. Сами авторы языков иногда просят включить сюда. Даже родственники подсказывают :) Много берётся на Хабре. Последнее время в Дзене можно встретить что-то уникальное. Общего алгоритма нет :)

     2023/11/04 20:57, Автор сайта          # 

Добавил язык программирования Sound. Интересно, зачем такое название дано языку? Чтобы найти его на пятисотой странице поисковой выдачи?

     2024/02/26 22:08, Ivan          # 

Я — разработчик языка программирования GAZ Иван Горчаков. Компилятор продолжает развиваться, добавились новые команды — например, работа с Microsoft Excel через OLE, работа с BMP-файлами. Множество скриптов написано на языке GAZ, которыми постоянно пользуюсь. Виртуальная машина языка GAZ в 2024 году работает быстрее, чем версия от 2011/2012 года.

Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход.

P.S. В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ, что делает софт настраиваемым. Но также существует и отдельная сборка компилятора GAZ, которая периодически обновляется.

Язык написан, т. к. в своё время темой компиляторов меня заинтересовал известный доцент Свердлов Сергей Залманович, который 20 февраля 2024 года умер в 69 лет профессором.

     2024/02/27 22:07, Автор сайта          # 

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

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

Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем. Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический.

В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ

На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно.

известный доцент Свердлов Сергей Залманович

По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал.

     2024/02/28 22:02, Бурановский дедушка          # 

Иван Горчаков, а Ваш язык назван не в честь Горьковского автозавода? :)

     2024/03/01 00:45, Деньги на WWWетер          # 

Иван Горчаков:

Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход.

И другие тоже пишут "для себя": https://habr.com/ru/articles/311604/#comment_9839894

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

     2024/03/02 16:34, Ivan          # 

Известный доцент Свердлов Сергей Залманович. По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал.

Я был его студентом. ВГПУ, выпуск 2007 года, учился в 2002-2007. У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время.

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

Сейчас бы точно не стал писать компилятор. Но поскольку он уже написан и работает — почему бы и не использовать в своих целях, немного дорабатывая время от времени под свои задачи. Почему не пользоваться самому — тем более компилятор работает и показал довольно неплохую стабильность, у меня уже несколько тысяч скриптов на нём уже написано, в том числе около 20 скриптов длиной более 1000 строк кода.

В 2021 году пришлось выпустить 64-разрядную версию (тоже для себя), благо Сергей Залманович научил красиво писать код и переход на x64 не вызвал много сложностей.

А не пытались разобраться, почему он не вызвал интерес?

Думаю в том числе потому, что я не пытался его продвигать и раскручивать. Но что толку вкладываться в рекламу если такое практически невозможно монетизировать?

А так может и взлетело бы как какой-нибудь аналог AutoIt. Язык писался именно для практических целей, красота языка и прочее было на 2 месте. Главное для меня не красота, а чтобы работало стабильно, с этим проблем особых нет. С простотой и обратной совместимостью новых версий языка тоже проблем нет. Последняя версия языка от 14 декабря 2023 года, на ней успешно запускаются скрипты 2009 года, например.

Чем не может похвастаться компилятор — так это разве что скоростью работы. Например, пустой цикл for выполняется миллион раз на Intel Core i7. Поэтому собственно и приходится добавлять новые функции время от времени в сам компилятор, а не писать их на встроенном языке. Чтобы работало быстрее.

Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем

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

Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический.

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

На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно.

Проект языка GAZ не закроется — просто не будет развиваться если я на его забью. Например, выйдет какая-нибудь новая версия Windows и приехали. Ну или сайт закроется если мне надоест платить за хостинг. Но сам компилятор в любом случае у меня останется до самой моей смерти, не для того я его писал чтобы потом уничтожить. Варианты взаимодействия и сотрудничества со мной возможны вплоть до моей смерти, даже при закрытии сайта. Мне ещё только 38 лет, так что думаю, ещё поживу.

     2024/03/02 17:24, Автор сайта          # 

Только сейчас до меня дошло, что Сергей Залманович Свердлов — это тот самый Сергей Свердлов из Вологды, который написал знаменитую статью «Арифметика синтаксиса», с которым у меня была заочная полемика. Тесен мир.

Я, например, вообще не очень-то общительный и коммуникабельный.

Знаете, не один Вы. Но есть один способ сделать Вас менее замкнутым. Хотя бы на время. Надо просто собраться в одном месте всем таким любителям изобретать языки и писать компиляторы и пообщаться. Между прочим, опыт был. Могу сказать, что прямо-таки вырастают крылья! Уже было предложение о встрече. Некоторые даже готовы приехать аж из Екатеринбурга. Желательно в летнее время и в какие-то длинные выходные. Но в этом году 12 июня приходится на среду, длинных выходных не будет. Так что вопрос пока открыт. Но если у Вас есть предложения, пишите на почту.

     2024/03/02 19:10, Ivan          # 

Да, жаль, что Сергей Залманович умер. Крутой был человек, рад что был его студентом. Последний раз с ним переписывался 13 сентября 2018 г., на день программиста. Он ответил: "Мне, конечно, приятно, что Вы заинтересовались в своё время тематикой компиляторов и даже не оставляете этот интерес" — буквально так.

По поводу встречи — даже не знаю, а что там делать и что обсуждать и кто вообще пойдёт.

Изучать чужие невостребованные языки на встрече вряд ли кто-то будет, хотя я может и ошибаюсь. А по поводу просто встретиться в Москве — может и хорошая идея. В 2024 году я точно не смогу никуда приехать. Впрочем, если будет какая встреча в Москве в 2025 году — посмотрим.

     2024/03/02 21:52, Ivan          # 

P. S. Еще был выше вопрос, почему GAZ. Название в честь газа, который течёт по трубам; было время хотел назвать bnz, но GAZ больше понравилось.

     2024/03/02 22:06, Автор сайта          # 

По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал.

Нашёл:
Свердлов Языки программирования и методы трансляции

У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время.

У меня такого предмета не было, методы трансляции проходил среди прочего. Но интерес вырос потом.

Изучать чужие невостребованные языки на встрече вряд ли кто-то будет

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

Сотрудники компиляторных фирм мало что публикуют — им некогда.

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

Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми? Вот такие моменты хорошо было бы обсуждать, оказывать взаимную помощь. Лично я не чувствую с чьей-то стороны конкуренцию, какое-то соперничество 😊

Название в честь

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

     2024/03/02 22:43, Ivan          # 

По сути создать какой-нибудь компилятор, если учился у Сергея Свердлова или читал его книги, — сложностей особых нет. Просто нужен интерес, а также надо много свободного времени, которого у многих нет (у меня ушло около 6 месяцев на написание чисто ядра с базовым набором функций, потом по сути только добавление новых функций в основном). Вот действительно настоящая сложность — сделать, чтобы он работал сколько-нибудь быстро, чтобы был оптимизированным, а в идеале чтобы написанный код транслировался в ассемблер/машинный язык, а не в свою же написанную виртуальную машину (лично мне такое, например, не по силам) — чтобы тот же цикл for выполнялся миллиард раз в секунду, а не миллион. А иначе получается язык для написания скриптов, а не программ, который только и остаётся как периодически наполнять новыми встроенными методами для решения новых задач; писать такие методы на самом языке с приемлемой производительностью не получится (попробуй напиши что-нибудь ресурсоёмкое, например, на встроенном языке PHP) — поэтому придётся периодически выпускать новые версии компилятора для эффективного решения новых задач.

     2024/03/03 10:18, MihalNik          # 

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

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

     2024/03/03 12:49, Автор сайта          # 

в идеале чтобы написанный код транслировался в ассемблер/машинный язык

Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код. Если будете транслировать в чистый Си, то могу порекомендовать TinyCC, он быстрее GCC в 9 раз. Но если делать язык исключительно для себя, то может и не стоит заморачиваться. Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет.

     2024/03/03 14:06, Ivan          # 

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

Стековая виртуальная машина. Как учил Сергей Свердлов. Как я понимаю, это самый простой вариант VM, но не самый эффективный. Но как я понимаю, замедление в любом случае будет в случае виртуальной машины. Вопрос только в том, в 10 раз или в 1000 раз. По правде, в 2012 году замедление было в 5000 раз, сейчас оптимизировал всё, что мог, стало медленнее в 1000 раз — скорее всего, дальнейшее значительное ускорение невозможно в рамках текущей VM.

Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код.

Можно, конечно. Но только тогда становится непонятным — зачем тогда нужен свой написанный компилятор. Если всё равно дополнительно придётся таскать с собой компилятор Си, Паскаля и т. д. — не лучше ли тогда сразу писать на Си или Паскале. К тому же у этих самых Си и Паскаля есть свои собственные лицензии, которые могут ограничивать встраивание их компиляторов в сторонние продукты.

Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет.

Да, возможна компиляция в EXE. И скомпилированный файл действительно будет работать и вести себя как EXE во всех смыслах (например, возможен его запуск из командной строки с параметрами, может работать отдельно без необходимости установки компилятора GAZ и т. д.) Но следует понимать, как устроен этот самый EXE. В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ. Поэтому такая "компиляция" в EXE не даст ускорения работы кода. Но работать будет действительно как EXE, что часто может пригодиться. Тот же AutoIt также позволяет, например, компилировать скрипты в EXE похожим образом.

Сейчас, начиная с 2015 года создал и GAZ.dll для встраивания компилятора в свои сторонние проекты.

     2024/03/03 14:26, Max Vetrov          # 

В конец файла записан исполняемый код программы на языке GAZ.

А если попробовать байт-код?

     2024/03/03 15:11, Ivan          # 

А если попробовать байт-код?

Разницы в производительности не будет. Т. к. компиляция самой программы на языке GAZ занимает около 1/10 секунды если размер кода в пределах 2000 строк (а больше писать на таком языке нет особого смысла). При запуске EXE это незаметно.

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

     2024/03/03 16:40, Автор сайта          # 

этих самых Си и Паскаля есть свои собственные лицензии

TinyCC можно, по-моему, свободно использовать и распространять.

В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ.

Когда-то были такие инструменты — FoxPro и Clipper. Первый был интерпретатором, а второй выдавал EXE, а язык был фактически одним и тем же. Но в EXE от Clipper не было исходника, хотя компилятор в него включался, т. к. без него не работала бы функция EVAL.

Медленно работает именно сам байт-код.

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

     2024/03/06 00:39, Ivan          # 

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

Я сравнивал производительность различных языков в 2009 году.

В общем оказалось, что 1С 7.7, ActionScript 2.0, PHP, Python и вообще языки с нестрогой типизацией оказались с довольно сильным замедлением скорости (сотни тысяч или в пределах миллиона выполнений почти пустого цикла с простыми вычислениями в секунду) в сравнении с Java/Delphi (сотни миллионов выполнений такого же цикла).

Что также наводит на мысли, что Java уже на момент 2009 года — это не совсем честная виртуальная машина, а больше нативный код (JIT-компиляция).

То есть даже виртуальная машина PHP (которую явно писали профессионалы и явно оптимизировали там всё, что можно) замедляет вычисление числодробилок раз в 100 — если бы всё было так просто — замедление было бы в 2-3 раза, максимум в 10 раз.

Конкретно по виртуальной машине GAZ — я полагаю — причины замедления в динамической типизации, большом количестве встроенных команд, в генерации не оптимизированного кода (для тех же циклов), ну и может ещё какие ошибки в реализации виртуальной машины с точки зрения производительности, в совокупности это даёт дополнительное замедление ещё в 10 раз в сравнении с PHP.

     2024/03/07 10:45, Автор сайта          # 

причины замедления в динамической типизации

Современные процессоры очень не любят переходы, особенно непредсказуемые. И вызовы тоже. Тесты, которые нерепрезентативны, но дают общее представление о проблеме: «C vs Haskell: сравнение скорости на простом примере». На некоторых примерах удалось получить отставание Хаскелла от Си в полторы тысячи раз.

создать какой-нибудь компилятор, если учился у Сергея Свердлова или читал его книги, — сложностей особых нет

А какие методы компиляции Вы использовали в своей разработке?

     2024/03/07 15:14, Ivan          # 

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

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

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

В общем, на 99% всё как Сергей Залманович учил. Но он учил писать компиляторы, но не учил, как сделать виртуальную машину быстрой.

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

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

А какие методы компиляции Вы использовали в своей разработке?

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

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

     2024/03/09 17:10, Автор сайта          # 

Да, побороться за ускорение можно. Но нужно ли это — на этот вопрос ответите только Вы.

не сказал бы, что эта медлительность как-то мешает

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

x86 ... не по зубам такая задача

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

парсер исходного текста ... синтаксический анализатор

То есть метод рекурсивного спуска? Правильно понял?

     2024/03/11 15:04, Ivan          # 

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

Я думаю: если и есть какие-то перспективы, то от ускорения в 2 раза ровным счётом ничего не изменится (а ускорить в 10 раз малой кровью — скорее всего, не получится). Все равно язык и компилятор будут решать ровно тот же класс задач, что решает и сейчас: по сути, если коротко, это упрощенная и урезанная версия AutoIt (который, кстати сам тоже не блещет скоростью).

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

Почему сам использую свой компилятор, а не AutoIt (который изначально более функционален, например: мне кажется, что язык GAZ выглядит проще (по крайней мере, для меня). Многие небольшие программы выглядят на нём короче, чем на AutoIt, также используется полная компиляция перед выполнением, а не во время выполнения как у AutoIt, что повышает надёжность кода.

Также что мне не понравилось в AutoIt — отсутствие массивов с нулевой длиной.

Не будь этих недостатков у AutoIt — сам бы использовал именно AutoIt как скриптовый язык для сборки своих проектов и встраивания в свои программы. Но про AutoIt я узнал в 2012 году, а GAZ написал в 2009-2012.

То есть метод рекурсивного спуска? Правильно понял?

Честно говоря, забыл уже как это называется. Но похоже, оно.

Сам транслятор исходного кода в байт-код, кстати, очень быстрый — довольно быстро обрабатываются и программы по 100 000 строк. Что показывает, что этот метод парсинга довольно эффективный. Ну а про медлительность VM и причины этого уже писал ...

     2024/03/11 19:58, Автор сайта          # 

Думаю, найдутся языки, программы на которых будут быстрее не в 2, а в 20 раз. И функций там будет на порядки больше. А простота во многом субъективна. Так что ответа на вопрос, что даёт Вашему языку перспективу, пока что нет.

метод рекурсивного спуска?

Честно говоря, забыл уже как это называется. Но похоже, оно.

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

сложностей особых нет

     2024/03/12 00:14, Ivan          # 

Думаю, найдутся языки, программы на которых будут быстрее не в 2, а в 20 раз.

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

И функций там будет на порядки больше.

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

А простота во многом субъективна.
Так что ответа на вопрос, что даёт Вашему языку перспективу, пока что нет.

1) Для меня именно как раз простота.

2) Возможность использования его как простого и урезанного аналога AutoIt, у которого практически нет конкурентов в его классе по простоте кода и обширности функций.

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

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

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

А вообще — конечно, было бы проще и лучше устранить перечисленные мной и другие недостатки AutoIt (который хорош — но имеет множество вариантов выстрелить себе в ногу при написании кода по сравнению с GAZ), чем продвигать мой компилятор.

В мечтах было бы выпустить версию компилятора GAZ под Android и большой набор скриптов для работы с файлами. Но 99,9% что эти мечты так и останутся мечтами навсегда ...

     2024/03/13 21:31, Ильдар          # 

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

Поверьте, это из области ненаучной фантастики.

     2024/03/15 20:34, Автор сайта          # 

А у Вас есть правила Вашего языка, записанные в БНФ? Вопрос к Ивану.

     2024/03/15 23:21, Ivan          # 

А у Вас есть правила Вашего языка, записанные в БНФ? Вопрос к Ивану.

Нет. И вообще я больше практик, чем теоретик. Функциональность интересовала больше, чем красота. Сразу делал всё на компе, без диаграмм и БНФ.

За основу языка брал смесь урезанного Паскаля и 1С 7.7 (из 1С взял = вместо := и динамические переменные).

Мы на 2 курсе писали свой компилятор языка О — и у меня было задание добавить в него поддержку массивов. Собственно этот язык, но с изначальной поддержкой массивов и стал основной GAZ. Также, разумеется, были добавлены if-then-else, while, repeat как неоходимый базовый функционал.

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

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

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

Потом писал много программ на этом языке и оказалось, что компилятор ведёт себя довольно стабильно. Собственно первой нормальной и стабильной сборкой языка можно считать версию от 2011/2012 года, выложенную на сайте. Что было дальше (крупные изменения):

1) 2015 год — выпуск GAZ.dll для возможности встраивания компилятора в сторонние приложения и пример встраивания для Delphi. Если кому-то нужно, могу скинуть. Удобная вещь.

2) 2017 год — ускорение виртуальной машины языка примерно в 5 раз.

3) 2017 год — поддержка #import — для возможности разбивки программы на несколько файлов-модулей.

4) 2019 год — поддержка OLE для работы с Excel.

5) 2020 год — добавление встроенной поддержки 2-мерных массивов. Очень не хватало до этого.

6) 2021 год — выпуск 64-разрядной версии компилятора GAZ. Можно колбасить практически любые данные без риска получить Out Of Memory.

Мелкие доработки нет смысла перечислять, они идут постоянно, раз в 3 месяца, добавление скриптов или встроенных модулей (написанных на языке GAZ) без модификации самого компилятора тоже считается. Хотя компилятор не очень в них и нуждается и уже сам по себе самодостаточен.

P.S. Чего бы временами очень хотелось, но этого нет и никогда не будет — поддержка записей, объектов, вложенных процедур. try-finally-end. Впрочем, как показала практика (и объём написанного кода на языке GAZ), и без этого можно неплохо жить — а вот не будь поддержки массивов — было бы действительно грустно.

     2024/03/16 16:12, Советский          # 

Ivan, БНФ — это просто.

     2024/03/17 00:00, alextretyak          # 

Поверьте, это из области ненаучной фантастики.

Ну, я бы не был так категоричен. Во многом всё зависит от автора языка и его способности продвигать своё детище. Вы ничего не слышали про язык программирования Zig? Это довольно молодой проект, появившийся менее 10 лет назад.

В 2020 году его автор, Эндрю Келли, основал некоммерческую организацию Zig Software Foundation. Посредством только GitHub на данный момент эту организацию спонсирует более 500 человек на общую сумму пожертвований свыше $12000 в месяц (https://github.com/sponsors/ziglang). А итоговая сумма пожертвований составляет свыше $300'000 в год начиная с 2021. Данные за каждый год представлены в файле ‘Finances’ на Google Диске по ссылке: https://ziglang.org/ru/zsf/

При всём при этом, если судить по общему количеству коммитов, основным разработчиком компилятора языка по-прежнему является его автор (https://github.com/ziglang/zig/graphs/contributors). У второго по величине вклада разработчика в 4 раза меньше коммитов, у третьего — в 7 раз меньше. Хотя сейчас основными коммитами автора Zig являются слияния изменений от других разработчиков, общее количество разработчиков на проекте совсем небольшое, и суммы пожертвований хватает, чтобы их содержать.

Да, таких успешных примеров совсем не много, и даже Бьёрн Страуструп, наверное, не зарабатывает столько на C++. Но дело в том, что он к этому и не стремился.

     2024/03/18 00:16, Бурановский дедушка          # 

даже Бьёрн Страуструп, наверное, не зарабатывает столько на C++.

В советское время было популярно такое наблюдение: «Наука — это удовлетворение любопытства за государственный счёт». Страуструп удовлетворил своё любопытство за счёт «AT&T Bell Labs».

Пример языка Zig замечателен. Вот только такое не работает в наших палестинах. У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования.

     2024/03/18 12:38, Ivan          # 

Тут ещё 1 момент. Если проект GAZ вдруг взлетел бы. То конечно, он оброс бы функциями, как минимум. Как максимум может, что-нибудь добавилось бы и в сам язык вроде поддержки try-finally-end или ускорение виртуальной машины в 5 раз. Но в этом случае есть не только +, но и — лично для меня. Пришлось бы подстраивать интересы языка не под себя, а под сообщество, язык стал бы уже не таким свободным и пластичным для меня лично, каковым является сейчас.

Может и баги бы какие-нибудь обнаружились бы, хотя мне и кажется, что их практически нет, последний небольшой баг исправлял в 2021 году (сейчас только что запустил генерируемый скрипт для преобразования 1 папки с файлами в другую на языке GAZ (64-bit), размер скрипта около 700 мегабайт, 113 000 строк кода, в сжатом виде 7z около 25 Мб). Компилятор выдерживает жесточайшие нагрузки и не глючит практически. В отличие от того же cine/fei (имхо и это как мне кажется, конечно — может, дело обстоит не так) — который очень функционален по сравнению с GAZ и даже мог иметь перспективы — будь он отлажен и доведён до ума — но явно самим автором не используется и явно не имеет такой базы юнит-тестов.

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

В самом деле, размер кода самого компилятора в 68 000 строк (на 2012 год) или 126 000 строк (на 2023 год) — притом, что за последние 11 лет добавлялись в основном новые функции (например, Base64Encode), а не дописывалось ядро — это совсем немного чтобы быть функциональным и глючить?

У кого есть свои компиляторы и из скольки строк кода они состоят?

     2024/03/18 12:59, Ivan          # 

У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования.

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

     2024/03/18 13:49, Ivan          # 

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

Не заметил такого практически вообще. Кроме 1 момента — в ВУЗе Сергей Свердлов очень большой акцент делал на красоте кода, а мне больше нравится акцент на функциональности. Впрочем, Паскалеподобный язык, как мне кажется, и не может быть как-то особо некрасив.

Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми?

Как я понимаю, эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит?

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

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

     2024/03/18 17:45, veector          # 

Ivan, хвостовая рекурсия это вот эта тема (там даже примеры есть): https://ru.wikipedia.org/wiki/Хвостовая_рекурсия

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

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

     2024/03/18 23:58, Автор сайта          # 

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

Почитатели языков с вершины рейтингов вряд ли с Вами согласятся. Да и Вы сами от него местами отказываетесь:

из 1С взял = вместо :=

эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит?

Допустим, есть язык с такими правилами:
выражение ::= операторы присваивания | условный оператор
условный оператор ::= "if" условие выражение "else" выражение "end"
Здесь наблюдается рекурсия: «выражение» содержит в себе «условный оператор», «условный оператор» содержит в себе «выражение». В Вашем языке есть что-то подобное, скорее всего. Было любопытно, как Вы перестраивали правила, чтоб избежать рекурсии.

     2024/03/19 02:04, Ivan          # 

Посмотрел код компилятора GAZ. TryOperator — главный элемент, что есть в языке. Вся программа — последовательность элементов TryOperator. Фактически означает обработку try Operator except end. Кстати, кроме вызова Operator содержит около 40 команд виртуальной машины: команды сохранения регистров стека, регистра базы, регистра для команд прерывания Break и продолжения Continue и прочего. И это в каждом операторе. Может, поэтому в том числе код такой медленный, так как он генерирует много команд виртуальной машины. Видимо, в процессе разработки компилятора добавлял нужные команды, чтобы работало и не глючило. И их стало много. А потом уже непонятно и самому стало, как это чудо оптимизировать.

Состоит из элементов типа и является обёрткой Operator, который в свою очередь является одним из:
OperatorAssignmentOrProcedure | OperatorIf | OperatorRepeat | OperatorWhile | 
OperatorLoop | OperatorFor | OperatorReturn | OperatorExit | OperatorBreak |
OperatorContinue | OperatorHalt
OperatorIf, к примеру, в секции после then как раз представляет собой TryOperator. Так что, похоже на то, рекурсия как раз есть.

Вторым ключевым и рекурсивным элементом языка является OperationOR, что означает Выражение.
OperationOR — OperationAND — OperationNOT — OperationCMP — OperationSumma — 
OperationAddon — OperationPower — OperationElement
То есть обрабатывается соблюдение приоритета операторов. OperationElement в свою очередь состоит из OperationOR.

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

     2024/03/19 02:19, Ivan          # 

из 1С взял = вместо :=

Видимо, долго работал на 1С 7.7 и проникся. По духу и синтаксису язык GAZ, конечно, Паскаль, пусть и немного "улучшенный". Чтобы короче писать: = вместо := и с динамической типизацией, чтобы не нужно было объявлять переменные. И раз уж язык разрабатывался как скриптовый, то было бы странным ещё объявлять переменные. И вообще, краткости кода хотелось по сравнению с Паскалем.

Почему по духу, как я считаю, Паскаль: в первую очередь потому, что код на нём простой и понятный, ничего особо сложного и нечитабельного. Как, например, на С++ написать не получится. Синтаксис на 95% как у Паскаля. Никаких || и &&, как в PHP. Никаких долларов в названиях переменных, как на AutoIt. Всё просто и понятно.

С++ считаю самым ужасным языком и ужасаюсь, как вообще можно было такое придумать, код совершенно нечитабельный. При этом пробовал писать программы на С++ и даже написал что-то там на 10 тысяч строк. Правда, преподаватель увидел и сказал, что так на С++ не пишут. Фактически код написан как на Паскале, но с использованием операторов С++, но зачёт поставил.

     2024/03/19 23:12, Автор сайта          # 

Так что, похоже на то, рекурсия как раз есть.

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

С++ считаю самым ужасным языком

Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать. Ада, который был для меня четвёртым по счёту и который можно считать более сложным вариантом Паскаля, мне не зашёл, а вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло.

     2024/03/20 10:39, Ivan          # 

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

Компиляция удивительно быстрая. Проблем вообще никаких нет. Пробовал генерировать и программы по 200 000 и по 500 000 строк, компилируются быстро.

По поводу больше памяти. Может и больше, но, скажем, 5 мегабайт или 10 — разницы вообще никакой нет с современными объёмами оперативной памяти. Когда 1 вкладка браузера потребляет 200 мегабайт. Во времена Pentium II может и было актуально. Так что этот пункт, кажется, спорный.

Вот что больше всего бесило в процессе разработки, так это утечки памяти. Например, при вызове функции Eval, что мешало ставить программы и скрипты, написанные на языке GAZ на сервера для работы 24/7. И не только при вызове функции Eval, но и, например, при выполнении кода.
A[2] = длинная строка
setlength(A, 1)
память не освобождалась. Потом худо-бедно это было решено.

     2024/03/20 15:41, Деньги на WWWетер          # 

Паскаль, пусть и немного "улучшенный".

Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ)

     2024/03/20 22:44, Ivan          # 

Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон

Только Питон хорошо прокинул пользователей с версиями 2 и 3. Нарушил обратную совместимость. И после выхода версии 3 — вторая версия, полагаю, не развивалась параллельно, как 3-я. Так что тоже в своём роде язык не идеальный.

По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык. Вот только я не знаю, что писалось вообще на этом Обероне. Получается — Оберон самый лучший, но почти не используемый на практике, Питон — самый лучший из используемых на практике.

     2024/03/23 18:24, MihalNik          # 

Допустим, есть язык с такими правилами:

выражение ::= операторы присваивания | условный оператор
условный оператор ::= "if" условие выражение "else" выражение "end"

Здесь наблюдается рекурсия: «выражение» содержит в себе «условный оператор», «условный оператор» содержит в себе «выражение». В Вашем языке есть что-то подобное, скорее всего. Было любопытно, как Вы перестраивали правила, чтоб избежать рекурсии.

Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует.

Разбор замедляет перегрузка смыслами операторных знаков и идентификаторов, а не рекурсия. Поэтому:

Компиляция удивительно быстрая. Проблем вообще никаких нет.

Это как раз не удивительно. Компонентный Паскаль, например, у меня парсился со сбором лексики около 100К строк в сек/ядро бюджетного ноута 12-го года с конструкциями вида:
case symbol of
...
Relation_s:
R:= S('=') or S('#') or S('<=') or S('<') or S('>=')
or S('>') or W('IN') or W('IS');
...
Смысла писать БНФ вместо сразу работающего и однозначного кода по сути нет. И перегрузка языка сложными правилами гораздо сильнее замедлит переваривание кода человеком, а не машиной. Вот написали Вы слишком теоретизированный БНФ, а потом по нему пишут такой же код. На деле должно быть:
Выражение ::= Выражение с ключевого слова | Выражение с идентификатора
И тогда сразу очевидно — берем слово, его хеш, смотрим в табличке наличие флага ключевого слова, сверяем с ключевым словом: да — проверяем допустимость (по табличке) и переходим к элементу грамматики, нет — работаем с процедурой или переменной, при том уже известно с чем именно, в отличие от "теории", которая, например, при опечатке проглотит вызов функции для идентификатора какой-нибудь целочисленной переменной, оставив проверку "на следующий этап".

вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло.

Довольно не просто проникнуться слабой типизацией, синтаксисом с трудным вылавливанием точечных опечаток и перегруженностью значков разными смыслами. Глянешь на какой-нубудь оператор "++" — ни краткий (достаточно одиночного +), ни однозначный (постфиксный и префиксный с различным приоритетом) — явно сделан чтобы писать спагетти код. Правда автоматом расплести подобное не представляет такой уж трудности, код любого ЯП можно при желании читать в любом синтаксисе, который программист себе пожелает сделать, да и генерить его из любого синтаксиса не сложно.

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

Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать.

А для многих он был лишь вторым или третьим, а потом ещё тоже много других и тоже было с чем сравнивать. Также надо понимать, что люди будут говорить о совершенно разных языках и средствах, называя С или ++. Сейчас ++ совсем не те, что были в 90-х, как и, например, 1С с 8-ой версии и до неё — просто небо и земля. Можно попробовать взять "Современное проектирование на С++" Александреску 2001-го года и сравнить с тем, как можно теперь. Было бы неплохо переписать Вашу утилиту транслитерации именно в духе современных ++.
По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык.
Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП, из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая.

     2024/03/24 07:31, kiv          # 

Что бы понять восторг от появления в руках Си, попробуйте представить путь автокодно-ассемблерный: Днепр-Урал-Наири-ЕС-СМ2-СМ4-НЕВА501-ИСКРА226 (и ещё кучка малоизвестных спец. архитектур) и, наконец, Си на x86. На рубеже 80-х — 90-х прошлого века я добился покупки и сам забирал ленту в НИЦЕВТ Си транслятора для ОС-ЕС и переписывал стандартную библиотеку под ПДО (СВМ), в которой была чистая паравитуализация и весь ввод-вывод организован не через обращение к каналам, а к гипервизору.

Для меня Си это универсальный мультиплатформенный макроассемблер. И кстати указатели и структуры органично сложились в голове на основе помимо ассемблерного опыта, ещё и опыта PL/1, в котором базированная структура "наше всё".

Для человека пришедшего в Си из Ассемблеров ++/--переменная или переменная++/-- — это элегантное изображение множества макросов, которые он писал до того, как в руках появился Си.

     2024/03/24 13:09, Автор сайта          # 

MihalNik

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

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

Смысла писать БНФ вместо сразу работающего и однозначного кода по сути нет.

Можно и не писать правила в БНФ, если это считать лишней работой, которая лишь расходует время. Но если есть правила в таком виде, то это документация, помогающая
1) разработчику языка, «кристаллизуя» его мысли,
2) разработчику компилятора в качестве ТЗ,
3) программисту, пользователю языка и компилятора для лучшего понимания.

Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир».

Довольно не просто проникнуться . . . перегруженностью значков разными смыслами.

Да, Вам тоже не повезло проникнуться духом Си. 🤣 Одни видят в инкрементах/декрементах элегантность, а другие — перегруженность. Но, кстати, от постфиксных операторов я предпочитаю отказаться.

для многих он был лишь вторым или третьим

Знаю таких, у кого он был первым. 🤣 И ничего, необратимых последствий для мозга не возникло.

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

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

Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП [Оберон], из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая.

Прям мои мысли читаете. 🤣 А набранные заглавными буквами ключевые слова — вообще отдельная песня.

kiv

сам забирал ленту в НИЦЕВТ Си транслятора для ОС-ЕС

А PL/1 Вас не устраивал? Тоже язык высокого уровня. Тем более, что Вы дальше пишите:

ещё и опыта PL/1, в котором базированная структура "наше всё".

это элегантное

Вот именно, сравнивая
а = а + 1
x = x + y
и
++ а
x += y
я понимаю, что краткость — сестра таланта. Что Ритчи был гений. Недооценённый, кстати. Если с Виртом сложился «культ личности», то о скромном гении Ритчи вспоминают куда реже. Если языки с синтаксисом Си наверху во всех рейтингах, то упоминаемость этих двух авторов языков являет нам противоположную картину.

     2024/03/24 13:12, MihalNik          # 

Что бы понять восторг..., попробуйте представить

Так есть более ценные предметы для понимания... Можно, например, представить, что вместо "int,int,int" можно "Ц Ц Ц", "ЦЦЦ" или "3 ц".

     2024/03/24 13:37, MihalNik          # 

Вам тоже не повезло проникнуться

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

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

Авторам КНИГ можно порекомендовать написать КОМПИЛЯТОР, который это делает автоматически.

Но если есть правила в таком виде, то это документация, помогающая

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

Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир».

Отличный пример. И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом?

     2024/03/24 14:11, kiv          # 

А PL/1 Вас не устраивал? Тоже язык высокого уровня.

Очень бы устроил, если был бы доступен на других платформах. Как-то почти всю мою жизнь одновременно приходилось работать всегда на нескольких. Устроил бы даже очень, но именно тот PL/1 который я знаю и помню, где помимо базированных структур была встроенная в язык многозадачность и асинхронный ввод/вывод. Я уже много раз писал в разных местах о том, что современные упоминания асинхронности вызывают у меня улыбку, ибо в середине 1980-х меня "фигурально били" в курилке, за то, что я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами. :)

     2024/03/24 15:27, Автор сайта          # 

Таким крайне опасно давать много денег.

Но Вы-то денег не даёте. Поэтому эта опасность Вас не касается. 🤣

И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом?

Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел.

Очень бы устроил, если был бы доступен на других платформах.

На x86 он был, вот только лично я узнал относительно недавно, когда поезд давно ушёл. Кстати, Орлов Владимир Николаевич, говоря о своём переходе с PL/1 на Си, отмечал, что для x86 не было компилятора PL/1, поэтому при переходе с ЕС ЭВМ на x86 пришлось переходить с PL/1 на Си. На что Дмитрий Юрьевич заметил, что компилятор таки был. Но это тоже было недавно, когда поезд уже ушёл.

я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами.

ОС ЕС была присуща многозадачность, поэтому у компилятора PL/1 была простая задача: сгенерировать код, который формирует параметры, а затем вызывает прерывание с нужным номером. Вот и всё. А DOS не была многозадачной, поэтому сомневаюсь, чтоб всё было так просто.

     2024/03/24 15:59, MihalNik          # 

Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел.

А где ещё успешно применяется БНФ?

     2024/03/24 18:01, Автор сайта          # 

БНФ применяется в генераторах синтаксических анализаторов. Yacc, ANTLR, JavaCC и прочих. Правда, формат записи разнится, но легко приводится от одного вида к другому.

     2024/03/24 19:26, MihalNik          # 

БНФ применяется в генераторах синтаксических анализаторов

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

     2024/03/24 19:35, Автор сайта          # 

Конечно. Более того, игрушками считают компиляторы, сделанные вручную, а вот сгенерированные такими инструментами — надёжными и с некоторым уровнем гарантированного качества.

     2024/03/24 19:38, Metasyntax          # 

БНФ

Software that accepts BNF (or a superset) as input

• ANTLR, a parser generator written in Java
• Coco/R, compiler generator accepting an attributed grammar in EBNF
• DMS Software Reengineering Toolkit, program analysis and transformation system for arbitrary languages
• GOLD, a BNF parser generator
• RPA BNF parser.[16] Online (PHP) demo parsing: JavaScript, XML
• XACT X4MR System,[17] a rule-based expert system for programming language translation
• XPL Analyzer, a tool which accepts simplified BNF for a language and produces a parser for that language in XPL; it may be integrated into the supplied SKELETON program, with which the language may be debugged[18] (a SHARE contributed program, which was preceded by A Compiler Generator[19])
• bnfparser2,[20] a universal syntax verification utility
• bnf2xml,[21] Markup input with XML tags using advanced BNF matching
• JavaCC,[22] Java Compiler Compiler tm (JavaCC tm) — The Java Parser Generator

Similar software

• GNU bison, GNU version of yacc
• Yacc, parser generator (most commonly used with the Lex preprocessor)
• Racket's parser tools, lex and yacc-style parsing (Beautiful Racket edition)
• Qlik Sense, a BI tool, uses a variant of BNF for scripting [23]
• BNF Converter (BNFC[24]), operating on a variant called "labeled Backus–Naur form" (LBNF). In this variant, each production for a given non-terminal is given a label, which can be used as a constructor of an algebraic data type representing that nonterminal. The converter is capable of producing types and parsers for abstract syntax in several languages, including Haskell and Java

Кроме того существуют другие формы записи КС грамматик .

     2024/03/24 20:23, MihalNik          # 

Более того, игрушками считают компиляторы, сделанные вручную.

Интересно было бы провести соответствие со списком TIOBE.

     2024/03/24 23:32, Автор сайта          # 

TIOBE — это про языки, а Yacc — про реализацию компиляторов. Тот же Си или C++ имеют множество реализаций как с помощью инструментов типа Yacc, так и написанных вручную.

     2024/03/25 00:36, MihalNik          # 

TIOBE — это про языки, а Yacc — про реализацию компиляторов.

Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать.

Тот же Си или C++ имеют множество реализаций как с помощью инструментов типа Yacc, так и написанных вручную.

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

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

     2024/03/25 00:44, MihalNik          # 

Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ)

Разработчик самого верхнего языка в этом перечне вряд ли так считает.

     2024/03/25 12:01, Metasyntax          # 

Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать.

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

     2024/03/25 15:23, Ivan          # 

Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ)

И в чём так уж хорош Питон? Что ввиду его медлительности постоянно приходится думать, как его ускорить всякими psyco, PyPy и прочими извращениями. В этом плане как раз куда лучше C++/Delphi/Java — для написания серьёзных программ. Или речь про интерпретируемые языки для написания скриптов, а не программ? Если так — тогда может и в самом деле Питон самый лучший.

     2024/03/25 18:23, Автор сайта          # 

Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать.

Никто ж не афиширует методы реализации своих компиляторов. В основном молчат, хотя бывают исключения: Уолтер Брайт, разработчик компиляторов Zortech C++ и D, делал это вручную. А вот TinyCC сделан с помощью какого-то генератора: во-первых, об этом писали, во-вторых, это чувствуется по очень неинформативным сообщениям об ошибках.

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

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

В теории генератор может создать более быстрый анализатор.

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

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

Насколько я знаю, Microsoft не хватает ночи, чтобы откомпилировать новые версии своих продуктов. Но у них и объёмы кода такие, что превзойдут всё, что наработано в РФ. У небольших организаций вряд ли будут проблемы.

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

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

Разработчик самого верхнего языка в этом перечне вряд ли так считает.

И в чём так уж хорош Питон?

Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв. Динамическая же типизация, интерпретация и связанная с этим медлительность — это несущественно на фоне этой революции. Александр Третьяк взял в свой язык 11l из Питона самое главное — синтаксис (дорабатывая его). И делает, если не ошибаюсь, язык со статической типизацией; компилятор, а не интерпретатор.

     2024/03/25 20:52, Ivan          # 

Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв.

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

Тем более не могу назвать язык "лучшим в мире", который страдает болезнью зависимости компиляции от отступов и тем более позволяет if-блоки оформлять отступами — громадное поле для багов.

     2024/03/25 22:14, Деньги на WWWетер          # 

игрушками считают компиляторы, сделанные вручную

Я бы даже сказал «кустарным способом».

зависимость компиляции от отступов — вот это как раз меня это выбесило

А кого-то взбесила бы зависимость компиляции от «then» и «end». А в Питоне «end» вообще не нужен.

     2024/03/25 23:22, Ivan          # 

Си был для меня седьмым по счёту языком, а C++ — восьмым

Для меня Си++ был вторым языком после Паскаля. Я был уверен, что Профессионал и Си++ это синонимы, поэтому даже написал на Си++ программу на 10 тысяч строк в 11 классе. Но при этом воспринимал Си++ как недопаскаль, фактически писал на Си как на Паскале, не используя дух Си++. А после того как Сергей Залманович раскритиковал Си++ на лекциях и вовсе перестал на нём писать.

     2024/03/25 23:47, Автор сайта          # 

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

Кстати, встретил книгу Свердлова «Конструирование компиляторов». Очень хорошие первые впечатления.

     2024/03/27 10:22, Ivan          # 

Вчера понял. Вместо написания многих языков "энтузиастами" можно использовать готовый известный язык Lua. Который можно напичкать функциями — кусками кода основной программы, вызываемыми из Lua. Будет как раз встраиваемое решение во внешние программы, чем так гордятся многие разработчики собственных компиляторов, в том числе я. По крайней мере, сам язык не придётся писать, а только необходимые функции.

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

Lua.dll распространяется по нормальной BSD-лицензии, а не какой-нибудь GPL, поэтому библиотеку можно встраивать в свои компиляторы, не раскрывая исходный код.

     2024/03/27 13:40, Автор сайта          # 

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

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

В AutoCAD применяют AutoLISP. Проторенная дорожка. Lua нашёл применение в наших импортозамещающих офисных пакетах вместо VBA. Хотя жаль, но не отечественный язык.

     2024/03/27 18:44, MihalNik          # 

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

Именно. Поменялось. ЭВМ почти не было, ЯВУ не было и опыта программирования на них не было. Языки программирования разрабатывали на бумаге. Вы можете зачеркнуть кусок БНФ и дописать кусок в конце — БНФ не сломается.

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

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

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

     2024/03/27 19:06, Ильдар          # 

Недостатки синтаксического анализа методом рекурсивного спуска:
  • создаются очень большие программы синтаксического анализа;
  • существует тенденция к появлению в теле одной функции операций, относящихся к разным фазам процесса компиляции.
Для эффективного использования рекурсивного спуска требуется:
  • преобразователь грамматики, который в большинстве случаев сможет трансформировать грамматику в форму LL(1);
  • возможность представить эквивалент программы синтаксического анализа методом рекурсивного спуска в табличной форме. Это означает, что при проверке входного текста программа будет не входить в функции и покидать их, а просто перемещаться по табличному эквиваленту грамматики, при необходимости занося в стек адреса возврата.
Хорошие преобразователи существуют и временами объединяются с инструментальными средствами и дают "таблицы" LL(1). Кроме того, те же инструменты могут определять операции, которые следует выполнять на определенных этапах синтаксического анализа. Существенным преимуществом является задание операций именно относительно исходной, а не преобразованной грамматики, поскольку пользователю удобнее мыслить понятиями исходной, более естественной грамматики, чем понятиями менее естественной LL(1)-грамматики, порожденной преобразователем. Если в преобразованной грамматике будет отсутствовать левая рекурсия, она может быть в исходной грамматике, обеспечивая, таким образом, более естественную основу для определения операций времени компиляции, таких как генерация кода для вычисления выражений слева направо.

     2024/03/27 22:48, MihalNik          # 

Это одно из преимуществ табличных методов разбора, которые применяются в средствах типа Yacc.

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

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

     2024/03/28 13:26, Ivan          # 

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

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

     2024/03/28 15:50, MihalNik          # 

Наоборот, странно было бы писать на интерпретируемом языке алгоритмы оптимизации.

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

Ну, как видите, есть куда. Только у Вашего языка своя определенная специализация. Прошло много лет с момента его создания, отслеживать развитие множества других технологий, поддерживая основной продукт, не являющийся собственно самим ЯП, просто выглядит нереально. Для сравнения — в какой-нибудь С++ завозят достижения даже не одного десятка лет свежести.

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

     2024/03/28 21:36, Ivan          # 

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

     2024/03/29 14:26, Советский          # 

Просто компилируется в код VM, а не x86.

Можно попробовать JIT-компиляцию для увеличения скорости.

     2024/03/29 14:49, Ivan          # 

Можно попробовать JIT-компиляцию для увеличения скорости.

На таком языке, где каждая переменная — это динамический массив с длиной 1 динамического типа (integer|float|string), боюсь, что JIT-компиляцию в принципе не сделать.

     2024/03/29 15:42, Советский          # 

... что JIT-компиляцию в принципе не сделать.

Мне кажется, что вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Всё, что интерпретируется, может быть откомпилировано.

     2024/03/30 01:22, Ivan          # 

Мне кажется вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Все что интерпретируется может быть откомпилировано.

Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Отдельная структура под исполняемый код и отдельная под переменные. И регистров у виртуальной машины пара десятков. Хорошо поговнокодил в своё время в попытках добиться стабильной работы компилятора (главным образом, реализация try-except-end потребовала много инструкций), очень много лишних инструкций. По правде говоря, стабильности работы добиться удалось.

Если всё это переводить на JIT — фактически придётся всё переписывать с нуля. И займёт по времени это раз в 10 больше, чем написать с нуля ещё пару компиляторов как у меня. И точно также будет не востребовано, ровным счётом ничего не изменится. Не говоря про то, что писать это всё придётся 10 лет и уже в процессе написания это всё устареет.

Как я понял, JIT — это вообще серьёзная штук а, довольно мало для каких языков она в принципе существует, только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT.

Если реально хочется использовать JIT и встраиваемый язык — как я выяснил, проще использовать готовый язык Lua, добавив в него свои процедуры и функции, которых там не хватает. И я думаю, это правило можно применить ко многим языкам, которые в списке. Сам так бы и сделал, если бы вернулся в 2009 год.

     2024/03/30 23:45, Автор сайта          # 

Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки.

Шла речь об оптимизации методов разбора для создаваемых компиляторов.

Просто компилируется в код VM, а не x86.

А если в код JVM или MSIL?

Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6.

Как так? Вроде бы писали по заветам С.З.Свердлова.

Если всё это переводить на JIT — фактически придётся всё переписывать с нуля.

Если компиляция разбита на фазы, то так не должно быть, по идее.

писать это всё придётся 10 лет и уже в процессе написания это всё устареет.

Если Ваш язык не содержит новых идей, то он устарел до написания.

только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT.

Д.Ю.Караваев много лет в одиночку пишет компилятор PL/1 под x86. Не JIT, конечно, но по скорости программы почти не уступают MS C++.

     2024/03/31 20:34, Ivan          # 

Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6.

Как так? Вроде бы писали по заветам С.З.Свердлова.

Свердлов не учил писать Continue и Break для циклов. А также try-except-end. А именно это потребовало добавления дополнительных стеков и регистров. Без добавления нескольких стеков пришлось бы активно копаться в едином, активно применяя команды drop, swap, over и т. д., что ещё больше бы увеличило объём говнокода и замедлило скорость.

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

Но тут надо отдать должное Свердлову: благодаря его заветам компилятор-таки дописан до конца. А без его заветов я бы скатился в говнокод куда сильнее и куда раньше, утонул бы в сложности и забросил компилятор, так и не написав.

Если Ваш язык не содержит новых идей, то он устарел до написания.

Может быть. Но если вместо добавления новых идей (например, добавлял было 2-мерные массивы и OLE) потратить время на JIT, то он устареет ещё быстрее. Новые идеи так-то были — замена стандартных BAT-файлов Windows. Простым языком. Язык существенно проще аналогов, а перед BAT имеет только один минус, что не встраиваемый. Ну я даже попробовал его "встроить" ещё в процессе написания — он инсталлируется в папку c:\windows\entry, а не в какие-нибудь "Program Files".

А если в код JVM или MSIL?

Честно говоря, такой же тёмный лес, как и x86. В JVM вообще смысла нет, т. к. язык потеряет одно из преимуществ — встраиваемость. И компилируемость в EXE.

Если компиляция разбита на фазы, то так не должно быть, по идее.

Может и можно сделать возможность ассемблерных вставок или вставок на языке С++/Delphi. Даже всерьёз думал об этом, причём в 2020 году. Но так руки и не дошли. Идея куда более простой кажется, чем полноценный JIT. Но толку от этого JIT всё равно особо не будет. На GAZ серьёзные программы и игры писать всё равно не получится, это изначально скриптовый язык. А для скриптов скорости хватает за глаза.

     2024/04/01 00:51, Автор сайта          # 

активно применяя команды drop, swap, over и т. д.

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

неохота больше в этом говне копаться... я бы скатился в говнокод куда сильнее и куда раньше

Вы так рекламируете своё детище, прямо диву даёшься.

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

Не знаю, какие задачи Вы ставили перед собой. Но доводилось обеспечивать взаимодействие своих программ как с «*.bat», так и с «*.exe» и «*.com». В Си есть функция spawnl, которая обеспечивает вызов файлов перечисленных выше типов. Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу. Но это решаемый вопрос. Такие же вызовы делал из Форта (слово RUN) и Клиппера (функция RUN).

     2024/04/01 11:30, Ivan          # 

Вы так рекламируете своё детище, прямо диву даёшься

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

Но внутренний код генерации команд для виртуальной машины такой, что заново не захочется туда лезть и что-то там править, чтобы ничего не сломать. Тем более через 12 лет после написания этого кода. И почему-то думаю, не у меня одного так, тут у многих людей в списке гораздо более сложные компиляторы написаны. Соответственно и потенциальных глюков там может быть больше. Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only.

К добавлению новых команд в виртуальную машину это, конечно, не относится. Но в большинстве случаев вместо добавления новых команд в виртуальную машину пишу модули на своём же языке. Правда, приходится иногда добавлять и команды в VM, как это случилось, например, с Base64Encode в 2019 году (сначала написал на своём языке, но потом производительность не понравилась для больших строк — например, размером в 100 Кб).

     2024/04/01 12:38, Ivan          # 

Не знаю, какие задачи Вы ставили перед собой.

Язык изначально создавался как командный интерпретатор для запуска программ, копирования, переименования файлов и т. д. Очень уж мне не понравился в этом плане BAT, захотелось что-то получше. Команды для работы со строками, числами, try-except и прочее, что сделало язык полноценным, было добавлено уже потом, в процессе.

На 99% возможностей для скриптов хватает, благо прошло уже более 10 лет, особо ничего дорабатывать не приходится. Если надо что доработать — процедуры легко пишутся на самом языке. Очень редко что-то приходится добавлять именно в VM — как правило, в основном случае нехватки производительности. Синтаксис же языка и генерация кода вообще не меняется, да и попробуй поменяй, свои же скрипты, накопленные за годы могут перестать работать или начать глючить.

Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу

Как правило, через командную строку, через параметры запуска. А вывод результата — либо также, в командную строку, либо в файл, который задаётся в параметрах запуска вызываемой программы, потом выполняется RunWait. Таким образом интегрируются почти все языки между собой, даже 1С. Но способ, конечно, не лучший и не самый удобный.

У меня, например, многопоточность поддерживается тоже с обменом данными через файлы. Хочется временами сделать возможность взаимодействия с DLL, возможность подключения внешних DLL, это более реально, чем заморачиваться с JIT, для этого не придётся лезть в сам язык, в генератор кода и т. д., а просто придётся добавить новые методы в VM. Но всё руки не доходят.

     2024/04/02 00:09, Автор сайта          # 

Не верю я, чтобы какой-либо разработчик забросил свой компилятор, если он в целом работающий и отлаженный.

Да запросто. Поинтересуйтесь языком Глагол. Автор языка написал компилятор и исчез. Но им продолжают пользоваться. И даже есть сайты пользователей языка, посвящённые Глаголу.

на Ассемблере программы изначально write-only.

Не скажите. У опытного программиста даже ассемблерные программы хорошо читаются.

     2024/04/02 00:40, Max Vetrov          # 

Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only.

Почему write-only?
ассемблер
Можно и читать, комментарии же есть, нормальные имена модулей, функций.

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

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

     2024/04/03 13:33, Ivan          # 

Можно и читать, комментарии же есть, нормальные имена модулей, функций.

В принципе, у меня примерно также. Может и не говнокод такое называется. Но тем не менее, желания туда лезть (в код подобного рода) и что-то там менять особо не возникает.

     2024/04/03 17:24, Max Vetrov          # 

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

Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть.

     2024/04/03 18:32, Ivan          # 

Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть.

Ускорить там что-то практически нереально без потенциального добавления багов. В случае проблем — да, относительно легко всё находится и исправляется, модульность есть.

Исправлял небольшие проблемы, было дело в 2016, 2017 и 2020. Возможно и сейчас что-то есть, чего я не знаю, но на компиляторе для себя написано уже более 200 тысяч строк кода.

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

     2024/04/03 20:06, Max Vetrov          # 

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

но на компиляторе для себя написано уже более 200 тысяч строк кода.

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

     2024/04/04 10:31, Ivan          # 

Собственно, никакой проблемы особо нет. Я сделал компилятор, теперь пользуюсь, кайфую :)

Почему не удаётся особо править VM и генератор кода — в первую очередь потому, что у меня код компилятора, можно сказать, в 2-х экземплярах. Один в качестве отдельного, автономного компилятора (а также GAZ.dll), другой встроен в программу Client Shop. И доработав что-то в одном месте, по идее эти же изменения нужно вносить и в другое место. Всё осложняется тем, что после встраивания компилятора в программу Client Shop были времена, что нарушал это правило: внеся доработки в автономную версию компилятора, не вносил в программу и наоборот. Поэтому программный код этих 2-х компиляторов разошёлся, хоть и совпадает на 95%.

Да, пробовал выравнивать код с помощью WinMerge и т. д., но всё равно полностью не выравнивается и код немного отличается. Ещё выравнивание отсложнено тем, что в сборке для программы в компилятор добавлено множество характерных именно для программы функций. А в автономной сборке есть функции, которых нет в программе. Некоторые методы (по правде, их немного, всего 1%), доработанны в 1 месте, но не доработанны в другом. Отличаются количеством параметров, например. Реализация InputString отличается в автономном компиляторе и в программе, хотя функциональность одинакова.

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

     2024/04/04 13:02, Max Vetrov          # 

Собственно, никакой проблемы особо нет. Я сделал компилятор, теперь пользуюсь, кайфую :)

Что-то не похоже :)

Да, пробовал выравнивать код с помощью WinMerge и т. д., но всё равно полностью не выравнивается и код немного отличается. Ещё выравнивание отсложнено тем, что в сборке для программы в компилятор добавлено множество характерных именно для программы функций. А в автономной сборке есть функции, которых нет в программе. Некоторые методы (по правде, их немного, всего 1%), доработанны в 1 месте, но не доработанны в другом. Отличаются количеством параметров, например. Реализация InputString отличается в автономном компиляторе и в программе, хотя функциональность одинакова.

Я так понимаю автономная версия использовалась для разработки. Текущую автономную версию — в архив, зачем бороться за этот 1%? От основной версии создаете новую ветку для разработки.

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

Ну не знаю, системы контроля версий помогают.
https://nvie.com/posts/a-successful-git-branching-model/
https://tleyden.github.io/blog/2014/04/09/a-successful-git-branching-model-with-enterprise-support/

     2024/04/12 19:41, Бурановский дедушка          # 

Читаю вот такой пассаж одного товарища из списка выше:

Развитие Русского Языка Программирования мне уже не интересно, так как я стал (и уже был) космополитом.

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

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

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

     2024/04/12 22:13, Вежливый Лис          # 

У автора того мнения о ненужности РЯП дрейф мотивации, и дефекты в логике. У Бурановского Дедушки дефекты в логике тоже есть и мотивации тоже нехватает. Это жизнь.

     2024/04/13 11:03, Автор сайта          # 

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

     2024/04/16 17:55, Ivan          # 

Я так понимаю автономная версия использовалась для разработки. Текущую автономную версию — в архив, зачем бороться за этот 1%? От основной версии создаете новую ветку для разработки.

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

Есть ли смысл самому использовать как инструмент и встраивать в свои продукты, иногда добавляя немного новых встроенных функций — пожалуй, отвечу "да". Выжимать прибыль и удобства из уже сделанного определённо стоит. По крайней мере на данном этапе. Но лучше стремиться использовать какие-то более стандартные решения — тот же Lua, например.

Писать с нуля что-то подобное точно не стоит, лучше изучать что-то типа 1С/С++ или хотя бы Python и зарабатывать по 150 тысяч в месяц, чем бултыхаться в своём болоте с самописными компиляторами. Впрочем, если это приятно, доставляет удовольствие и приносит какие-то деньги — почему бы и нет ...

     2024/04/18 00:21, Ильдар          # 

если это приятно, доставляет удовольствие и приносит какие-то деньги

Кому-то это приятно и без денег :)

     2024/04/18 11:14, Ivan          # 

Кому-то это приятно и без денег :)

Безусловно приятно — иначе бы не было столько проектов от энтузиастов, половина из которых, наверняка, вообще ничего от своих проектов не получили. И вообще приятно применять и использовать полученные знания — в моём случае знания, полученные от Сергея Свердлова. В моём случае хотя бы получилось применять и использовать.

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

Да, компилятор по сути написан по большей части в рабочее время, работа была не бей лежачего. Но с другой стороны и платили там соответствующим образом. Пока я там сидел и балдел за 20 тысяч в месяц и писал компилятор, мои однокурсники уже по 40-60 тысяч зарабатывали (да, это были приличные суммы, скажем, в 2010 году), накупили квартир, машин, поездили по разным странам.

Сейчас же мне гораздо более приятно, что я работаю удалённо, а не сижу в офисе 9/5 (с перерывом на обед). Ну и то, что компилятор уже написан и не лежит бесполезно, а его можно использовать — хоть немного, но всё равно греет душу.

     2024/04/20 10:34, Ivan          # 

Кстати, без шуток. Увлёкся я тут в последний месяц этими всякими Lua, Python и прочим. Казалось бы, простейшую задачу нужно решить, но не получается:
  • Выбрать скриптовый язык программирования, на котором можно как писать отдельные скрипты, так и встраивать эти же скрипты в свои приложения на Delphi без сильного переписывания. У Lua с этим проблемы, например — как обычный язык, без встраивания он совершенно нефункциональный.
  • Он должен быть совместим как с Delphi 7, так и с Delphi XE8 и встраиваться в обе среды. Скрипты должны работать без переписывания. У меня проект, который ведётся одновременно на Delphi 7 и на Delphi XE8.
  • Язык программирования должен быть совместим со всеми ОС — начиная от Windows XP до Windows 11. У Python с этим проблемы, например, они уже даже от Windows 7 начали отказываться. Я сам не могу отказаться от поддержки Windows 7, т. к. мой продукт должен работать на всех ОС — поэтому такой встраиваемый язык не подходит.
  • Встраиваться язык должен в Delphi желательно без необходимости подключения километровых модулей с непонятными лицензиями и непонятным качеством. Даже у Lua с этим проблемы — библиотеки или непонятно кем написаны, или имеют лицензию GPL, что неприемлемо или не работают одновременно со старыми и новыми версиями Delphi. Тексты библиотек километровые, а вроде же это Lua, где всё должно быть просто.
На фоне всего этого мой самописный компилятор GAZ под мою текущую задачу выглядит не так плохо.

Может, кто подскажет стандартные решения: как можно выполнить задачу, описанную выше, не прибегая к использованию языков "энтузиастов" или к самописным решениям?

     2024/04/21 00:03, Автор сайта          # 

Я уже говорил, как бы сделал я. Наверняка в Делфи есть подобное. Я бы ещё подумал использовать Си в качестве скриптового языка: компилятор TinyСС настолько быстр, что пауза на компиляцию почти незаметна. Был прецедент такого использования: кто-то из «наших» израильтян использовал его вместо скриптов на PHP. Вариантов, на самом деле, немало. Но всё равно окончательный выбор только за Вами.

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

     2024/04/21 00:48, Ivan          # 

Я уже говорил, как бы сделал я. Наверняка в Делфи есть подобное. Я бы ещё подумал использовать Си в качестве скриптового языка: компилятор TinyСС настолько быстр, что пауза на компиляцию почти незаметна. Был прецедент такого использования: кто-то из «наших» израильтян использовал его вместо скриптов на PHP. Вариантов, на самом деле, немало. Но всё равно окончательный выбор только за Вами.


У моего компилятора есть преимущество. Можно на нём писать скрипты и модули и почти без изменений потом встраивать в основную программу, при этом функционала для моих задач достаточно. В этом плане — как я полагаю, сходство с Python — только встраивается проще и поддерживает все операционные системы Windows и все версии Delphi.

Lua слишком малофункционален и отдельно как скриптовый язык его использовать сложно. С++ слишком сложный и перегруженный. Нашёл ещё какой-то PascalScript — вроде функциональный язык для встраивания, надо разбираться. Можно бы использовать AutoIt, на который я во многом равнялся, но у него тоже есть минусы.

А сейчас этот компилятор не является тем якорем, который держит Вас на текущей работе?

Думаю, нет. Я уже не на той работе. И если что и держит на текущей работе — то что-то другое.

     2024/04/22 21:56, Ильдар          # 

на компиляторе для себя написано уже более 200 тысяч строк кода.

Ну и зачем тогда париться? Язык самому нравится, компилятор вылизан (протестирован аж на 200 000 строк кода), чего ещё надо? Зачем PascalScript? Первая заповедь инженера: если работает — не трожь.

     2024/04/23 15:57, Ivan          # 

Просто интересно — какие ещё есть варианты внедрения компилятора кроме моего в Delphi-софт. Нет, не для отказа от своего решения. Скорее чтобы параллельно добавить в софт возможность выполнения скриптов ещё на одном языке. Возможности которого, возможно, больше, чем в моём варианте. Например, возможность менять свойства VCL в Runtime, если включен RTL и т. д.

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

     2024/04/25 21:05, Ttimofeyka          # 

К слову, для меня до сих пор сложной частью является совместимость с cdecl64. Обычно мало кто говорит об этой проблеме, но соглашение о вызовах C для структур работает крайне неоднозначно — важен не только размер структуры, но и порядок размещения типов внутри её (протестировано с помощью godbolt на компиляторах C/C++, clang).

     2024/04/28 14:50, Автор сайта          # 

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

Решился на пополнение списка диалектом Си от Андрея Николаевича Терехова — РуСи. Его отличает от оригинального Си как ограничения, так и расширения. Язык предназначен как для обучения студентов, так и для разработки высоконадежного ПО.

     2024/05/02 18:24, Ильдар          # 

РуСи... для разработки высоконадежного ПО.

Неужели в нём запретили void* и приведение типов (void*)?

     2024/05/03 22:19, Ivan          # 

C++ — мой нелюбимый язык. За его сложность и плохую читаемость. Хуже него только Perl — там всего в 10 строчках можно такое написать, что без бутылки не разберёшься. Слава Вирту, что придумал Паскаль.

     2024/05/03 22:29, Прохожий          # 

Паскаль в утиль.

Слава Вирту

Не сотвори себе кумира!

     2024/05/03 22:38, Ivan          # 

Паскаль в утиль.

Не могу так сказать. Т. к. учился на Турбо-Паскале с 2001 по 2006. Потом перешёл на Delphi в 2006-м и по 2024-й на нём и сижу. 23 года стажа на языке Паскаль! Ненамного меньше, чем стаж езды на велосипеде.

Это хороший, продуманный и понятный язык. Непонятно только, почему вакансий на Delphi так мало и эти вакансии не сказать, что хорошие.

     2024/05/04 00:59, Автор сайта          # 

Не сотвори себе кумира!

Да, выше на эту тему уже высказывались:

Когда же назовут какой-нибудь язык в честь Вильяма нашего Шекспира Денниса Ритчи? Его вклад в языки ничуть не меньший, чем у Вирта. На его языке написали больше, чем на всех виртовских вместе взятых. Получается, что культ Вирта есть, а культа виртовских языков нет. А с Си всё наоборот: есть культ языка, но нет культа его автора.

Не согласен с этим:

Это хороший, продуманный и понятный язык.

Языку более полувека. За это время многое придумано, что помогает разработке. Тольяттинской «копейке» тоже более полувека. Её несовременность вроде бы всем очевидна. А вот несовременность Паскаля (да и Си тоже) почему-то очевидна не всем. Как, к примеру, из Паскалевской функции вернуть результат, если всё пошло по плану, а если пошло не по плану, то как-то передать информацию об этом в вызывавшую функцию? Да так, чтобы было невозможно обратиться к результату, если вычисления пошли не по плану. Если быть короче, то как в Паскале выполнить обработку особых ситуаций, аналогичных монадам Maybe и Either в Haskell? И таких примеров несовременности немало.

     2024/05/04 01:08, Паскалюб          # 

Паскаль для аристократов, плебеям здесь не место. Только ценители осознают красоту Паскаля.

     2024/05/04 10:22, Прохожий          # 

Тольяттинской «копейке» тоже более полувека. Её несовременность вроде бы всем очевидна.

Людей держит не функциональность, а что-то другое. Эмоции(связь со своей старой жизнью), инерция(нежелание что-то менять), лень.

     2024/05/06 11:29, Ivan          # 

Как, к примеру, из Паскалевской функции вернуть результат, если всё пошло по плану, а если пошло не по плану, то как-то передать информацию об этом в вызывавшую функцию?

raise Exception.Create — подойдёт?

Кстати те, кто много лет работал на Delphi — часто и на C++ пишут в таком же стиле, как на Паскале, не используя возможности С++ в полной мере. И просто считая Си испорченным Паскалем.

Людей держит не функциональность, а что-то другое.
Эмоции(связь со своей старой жизнью), инерция(нежелание что-то менять), лень.

Вот как интересно. А если у меня написано 550 000 строк кода — мне что, на другом языке это всё переписывать? Я понимаю, что новые языки волшебно-крутые по сравнению с Delphi — но они при этом не поймут даже 10% кода, написанного на Delphi несмотря на их крутость.

Миграция с Delphi 7 на Delphi XE8 и то была геморроем и заняла месяц почти + исправление багов ещё около года. А миграция совсем на другой язык это значит переписать всё с нуля. Поэтому нет особого смысла.

Вот если писать что-то новое — стоит ли использовать Delphi — тут уже вопрос. Если и использовать, то не версию 7, а какой-нибудь XE10, скорее всего. А вообще альтернатив Delphi не видно — чтобы была быстрая компиляция и быстрое получение EXE. Чтобы не требовалось устанавливать разные .NET или Java (которая, кстати, тоже имеет уязвимости и баги), про Си++ вообще молчу. Чтобы программа работала на любых ОС начиная с Windows XP.

Непонятно только при этом — почему у Delphi такая низкая популярность.

     2024/05/06 16:10, Автор сайта          # 

raise Exception.Create — подойдёт?

Нет, не пойдёт. Вот что пишут про Delphi:

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

Видите, это не повседневный инструмент.

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

try
AssignFile(F, FileName);
Reset(F); // если файл не найден,
//возникает исключительная ситуация EInOutError
except
on Exception do ...
end;

Но для экономии ресурсов можно использовать и другой способ:

if FileExists(FileName) then    // возвращает False если файл не найден
//исключительной ситуации не возникает
begin
AssignFile(F, FileName);
Reset(F);
end;
Но есть третий способ, который берёт лучшее от двух перечисленных, я приводил в пример монады Maybe и Either в Haskell. Он сочетает как обязательность проверки, которая присуща обработке исключений, так и легковесность обычных условных выражений. Это как раз и отличает современные языки от устаревших.

если у меня написано 550 000 строк кода — мне что, на другом языке это всё переписывать?

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

Я понимаю, что новые языки волшебно-крутые по сравнению с Delphi — но они при этом не поймут даже 10% кода, написанного на Delphi несмотря на их крутость.

Кто они, которые не поймут? Новые волшебно-крутые языки? Ну так их компиляторы понимают свои тексты, на не Объектного Паскаля.

А вообще альтернатив Delphi не видно — чтобы ... программа работала на любых ОС начиная с Windows XP.

И заканчивая KasperskyOS?

Непонятно только при этом — почему у Delphi такая низкая популярность.

Не пробовали найти тех, кто перешёл с Delphi на что-то другое, чтобы стаж разработки на чём-то другом был не меньше предыдущего опыта?

     2024/05/06 21:33, Прохожий          # 

Вот как интересно. А если у меня написано 550 000 строк кода — мне что, на другом языке это всё переписывать? Я понимаю, что новые языки волшебно-крутые по сравнению с Delphi — но они при этом не поймут даже 10% кода, написанного на Delphi несмотря на их крутость.

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

Миграция с Delphi 7 на Delphi XE8 и то была геморроем и ...

Может, поэтому у Delphi проблемы. Может также проблема, что Delphi занимается только одна контора.

Вот если писать что-то новое — стоит ли использовать Delphi — тут уже вопрос. Если и использовать, то не версию 7, а какой-нибудь XE10, скорее всего.

Задаетесь вопросом — стоит ли использовать Delphi для нового и сразу же отвечаете, что нужно использовать версию Delphi не X, а Y. Немного странно.

А вообще альтернатив Delphi не видно — чтобы была быстрая компиляция и быстрое получение EXE.

Если безопасность отключить, то ещё быстрее будет. Это просто привычка. Кроме Delphi сколько вы языков ещё знаете?

Чтобы не требовалось устанавливать разные .NET или Java (которая, кстати, тоже имеет уязвимости и баги), про Си++ вообще молчу. Чтобы программа работала на любых ОС начиная с Windows XP.

А какие могут быть проблемы с ними? Что-то я не понимаю? Просто холивар.

Непонятно только при этом — почему у Delphi такая низкая популярность.

Потому что есть другие альтернативы. Кому как удобнее, тот так и пишет. Мне как бы все равно, что вы любите Delphi, нравится — пишите. Зачем вам других обращать в свою веру?

Я в своё время в институте столкнулся с Паскалем. Но он мне не зашел — переменные надо писать в определенном месте, а не в месте использования, begin-end — вместо простых скобок. В общем это всё вкусовщина и холивар. Пишите на том, на чём удобно, главное чтобы сам язык хорошо поддерживался, появлялись новые библиотеки.

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

     2024/05/07 13:02, Ivan          # 

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

Смысла в таком компиляторе в случае моего языка не вижу. Уж лучше тогда сразу писать программы под этот другой язык программирования, зачем лишнее звено.

Не пробовали найти тех, кто перешёл с Delphi на что-то другое, чтобы стаж разработки на чём-то другом был не меньше предыдущего опыта?

Не пробовал

Если безопасность отключить, то ещё быстрее будет. Это просто привычка. Кроме Delphi сколько вы языков ещё знаете?

Насколько знаю? Знаком с PHP, JavaScript, CSS, Node, C++, Java, AutoIt, BAT, SQL — писал небольшие программы на этих языках.

А какие могут быть проблемы с ними? Что-то я не понимаю? Просто холивар.

То, что не у всех пользователей .NET и Java установлены. И нужно либо встраивать это в общий инсталлятор. Либо терять часть клиетов.

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

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

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

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

Сергей Залманович — кстати, сделал язык Оберон и компилятор, транслирующий код в Java. Но я так и не понял, зачем мне использовать его Оберон если можно сразу писать на Java. Всё равно без установки Java его Оберон работать не будет. Получается фактически та же Java, только с меньшим функционалом, ограниченным возможностями Оберон. И код, скорее всего, будет работать медленнее, чем если писать непосредственно на Java.

Если быть короче, то как в Паскале выполнить обработку особых ситуаций, аналогичных монадам Maybe и Either в Haskell?

Почему именно Delphi с Haskell сравниваем? У тех же Java и .NET тоже популярность выше, чем у Delphi. А преимущества их не очевидны.

     2024/05/07 20:11, Ильдар          # 

Задал вопрос YandexGPT:

Почему среда программирования Delphi перестала пользоваться популярностью?

Ответ такой:

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

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

     2024/05/07 23:08, Автор сайта          # 

Смысла в таком компиляторе в случае моего языка не вижу. Уж лучше тогда сразу писать программы под этот другой язык программирования, зачем лишнее звено.

Если Вы однажды решили, что надо переходить на новый язык программирования, например Rust или любой другой, то у Вас возникнет вопрос: а как перенести эти 550 000 строк кода на новый язык? Переписать, что ли? Да не обязательно. Просто надо научить Ваш компилятор генерировать не байт-код, а код на Rust. Один раз перенесли 550 000 строк, а дальше просто продолжаете пополнять свои наработки уже на новом языке.

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

У Герберта Шилдта как-то прочитал рассуждение в таком духе: «Если Вам не нравятся существующие языки программирования — напишите свой! Современное состояние инструментов для написания компиляторов позволяет это сделать сравнительно легко и быстро».

Почему именно Delphi с Haskell сравниваем? У тех же Java и .NET тоже популярность выше, чем у Delphi.

Знакомство с другими парадигмами может оказаться очень полезным. Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело.

     2024/05/08 06:37, Вежливый Лис          # 

Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело.

Но топчик почему-то Python...

     2024/05/08 12:44, Ivan          # 

Просто надо научить Ваш компилятор генерировать не байт-код, а код на Rust. Один раз перенесли 550 000 строк, а дальше просто п7родолжаете пополнять свои наработки уже на новом языке.

Не всё так просто. Код в 550 000 строк таким образом не перенести на другой язык. Хотя бы по той причине, что код Delphi-специфичный, аналогичного функционала на Java или .NET может и не быть (хотя могут быть другие возможности). Все эти обработчики событий на Delphi, overread методы, DBGrid и прочее.

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

Знакомство с другими парадигмами может оказаться очень полезным. Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело.

Неужели код на Haskell, например, пустой цикл, может выполняться миллиард, а не миллион раз, как на Python? Если производительность кода ниже на порядок — то нечего и сравнивать с Delphi — значит, это не для написания больших программ.

Но топчик почему-то Python...

Это ещё почему? Интерпретатор, а не компилятор, который в разы медленнее Delphi. Потому и сравниваю с Java и .NET, а н с каким-ниюудль Python.

     2024/05/08 15:34, Автор сайта          # 

Был упомянут Haskell, а не Python не потому, что он лучше или производительнее, а потому что он из совсем другой парадигмы. Задачи решаются другим способом. Знакомство с другими подходами расширяют кругозор, что, в общем-то, желательно для людей, придумывающих новые языки программирования. Однако слова

Неужели код на Haskell, например, пустой цикл

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

Если производительность кода ниже на порядок — то нечего и сравнивать с Delphi — значит, это не для написания больших программ.

Haskell, по некоторым утверждениям, уступает Си в скорости в 3,5 раза («Функциональное программирование»). Однако на некоторых задачах мне удалось добиться разницы в полторы тысячи раз («C vs Haskell: сравнение скорости на простом примере»). Это говорит о том, что Haskell не универсален и нужно понимать, на каких задачах он может тормозить. Но если программа будет в 3,5 раза медленнее, то это не очень большая цена, учитывая прогресс процессоров. Тем более, что «правильность важнее эффективности», как утверждает Лидия Васильевна Городняя. С чем я на 90% согласен.

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

Существуют. Например GnuCOBOL:

Свободный проект GnuCOBOL позволяет транслировать программы на языке COBOL в представление на языке C для последующей компиляции при помощи GCC или других компиляторов C.

Весьма востребованное решение:

Общий объём написанного на COBOL кода оценивается в сотни млрд строк, из которых более 100 млрд строк до сих пор активно используются, в основном в финансовых учреждениях (по состоянию на 2017 год 43% банковских систем продолжали использовать COBOL, код на COBOL применялся при обработке около 80% персональных финансовых транзакций и в 95% терминалов для приёма платежей по банковским картам).

     2024/05/08 21:04, Ivan          # 

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

     2024/05/08 22:16, Автор сайта          # 

Это далеко не эзотерический язык, не для потехи. В рейтинге Tiobe он на 28 месте. Выше, чем Julia, Perl, Lua, Lisp, Forth, Bash. Наверное, это о чём-то говорит. Здесь описано одно мнение: «Один разработчик на Haskell заменяет пять программистов на JavaScript».

     2024/05/08 22:55, Ivan          # 

говорят о незнакомстве с Haskell, в котором нет циклов

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

     2024/05/09 00:06, Автор сайта          # 

Так Вы же задавались вопросом, отчего Delphi теряет популярность. Вам отвечают, что он не шагает в ногу со временем. Тот же Haskell, который предложил что-то новое, поднялся в рейтинге Tiobe за 8 лет на 10 мест. Котлин предложил немало нового, он в этом рейтинге 19-й. Он ещё не догнал Delphi, но, видится, это лишь вопрос времени.

     2024/05/09 13:05, Прохожий          # 

Интерпретатор, а не компилятор, который в разы медленнее Delphi.

Все в этом мире относительно. Существует байт-код Python .

     2024/05/11 16:33, Автор сайта          # 

Иван, про Delphi пишут. Возможно, Вам будет, что сказать.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

●  Отечественные компании-разработчики компиляторов

●  Энтузиасты-разработчики компиляторов и их проекты

●  Ресурсы, посвящённые созданию языков программирования и компиляторов

●  Экскурс в историю разработок языков программирования и компиляторов в СССР

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/07/08 16:56 ••• veector
Постфиксные инкремент и декремент

2024/07/01 21:58 ••• Прохожий
ЕС ЭВМ — это измена, трусость и обман?

2024/06/21 00:20 ••• Gudleifr
О превращении кибернетики в шаманство

2024/06/19 00:16 ••• Gudleifr
Программирование исчезнет. Будет дрессировка нейронных сетей

2024/06/12 11:27 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других

2024/05/31 12:31 ••• Прохожий
Идеальный транслятор

2024/05/28 15:16 ••• Прохожий
Русской операционной системой должна стать ReactOS

2024/05/25 17:18 ••• Прохожий
Избранные компьютерные анекдоты

2024/05/11 16:33 ••• Автор сайта
Энтузиасты-разработчики компиляторов и их проекты

2024/04/28 15:58 ••• Автор сайта
Обработка ошибок

2024/04/23 00:00 ••• alextretyak
Признаки устаревшего языка

2024/04/20 21:28 ••• Бурановский дедушка
Русский язык и программирование

2024/04/01 23:39 ••• Бурановский дедушка
Новости и прочее