Энтузиасты-разработчики компиляторов и их проекты
Перечень (в алфавитном порядке, по ссылке — подробнее)
Подробнее
Выше перечислены оригинальные языки программирования. Здесь нет перечня компиляторов к языкам, придуманным «не у нас». В качестве исключения только хотелось бы отметить интересный проект Андрея Андреева «Странник» — компилятор с общей семантической базой языков Паскаль, Модула-2 и Си. Смотри так же:
Опубликовано: 2012.09.25, последняя правка: 2024.04.18 14:29
Отзывы
Ещё у мелкомягких есть SmallBasic, сам пробовал, идея хорошая, реализация как всегда (поэтому бросил и пошёл искать другое), и похоже проект то ли бросили, то ли некому делать, всё давно повисло. Если бы они проект тянули нормально, был бы хороший язык для начинающих. По одной из ссылок нашёл HomeLisp, недавно было обновление, проект жив. Буду смотреть, что это такое. Админ, спасибо за страничку (хорошо бы её обновить и даты обязательно проставить, ссылки перепроверить, одна сдохла).
Здесь перечислены языки отечественных авторов. Список компиляторов/интерпретаторов к готовым языкам можно поискать в других местах, я их уже указывал: Ресурсы, посвящённые созданию языков программирования и компиляторов. Там можно найти и Бейсик, и Паскаль, и Форт... Немало проектов, в том числе международных.
Хотя Валентину с сайта я убрал, так как автор Уткин куда-то пропал и уже долгое время не выходит на связь и не присылает никаких обновлений языка. Но последняя версия Валентины у меня все таки есть, если интересно пишите на almin-soft(собака)yandex(тчк)ru
еще забыт язык vkACL, у него русский автор и я в нем усматриваю аналогию с шитым кодом. Автор Виктор Кон, физик, что-там с линзами по работе с рентгеном, совместный российско-французский проект. Я переписывался с ним одно время как раз по-поводу создания языков программирования. Насколько помню язык прост и не поддерживает рекурсию (автору не требовался).
Язык интерпретируемый, на том же сайте есть интерпретатор и есть набор утилит на этом языке. Поскольку создавался он ещё в среде ДОС (последняя версия транслятора — 2001 год) и я так и не собрался перевести его под окна, сейчас, конечно. Его применение затруднительно и не так актуально. Однако, я сам до сих пор использую некоторые полезные утилиты на этом языке. Кроме того, на Эллочке были написаны интерпретатор и компилятор(!) известного языка "brainfuck". Их тоже можно скачать на указанном сайте.
обсуждение на этом сайте носит несколько однобокий характер Да тут немало языков рассматривалось. Или однобокость заключается в том, что не рассматривался MUMPS?в отличие от многих других языков, работоспособен Не могли бы привести примеры неработоспособных языков? C/C++? Java? C#? Pascal? PHP? Oberon? Ruby? D? Javascript? 1С, в конце концов?
Посмотреть это можно здесь.
Поэтому определения слова: : prepare ... ;или : подготовить ... ;или : bereiten ... ;Никакой разницы не имеет.
Например: "RU" vocДалее компиляция (интерпретация) пойдет в словарь RU, который станет текущим словарем. В Jpho в системном словаре JFO более 500 предопределенных слов, но если мы хотим переопределить слова в другом языке, то следует создать файл-словарь, в котором будут определены слова на необходимом языке. Например: : дублировать dup ;Это значит, что вместо стандартного слова dup аналогично будет работать слово "дублировать". Не вижу никакого смысла вводить название слов по-русски в код, так как это можно реализовать загрузкой словаря (и по-английски короче и традиция).
Обратная (польская) запись: 100 300 +На вершину стека положили число 100, потом 300 (100 ушло в позицию 1 стека, в положение 0 попало число 300), слово "+" складывает два объекта в стеке с положением 0 и 1, и возвращает сумму на вершину стека. Т.е. на вершине стека будет 400. 100 300 + .А это все сложит и выведет результат в выходной поток. Определим слово "возведение_в_квадрат" // n — n2Дублируем число в стеке, а потом перемножаем, результат в стек.
1. Язык Jpho предназначен не для написания приложений (хотя это возможно), а для интеграции с Java и Java EE технологиями. (понятно, что изменения Java-кода требуется перекомпиляцию проекта, в основном это в работающей системе невозможно). 2. Изменение Jpho-скрипта возможно без переустановки систем (тем более, что коды мы храним в БД). 3. Jpho может обратиться к любому Bean, менеджеру, к БД или Web-сервису. 4. Jpho, в отличии от FORTH, использует префиксы и постфиксы, например, создание переменной: 100 Моя_переменная!Получить значение из атрибута (используется префикс): @nameТ.е. получить из объекта в стеке значение геттера getName. !name - тоже установить setName.Остальное можно прочитать в документации.
Сейчас запросы другие, но остаются в приоритете: 1. Интеграция с приложениями 2. Быстрая обучаемость 3. Замена кода без перекомпиляции проекта 4. Бесконечное количество отчетов в HTML/Excel/PDF 5. Работа Web-сервисов и клиентов.
1. Расхождения с Фортом стилистические и не только (например, префиксы, постфиксы). Например, в FORTH строка должна начинаться со слова «" »: " Это строка". Слово «"» прочитает из входного потока слово «" » и поймет, что это строка. В Jpho используется префикс " и никаких пробелов не нужно 2. Да, Jpho работает на JVM. Другие реализации возможны: PHP, JavaScript (который и так используется в Web-технологии), C++.
Для поддержки языка (кодирование и сборка) осуществлена адаптация интегрированной среды разработки Netbeans. Основной набор инструментов, доступных для Java, теперь доступен и для нового диалекта Ява. Также в рамках поддержки этого проекта осуществлено добавление кириллических аналогов ключевых слов языков C/C++/ObjC/ObjC++ в компиляторе GCC. Получившийся компилятор предполагается назвать RuCC/Ru++. В планах есть оборачивание стандартной библиотеки C кириллическими именами и примерно такой же подход для стандартной библиотеки C++.
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/ , есть примеры и описание языка.
Сборка содержит модули OMeta, SmaCC — компиляторы компиляторов (с примерами грамматик готовых языков в SmaCC) которые могут быть использованы для разработки своего транслятора или полуавтоматической трансляции в/из свой язык программирования.
Вот Глагол — русский язык программирования, уникальный? По-моему, нет — это просто Оберон-2 с русским синтаксисом. Концептуально Глагол, Оберон-2 и какой-нибудь BlackBox Component Pascal, школьная сборка http://www.inr.ac.ru/~info21/software.htm http://inf.1september.ru/article.php?ID=200800100 — это один и тот же язык, семантически. Небольшие отличия в синтаксисе и переводе — не существенны. А например Рапира и Оберон — разные языки, ибо в Рапире кортежи есть, а в Обероне — нет.
Мечтаю увидеть русский LOLCODE :) ПРИВ
https://gitlab.com/budden/ja-o-s
Глагол позиционировался автором как отдельный язык. А как Вы позиционируете свой язык? Если как отдельный, то тогда нужна ссылка, где бы описывался именно язык.
ЯОС никак не расшифровывается, просто название ОС с кириллицей в явном виде. Это рабочее название, может ещё смениться.
https://gitlab.com/budden/ja-o-s/-/blob/главная/док/яп-активный-оберон/описание-языка.md
Автор Глагола назвал свой язык Глаголом. Я ему поверил и включил в этот список. Вы же называете Обероном, я Вам тоже верю, и поэтому не включаю. Хотя желаю успехов в работе.
Но, простите, эта ниша уже занята. Для школы уже написаны учебники. При этом очередной новый язык не обладает обратной совместимостью этими книгами. В учебнике написано одно, а в новом языке — совсем другое. Учителя информатики его не знают. Гороно/районо инициативу, скорее всего пресечёт. Остаются школьные кружки, и то если эти кружки будет вести автор языка.
Для школы уже написаны учебники. К сожалению, они никуда не годятся. Тем более современные. Начинать учить системщика надо бы с написания своего языка. А готовить пользователя — наоборот с купи-продай с минимальным введением в ПО. Недавно нашел свои преподавательские заметки, сильно смеялся. Тогдашний ПТУ-шник, сегодня — гик.
Существенно то, что язык с ними не совместим Хороший учебник вообще не должен быть ориентирован на язык. А язык должен быть совместим только с практическими(!) задачами, которые учащиеся могут решить.
Так вот надежды несбыточны Сбыточны. Только нужно писать язык вместе(!) с учащимися под практические(!) задачи.
Да нет, с первоклассниками не придумывают азбуку или правила арифметики А тут и не нужно изобретать азбуку, нужно научить писать изложения и сочинения. Программирование не является "отраслью" — это полезный навык, вроде умения есть ножом и вилкой и мыть руки после туалета.
Уроки по информатике он ведёт по школьной программе. А вот на кружках у него свобода рук Я обходил эту проблему внедрением программированного обучения.
(условие) -> {действие} -> {действие иначе};Цикл:(условие) <--> {тело цикла};
Т.е. невключение моего проекта в данный список начинает уже выглядеть несколько искусственным. Также неясно, чем ЯОС хуже Глагола. Компилятор Глагола вроде бы закрыт, поэтому Вы не можете утверждать, что он написан Издателем. А значит, нельзя отказать ЯОС во включении в список. Неясно, чем он хуже OneScript, который является клоном 1С, в точки зрения языка. В ЯОС есть отличия и нововведения. Что ещё мешает?
Ещё нужно вспомнить о компиляторе Оберона «Восток», который написал Comdiv. В отличие от Вашего, у него компилятор собственной разработки. Вполне резонно Comdiv может меня спросить, почему я обошёл его проект вниманием. Есть и другие разработки компиляторов «ненаших» языков, например, Си Алексея Мандрыкина. А вообще роль и важность этого списка для меня не слишком очевидна :)
Обнаружил некоторое созвучие в идеях, а именно в идентификаторах, которые, по мнению Алексея, могут был на кириллице, содержать в себе пробелы, и даже могут вообще содержать произвольный текст, если заключены в кавычки. Это соответствует тому, что было в русификаторе Си Нашёл («Тривиль — вопросы и уточнения») у Недори это «созвучие»:4) Идентификатор Паниковать!Я бы даже назвал это не созвучием, а прямым заимствованием (если не сказать больше). Лично я не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. Только на этом сайте. Вот фрагменты Вашего кода («Вычисление определителя матрицы. Программа на русском Си»): _31 №;Тут и кириллица, и пробелы, и «№» в идентификаторах. Так что Ваши идеи уже находят место в других языках.
Лично я не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. Только на этом сайте. А я знаю. Например, язык "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, Тривиль.
не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. А я знаю. Процитирую описание языка с сайта:2.4 Идентификаторы Вы давно клоните в сторону всякого рода гипертекстов, литературного программирования. Но это, как и «программирование без программистов», не интересует. Цель заявлена, отклонения от курса не будет. При этом мы оба можем оказаться правы, ведь абсолютно универсальных языков не бывает, каждому может найтись своя ниша.
Более того, можно вводить идентификатор между вертикальным чертами, тогда допустимы вообще любые символы кроме вертикальной черты. Примеры идентификаторов: В контексте "Natural Language Programming" — интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем. Например, падежей, склонений, спряжений, наречий, причастий и т.п. различных суффиксов при одинаковом корне. Например, есть японский язык программирования Nadesico с поддержкой падежей (в остальном он примерно похож на бейсик). Но там иероглифы, и форма записи вообще слоговая. Для благозвучия "программирования на русском" было бы разумно не только поддерживать пробелы в идентификаторах, но и задавать флексии, например те же падежи: родительный — некий класс имярек, творительный — порождающий интерфейс, один из нескольких, скорее генератор с yield чем просто какой-то из конструкторов винительный — resonsibility (основная функция, ответственность, которую класс реализует самостоятельно) предложный — concern или collaboration (прочие обязанности, делегируемые другим классам). Тогда сразу по форме имени мы узнали бы как он будет использоваться, и чего от него стоит ожидать. Ну и для прочих наречий и причастий можно был бы найти применение. И для всяких древностей типа звательный падеж, двойственное число, ариост плюсквамперфект и т.д.
можно вводить идентификатор между вертикальным чертами Это весьма непродуманный вариант. Это не просто вертикальные черты, это обозначение операции «или». Если изъять из этот символ из перечня операций, то что взамен? Ничего лучшего для «или» не придумаешь. В русификаторе C/C++ более десятка лет используются обратные апострофы. Между ними могут быть любые символы:`это идентификатор из любых символов !@#$%^&*()_+`Вариант с обратными апострофами хорош тем, что этот символ на клавиатуре есть, а вот традиции использовать его в языках программированя — нет. Поэтому он свободен для применения в новинках. вообще в Лиспах принято несколько слов писать через минус, а не пробел. И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше. Но и он проигрывает самому обычному пробелу, который придаёт естественность многословным идентификаторам. Не правда лине печётсяэто лучше, чем не-печётся? интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем. Совсем не интересно. Думаю, она появится тогда, когда программированием займутся нейронные сети. И как бы мы ни упирались, нас отправят на заслуженный отдых. Именно поэтому неинтересно.задавать флексии, например те же падежи Считаю пустой тратой времени. Попробуйте, для начала, описать правила русского языка в БНФ, а потом эту формализацию воплотить в транслятор. Даже воплощать не надо — достаточно заняться первым, а до второго дойдёте с кончиной либо падишаха, либо осла.Но Вы можете опровергнуть. Просто реализуйте всё то, что предлагаете. Останется тогда признать Вашу правоту.
Это не просто вертикальные черты, это обозначение операции «или». Если изъять из этот символ из перечня операций, то что взамен? Ничего лучшего для «или» не придумаешь. А зачем придумывать что-то для "или"? Знака нет на русской раскладке, т.е. набирать неудобно. Хотя раскладку можно настроить, но тогда уже странно объяснять какой-либо выбор наличием или отсутствием чего-то на ней — получается, что взбрело в голову, то и хорошо. Хорошо, что что-то туда взбрело)задавать флексии, например те же падежи Считаю пустой тратой времени. однако:Не правда ли для начала, описать правила русского языка в БНФ Зачем, если можно просто спросить падеж с исходной формой в словаре?Думаю, она появится тогда, когда программированием займутся нейронные сети. И как бы мы ни упирались, нас отправят на заслуженный отдых. Именно поэтому неинтересно. Нейросеть умеет делать то, чему она обучена на готовых решениях и делать нечетко, а это не всегда то, что нужно, обычно как раз всякие неинтересные задачи.
Не правда ли, "ширина окна" лучше чем "окно.ширина" или "окно->ширина", а "10 чисел" лучше чем "число[10]"? Достичь более-менее терпимой естественности в рамках одного идентификатора нетрудно. Если же в погоне за совершенством начать приводить целые языковые конструкции к правилам русского языка, то запросто утонешь в сложности. Лучше усилия направлять в другом направлении, где отдачи от вложенных усилий будет больше.Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее. Зачем, если можно просто спросить падеж с исходной формой в словаре? А если в словаре нет специфичных терминов? Как видоизменять «IP-адрес» (которого нет в словарях!) по числам и падежам? Ведь есть просто безграмотные люди (меня сегодня повеселили словами «борщь» и «пильмени»), тогда вместе с программированием будет происходить и «отладка» русского текста?Конечно, могу ошибаться. Просто продемонстрируйте работающее решение со словарями. И я перейду на светлую сторону :) Наше обсуждение отклонилось от темы статьи. Но куда перенести комментарии?
Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее. Ну также как к подчеркам/дефисам в идентификаторах. Ведь "пр-к" короче чем "прямоугольник". То есть и в естественных языках и в ЯП дефис также может быть очень полезен.Достичь более-менее терпимой естественности в рамках одного идентификатора нетрудно. Нетрудно, но для большинства точно также будет бессмысленно. На самом деле незначащий мусорный клей мешает даже меньше чем значащий. Только поэтому среди распространенных ЯП пробелов в них нет. Более того, достичь вполне терпим_ естественност_ нетрудно_ и в рамк_ цел_ выражен_ обычн_ ЯП. Для эт_ достаточн_ вместо изменяем_ част_ слов_ писать какой-нибудь "_".
И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше. Дефис-то набирается одним пальцем, а подчерк — двумя, потому что в верхнем регистре. Этим он хуже.
Прочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку.
В программе на Фортране, вместо "DO 3 I = 1,3" было набрано "DO 3 I = 1.3", что было воспринято компилятором как присвоение значения 1.3 переменной DO3I Все ещё хотите пробелы?
Во-вторых, очень странно, что в Фортране допускаются идентификаторы в пробелах. Вот читаю документацию по языку: Для обозначения переменной служит идентификатор — последовательность, состоящая не более чем из шести цифр и букв алфавита, причем первым символом должна быть буква. Пробелы в записи идентификаторов не допускаются. Что-то мне кажется, что тут ошибка зарыта в другом месте. Пробелы не виноваты. Возможно, компилятор должен был сообщить об ошибке. Но могу ошибаться, ибо Фортран совсем не знаю.Ну и в-третьих, ключевые слова, идущие впереди идентификатора, не должны входить в этот идентификатор. Например, if i > 0
забирайте свои слова назад Забираю :) Ну надо же, в таких древних языках такое уже было. Ходим по кругу, можно сказать. А ведь такая узкая прослойка программистов была! Однажды мне одна дама задала вопрос, отчего я с компьютерами «на ты». Ответил, что получил образование в этой области. Удивилась: «Неужели этому учат?». А ведь учат уже более полувека. Дольше, чем ей было лет тогда.
Прочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку. Спасибо за наглядный пример кода. Вот по этому тексту вопрос: "многословные идентификаторы", или "идентификаторы с пробелами" все в именительном падеже.ПОИСК В ТИ(ДАННОЕ ИМЯ)логично было бы просклонять в родительном или винительном: ПОИСК В ТАБЛИЦЕ ИДЕНТИФИКАТОРОВ (ДАННОГО ИМЕНИ)Можно также придумать 1. В языке 1С, например. Ява-подобные идентификаторы типа СтаршийПомощникМладшегоДворника МенеджерОбъектовДекораторАбстрактнойФабрикиМостаСинглтонаКомпозитораВивисектора и прочие "немецкоязычные" идентификаторы на четыре строки одним словопредложениемсинтетическогословотворчествамокроходовсоснегоступами. ///RTFM: Марк Твен, "Почему немецкий не мой любимый язык". Читается это всё нелепо, не по-русски: никакой лепоты. Например, потому что искусствено навязывается именительный падеж строго везде, даже там где невместно сие. 2. В языке RInform, русский Inform6. Здесь просто отбрасываются окончания. Ну и задаются все словоформы в разных падежах как синонимы. 3. Любопытно, как это было реализовано в русском Алгол-68, есть ли тут какая-то информация. В общем, насколько я понимаю — никто специально не следит за корректностью спряжений, склонений, падежей, времён и прочих словоформ, все либо ограничиваются именительным падежом либо таблицей синонимов. А между тем, можно сделать эту информацию значащей.
Также анафоры типа "оно её", "того на этого","это самое","вот эта фиговина" — тоже можно выводить в раскрытие означаемого полуавтоматически (типа макроса "анафорического if" в лиспе, подставляющего нужное вместо it). Попытаюсь продолжить пример Алгол-68 из Википедии в гипотетический "русский Алгол": # Next day date - english variantНе правда ли, с синонимами, падежами, склонениями стало легче читаться? Отсутствие возможности корректно склонять падежи, сопрягать времена, использовать нужные синонимы, лексемы, морфемы, и, самое главное — семемы приводит к тому, что и читается сей код вымученно, искусственно, не по-русски. Русский язык богат и выразителен. Велик и могуч. Там есть полисемия, синкопа. Анафора, метафора и гипербола. По сути он есть свой собственный метаязык: мы просто ещё не до конца осознаём механизмы его метапрограммирования. Придумывать же очередной Волапюк с навязанным везде именительным падежом "многословных идентификаторов" есть вымученно-вырожденно-вынужденный способ потерять всё это богатство и выразительность. Хватит нам уже одной Явы или ихнего хтонично тевтонского ABAP-а.
Попробуйте, для начала, описать правила русского языка в БНФ, а потом эту формализацию воплотить в транслятор. Запрограммируйте "падение редуцированных гласных" и чередование гласных в БНФ, слабо? То-то же. То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше.
Functions may return any type. Note that indentation is significant — there are no BEGIN-END's or { }'s: HOW TO RETURN inverse t: Пример кода на ЛОГО, определение функции: TO HELLOВ русской версии языка Лого: ДЛЯ ПРИВЕТСТВИЯ(Болгарская болгаро- и русскоязычная версия ЛОГО 2.0 для Правец 8). Видите, что было в этих языках? Человекочитаемость! Лексемы были подобраны так, чтобы не компьютеру было удобно это парсить, а человеку писать задуманное. Допустим, развивался бы Алгол-68 с первичным синтаксисом (лиспоподобным, который там уже был) и вторичным, синонимами (примерно так же, как реализовали многоязычность). А потом к этому бы добавили синтаксических макросов в духе языка Dylan и D-expressions. И можно было бы невозбранно добавлять себе всякие синонимы, чтобы писать и читать было удобно — а не вмещаться в прокрустово ложе ограничений искусственного языка. Например, вместо проц следующий день = (дата ъ) дата: введём функцию следующий день это (дата ъ) дата, такая, что:то есть, помимо паттернов в макросах D-expressions добавлять многословные идентификаторы и синонимы, роды, падежи, склонения и спряжения для повышения человекочитаемости. Вообще, любопытно было возродить Алгол-68 на Dylan (или наоборот).
логично было бы просклонять в родительном или винительном Оно-то логично. И патриотично, и культурно, и интеллигентно. Однако ж как сделать, чтобы мой компилятор отслеживал, где правильно, а где нет? Чтобы если правила русского языка диктуют необходимость родительного падежа, то попытки иных употреблений пресекались? Ведь даже формальное соблюдения синтаксиса не достаточно: выбрать между «это жеребёнок» и «это же ребёнок» можно, только зная семантику.Чтобы компилятор понимал такие вещи, нужно делать мощнейший анализ и иметь большие ресурсы. А значит, компьютер программиста будет тормозить. Либо это будет делаться на сервере, но тогда будет тормозить из-за ограниченности канала связи. Если кто-то добьётся успехов на этом пути, то я буду рад пользоваться такой продвинутой технологией. Но сам я не филолог, не лингвист и не корифей всех наук. Поэтому буду браться только за то, что мне по силам. Отсутствие возможности корректно склонять падежи, сопрягать времена, использовать нужные синонимы, лексемы, морфемы, и, самое главное — семемы приводит к тому, что и читается сей код вымученно, искусственно, не по-русски. На данный момент у нас два варианта.
Русский язык богат и выразителен. Велик и могуч. Так не портьте его. Я очень много времени провожу, исправляя за Вами ошибки. А то Вы радеете, чтоб в языке программирования комар носа не подточил, а сами пишете тяп-ляп. Могу сказать, что если появится безупречный с Вашей точки зрения русский Алгол, то Вам придётся исправлять за собой много ошибок: там пунктуация страдает, сям Вы не любите писать с большой буквы имена собственные или начало предложения и т.д. Вы будете несовместимы с таким совершенным инструментом.То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше. Значит, надо перейти от слов к делу и написать W-грамматику для русского языка.«ДЛЯ ПРИВЕТСТВИЯ» — это укладывается в один идентификатор. А раз так, то ничего сложного, здесь никто не контролирует падежи. «ПИШИ [Привет, мир!]» — а вот это не по-русски! Правильно писать так: «Пиши: "Привет, мир!"». После «Пиши» необходимо двоеточие. Квадратные скобки в русском языке играют совсем другую роль. прокрустово ложе ограничений искусственного языка Николай Лобачевский, русский математик: «Чему одолжены своими блестящими успехами науки, слава нынешних времен, торжество ума человеческого? Без сомнения, искусственному языку своему!»Вообще, любопытно было возродить Алгол-68 на Dylan (или наоборот). Это праздное любопытство или побуждающее засучить рукава?
Любопытно, как пополняется Ваш список? О некоторых языках вообще был ни слухом, ни духом. Откуда?!
Его язык нравится честностью, если это можно так назвать. Программа на нём делает ровно то, что предписано. Мне много подсказывают. Мои читатели и соавтор по написанию статей Д. Ю. Караваев. Сами авторы языков иногда просят включить сюда. Даже родственники подсказывают :) Много берётся на Хабре. Последнее время в Дзене можно встретить что-то уникальное. Общего алгоритма нет :)
Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход. P.S. В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ, что делает софт настраиваемым. Но также существует и отдельная сборка компилятора GAZ, которая периодически обновляется. Язык написан, т. к. в своё время темой компиляторов меня заинтересовал известный доцент Свердлов Сергей Залманович, который 20 февраля 2024 года умер в 69 лет профессором.
больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано А не пытались разобраться, почему он не вызвал интерес? Ведь не у всех так. У Котлина как-то вышло пробиться в люди.Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем. Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический. В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно.известный доцент Свердлов Сергей Залманович По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал.
Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход. И другие тоже пишут "для себя": https://habr.com/ru/articles/311604/#comment_9839894Я тоже писал свой язык программирования лет 10 назад, поэтому не вижу в вашем начинании ничего плохого, но выносить его из песочницы все же следует после того, как вы поймете, что это действительно может быть полезно.
Известный доцент Свердлов Сергей Залманович. По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал. Я был его студентом. ВГПУ, выпуск 2007 года, учился в 2002-2007. У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время.Почему начал писать компилятор — работал в таком месте, где работа не бей лежачего. Но присутствовать на рабочем месте обязан. Вот и занимался всякой фигнёй. Сейчас бы точно не стал писать компилятор. Но поскольку он уже написан и работает — почему бы и не использовать в своих целях, немного дорабатывая время от времени под свои задачи. Почему не пользоваться самому — тем более компилятор работает и показал довольно неплохую стабильность, у меня уже несколько тысяч скриптов на нём уже написано, в том числе около 20 скриптов длиной более 1000 строк кода. В 2021 году пришлось выпустить 64-разрядную версию (тоже для себя), благо Сергей Залманович научил красиво писать код и переход на x64 не вызвал много сложностей. А не пытались разобраться, почему он не вызвал интерес? Думаю в том числе потому, что я не пытался его продвигать и раскручивать. Но что толку вкладываться в рекламу если такое практически невозможно монетизировать?А так может и взлетело бы как какой-нибудь аналог AutoIt. Язык писался именно для практических целей, красота языка и прочее было на 2 месте. Главное для меня не красота, а чтобы работало стабильно, с этим проблем особых нет. С простотой и обратной совместимостью новых версий языка тоже проблем нет. Последняя версия языка от 14 декабря 2023 года, на ней успешно запускаются скрипты 2009 года, например. Чем не может похвастаться компилятор — так это разве что скоростью работы. Например, пустой цикл for выполняется миллион раз на Intel Core i7. Поэтому собственно и приходится добавлять новые функции время от времени в сам компилятор, а не писать их на встроенном языке. Чтобы работало быстрее. Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем Не совсем единственным. Продвинутые пользователи ПО для магазинов тоже могут там что-то на нём настраивать. Но речь в их случае, конечно, не идёт про написание полноценных скриптов или программ.Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический. Я, например, вообще не очень-то общительный и коммуникабельный. И думаю многие из тех, кто пишет компиляторы — тоже. Договориться в этом мире о чём-то вообще довольно сложно.На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно. Проект языка GAZ не закроется — просто не будет развиваться если я на его забью. Например, выйдет какая-нибудь новая версия Windows и приехали. Ну или сайт закроется если мне надоест платить за хостинг. Но сам компилятор в любом случае у меня останется до самой моей смерти, не для того я его писал чтобы потом уничтожить. Варианты взаимодействия и сотрудничества со мной возможны вплоть до моей смерти, даже при закрытии сайта. Мне ещё только 38 лет, так что думаю, ещё поживу.
Я, например, вообще не очень-то общительный и коммуникабельный. Знаете, не один Вы. Но есть один способ сделать Вас менее замкнутым. Хотя бы на время. Надо просто собраться в одном месте всем таким любителям изобретать языки и писать компиляторы и пообщаться. Между прочим, опыт был. Могу сказать, что прямо-таки вырастают крылья! Уже было предложение о встрече. Некоторые даже готовы приехать аж из Екатеринбурга. Желательно в летнее время и в какие-то длинные выходные. Но в этом году 12 июня приходится на среду, длинных выходных не будет. Так что вопрос пока открыт. Но если у Вас есть предложения, пишите на почту.
По поводу встречи — даже не знаю, а что там делать и что обсуждать и кто вообще пойдёт. Изучать чужие невостребованные языки на встрече вряд ли кто-то будет, хотя я может и ошибаюсь. А по поводу просто встретиться в Москве — может и хорошая идея. В 2024 году я точно не смогу никуда приехать. Впрочем, если будет какая встреча в Москве в 2025 году — посмотрим.
По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал. Нашёл:
У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время. У меня такого предмета не было, методы трансляции проходил среди прочего. Но интерес вырос потом.Изучать чужие невостребованные языки на встрече вряд ли кто-то будет Можно просто поделиться радостью творчества. Мне как-то написали, что образовался некоторый отрыв между теорией, преподаваемой в вузах, и практикой разработки компиляторов:Сотрудники компиляторных фирм мало что публикуют — им некогда. Я это знаю по себе. Ставлю перед языком какие-то задачи, но как воплотить это в компиляторе — непонятно. В учебниках нет таких методов, чтобы взять и прямо сразу с его помощью всё сделать. Приходится придумывать что-то своё.Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми? Вот такие моменты хорошо было бы обсуждать, оказывать взаимную помощь. Лично я не чувствую с чьей-то стороны конкуренцию, какое-то соперничество 😊 Название в честь А у меня до сих пор нет названия у языка. Пока что можно потерпеть, ибо нет самого языка. Но когда-нибудь надо будет определиться.
Вот действительно настоящая сложность — сделать, чтобы он работал сколько-нибудь быстро, чтобы был оптимизированным, а в идеале чтобы написанный код транслировался в ассемблер/машинный язык, а не в свою же написанную виртуальную машину (лично мне такое, например, не по силам) — чтобы тот же цикл for выполнялся миллиард раз в секунду, а не миллион. Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Там везде текст на тексте? Вернее сказать не ошибка, а просчет.
в идеале чтобы написанный код транслировался в ассемблер/машинный язык Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код. Если будете транслировать в чистый Си, то могу порекомендовать TinyCC, он быстрее GCC в 9 раз. Но если делать язык исключительно для себя, то может и не стоит заморачиваться. Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет.
Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Стековая виртуальная машина. Как учил Сергей Свердлов. Как я понимаю, это самый простой вариант VM, но не самый эффективный. Но как я понимаю, замедление в любом случае будет в случае виртуальной машины. Вопрос только в том, в 10 раз или в 1000 раз. По правде, в 2012 году замедление было в 5000 раз, сейчас оптимизировал всё, что мог, стало медленнее в 1000 раз — скорее всего, дальнейшее значительное ускорение невозможно в рамках текущей VM.Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код. Можно, конечно. Но только тогда становится непонятным — зачем тогда нужен свой написанный компилятор. Если всё равно дополнительно придётся таскать с собой компилятор Си, Паскаля и т. д. — не лучше ли тогда сразу писать на Си или Паскале. К тому же у этих самых Си и Паскаля есть свои собственные лицензии, которые могут ограничивать встраивание их компиляторов в сторонние продукты.Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет. Да, возможна компиляция в EXE. И скомпилированный файл действительно будет работать и вести себя как EXE во всех смыслах (например, возможен его запуск из командной строки с параметрами, может работать отдельно без необходимости установки компилятора GAZ и т. д.) Но следует понимать, как устроен этот самый EXE. В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ. Поэтому такая "компиляция" в EXE не даст ускорения работы кода. Но работать будет действительно как EXE, что часто может пригодиться. Тот же AutoIt также позволяет, например, компилировать скрипты в EXE похожим образом.Сейчас, начиная с 2015 года создал и GAZ.dll для встраивания компилятора в свои сторонние проекты.
В конец файла записан исполняемый код программы на языке GAZ. А если попробовать байт-код?
А если попробовать байт-код? Разницы в производительности не будет. Т. к. компиляция самой программы на языке GAZ занимает около 1/10 секунды если размер кода в пределах 2000 строк (а больше писать на таком языке нет особого смысла). При запуске EXE это незаметно.Медленно работает именно сам байт-код. Если на нём писать что-то типа числодробилок, например. Тем не менее, мне для решения 99% задач хватает. Хотя, конечно, хотелось бы и побыстрее, но тут генерацию самого байт-кода надо делать более эффективной и виртуальную машину оптимизировать (а это неизбежно приведёт к багам, которые надо будет устранять и т. д.)
этих самых Си и Паскаля есть свои собственные лицензии TinyCC можно, по-моему, свободно использовать и распространять.В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ. Когда-то были такие инструменты — FoxPro и Clipper. Первый был интерпретатором, а второй выдавал EXE, а язык был фактически одним и тем же. Но в EXE от Clipper не было исходника, хотя компилятор в него включался, т. к. без него не работала бы функция EVAL.Медленно работает именно сам байт-код. Есть ещё прямой шитый код и косвенный шитый код, это из Форта. Даёт весьма неплохую скорость, хотя и уступает раза в 2 Си-шным программам. Но, думаю, динамическая типизация тоже внесла свой вклад.
Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Я сравнивал производительность различных языков в 2009 году.В общем оказалось, что 1С 7.7, ActionScript 2.0, PHP, Python и вообще языки с нестрогой типизацией оказались с довольно сильным замедлением скорости (сотни тысяч или в пределах миллиона выполнений почти пустого цикла с простыми вычислениями в секунду) в сравнении с Java/Delphi (сотни миллионов выполнений такого же цикла). Что также наводит на мысли, что Java уже на момент 2009 года — это не совсем честная виртуальная машина, а больше нативный код (JIT-компиляция). То есть даже виртуальная машина PHP (которую явно писали профессионалы и явно оптимизировали там всё, что можно) замедляет вычисление числодробилок раз в 100 — если бы всё было так просто — замедление было бы в 2-3 раза, максимум в 10 раз. Конкретно по виртуальной машине GAZ — я полагаю — причины замедления в динамической типизации, большом количестве встроенных команд, в генерации не оптимизированного кода (для тех же циклов), ну и может ещё какие ошибки в реализации виртуальной машины с точки зрения производительности, в совокупности это даёт дополнительное замедление ещё в 10 раз в сравнении с PHP.
причины замедления в динамической типизации Современные процессоры очень не любят переходы, особенно непредсказуемые. И вызовы тоже. Тесты, которые нерепрезентативны, но дают общее представление о проблеме: «C vs Haskell: сравнение скорости на простом примере». На некоторых примерах удалось получить отставание Хаскелла от Си в полторы тысячи раз.создать какой-нибудь компилятор, если учился у Сергея Свердлова или читал его книги, — сложностей особых нет А какие методы компиляции Вы использовали в своей разработке?
Современные процессоры очень не любят переходы, особенно непредсказуемые. И вызовы тоже. Да, а у меня за выполнение команд отвечает один большой CASE с вызовами нужной процедуры для каждой команды. Пробовал делать без CASE, а с помощью прямых переходов на адреса процедур — но это не ускоряет выполнение.Немного ускорило процесс то, что убрал процедуры для наиболее часто используемых команд виртуальной машины (add, sub, goto) и разместил код непосредственно в CASE. В общем, на 99% всё как Сергей Залманович учил. Но он учил писать компиляторы, но не учил, как сделать виртуальную машину быстрой. По языку — я даже знаю сейчас, как можно его ускорить раза в 2 — например, добавить команд для виртуальной машины — для выполнения цепочек последовательных команд одной командой — чтобы уменьшить вызовы CASE и непредсказуемые переходы или оптимизировать генерацию команд для выполнения на виртуальной машине — но честно говоря, не особо есть смысл этим заниматься. А так как компилятор GAZ активно используется в своих разработках — стабильность работы куда важнее, чем мифическое ускорение всего лишь в 2 раза. Очень много лишних команд генерируется ещё, например, для обработки исключений try-except-end и вообще команд генерируется чересчур много и я не занимался оптимизацией этого дела, а занимался тем, чтобы это просто работало и не глючило. Потому, думаю и довольно медленно работает. Но учитывая большое количество встроенных команд и скорости современных процессоров я бы не сказал, что эта медлительность как-то мешает в практических проектах. А какие методы компиляции Вы использовали в своей разработке? Сначала пишем модуль — парсер исходного текста, преобразование его в лексемы. Потом синтаксический анализатор и на его основе и лексический анализатор тоже. Генерируем код для виртуальной машины, потом выполняем его на написанной виртуальной машине.Мне всегда хотелось генерировать код не для своей виртуальной машины, а для процессора x86 — но судя по всему, мне не по зубам такая задача — тем более с динамической типизацией. Да и не учили нас этому.
не сказал бы, что эта медлительность как-то мешает Ну да, процессоры быстры как никогда. А на некоторых классах задач основная задержка идёт не от медленного выполнения байт-кода программы, а в силу того, что чтение или запись файлов (к примеру) делается многократно медленнее.x86 ... не по зубам такая задача При некоторой настойчивости и наличии времени эта задача решается. На сайте Андрея Хохлова есть краткое пособие по генерации кода. Но это опять же — нужно ли Вам это? Вы готовы утверждать, что Ваш язык содержит нечто, что даёт ему перспективу?парсер исходного текста ... синтаксический анализатор То есть метод рекурсивного спуска? Правильно понял?
Вы готовы утверждать, что Ваш язык содержит нечто, что даёт ему перспективу? Я думаю: если и есть какие-то перспективы, то от ускорения в 2 раза ровным счётом ничего не изменится (а ускорить в 10 раз малой кровью — скорее всего, не получится). Все равно язык и компилятор будут решать ровно тот же класс задач, что решает и сейчас: по сути, если коротко, это упрощенная и урезанная версия AutoIt (который, кстати сам тоже не блещет скоростью).Если найдётся время, то куда целесообразнее потратить его, например, на добавление новых функций (список того, что хотелось бы доработать, у меня есть. Если всё это реализовать, то хватит как раз до 2030 года), чем на ускорение VM. Почему сам использую свой компилятор, а не AutoIt (который изначально более функционален, например: мне кажется, что язык GAZ выглядит проще (по крайней мере, для меня). Многие небольшие программы выглядят на нём короче, чем на AutoIt, также используется полная компиляция перед выполнением, а не во время выполнения как у AutoIt, что повышает надёжность кода. Также что мне не понравилось в AutoIt — отсутствие массивов с нулевой длиной. Не будь этих недостатков у AutoIt — сам бы использовал именно AutoIt как скриптовый язык для сборки своих проектов и встраивания в свои программы. Но про AutoIt я узнал в 2012 году, а GAZ написал в 2009-2012. То есть метод рекурсивного спуска? Правильно понял? Честно говоря, забыл уже как это называется. Но похоже, оно.Сам транслятор исходного кода в байт-код, кстати, очень быстрый — довольно быстро обрабатываются и программы по 100 000 строк. Что показывает, что этот метод парсинга довольно эффективный. Ну а про медлительность VM и причины этого уже писал ...
метод рекурсивного спуска? сложностей особых нет
Думаю, найдутся языки, программы на которых будут быстрее не в 2, а в 20 раз. Уверен, найдутся. Например, Python или ещё какие аналоги явно будут работать быстрее. Но всё-таки мой компилятор больше аналог AutoIt, а не Python. На Python многие задачи потребуют гораздо больше кода, чем на AutoIt.И функций там будет на порядки больше. Ну если предположить (что из области фантастики, конечно), что мой язык был бы востребован хотя бы настолько, что я мог бы на нём (а не на других своих проектах) зарабатывать хотя бы тысяч 100 в месяц (рублей) ... поверьте, функционал бы постоянно расширялся и возможно, достиг бы половины возможностей того же PHP. А так, на энтузиазме вижу смысл расширять исключительно по мере своих потребностей, под свои задачи.А простота во многом субъективна. 2) Возможность использования его как простого и урезанного аналога AutoIt, у которого практически нет конкурентов в его классе по простоте кода и обширности функций. 3) Возможность использования как простого и функционального языка для обучения детей, позволяющего быстро и просто писать функциональные скрипты (в сравнении с Pascal ABC) — например, перезагрузить систему или открыть CD-ROM. Правда, не факт, т. к. динамическая типизация привьёт этим детям плохие привычки программирования ... 4) Расширяемость функционала под потребности (да, плюс похоже только для меня самого, так как кто-то другой не будет, скорее всего, готов платить за доработки компилятора с закрытым исходным кодом под него). 5) Большое количество написанных скриптов (уже несколько тысяч), которые я использую в основном для себя. А вообще — конечно, было бы проще и лучше устранить перечисленные мной и другие недостатки AutoIt (который хорош — но имеет множество вариантов выстрелить себе в ногу при написании кода по сравнению с GAZ), чем продвигать мой компилятор. В мечтах было бы выпустить версию компилятора GAZ под Android и большой набор скриптов для работы с файлами. Но 99,9% что эти мечты так и останутся мечтами навсегда ...
из области фантастики ... мой язык был бы востребован хотя бы настолько, что я мог бы на нём (а не на других своих проектах) зарабатывать хотя бы тысяч 100 в месяц (рублей) ... поверьте, Поверьте, это из области ненаучной фантастики.
А у Вас есть правила Вашего языка, записанные в БНФ? Вопрос к Ивану. Нет. И вообще я больше практик, чем теоретик. Функциональность интересовала больше, чем красота. Сразу делал всё на компе, без диаграмм и БНФ.За основу языка брал смесь урезанного Паскаля и 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), и без этого можно неплохо жить — а вот не будь поддержки массивов — было бы действительно грустно.
Поверьте, это из области ненаучной фантастики. Ну, я бы не был так категоричен. Во многом всё зависит от автора языка и его способности продвигать своё детище. Вы ничего не слышали про язык программирования 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++. Но дело в том, что он к этому и не стремился.
даже Бьёрн Страуструп, наверное, не зарабатывает столько на C++. В советское время было популярно такое наблюдение: «Наука — это удовлетворение любопытства за государственный счёт». Страуструп удовлетворил своё любопытство за счёт «AT&T Bell Labs».Пример языка Zig замечателен. Вот только такое не работает в наших палестинах. У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования.
Может и баги бы какие-нибудь обнаружились бы, хотя мне и кажется, что их практически нет, последний небольшой баг исправлял в 2021 году (сейчас только что запустил генерируемый скрипт для преобразования 1 папки с файлами в другую на языке GAZ (64-bit), размер скрипта около 700 мегабайт, 113 000 строк кода, в сжатом виде 7z около 25 Мб). Компилятор выдерживает жесточайшие нагрузки и не глючит практически. В отличие от того же cine/fei (имхо и это как мне кажется, конечно — может, дело обстоит не так) — который очень функционален по сравнению с GAZ и даже мог иметь перспективы — будь он отлажен и доведён до ума — но явно самим автором не используется и явно не имеет такой базы юнит-тестов. У меня же больше акцент на качество и стабильность и на активное использование своего компилятора самим собой, а не на количество функций. Может и по той причине, что само ядро компилятора небольшое и несложное, глючить там особо нечему. В самом деле, размер кода самого компилятора в 68 000 строк (на 2012 год) или 126 000 строк (на 2023 год) — притом, что за последние 11 лет добавлялись в основном новые функции (например, Base64Encode), а не дописывалось ядро — это совсем немного чтобы быть функциональным и глючить? У кого есть свои компиляторы и из скольки строк кода они состоят?
У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования. Пока знаю только 1 язык, который у нас взлетел — это встроенный язык 1С. На нём на самом деле много чего можно писать и довольно сложное, язык очень функциональный и полностью российский, востребованный чуть ли на 1 месте в России. Но взлетел, увы, только как побочный продукт к системе автоматизации 1С, а не сам по себе.
Можно просто поделиться радостью творчества. Мне как-то написали, что образовался некоторый отрыв между теорией, преподаваемой в вузах, и практикой разработки компиляторов Не заметил такого практически вообще. Кроме 1 момента — в ВУЗе Сергей Свердлов очень большой акцент делал на красоте кода, а мне больше нравится акцент на функциональности. Впрочем, Паскалеподобный язык, как мне кажется, и не может быть как-то особо некрасив.Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми? Как я понимаю, эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит?Вот такие моменты хорошо было бы обсуждать, оказывать взаимную помощь. Лично я не чувствую с чьей-то стороны конкуренцию, какое-то соперничество Да какая тут может быть вообще конкуренция. Если встреча авторов с языками, востребованность которых около нуля и на которых авторы не зарабатывают денег. Нет поля для соперничества, нечего друг у друга отжимать, т. к. доля рынка у каждого и так около 0.
Тема зависит не от языка, а от возможности оптимизации компилятора, т.е. вас это коснется, если будете увлекаться рекурсиями. А если по-простому, по-программистски, то это вариант оптимизации, когда вместо ассемблерной инструкции вызова подпрограммы (call) компилятор ставит инструкцию перехода (jump), т.к. текущий результат (контекст) полностью совпадает с входными параметрами на следующей итерации. Вообще, такая оптимизация возможна, когда рекурсию можно преобразовать в простой for() и компилятор догадывается об этом. Виртуальных машин это тоже касается.
Паскалеподобный язык, как мне кажется, и не может быть как-то особо некрасив. Почитатели языков с вершины рейтингов вряд ли с Вами согласятся. Да и Вы сами от него местами отказываетесь:из 1С взял = вместо := эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит? Допустим, есть язык с такими правилами:выражение ::= операторы присваивания | условный операторЗдесь наблюдается рекурсия: «выражение» содержит в себе «условный оператор», «условный оператор» содержит в себе «выражение». В Вашем языке есть что-то подобное, скорее всего. Было любопытно, как Вы перестраивали правила, чтоб избежать рекурсии.
Состоит из элементов типа и является обёрткой Operator, который в свою очередь является одним из:OperatorAssignmentOrProcedure | OperatorIf | OperatorRepeat | OperatorWhile | OperatorIf, к примеру, в секции после then как раз представляет собой TryOperator. Так что, похоже на то, рекурсия как раз есть.Вторым ключевым и рекурсивным элементом языка является OperationOR, что означает Выражение.OperationOR — OperationAND — OperationNOT — OperationCMP — OperationSumma —То есть обрабатывается соблюдение приоритета операторов. OperationElement в свою очередь состоит из OperationOR.Ну а неэффективность и медлительность — это видимо потому, что хотелось хоть какой-то язык написать, и чтобы работало и не глючило. А оптимизация компиляторов — это, похоже, это не моё...
из 1С взял = вместо := Видимо, долго работал на 1С 7.7 и проникся. По духу и синтаксису язык GAZ, конечно, Паскаль, пусть и немного "улучшенный". Чтобы короче писать:= вместо := и с динамической типизацией, чтобы не нужно было объявлять переменные. И раз уж язык разрабатывался как скриптовый, то было бы странным ещё объявлять переменные. И вообще, краткости кода хотелось по сравнению с Паскалем.Почему по духу, как я считаю, Паскаль: в первую очередь потому, что код на нём простой и понятный, ничего особо сложного и нечитабельного. Как, например, на С++ написать не получится. Синтаксис на 95% как у Паскаля. Никаких || и &&, как в PHP. Никаких долларов в названиях переменных, как на AutoIt. Всё просто и понятно.С++ считаю самым ужасным языком и ужасаюсь, как вообще можно было такое придумать, код совершенно нечитабельный. При этом пробовал писать программы на С++ и даже написал что-то там на 10 тысяч строк. Правда, преподаватель увидел и сказал, что так на С++ не пишут. Фактически код написан как на Паскале, но с использованием операторов С++, но зачёт поставил.
Так что, похоже на то, рекурсия как раз есть. Значит, вы не делали преобразований правил языка, чтобы избежать рекурсии. Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует.С++ считаю самым ужасным языком Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать. Ада, который был для меня четвёртым по счёту и который можно считать более сложным вариантом Паскаля, мне не зашёл, а вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло.
Значит, вы не делали преобразований правил языка, чтобы избежать рекурсии. Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует. Компиляция удивительно быстрая. Проблем вообще никаких нет. Пробовал генерировать и программы по 200 000 и по 500 000 строк, компилируются быстро.По поводу больше памяти. Может и больше, но, скажем, 5 мегабайт или 10 — разницы вообще никакой нет с современными объёмами оперативной памяти. Когда 1 вкладка браузера потребляет 200 мегабайт. Во времена Pentium II может и было актуально. Так что этот пункт, кажется, спорный. Вот что больше всего бесило в процессе разработки, так это утечки памяти. Например, при вызове функции Eval, что мешало ставить программы и скрипты, написанные на языке GAZ на сервера для работы 24/7. И не только при вызове функции Eval, но и, например, при выполнении кода. A[2] = длинная строкапамять не освобождалась. Потом худо-бедно это было решено.
Паскаль, пусть и немного "улучшенный". Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ)
Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон Только Питон хорошо прокинул пользователей с версиями 2 и 3. Нарушил обратную совместимость. И после выхода версии 3 — вторая версия, полагаю, не развивалась параллельно, как 3-я. Так что тоже в своём роде язык не идеальный.По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык. Вот только я не знаю, что писалось вообще на этом Обероне. Получается — Оберон самый лучший, но почти не используемый на практике, Питон — самый лучший из используемых на практике.
Допустим, есть язык с такими правилами: Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует. Разбор замедляет перегрузка смыслами операторных знаков и идентификаторов, а не рекурсия. Поэтому:Компиляция удивительно быстрая. Проблем вообще никаких нет. Это как раз не удивительно. Компонентный Паскаль, например, у меня парсился со сбором лексики около 100К строк в сек/ядро бюджетного ноута 12-го года с конструкциями вида:case symbol ofСмысла писать БНФ вместо сразу работающего и однозначного кода по сути нет. И перегрузка языка сложными правилами гораздо сильнее замедлит переваривание кода человеком, а не машиной. Вот написали Вы слишком теоретизированный БНФ, а потом по нему пишут такой же код. На деле должно быть: Выражение ::= Выражение с ключевого слова | Выражение с идентификатораИ тогда сразу очевидно — берем слово, его хеш, смотрим в табличке наличие флага ключевого слова, сверяем с ключевым словом: да — проверяем допустимость (по табличке) и переходим к элементу грамматики, нет — работаем с процедурой или переменной, при том уже известно с чем именно, в отличие от "теории", которая, например, при опечатке проглотит вызов функции для идентификатора какой-нибудь целочисленной переменной, оставив проверку "на следующий этап". вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло. Довольно не просто проникнуться слабой типизацией, синтаксисом с трудным вылавливанием точечных опечаток и перегруженностью значков разными смыслами. Глянешь на какой-нубудь оператор "++" — ни краткий (достаточно одиночного +), ни однозначный (постфиксный и префиксный с различным приоритетом) — явно сделан чтобы писать спагетти код. Правда автоматом расплести подобное не представляет такой уж трудности, код любого ЯП можно при желании читать в любом синтаксисе, который программист себе пожелает сделать, да и генерить его из любого синтаксиса не сложно.Другое дело, что да, для своего времени в сравнении с другими средствами язык занял большую рыночную нишу и даже удерживает часть до сих пор. Но многие, используя, его уже не пишут и не читая, лишь скармливая компилятору сгенерированный на нем код. Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать. А для многих он был лишь вторым или третьим, а потом ещё тоже много других и тоже было с чем сравнивать. Также надо понимать, что люди будут говорить о совершенно разных языках и средствах, называя С или ++. Сейчас ++ совсем не те, что были в 90-х, как и, например, 1С с 8-ой версии и до неё — просто небо и земля. Можно попробовать взять "Современное проектирование на С++" Александреску 2001-го года и сравнить с тем, как можно теперь. Было бы неплохо переписать Вашу утилиту транслитерации именно в духе современных ++.По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык.Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП, из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая.
Для меня Си это универсальный мультиплатформенный макроассемблер. И кстати указатели и структуры органично сложились в голове на основе помимо ассемблерного опыта, ещё и опыта PL/1, в котором базированная структура "наше всё". Для человека пришедшего в Си из Ассемблеров ++/--переменная или переменная++/-- — это элегантное изображение множества макросов, которые он писал до того, как в руках появился Си.
Разбор замедляет перегрузка смыслами операторных знаков и идентификаторов, а не рекурсия. Авторы книг по компиляции настойчиво рекомендуют заменять рекурсию на итерацию за счёт приведения рекурсии к хвостовой. От перегрузки смыслами лучше уходить. Но тут ещё может выручить разница между унарными и бинарными операторами.Смысла писать БНФ вместо сразу работающего и однозначного кода по сути нет. Можно и не писать правила в БНФ, если это считать лишней работой, которая лишь расходует время. Но если есть правила в таком виде, то это документация, помогающая1) разработчику языка, «кристаллизуя» его мысли, 2) разработчику компилятора в качестве ТЗ, 3) программисту, пользователю языка и компилятора для лучшего понимания. Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир». Довольно не просто проникнуться . . . перегруженностью значков разными смыслами. Да, Вам тоже не повезло проникнуться духом Си. 🤣 Одни видят в инкрементах/декрементах элегантность, а другие — перегруженность. Но, кстати, от постфиксных операторов я предпочитаю отказаться.для многих он был лишь вторым или третьим Знаю таких, у кого он был первым. 🤣 И ничего, необратимых последствий для мозга не возникло.многие, используя, его уже не пишут и не читая, лишь скармливая компилятору сгенерированный на нем код. И это открывает дорогу новым языкам на очень большое количество платформ. Потому что первым написанным для новой платформы компилятором бывает именно Си.Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП [Оберон], из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая. Прям мои мысли читаете. 🤣 А набранные заглавными буквами ключевые слова — вообще отдельная песня.kiv сам забирал ленту в НИЦЕВТ Си транслятора для ОС-ЕС А PL/1 Вас не устраивал? Тоже язык высокого уровня. Тем более, что Вы дальше пишите:ещё и опыта PL/1, в котором базированная структура "наше всё". это элегантное Вот именно, сравниваяа = а + 1и ++ ая понимаю, что краткость — сестра таланта. Что Ритчи был гений. Недооценённый, кстати. Если с Виртом сложился «культ личности», то о скромном гении Ритчи вспоминают куда реже. Если языки с синтаксисом Си наверху во всех рейтингах, то упоминаемость этих двух авторов языков являет нам противоположную картину.
Что бы понять восторг..., попробуйте представить Так есть более ценные предметы для понимания... Можно, например, представить, что вместо "int,int,int" можно "Ц Ц Ц", "ЦЦЦ" или "3 ц".
Вам тоже не повезло проникнуться Бывают, люди, которые считают, что им не повезло, от того что другие не "прониклись" тем же чем и они. Таким крайне опасно давать много денег.Авторы книг по компиляции настойчиво рекомендуют заменять рекурсию на итерацию за счёт приведения рекурсии к хвостовой. Авторам КНИГ можно порекомендовать написать КОМПИЛЯТОР, который это делает автоматически.Но если есть правила в таком виде, то это документация, помогающая Или мешающая. Потому что это будет лишь часть правил, вырванная из контекста. А потом к ним надо будет приложить другие, и всё это будет разбросано по разным частям и быстро начнет расходится с реализацией...Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир». Отличный пример. И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом?
А PL/1 Вас не устраивал? Тоже язык высокого уровня. Очень бы устроил, если был бы доступен на других платформах. Как-то почти всю мою жизнь одновременно приходилось работать всегда на нескольких. Устроил бы даже очень, но именно тот PL/1 который я знаю и помню, где помимо базированных структур была встроенная в язык многозадачность и асинхронный ввод/вывод. Я уже много раз писал в разных местах о том, что современные упоминания асинхронности вызывают у меня улыбку, ибо в середине 1980-х меня "фигурально били" в курилке, за то, что я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами. :)
Таким крайне опасно давать много денег. Но Вы-то денег не даёте. Поэтому эта опасность Вас не касается. 🤣И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом? Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел.Очень бы устроил, если был бы доступен на других платформах. На x86 он был, вот только лично я узнал относительно недавно, когда поезд давно ушёл. Кстати, Орлов Владимир Николаевич, говоря о своём переходе с PL/1 на Си, отмечал, что для x86 не было компилятора PL/1, поэтому при переходе с ЕС ЭВМ на x86 пришлось переходить с PL/1 на Си. На что Дмитрий Юрьевич заметил, что компилятор таки был. Но это тоже было недавно, когда поезд уже ушёл.я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами. ОС ЕС была присуща многозадачность, поэтому у компилятора PL/1 была простая задача: сгенерировать код, который формирует параметры, а затем вызывает прерывание с нужным номером. Вот и всё. А DOS не была многозадачной, поэтому сомневаюсь, чтоб всё было так просто.
Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел. А где ещё успешно применяется БНФ?
БНФ применяется в генераторах синтаксических анализаторов А те применялись в разработке каких-то успешных ЯП, или это чисто академические игрушки?
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 Кроме того существуют другие формы записи КС грамматик .
Более того, игрушками считают компиляторы, сделанные вручную. Интересно было бы провести соответствие со списком TIOBE.
TIOBE — это про языки, а Yacc — про реализацию компиляторов. Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать.Тот же Си или C++ имеют множество реализаций как с помощью инструментов типа Yacc, так и написанных вручную. Так это следствие/часть обрастания популярностью. В т.ч. как часть академической работы — разработчики генераторов, например, должны показать работоспособность своих изделий, студенты — умение ими пользоваться.В теории генератор может создать более быстрый анализатор. Но уже сейчас можно и не почувствовать разницу до нескольких сотен тысяч — миллиона строк кода на большинстве современных устройств. Задача это легко разделимая между вычислительными мощностями. Когда-то машины были медленнее и дороже в тысячи раз — разница ощутилась бы значительно раньше. Зато процесс внесения изменений в язык может стать в разы утомительнее. Не выйдут ли дороже неизбежные ошибки его проектирования, прототипирование?
Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ) Разработчик самого верхнего языка в этом перечне вряд ли так считает.
Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать. Если сейчас такого нет, это не значит что это будет всегда. Всё может поменяться. Ранее люди думали что черных лебедей не существует.
Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ) И в чём так уж хорош Питон? Что ввиду его медлительности постоянно приходится думать, как его ускорить всякими psyco, PyPy и прочими извращениями. В этом плане как раз куда лучше C++/Delphi/Java — для написания серьёзных программ. Или речь про интерпретируемые языки для написания скриптов, а не программ? Если так — тогда может и в самом деле Питон самый лучший.
Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать. Никто ж не афиширует методы реализации своих компиляторов. В основном молчат, хотя бывают исключения: Уолтер Брайт, разработчик компиляторов Zortech C++ и D, делал это вручную. А вот TinyCC сделан с помощью какого-то генератора: во-первых, об этом писали, во-вторых, это чувствуется по очень неинформативным сообщениям об ошибках.как часть академической работы — разработчики генераторов, например, должны показать работоспособность своих изделий, студенты — умение ими пользоваться. Это давно вышло за рамки вузов. Разработчики коммерческих компиляторов пользуют средства автоматизации в хвост и гриву.В теории генератор может создать более быстрый анализатор. Это одно из преимуществ табличных методов разбора, которые применяются в средствах типа Yacc. Одно дело иметь компактную табличку, а другое — размазать логику на множество функций.Но уже сейчас можно и не почувствовать разницу до нескольких сотен тысяч — миллиона строк кода на большинстве современных устройств. Насколько я знаю, Microsoft не хватает ночи, чтобы откомпилировать новые версии своих продуктов. Но у них и объёмы кода такие, что превзойдут всё, что наработано в РФ. У небольших организаций вряд ли будут проблемы.Зато процесс внесения изменений в язык может стать в разы утомительнее. Не выйдут ли дороже неизбежные ошибки его проектирования, прототипирование? Когда логика сосредоточена в одном месте, а не размазана по функциям, то вроде бы должно быть легче.Разработчик самого верхнего языка в этом перечне вряд ли так считает. И в чём так уж хорош Питон? Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв. Динамическая же типизация, интерпретация и связанная с этим медлительность — это несущественно на фоне этой революции. Александр Третьяк взял в свой язык 11l из Питона самое главное — синтаксис (дорабатывая его). И делает, если не ошибаюсь, язык со статической типизацией; компилятор, а не интерпретатор.
Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв. Да, кстати — совсем забыл — но зависимость компиляции от отступов — вот это как раз меня это выбесило ещё в первый день знакомства с Питоном. Нет — я, конечно, понимаю, нужно писать красивый и понятный код, правильно расставлять отступы и т. д. Но во время отладки, например — когда нужно временно закомментировать один код и раскомментировать другой — эта особенность Питона будет адски неудобной.Тем более не могу назвать язык "лучшим в мире", который страдает болезнью зависимости компиляции от отступов и тем более позволяет if-блоки оформлять отступами — громадное поле для багов.
игрушками считают компиляторы, сделанные вручную Я бы даже сказал «кустарным способом».зависимость компиляции от отступов — вот это как раз меня это выбесило А кого-то взбесила бы зависимость компиляции от «then» и «end». А в Питоне «end» вообще не нужен.
Си был для меня седьмым по счёту языком, а C++ — восьмым Для меня Си++ был вторым языком после Паскаля. Я был уверен, что Профессионал и Си++ это синонимы, поэтому даже написал на Си++ программу на 10 тысяч строк в 11 классе. Но при этом воспринимал Си++ как недопаскаль, фактически писал на Си как на Паскале, не используя дух Си++. А после того как Сергей Залманович раскритиковал Си++ на лекциях и вовсе перестал на нём писать.
Кстати, встретил книгу Свердлова «Конструирование компиляторов». Очень хорошие первые впечатления.
Разработчики игр, например, явно не дураки, не пишут свои языки, а используют готовые. Не знаю, правда, возможна ли в этом случае компиляция в EXE, но других минусов не вижу. Lua.dll распространяется по нормальной BSD-лицензии, а не какой-нибудь GPL, поэтому библиотеку можно встраивать в свои компиляторы, не раскрывая исходный код.
Разработчики игр, например, явно не дураки, не пишут свои языки, а используют готовые. Можно сказать, что это разные если не профессии, то специализации. Требует разных знаний и навыков. Но знаю одно исключение: один из читателей и комментаторов этого сайта раньше разрабатывал игры, а теперь учится в аспирантуре и разрабатывает свой язык. Не буду показывать пальцем. 🤣В AutoCAD применяют AutoLISP. Проторенная дорожка. Lua нашёл применение в наших импортозамещающих офисных пакетах вместо VBA. Хотя жаль, но не отечественный язык.
Если сейчас такого нет, это не значит что это будет всегда. Всё может поменяться. Именно. Поменялось. ЭВМ почти не было, ЯВУ не было и опыта программирования на них не было. Языки программирования разрабатывали на бумаге. Вы можете зачеркнуть кусок БНФ и дописать кусок в конце — БНФ не сломается.Поэтому для бумаги это отличный формат. Да, это не вся необходимая информация. Да, синтаксис и прочее получается разбросанным как попало, а вовсе не как тут писали, что, мол, "всё в одном месте". Но переписывать БНФ прям целиком прям каждый раз не нужно. Ещё догадались вырезать из бумаги/картона кусочки и складывать/прикреплять к чему-то, но это занимает большое рабочее пространство. Как ползали по полу и кого "поставили на колени" можете прочитать в мемуарах. Да, были языки, сделанные на коленках в прямом смысле этого слова. Сейчас же у всех суперЭВМ с отличными клавиатурами, мониторами, текстовые редакторы, работающие мгновенно и, наконец, 100500 работающих языков программирования. Но можно по-прежнему неосознанно имитировать физические ограничения работы с бумагой. Примерно как с неэффективной раскладкой клавиатуры, по-прежнему рассчитанной на имитацию зажатий давно несуществующих шестеренок) С таким же успехом можно симитировать разработку какой-нибудь Ады: а давайте сейчас тоже напишем БНФ, издадим учебники к несущствующему языку программирования... Подумаешь, ну, займет это несколько лет.
Это одно из преимуществ табличных методов разбора, которые применяются в средствах типа Yacc. Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. И табличку вполне cгенерируют вместо цепочки последовательных сравнений одной и той же переменной, хеш-функцию подберут, даже могут строку в оператор выбора. Так или иначе в языках есть соответствующие возможности. Потому что парсеров всяких пишется на них куча. Именно на них.Как минимум странно создавать высокоуровневый язык, который этого не умеет и при этом на выходе также не делегирует задачу умеющему это делать языку. Опять же, используя не умеющий этого делать язык.
Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. Как минимум странно создавать высокоуровневый язык, который этого не умеет Да, мы — разработчики-энтузиасты, люди вообще странные. Для примера — GAZ — очень высокоуровневый язык (куда уж ещё более высокоуровневый), но этого не умеет.
Да, мы — разработчики-энтузиасты, люди вообще странные. Для примера — GAZ — очень высокоуровневый язык (куда уж ещё более высокоуровневый), но этого не умеет. Ну, как видите, есть куда. Только у Вашего языка своя определенная специализация. Прошло много лет с момента его создания, отслеживать развитие множества других технологий, поддерживая основной продукт, не являющийся собственно самим ЯП, просто выглядит нереально. Для сравнения — в какой-нибудь С++ завозят достижения даже не одного десятка лет свежести.В Питоне, например, оператор выбора по строкам работает. И даже у некоторых из перечня энтузиастов. Но какая там может быть оптимизация при интерпретации понятия не имею. Однако, разработчикам компиляторов Питона с этим уже приходится что-то делать.
Просто компилируется в код VM, а не x86. Можно попробовать JIT-компиляцию для увеличения скорости.
Можно попробовать JIT-компиляцию для увеличения скорости. На таком языке, где каждая переменная — это динамический массив с длиной 1 динамического типа (integer|float|string), боюсь, что JIT-компиляцию в принципе не сделать.
... что JIT-компиляцию в принципе не сделать. Мне кажется, что вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Всё, что интерпретируется, может быть откомпилировано.
Мне кажется вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Все что интерпретируется может быть откомпилировано. Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Отдельная структура под исполняемый код и отдельная под переменные. И регистров у виртуальной машины пара десятков. Хорошо поговнокодил в своё время в попытках добиться стабильной работы компилятора (главным образом, реализация try-except-end потребовала много инструкций), очень много лишних инструкций. По правде говоря, стабильности работы добиться удалось.Если всё это переводить на JIT — фактически придётся всё переписывать с нуля. И займёт по времени это раз в 10 больше, чем написать с нуля ещё пару компиляторов как у меня. И точно также будет не востребовано, ровным счётом ничего не изменится. Не говоря про то, что писать это всё придётся 10 лет и уже в процессе написания это всё устареет. Как я понял, JIT — это вообще серьёзная штук а, довольно мало для каких языков она в принципе существует, только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT. Если реально хочется использовать JIT и встраиваемый язык — как я выяснил, проще использовать готовый язык Lua, добавив в него свои процедуры и функции, которых там не хватает. И я думаю, это правило можно применить ко многим языкам, которые в списке. Сам так бы и сделал, если бы вернулся в 2009 год.
Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. Шла речь об оптимизации методов разбора для создаваемых компиляторов.Просто компилируется в код VM, а не x86. А если в код JVM или MSIL?Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Как так? Вроде бы писали по заветам С.З.Свердлова.Если всё это переводить на JIT — фактически придётся всё переписывать с нуля. Если компиляция разбита на фазы, то так не должно быть, по идее.писать это всё придётся 10 лет и уже в процессе написания это всё устареет. Если Ваш язык не содержит новых идей, то он устарел до написания.только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT. Д.Ю.Караваев много лет в одиночку пишет компилятор PL/1 под x86. Не JIT, конечно, но по скорости программы почти не уступают MS C++.
Вы не знаете, из какого говнокода у меня состоит 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 серьёзные программы и игры писать всё равно не получится, это изначально скриптовый язык. А для скриптов скорости хватает за глаза.
активно применяя команды drop, swap, over и т. д. Языку Форт хватает двух стеков. Но рассуждать, не зная причин Ваших решений, конечно легко, а вот с чем боролись на практике — трудно представить.неохота больше в этом говне копаться... я бы скатился в говнокод куда сильнее и куда раньше Вы так рекламируете своё детище, прямо диву даёшься.замена стандартных BAT-файлов Windows... перед BAT имеет только один минус, что не встраиваемый. Не знаю, какие задачи Вы ставили перед собой. Но доводилось обеспечивать взаимодействие своих программ как с «*.bat», так и с «*.exe» и «*.com». В Си есть функцияspawnl, которая обеспечивает вызов файлов перечисленных выше типов. Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу. Но это решаемый вопрос. Такие же вызовы делал из Форта (слово RUN) и Клиппера (функция RUN).
Вы так рекламируете своё детище, прямо диву даёшься Сам компилятор работает стабильно и проверен лично мной на сроке использования более 10 лет, сейчас сам его активно использую, этого достаточно. Не все энтузиасты могут это сказать о своих компиляторах, некоторые проекты создавались изначально как нечто амбициозное, а потом загнулись, как я понимаю, утонув в своей сложности и глюках. Не верю я, чтобы какой-либо разработчик забросил свой компилятор, если он в целом работающий и отлаженный.Но внутренний код генерации команд для виртуальной машины такой, что заново не захочется туда лезть и что-то там править, чтобы ничего не сломать. Тем более через 12 лет после написания этого кода. И почему-то думаю, не у меня одного так, тут у многих людей в списке гораздо более сложные компиляторы написаны. Соответственно и потенциальных глюков там может быть больше. Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only. К добавлению новых команд в виртуальную машину это, конечно, не относится. Но в большинстве случаев вместо добавления новых команд в виртуальную машину пишу модули на своём же языке. Правда, приходится иногда добавлять и команды в VM, как это случилось, например, с Base64Encode в 2019 году (сначала написал на своём языке, но потом производительность не понравилась для больших строк — например, размером в 100 Кб).
Не знаю, какие задачи Вы ставили перед собой. Язык изначально создавался как командный интерпретатор для запуска программ, копирования, переименования файлов и т. д. Очень уж мне не понравился в этом плане BAT, захотелось что-то получше. Команды для работы со строками, числами, try-except и прочее, что сделало язык полноценным, было добавлено уже потом, в процессе.На 99% возможностей для скриптов хватает, благо прошло уже более 10 лет, особо ничего дорабатывать не приходится. Если надо что доработать — процедуры легко пишутся на самом языке. Очень редко что-то приходится добавлять именно в VM — как правило, в основном случае нехватки производительности. Синтаксис же языка и генерация кода вообще не меняется, да и попробуй поменяй, свои же скрипты, накопленные за годы могут перестать работать или начать глючить. Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу Как правило, через командную строку, через параметры запуска. А вывод результата — либо также, в командную строку, либо в файл, который задаётся в параметрах запуска вызываемой программы, потом выполняется RunWait. Таким образом интегрируются почти все языки между собой, даже 1С. Но способ, конечно, не лучший и не самый удобный.У меня, например, многопоточность поддерживается тоже с обменом данными через файлы. Хочется временами сделать возможность взаимодействия с DLL, возможность подключения внешних DLL, это более реально, чем заморачиваться с JIT, для этого не придётся лезть в сам язык, в генератор кода и т. д., а просто придётся добавить новые методы в VM. Но всё руки не доходят.
Не верю я, чтобы какой-либо разработчик забросил свой компилятор, если он в целом работающий и отлаженный. Да запросто. Поинтересуйтесь языком Глагол. Автор языка написал компилятор и исчез. Но им продолжают пользоваться. И даже есть сайты пользователей языка, посвящённые Глаголу.на Ассемблере программы изначально write-only. Не скажите. У опытного программиста даже ассемблерные программы хорошо читаются.
Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only. Почему write-only?
Синтаксис же языка и генерация кода вообще не меняется, да и попробуй поменяй, свои же скрипты, накопленные за годы могут перестать работать или начать глючить. Энтузиазм пропал. Напишите новый язык (с учетом вашего опыта код, возможно, будет лучше) или используйте готовый и сделайте миграцию.
Можно и читать, комментарии же есть, нормальные имена модулей, функций. В принципе, у меня примерно также. Может и не говнокод такое называется. Но тем не менее, желания туда лезть (в код подобного рода) и что-то там менять особо не возникает.
Но тем не менее, желания туда лезть (в код подобного рода) и что-то там менять особо не возникает. Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть.
Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть. Ускорить там что-то практически нереально без потенциального добавления багов. В случае проблем — да, относительно легко всё находится и исправляется, модульность есть.Исправлял небольшие проблемы, было дело в 2016, 2017 и 2020. Возможно и сейчас что-то есть, чего я не знаю, но на компиляторе для себя написано уже более 200 тысяч строк кода. Как правило, проблемы исправляются за счёт дополнительной генерации кода для виртуальной машины. Хотя, зная глюки, можно было их просто обходить, а не исправлять, но предпочитаю исправлять.
Медленно работает именно сам байт-код. ... Хотя, конечно, хотелось бы и побыстрее, но тут генерацию самого байт-кода надо делать более эффективной и виртуальную машину оптимизировать (а это неизбежно приведёт к багам, которые надо будет устранять и т. д.) но на компиляторе для себя написано уже более 200 тысяч строк кода. Вы боитесь изменений в виртуальной машине, так как это может повлиять на выполнение старого кода. А почему бы просто не написать другую версию виртуальной машины? Старый код будет работать на старой версии, новый код — на новой версии виртуальной машины. И всё работает стабильно. Старый код будет постепенно отмирать. Что в итоге вы хотите получить?
Почему не удаётся особо править VM и генератор кода — в первую очередь потому, что у меня код компилятора, можно сказать, в 2-х экземплярах. Один в качестве отдельного, автономного компилятора (а также GAZ.dll), другой встроен в программу Client Shop. И доработав что-то в одном месте, по идее эти же изменения нужно вносить и в другое место. Всё осложняется тем, что после встраивания компилятора в программу Client Shop были времена, что нарушал это правило: внеся доработки в автономную версию компилятора, не вносил в программу и наоборот. Поэтому программный код этих 2-х компиляторов разошёлся, хоть и совпадает на 95%. Да, пробовал выравнивать код с помощью WinMerge и т. д., но всё равно полностью не выравнивается и код немного отличается. Ещё выравнивание отсложнено тем, что в сборке для программы в компилятор добавлено множество характерных именно для программы функций. А в автономной сборке есть функции, которых нет в программе. Некоторые методы (по правде, их немного, всего 1%), доработанны в 1 месте, но не доработанны в другом. Отличаются количеством параметров, например. Реализация InputString отличается в автономном компиляторе и в программе, хотя функциональность одинакова.По этой причине собственно, добавление новых функций сразу в 2 места всегда пожалуйста, а любые правки кодогенератора или VM сильно осложнены. И никакие системы контроля версий не помогают удобным способом править код сразу в 2-х местах.
Собственно, никакой проблемы особо нет. Я сделал компилятор, теперь пользуюсь, кайфую :) Что-то не похоже :)Да, пробовал выравнивать код с помощью 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/
Развитие Русского Языка Программирования мне уже не интересно, так как я стал (и уже был) космополитом. Прекратить развивать русский язык программирования, чтобы не рос российский ВПК, но при этом позволить развиваться остальным языкам, чтобы росли остальные ВПК — это, конечно, тоже позиция. А может это и не позиция вовсе, а поза? Поза страуса, например.
Я так понимаю автономная версия использовалась для разработки. Текущую автономную версию — в архив, зачем бороться за этот 1%? От основной версии создаете новую ветку для разработки. Проект стабильный. Нет смысла уже в нём что-то глобально исправлять на данной стадии, оно того не стоит и не окупится. Нестандартный велосипед, на котором захочет ездить человек может 50 так и останется нестандартным велосипедом, что там ни меняй.Есть ли смысл самому использовать как инструмент и встраивать в свои продукты, иногда добавляя немного новых встроенных функций — пожалуй, отвечу "да". Выжимать прибыль и удобства из уже сделанного определённо стоит. По крайней мере на данном этапе. Но лучше стремиться использовать какие-то более стандартные решения — тот же Lua, например. Писать с нуля что-то подобное точно не стоит, лучше изучать что-то типа 1С/С++ или хотя бы Python и зарабатывать по 150 тысяч в месяц, чем бултыхаться в своём болоте с самописными компиляторами. Впрочем, если это приятно, доставляет удовольствие и приносит какие-то деньги — почему бы и нет ...
если это приятно, доставляет удовольствие и приносит какие-то деньги Кому-то это приятно и без денег :)
Кому-то это приятно и без денег :) Безусловно приятно — иначе бы не было столько проектов от энтузиастов, половина из которых, наверняка, вообще ничего от своих проектов не получили. И вообще приятно применять и использовать полученные знания — в моём случае знания, полученные от Сергея Свердлова. В моём случае хотя бы получилось применять и использовать.Но факты упрямы. Жизнь такая, что нужны деньги — платить за свет, газ, ипотеку, хочется куда-то съездить, особенно пока молодой, потом будет поздно. В какой-то момент я понял, что просто просираю время и жизнь и надо остановиться. Да, компилятор по сути написан по большей части в рабочее время, работа была не бей лежачего. Но с другой стороны и платили там соответствующим образом. Пока я там сидел и балдел за 20 тысяч в месяц и писал компилятор, мои однокурсники уже по 40-60 тысяч зарабатывали (да, это были приличные суммы, скажем, в 2010 году), накупили квартир, машин, поездили по разным странам. Сейчас же мне гораздо более приятно, что я работаю удалённо, а не сижу в офисе 9/5 (с перерывом на обед). Ну и то, что компилятор уже написан и не лежит бесполезно, а его можно использовать — хоть немного, но всё равно греет душу.
Может, кто подскажет стандартные решения: как можно выполнить задачу, описанную выше, не прибегая к использованию языков "энтузиастов" или к самописным решениям?
Вы писали, что язык и компилятор появились из-за того, что работа была не бей лежачего. А сейчас этот компилятор не является тем якорем, который держит Вас на текущей работе?
Я уже говорил, как бы сделал я. Наверняка в Делфи есть подобное. Я бы ещё подумал использовать Си в качестве скриптового языка: компилятор TinyСС настолько быстр, что пауза на компиляцию почти незаметна. Был прецедент такого использования: кто-то из «наших» израильтян использовал его вместо скриптов на PHP. Вариантов, на самом деле, немало. Но всё равно окончательный выбор только за Вами. У моего компилятора есть преимущество. Можно на нём писать скрипты и модули и почти без изменений потом встраивать в основную программу, при этом функционала для моих задач достаточно. В этом плане — как я полагаю, сходство с Python — только встраивается проще и поддерживает все операционные системы Windows и все версии Delphi. Lua слишком малофункционален и отдельно как скриптовый язык его использовать сложно. С++ слишком сложный и перегруженный. Нашёл ещё какой-то PascalScript — вроде функциональный язык для встраивания, надо разбираться. Можно бы использовать AutoIt, на который я во многом равнялся, но у него тоже есть минусы. А сейчас этот компилятор не является тем якорем, который держит Вас на текущей работе? Думаю, нет. Я уже не на той работе. И если что и держит на текущей работе — то что-то другое.
на компиляторе для себя написано уже более 200 тысяч строк кода. Ну и зачем тогда париться? Язык самому нравится, компилятор вылизан (протестирован аж на 200 000 строк кода), чего ещё надо? Зачем PascalScript? Первая заповедь инженера: если работает — не трожь.
Не для отказа от своего решения, нет. Скорее чтобы параллельно добавить в софт возможность выполнения скриптов ещё на одном языке. Возможности которого, возможно, больше, чем в моём варианте. Например, возможность менять свойства VCL в Runtime если включен RTL и т. д. А то мне кажется — возможно, я себя ограничиваю в чём-то своим компилятором. Не потому что его использую — а потому что используя только его — упускаю некоторые возможности, которые могут быть в других, стандартных решениях. Хотя в случае с Delphi (в отличие от С++) нормальных встроенных решений, как я понял, в принципе, немного.
Написать автору можно на электронную почту |
2013/05/04 01:03, DIBOX 
