Энтузиасты-разработчики компиляторов и их проекты
Перечень (в алфавитном порядке, по ссылке — подробнее)
Подробнее
Выше перечислены оригинальные языки программирования. Здесь нет перечня компиляторов к языкам, придуманным «не у нас». В качестве исключения только хотелось бы отметить интересный проект Андрея Андреева «Странник» — компилятор с общей семантической базой языков Паскаль, Модула-2 и Си. Смотри так же:
Опубликовано: 2012.09.25, последняя правка: 2024.10.30 00:22
Отзывы✅ 2013/05/04 01:03, DIBOX #0 В чём я смогу написать собственный язык программирования ?✅ 2013/05/04 13:07, Автор сайта #1 Как-то слишком общо поставлен вопрос. Что Вы имели в виду под «в чём»? Разработку языка желательно закончить формальным описанием грамматики и описанием семантики. А дальше — разработка компилятора, на этот есть счёт много литературы. На Ваш вопрос трудно ответить двумя предложениями.✅ 2013/05/09 05:57, newGentee #2 Gentee автор бросил в 2010, вчера он это подтвердил (8 мая 2013) на форуме, форум смешанный, англо-русский.Ещё у мелкомягких есть SmallBasic, сам пробовал, идея хорошая, реализация как всегда (поэтому бросил и пошёл искать другое), и похоже проект то ли бросили, то ли некому делать, всё давно повисло. Если бы они проект тянули нормально, был бы хороший язык для начинающих. По одной из ссылок нашёл HomeLisp, недавно было обновление, проект жив. Буду смотреть, что это такое. Админ, спасибо за страничку (хорошо бы её обновить и даты обязательно проставить, ссылки перепроверить, одна сдохла). ✅ 2013/05/12 22:46, Автор сайта #3 Разбил список на активные/замороженные проекты. Отметил неактуальные ссылки.Здесь перечислены языки отечественных авторов. Список компиляторов/интерпретаторов к готовым языкам можно поискать в других местах, я их уже указывал: Ресурсы, посвящённые созданию языков программирования и компиляторов. Там можно найти и Бейсик, и Паскаль, и Форт... Немало проектов, в том числе международных. ✅ 2013/12/20 16:59, Alexandre Minoshi (Almin-Soft) #4 http://alminsoft.nx0.ru/ переехал на новую площадку. Теперь его можно найти по ссылке almin-soft.ruХотя Валентину с сайта я убрал, так как автор Уткин куда-то пропал и уже долгое время не выходит на связь и не присылает никаких обновлений языка. Но последняя версия Валентины у меня все таки есть, если интересно пишите на almin-soft(собака)yandex(тчк)ru ✅ 2014/01/17 08:33, Сергей #5 В языке Delavar английские служебные слова. Наверное, стоит его переместить в иной раздел — без кириллицы.✅ 2014/03/27 21:39, Слава #6 еще забыт язык vkACL, у него русский автор и я в нем усматриваю аналогию с шитым кодом.✅ 2014/04/30 02:33, Utkin #7 еще забыт язык vkACL, у него русский автор и я в нем усматриваю аналогию с шитым кодом. Автор Виктор Кон, физик, что-там с линзами по работе с рентгеном, совместный российско-французский проект. Я переписывался с ним одно время как раз по-поводу создания языков программирования. Насколько помню язык прост и не поддерживает рекурсию (автору не требовался).✅ 2014/04/30 02:36, Utkin #8 Последнее хранилище Валентины✅ 2014/08/14 18:31, Виктор Кон #9 Хочу уточнить про язык vkACL. Он не забыт, я его делал для себя, и я постоянно им пользуюсь. У него был сайт vkacl.narod.ru, он до сих пор в строю, хотя и переехал на юкоз. Язык называется ACL (advanced command language), а приставка vk указывает на автора. В многочисленных каталогах программ стоят старые версии, а на сайте есть новые. Язык реально не компилируется, а интерпретируется программой, написанной на Java. Он очень простой по структуре, но из-за наличия огромного количества команд и их параметров все сразу усвоить сложно. На языке можно писать программы любой степени сложности, но в ограниченных областях. В основном это работа с файлами, текстом, расчеты, графики, картинки, постскрипт, можно делать анимации, презентации, работать с pdf файлами. Короче все то, что мне необходимо. Базами данных я не занимаюсь, этого нет (то есть sql, xml). На сайте все написано. Главная цель языка была в том, чтобы писать программы очень быстро и сразу их исполнять. В самой программе есть и среда разработки и набор готовых программ. Среди готовых программ есть в частности программы быстрого создания вэб сайтов из текста и создание электронных книг в формате fb2.✅ 2014/08/21 11:05, Эрих Гаузер #10 Есть ещё один язык. Создан он мной, называется он «Ellochka» («Эллочка»), его описание находится на этой странице.Язык интерпретируемый, на том же сайте есть интерпретатор и есть набор утилит на этом языке. Поскольку создавался он ещё в среде ДОС (последняя версия транслятора — 2001 год) и я так и не собрался перевести его под окна, сейчас, конечно. Его применение затруднительно и не так актуально. Однако, я сам до сих пор использую некоторые полезные утилиты на этом языке. Кроме того, на Эллочке были написаны интерпретатор и компилятор(!) известного языка "brainfuck". Их тоже можно скачать на указанном сайте. ✅ 2015/03/02 08:52, Александр #11 Привет всем! Сайт классный. Я недавно начал писать собственный интерпретатор скриптового языка, но знаний мало, а книг толковых нет, много воды. Поэтому решил начать что-то сам. Предлагаю энтузиастам-программистам С# объединиться и создать полноценный скриптовый язык, котоорый будет работать как на стороне сервера, так и на строне клиента. Чтобы не было разбиения на языки типа php, javascript, ajax, jquery и тому подобные. Чтобы был один язык, но был двузадачным (для клиента и сервера). Кому это интересно, пишите на почту: almp@i.ua или skype: avmpapus✅ 2015/04/07 08:53, misha_shar53 #12 Понравился этот сайт. Вопрос создания нового языка программирования меня сильно интересует. Но обсуждение на этом сайте носит несколько однобокий характер. Из рассмотрения выпал язык MUMPS. По-моему, незаслуженно. Он, конечно, малопопулярен, но, в отличие от многих других языков, работоспособен. На нем работают с 70-х годов до нашего времени. И здесь есть чем гордится. В 80-90-е годы Игорем Фетисовым была создана MUMPS-система NTSM. Которая использовалась на территории бывшего СССР. У меня на этой системе был разработан бух.учет который работает до сих пор. Сейчас активно разрабатывается и функционирует очень интересная система MUMPS MiniM. Разработчик — Евгений Каратаев. Есть его книги по MUMPS. Вышла книжка про MUMPS: http://www.solon-press.ru/shop.html?id=845. Со временем должна попасть в самые различные книжные магазины.✅ 2015/04/07 16:30, Автор сайта #13 обсуждение на этом сайте носит несколько однобокий характер Да тут немало языков рассматривалось. Или однобокость заключается в том, что не рассматривался MUMPS?в отличие от многих других языков, работоспособен Не могли бы привести примеры неработоспособных языков? C/C++? Java? C#? Pascal? PHP? Oberon? Ruby? D? Javascript? 1С, в конце концов?✅ 2015/07/08 16:54, ibzh #14 Я тоже в некотором роде энтузиаст программирования на русском языке. Свой компилятор я, правда, не пишу, зато русифицирую систему литературного программирования web, разработанную Д. Кнутом. Русифицированные файлы этой системы позволяют как определять русские имена переменных, так и переопределять стандартные ключевые слова языка Паскаль на русские.Посмотреть это можно здесь. ✅ 2015/09/21 23:11, Igor Tomassov #15 Jpho может использовать любой язык (language) для определения слов, констант, переменных и т.д. Обычно это кодировка UTF-8.Поэтому определения слова: : prepare ... ;или : подготовить ... ;или : bereiten ... ;Никакой разницы не имеет. ✅ 2015/09/22 13:30, Автор сайта #16 Если у вас будет поддерживаться 200 языков, то ключевые слова на одном языке могут повторять другие ключевые слова на другом языке. Т.е. возможны противоречия. Или идентификатор на одном языке может быть воспринят как ключевое слово на другом языке.✅ 2015/09/22 20:08, Igor Tomassov #17 Вопрос интересный. В Jpho, как в FORTH, используются словари. Словарь может быть определен в виде Java-файла (JphoVocabulary, слово extends) или в обычном коде Jpho (слово voc). По второму варианту используется слово import для загрузки Jpho-файла, интерпретация которого может быть осуществлена в соответствующий словарь.Например: "RU" vocДалее компиляция (интерпретация) пойдет в словарь RU, который станет текущим словарем. В Jpho в системном словаре JFO более 500 предопределенных слов, но если мы хотим переопределить слова в другом языке, то следует создать файл-словарь, в котором будут определены слова на необходимом языке. Например: : дублировать dup ;Это значит, что вместо стандартного слова dup аналогично будет работать слово "дублировать". Не вижу никакого смысла вводить название слов по-русски в код, так как это можно реализовать загрузкой словаря (и по-английски короче и традиция). ✅ 2015/09/22 20:34, Igor Tomassov #18 Еще хотел бы добавить. Jpho (как и FORTH) — стековый язык: все параметры приходят из стека и возвращаются в стек. Поэтому в Jpho нет функций, есть только слова или код, который сразу выполняется при интерпретации (в том числе условные переходы и циклы). Большинство слов перегружено, например, слово "+" работает с числами, строками, списками и т.д. Если есть необходимость, то в коде Jpho можно ещё "перегрузить" слово. Как в FORTH, Jpho поддерживает правило — минимальное количество символов для выполнения операции (слова). Поэтому вывод в выходной поток из стека просто точка «.».Обратная (польская) запись: 100 300 +На вершину стека положили число 100, потом 300 (100 ушло в позицию 1 стека, в положение 0 попало число 300), слово "+" складывает два объекта в стеке с положением 0 и 1, и возвращает сумму на вершину стека. Т.е. на вершине стека будет 400. 100 300 + .А это все сложит и выведет результат в выходной поток. Определим слово "возведение_в_квадрат" // n — n2Дублируем число в стеке, а потом перемножаем, результат в стек. ✅ 2015/09/22 20:40, Автор сайта #19 Т.е. расхождения с Фортом на грани стилистических? Ну и выполнение не на реальной машине, а на JVM.✅ 2015/09/22 21:06, Igor Tomassov #20 Еще дополнение.1. Язык Jpho предназначен не для написания приложений (хотя это возможно), а для интеграции с Java и Java EE технологиями. (понятно, что изменения Java-кода требуется перекомпиляцию проекта, в основном это в работающей системе невозможно). 2. Изменение Jpho-скрипта возможно без переустановки систем (тем более, что коды мы храним в БД). 3. Jpho может обратиться к любому Bean, менеджеру, к БД или Web-сервису. 4. Jpho, в отличии от FORTH, использует префиксы и постфиксы, например, создание переменной: 100 Моя_переменная!Получить значение из атрибута (используется префикс): @nameТ.е. получить из объекта в стеке значение геттера getName. !name - тоже установить setName.Остальное можно прочитать в документации. ✅ 2015/09/22 21:46, Igor Tomassov #21 Да, скажем идея Чака Мура с Фортом (а он создал язык для управления телескопом), которую я абсолютно не понял (зная Lisp, Fortran, Algol, PL и т.д) в конечном итоге привела к тому, что это все очень логично и лаконично. На FORTH можно было реализовать ОС для компьютера, или включить его в телефонную станцию (менее 6 кБ оперативной памяти), или программировать машинные автоматы.Сейчас запросы другие, но остаются в приоритете: 1. Интеграция с приложениями 2. Быстрая обучаемость 3. Замена кода без перекомпиляции проекта 4. Бесконечное количество отчетов в HTML/Excel/PDF 5. Работа Web-сервисов и клиентов. ✅ 2015/09/22 20:55, Автор сайта #22 Плюсы, которыми обладает Форт, появились более 40 лет назад. И до сих пор этот потенциал не раскрыт. Что побудило написать вот такое пессимистическое: Почему обречён язык Форт.✅ 2015/09/22 22:02, Igor Tomassov #23 Не ответил на вопросы:1. Расхождения с Фортом стилистические и не только (например, префиксы, постфиксы). Например, в FORTH строка должна начинаться со слова «" »: " Это строка". Слово «"» прочитает из входного потока слово «" » и поймет, что это строка. В Jpho используется префикс " и никаких пробелов не нужно 2. Да, Jpho работает на JVM. Другие реализации возможны: PHP, JavaScript (который и так используется в Web-технологии), C++. ✅ 2015/09/22 22:21, Igor Tomassov #24 Но язык никому не нужен, если он не дает конечные результаты для пользователей. Это мы с Вами можем рассуждать о красивости/некрасивости конструкций в языке программирования. Для Заказчика/Конечного пользователя есть только набор интерфейсов, функционала и отчетов. В данной конкретной ситуации, Jpho мы используем, как скрипт для Java EE технологии, со всеми его возможностями.✅ 2016/07/17 11:14, mahairod #25 Теперь есть и ещё один язык программирования на основе кириллицы — Ява, кириллизованная версия Java. Сайт с базовым описанием: http://wiki.elliptica.net/вики/Ява. Код классов взаимодействует с нативным кодом через кириллические сигнатуры методов в бинарных библиотеках (собраны с поддержкой расширенных международных идентификаторов).Для поддержки языка (кодирование и сборка) осуществлена адаптация интегрированной среды разработки Netbeans. Основной набор инструментов, доступных для Java, теперь доступен и для нового диалекта Ява. Также в рамках поддержки этого проекта осуществлено добавление кириллических аналогов ключевых слов языков C/C++/ObjC/ObjC++ в компиляторе GCC. Получившийся компилятор предполагается назвать RuCC/Ru++. В планах есть оборачивание стандартной библиотеки C кириллическими именами и примерно такой же подход для стандартной библиотеки C++. ✅ 2017/10/24 15:29, no1 #26 Euphoria — интерпретируемый язык с очень быстрым интерпретатором. Распространяется public domain с середины 90-х, до этого была платная версия, затем был форк.Cайт проекта http://www.rapideuphoria.com/news.htm http://openeuphoria.org/wiki/view/DownloadEuphoria.wc — новые версии 4.0, старые legacy, форки альтернативный форк с доработками http://phix.x10.mx/ репозиторий https://bitbucket.org/petelomax/phix/src Есть *большое* множество библиотек, привязок к библиотекам и примеров кода http://www.rapideuphoria.com/archive.htm Встречаются и необычные, например привязки в ассемблеру fasm http://www.rapideuphoria.com/fasm4eu.zip http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.TgsFlatAssembler В phix встроена инструкция #ilasm, и более продвинутый отладчик и оптимизатор Поддерживаются кириллические идентификаторы и unicode в новых версиях, операторы на английском Кроме того, старая версия была портирована для одновременной поддержки операторов и идентификаторов на русском языке: http://www.private.peterlink.ru/kinz/3.2ru/index.html http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.BilingualEuphoria25 http://www.rapideuphoria.com/lan.htm -> http://www.rapideuphoria.com/ru_eu_11.zip Автор порта И. Н. Качан http://www.private.peterlink.ru/kinz/ , есть примеры и описание языка. ✅ 2017/10/24 15:33, no1 #27 Полиглот: Смоллток на русском языке (портированный Squeak 3.9) + книга А. Голдберг "Смоллток. Язык и его реализация" https://sites.google.com/site/polyglotsqueak/Сборка содержит модули OMeta, SmaCC — компиляторы компиляторов (с примерами грамматик готовых языков в SmaCC) которые могут быть использованы для разработки своего транслятора или полуавтоматической трансляции в/из свой язык программирования. ✅ 2017/10/25 13:20, Автор сайта #28 Написанное Вами, конечно, интересно. Но на этой странице собраны те языки программирования, которые можно считать отечественными. Языки, созданные за рубежом и их русификация — это другая тема.✅ 2017/10/28 23:34, no1 #29 Тезис понятен, но иногда разделить не так-то просто.Вот Глагол — русский язык программирования, уникальный? По-моему, нет — это просто Оберон-2 с русским синтаксисом. Концептуально Глагол, Оберон-2 и какой-нибудь BlackBox Component Pascal, школьная сборка http://www.inr.ac.ru/~info21/software.htm http://inf.1september.ru/article.php?ID=200800100 — это один и тот же язык, семантически. Небольшие отличия в синтаксисе и переводе — не существенны. А например Рапира и Оберон — разные языки, ибо в Рапире кортежи есть, а в Обероне — нет. ✅ 2017/10/29 19:14, Автор сайта #30 Раз Глагол был назван его автором именно Глаголом, а не русским Обероном, значит у него было какое-то видение самобытности или уникальности собственного творения. Я с ним не спорю и не провожу экспертиз на идентичность, просто верю на слово. Но если разработка компилятора какого-то языка, появившегося за рубежом, производится какой-то отечественной компанией, то можно подправить другой список: Отечественные компании-разработчики компиляторов. Почему компаниям «можно» быть упомянутым, а отдельным людям нет? Потому что этот список может помочь кому-то найти работу, совпадающую с хобби.✅ 2017/12/15 01:46, SIMPLETON #31 К сожалению, вижу в новостях на сайте КОНЦЕПТа, что проект завершён. Хотя шикарная вещь, ей бы только библиотек побольше — и в школы/вузы.Мечтаю увидеть русский LOLCODE :) ПРИВ ✅ 2018/03/25 21:14, Денис Будяк #32 Не помешает добавить школьную сборку info21 (aka школьная сборка блэкбокс)✅ 2020/07/29 10:00, Тимофей #33 Добавьте языки: Ü, Umka. Про него есть на Хабре.✅ 2020/10/07 17:34, NuShaman #34 Алгоритм-2 уже не поддерживается (заморожен). Сайт перенесён в архив http://web-arhive.ru✅ 2021/04/23 12:58, Автор сайта #35 Пополнил список языками Cine, Ü, Картарика, Санда.✅ 2021/05/09 00:35, Владимир Соколов #36 Благодарю за упоминание Санды.✅ 2021/05/13 23:43, Денис Будяк #37 Здравствуйте! Добавьте, пожалуйста, ссылку на ЯОС. Там есть уже полностью готовый язык программирования с русскими ключевыми словами, со средой разработки (перевод языка "Активный Оберон"). Сейчас идёт перевод компилятора на русский язык и вставка русских ключевых слов в описание языка.https://gitlab.com/budden/ja-o-s ✅ 2021/05/14 13:20, Денис Будяк #38 А "Яр" уже давно заморожен. Я понял, у вас не считаются отечественными переводы, хотя если Глагол тут есть, то и язык ЯОС тоже по логике имеет право быть. Тем более, что язык ЯОС уже имеет как минимум одно существенное отличие от Активного Оберна, например, в нём есть модификатор override/перекрыта, который является обязательным в русскоязычном варианте. Также там доделан тип SET64, который в оригинале не работает.✅ 2021/05/16 14:13, Автор сайта #39 Посмотрел описание на Вашем сайте. Сайт убедил меня в том, что ЯОС — это и язык, и операционная система. Аббревиатура «ЯОС» может так и расшифровывается — Язык и Операционная Система? И где провести границу между языком и ОС?Глагол позиционировался автором как отдельный язык. А как Вы позиционируете свой язык? Если как отдельный, то тогда нужна ссылка, где бы описывался именно язык. ✅ 2021/05/18 11:35, Денис Будяк #40 Пока что это всё же русскоязычная версия Активного Оберона, отличия недостаточные, чтобы считать новым языком. Считать ли перевод ключевых слов созданием отдельного языка? С точки зрения совместимости — да, потому что другой компилятор АО этот код не скомпилирует. С точки зрения дизайна языка — вряд ли. Описание языка здесь: https://gitlab.com/budden/ja-o-s/-/blob/главная/док/яп-активный-оберон/описание-языка.md — пока оно запаздывает и в нём только англоязычные ключевые слова, но переделка слов на русскоязычные ожидается буквально на днях.ЯОС никак не расшифровывается, просто название ОС с кириллицей в явном виде. Это рабочее название, может ещё смениться. ✅ 2021/05/18 11:37, Денис Будяк #41 Граница между языком и ОС проводится, думаю, как обычно. Единственное, что тут линковщик, по сути дела, не оставляет выбор — писать под эту ОС на данный момент можно только на этом языке (если не сделать интерпретатор или иной компилятор).✅ 2021/05/18 22:58, Денис Будяк #42 По счастливому совпадению, как раз сегодня готова переделка описания языка — теперь там есть русские ключевые слова, модификаторы и встроенные типы, а в конце текста — табличка с английскими переводами.https://gitlab.com/budden/ja-o-s/-/blob/главная/док/яп-активный-оберон/описание-языка.md ✅ 2021/05/19 10:43, Автор сайта #43 В описании язык носит название «Оберон». Отличия от стандарта — в двух небольших деталях. Если б Вы назвали язык «Оберёг», немного изменили семантику, добавили туда условные лямбды и замыкания, то вопросов бы не было. Ведь эта страничка посвящена не новым компиляторам языков, а новым языкам. Изготовление компилятора — вполне себе уважаемый труд. Но страничка эта — о языках. В моей утилите русификации Си больше отступлений от стандарта. Но поскольку они никак не затрагивают семантику, а изменения синтаксиса на уровне вкусов, то у меня даже мыслей не было, что это язык. А так можно было бы назвать «Си-рус». Или «Сириус» для красоты :)Автор Глагола назвал свой язык Глаголом. Я ему поверил и включил в этот список. Вы же называете Обероном, я Вам тоже верю, и поэтому не включаю. Хотя желаю успехов в работе. ✅ 2021/05/19 21:54, Денис Будяк #44 Ответ понятен, вроде всё правильно, но с другой стороны, результат не очень устраивает. Подумаю, что с этим делать. Вносить изменения в язык нет повода и это несвоевременно, название пока придумывать неохота.✅ 2021/05/19 22:54, Автор сайта #45 Ещё не вечер :) Может быть, Вы когда-нибудь внесёте в язык что-то своё, чего Вам не хватает. Не может быть, чтобы у Вас не было идей. Тем более, что Оберон — аскетичный язык. Чересчур лаконичный. Вот тогда вернёмся к разговору :)✅ 2021/05/19 23:15, Денис Будяк #46 Угу. Только активный Оберон уже не такой лаконичный. Оберонщики объявили его ересью и мимикрией :) Идеи есть, конечно, но вряд ли в этом году что-нибудь реализую.✅ 2022/04/24 22:20, Автор сайта #47 Добавил 3 новых языка в список:Проверил ссылки, обновил информацию по остальным.✅ 2022/04/26 00:35, Неслучайный читатель #48 Знакомлюсь не с первым «самодельным» языком программирования. И знаете, что заметил? Интересная закономерность — многие разработчики находят, что подходящая ниша для их творений — это обучение (как правило, школьников) программированию. И действительно, для серьёзного программирования они не пригодны — не «обросли мясом». Серьёзные организации будут выбирать серьёзные инструменты. И куда тогда пристроить своё творение? Конечно туда, где публика невзыскательна. В школу!Но, простите, эта ниша уже занята. Для школы уже написаны учебники. При этом очередной новый язык не обладает обратной совместимостью этими книгами. В учебнике написано одно, а в новом языке — совсем другое. Учителя информатики его не знают. Гороно/районо инициативу, скорее всего пресечёт. Остаются школьные кружки, и то если эти кружки будет вести автор языка. ✅ 2022/04/26 13:33, Gudleifr #49 Для школы уже написаны учебники. К сожалению, они никуда не годятся. Тем более современные. Начинать учить системщика надо бы с написания своего языка. А готовить пользователя — наоборот с купи-продай с минимальным введением в ПО. Недавно нашел свои преподавательские заметки, сильно смеялся. Тогдашний ПТУ-шник, сегодня — гик.✅ 2022/04/27 16:13, Неслучайный читатель #50 Для языка, который хотят внедрить в школу, не важно, какого качества учебники. Существенно то, что язык с ними не совместим. Поэтому в школу язык не попадёт, при этом тоже не важно, какого качества язык. Есть стандарт. Всё, что ему не соответствует, пролетает.✅ 2022/04/27 16:26, Gudleifr #51 Существенно то, что язык с ними не совместим Хороший учебник вообще не должен быть ориентирован на язык. А язык должен быть совместим только с практическими(!) задачами, которые учащиеся могут решить.✅ 2022/04/27 16:43, Неслучайный читатель #52 Главный герой моих мыслей — не учебник, а язык. И разработчик языка, который питает надежды сделать свой язык главным героем школьного урока по информатике. Так вот надежды несбыточны. Бизнес-план хромает: переиздать учебник разработчик не может и переучить учителей не в силах.✅ 2022/04/27 16:47, Gudleifr #53 Так вот надежды несбыточны Сбыточны. Только нужно писать язык вместе(!) с учащимися под практические(!) задачи.✅ 2022/04/27 17:26, Неслучайный читатель #54 Да нет, с первоклассниками не придумывают азбуку или правила арифметики. С больными не изобретают рецептуру лекарств. Задача учителя — принести знания, но как ученики, не обладая знаниями, будут помогать учителю формулировать эти знания? Как стадо может отобрать кнут у пастуха и гнать себя в нужном направлении? Это заблуждение, что мнение дилетантов полезно в отрасли с высоким порогом вхождения. Если это не так, то пусть школьники для начала сконструируют процессор с конвейером, кэшами, виртуальной памятью и прочими шахматами и поэтессами.✅ 2022/04/27 17:32, Gudleifr #55 Да нет, с первоклассниками не придумывают азбуку или правила арифметики А тут и не нужно изобретать азбуку, нужно научить писать изложения и сочинения. Программирование не является "отраслью" — это полезный навык, вроде умения есть ножом и вилкой и мыть руки после туалета.✅ 2022/04/27 21:14, Автор сайта #56 Знаком с одним преподавателем информатики в колледже. Он заодно ведёт кружки программирования и робототехники. Уроки по информатике он ведёт по школьной программе. А вот на кружках у него свобода рук. Поэтому в ограниченных масштабах чей-то язык может попасть в школу.✅ 2022/04/27 21:48, Gudleifr #57 Уроки по информатике он ведёт по школьной программе. А вот на кружках у него свобода рук Я обходил эту проблему внедрением программированного обучения.✅ 2022/04/27 23:06, Неслучайный читатель #58 Программирование — это отрасль знаний. Печатать на клавиатуре, в том числе «if», «else», «do» — это навык, а вот писать их в нужном порядке и с нужными параметрами — это требует знаний. Навыков тут недостаточно.✅ 2022/05/11 18:18, Автор сайта #59 Обнаружил NewLang — новый язык программирования. Один из немногих, который не имеет некоторых признаков устаревшего языка. В нём нет ключевых слов. В этом сперва увиделось сходство с PL/1, однако сходства на самом деле нет. Ибо ключевые слова заменены на некие комбинации спецсимволов. Например, условный оператор:(условие) -> {действие} -> {действие иначе};Цикл:(условие) <--> {тело цикла};✅ 2022/06/29 16:21, Автор сайта #60 Добавил в в перечень язык программирования Перфолента, в котором идентификаторы записывают на русском языке. Разработчик — частное предприятие «ПРОМКОД» (Украина). Да, на Украине тоже программируют на русском.✅ 2022/08/27 21:25, Автор сайта #61 Пополнил список языком LN. Этот язык основан на Нормальных Алгоритмах Маркова (НАМ), которые, по словам автора языка LN, стали основой для продукционной парадигмы, о которой, по сути, нет качественных материалов. НАМ ранее были воплощены в языке Рефал. Язык LN — ещё одно воплощение, автором которой является пользователь Хабра с ником «Icon0clast».✅ 2022/09/23 22:16, Денис Будяк #62 Добрый день. Ещё раз запрошу включение ЯОС в данный список. Она ничем не хуже, чем Дизель-Паскаль. Да, компилятор написал не я. Но я написал движок перевода, позволюящий иметь две версии исходников — на русском и на английском, причём это касается не только ключевых слов, а и пользовательских имён. Кроме того, сделал (экспериментальный) механизм макросов, а также добавил новые типы данных.Т.е. невключение моего проекта в данный список начинает уже выглядеть несколько искусственным. Также неясно, чем ЯОС хуже Глагола. Компилятор Глагола вроде бы закрыт, поэтому Вы не можете утверждать, что он написан Издателем. А значит, нельзя отказать ЯОС во включении в список. Неясно, чем он хуже OneScript, который является клоном 1С, в точки зрения языка. В ЯОС есть отличия и нововведения. Что ещё мешает? ✅ 2022/09/24 15:09, Автор сайта #63 Ну хорошо, я поступился принципами и пошёл Вам на уступки. Но что я должен написать? «ЯОС» — это не очень понятный симбиоз языка и ОС, как я понял. Но фраза с Вашего сайта «реализация ШАЯ в ЯОС» (ШАЯ — школьный алгоритмический язык, «Кумир») говорит о том, что это не язык, а операционная система, обо язык в языке не реализуется, он реализуется в ОС. Название «ЯОС» отпадает. Что тогда я должен написать? Какое имя собственное? «Русифицированный Оберон-2»?Ещё нужно вспомнить о компиляторе Оберона «Восток», который написал Comdiv. В отличие от Вашего, у него компилятор собственной разработки. Вполне резонно Comdiv может меня спросить, почему я обошёл его проект вниманием. Есть и другие разработки компиляторов «ненаших» языков, например, Си Алексея Мандрыкина. А вообще роль и важность этого списка для меня не слишком очевидна :) ✅ 2022/09/24 16:43, Денис Будяк #64 Список важный и уникальный, на мой взгляд. Как минимум, он является предостережением каждому, кому взбредёт в голову его пополнить собой :) Язык пока не имеет названия, но можно назвать "Яр", т.к. это название в принципе было зарезервировано, и оно отражено в стандартном расширении модуля "ярм". А старый Яр тогда надо называть "старый Яр". Яр так же относится к Активному Оберону, как Глагол к обычному Оберону, т.е. это русский перевод + внесённые изменения. А ЯОС — это не только ОС, но и среда разработки приложений, поэтому Яр может исполняться и под Linux/Windows. Спасибо!✅ 2022/09/24 16:47, Денис Будяк #65 Т.е. ЯОС не претендует на включение в Ваш список, только язык программирования Яр требует. Как любой интерпретатор требует для своего исполнения какой-то среды, так и Яр требует ЯОС для своего исполнения. Но не потому, что Яр — интерпретатор (он компилятор, хотя есть и интерпретатор подмножества языка), а потому, что рантайм среда для него — это ЯОС. Наличие какой-то рантайм среды, без которой язык не работает — это тоже не повод для невключения в список, ведь у Вас же есть в списке другие интерпретаторы. Например, OneScript не будет работать без .Net, и Вы включаете в список OneScript, но не включаете .Net. Точно так же можно включить Яр, но не включать ЯОС. В общем, не могу понять, какие принципы тут нарушены, мне кажется это некое недоразумение из-за того, что у меня не один проект, а целый набор матрёшек, и взаимосвязи между матрёшками не всегда видны снаружи. Давайте я отвечу на все вопросы, чтобы у меня была чиста совесть и я не думал, что продавил какие-то Ваши принципы.✅ 2022/09/27 22:57, Автор сайта #66 Поддавшись на уговоры, дополняю принципы формирования перечня отечественных языков программирования. Теперь он может так же включать в себя отечественные оригинальные расширения языков зарубежного происхождения. Поэтому пополнил список языками Яр и PL/1.✅ 2022/09/28 19:20, Денис Будяк #67 Отлично, даже не знаю, за кого больше радоваться — за свой проект или за PL/1. Спасибо!✅ 2022/12/03 20:41, Автор сайта #68 Добавил в свой список два языка программирования: ALLang и Тривиль. На втором хотелось бы остановиться подробнее. Ведь его автор — Алексей Недоря, известный всей стране по проекту «Кронос» в средине 1980-х. Для меня — это «тяжеловес» из мира языков и компиляторов, «глыба и матёрый человечище». Сравнительно недавно обнаружил его сайт и прочёл анонс: Алексей в сотрудничестве с Huawei разрабатывает новый язык программирования. Сайт долго не обновлялся, потом Huawei и вовсе втихую ушла из России. Это давало повод думать, что проект накрылся. Но тут новость! Язык всё-таки создаётся. И даже не язык, а целая экосистема из семейства языков разного назначения с кроссплатформенностью. Ну а язык Тривиль — это отправная точка. Обнаружил некоторое созвучие в идеях, а именно в идентификаторах, которые, по мнению Алексея, могут был на кириллице, содержать в себе пробелы, и даже могут вообще содержать произвольный текст, если заключены в кавычки. Это соответствует тому, что было в русификаторе Си уже несколько лет назад, однако у меня сейчас есть некоторое продвижение вперёд, о котором скоро будет рассказано. Есть моменты, которые не понравились. Но у каждого своя правда, свой собственный опыт.✅ 2022/12/06 23:00, Неслучайный читатель #69 Обнаружил некоторое созвучие в идеях, а именно в идентификаторах, которые, по мнению Алексея, могут был на кириллице, содержать в себе пробелы, и даже могут вообще содержать произвольный текст, если заключены в кавычки. Это соответствует тому, что было в русификаторе Си Нашёл («Тривиль — вопросы и уточнения») у Недори это «созвучие»:4) Идентификатор Паниковать!Я бы даже назвал это не созвучием, а прямым заимствованием (если не сказать больше). Лично я не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. Только на этом сайте. Вот фрагменты Вашего кода («Вычисление определителя матрицы. Программа на русском Си»): _31 №;Тут и кириллица, и пробелы, и «№» в идентификаторах. Так что Ваши идеи уже находят место в других языках. ✅ 2022/12/07 10:45, Автор сайта #70 На языки программирования копирайт не распространяется.✅ 2022/12/07 11:57, Бурановский дедушка #71 А то бы авторы Фортрана и Алгола до сих пор собирали дань :)✅ 2022/12/12 16:53, void #72 Неслучайный читательЛично я не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. Только на этом сайте. А я знаю. Например, язык "1" или Адина, автор — Клочков Роман (monk). Документация и описание языка и примеров: https://docs.racket-lang.org/russian-lang/index.html. Анонс на Linux.org.ru: https://www.linux.org.ru/forum/development/15794630/page20#comments. Там есть примеры кода. Недавняя новость: https://www.linux.org.ru/news/development/16988270. Там тоже есть примеры кода."Синтаксис от Хаскеля, семантика от Ракета" — диалект Лиспа с русским синтаксисом. Можно добавить в список. Реализован как DSL на Racket. На Racket вообще удобно разрабатывать собственные диалекты языков. Вот например, создают диалект с поддержкой IDE и отладчика: https://shmat-razum.blogspot.com/2011/11/racket.html, а вот краткий обзор https://shmat-razum.blogspot.com/2011/09/dsl.html В Лиспах, кстати, могут быть в идентификаторах пробелы и Unicode символы. Только нужно оборачивать литералы соответствующими символами, конец/начало идентификатора. В Unicode, кстати, могут быть символы пробел и разные виды скобок. То есть, можно было бы просто реализовать несколько видов пробелов — стандартный, разрывный и неразрывный с другим кодом. Кстати, вот ещё недавняя находка на Racket, книга Beautiful Racket: https://beautifulracket.com, написана на средстве документирования/поддержки грамотного программирования Pollen: https://docs.racket-lang.org/pollen/ «Зачем Racket? Зачем Лисп? Зачем языково-ориентированное программирование?»: https://habr.com/ru/post/445822/ Это ещё в тему "Устарел ли текст как форма представления программы", проект языка CURL; https://en.wikipedia.org/wiki/Curl_(programming_language), предлагал единый язык для разработки "программируемой документации" (в отличие от набора диалектов вроде различных версий HTML, CSS, JS в типичном браузере). Это по сути диалект Лиспа (ближе к Dylan, Thomas, goo и идее "функциональных объектов", то есть объекты и их интерфейсы в духе метаобъектного протокола как first-class objects на уровне языка. Если CURL сейчас представляет собой инфраструктуру и IDE, плагины и фреймворки (например, MVC), написанные на таком языке для реализации Rich Application как гипертекстового программируемого документа — но реализованные как набор диалектов с единым синтаксисом, у которого текст документа — это полноценный литерал типа текст, типа объект; есть и другие типы объектов представленные выражениями форм в фигурных скобках. То в Pollen реализована по сути та же самая идея, только как диалект Лиспа, встроенного в Racket: документация, то есть, текстовый литерал может быть в разметке Markdown или любой другой, для которой написан парсер; публикация в выходной формат — также настраиваема (изначально есть поддержка HTML и PDF, но можно добавить и свои собственные). При этом реализуется всё та же идея — "программируемой документации". Книга — это программа, с некоторыми объектами динамически вычисляемыми. Как я понял, к этой же идее — компонентная сборка программ, документов, приложеньиц обновляемых Rich Application Dashboard, "Автопрограммирование — программирование без программистов": https://chuzhakin.com/программирование-без-программистов/ идёт и А. Е. Недоря в языках Вир, Вир-2, Тривиль. ✅ 2022/12/12 22:12, Автор сайта #73 Язык добавил в свой список.не знаю языков программирования, в которых в идентификаторах бы была и кириллица, и пробелы, и символ номера. А я знаю. Процитирую описание языка с сайта:2.4 Идентификаторы Вы давно клоните в сторону всякого рода гипертекстов, литературного программирования. Но это, как и «программирование без программистов», не интересует. Цель заявлена, отклонения от курса не будет. При этом мы оба можем оказаться правы, ведь абсолютно универсальных языков не бывает, каждому может найтись своя ниша. ✅ 2022/12/13 22:49, void #74 Более того, можно вводить идентификатор между вертикальным чертами, тогда допустимы вообще любые символы кроме вертикальной черты. Примеры идентификаторов: В контексте "Natural Language Programming" — интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем. Например, падежей, склонений, спряжений, наречий, причастий и т.п. различных суффиксов при одинаковом корне. Например, есть японский язык программирования Nadesico с поддержкой падежей (в остальном он примерно похож на бейсик). Но там иероглифы, и форма записи вообще слоговая. Для благозвучия "программирования на русском" было бы разумно не только поддерживать пробелы в идентификаторах, но и задавать флексии, например те же падежи: родительный — некий класс имярек, творительный — порождающий интерфейс, один из нескольких, скорее генератор с yield чем просто какой-то из конструкторов винительный — resonsibility (основная функция, ответственность, которую класс реализует самостоятельно) предложный — concern или collaboration (прочие обязанности, делегируемые другим классам). Тогда сразу по форме имени мы узнали бы как он будет использоваться, и чего от него стоит ожидать. Ну и для прочих наречий и причастий можно был бы найти применение. И для всяких древностей типа звательный падеж, двойственное число, ариост плюсквамперфект и т.д. ✅ 2022/12/14 00:48, Автор сайта #75 можно вводить идентификатор между вертикальным чертами Это весьма непродуманный вариант. Это не просто вертикальные черты, это обозначение операции «или». Если изъять из этот символ из перечня операций, то что взамен? Ничего лучшего для «или» не придумаешь. В русификаторе C/C++ более десятка лет используются обратные апострофы. Между ними могут быть любые символы:`это идентификатор из любых символов !@#$%^&*()_+`Вариант с обратными апострофами хорош тем, что этот символ на клавиатуре есть, а вот традиции использовать его в языках программированя — нет. Поэтому он свободен для применения в новинках. вообще в Лиспах принято несколько слов писать через минус, а не пробел. И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше. Но и он проигрывает самому обычному пробелу, который придаёт естественность многословным идентификаторам. Не правда лине печётсяэто лучше, чем не-печётся? интересно, когда же в языках программирования появится полноценная поддержка разного рода морфем. Совсем не интересно. Думаю, она появится тогда, когда программированием займутся нейронные сети. И как бы мы ни упирались, нас отправят на заслуженный отдых. Именно поэтому неинтересно.задавать флексии, например те же падежи Считаю пустой тратой времени. Попробуйте, для начала, описать правила русского языка в БНФ, а потом эту формализацию воплотить в транслятор. Даже воплощать не надо — достаточно заняться первым, а до второго дойдёте с кончиной либо падишаха, либо осла.Но Вы можете опровергнуть. Просто реализуйте всё то, что предлагаете. Останется тогда признать Вашу правоту. ✅ 2022/12/14 16:10, MihalNik #76 Это не просто вертикальные черты, это обозначение операции «или». Если изъять из этот символ из перечня операций, то что взамен? Ничего лучшего для «или» не придумаешь. А зачем придумывать что-то для "или"? Знака нет на русской раскладке, т.е. набирать неудобно. Хотя раскладку можно настроить, но тогда уже странно объяснять какой-либо выбор наличием или отсутствием чего-то на ней — получается, что взбрело в голову, то и хорошо. Хорошо, что что-то туда взбрело)задавать флексии, например те же падежи Считаю пустой тратой времени. однако:Не правда ли для начала, описать правила русского языка в БНФ Зачем, если можно просто спросить падеж с исходной формой в словаре?Думаю, она появится тогда, когда программированием займутся нейронные сети. И как бы мы ни упирались, нас отправят на заслуженный отдых. Именно поэтому неинтересно. Нейросеть умеет делать то, чему она обучена на готовых решениях и делать нечетко, а это не всегда то, что нужно, обычно как раз всякие неинтересные задачи.✅ 2022/12/14 18:31, Автор сайта #77 Не правда ли, "ширина окна" лучше чем "окно.ширина" или "окно->ширина", а "10 чисел" лучше чем "число[10]"? Достичь более-менее терпимой естественности в рамках одного идентификатора нетрудно. Если же в погоне за совершенством начать приводить целые языковые конструкции к правилам русского языка, то запросто утонешь в сложности. Лучше усилия направлять в другом направлении, где отдачи от вложенных усилий будет больше.Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее. Зачем, если можно просто спросить падеж с исходной формой в словаре? А если в словаре нет специфичных терминов? Как видоизменять «IP-адрес» (которого нет в словарях!) по числам и падежам? Ведь есть просто безграмотные люди (меня сегодня повеселили словами «борщь» и «пильмени»), тогда вместе с программированием будет происходить и «отладка» русского текста?Конечно, могу ошибаться. Просто продемонстрируйте работающее решение со словарями. И я перейду на светлую сторону :) Наше обсуждение отклонилось от темы статьи. Но куда перенести комментарии? ✅ 2022/12/14 19:45, MihalNik #78 Так что к символам вроде «. -> [ ]» надо относиться как к элементам искусственного языка. Который лаконичнее естественного и часто воспринимается быстрее. Ну также как к подчеркам/дефисам в идентификаторах. Ведь "пр-к" короче чем "прямоугольник". То есть и в естественных языках и в ЯП дефис также может быть очень полезен.Достичь более-менее терпимой естественности в рамках одного идентификатора нетрудно. Нетрудно, но для большинства точно также будет бессмысленно. На самом деле незначащий мусорный клей мешает даже меньше чем значащий. Только поэтому среди распространенных ЯП пробелов в них нет. Более того, достичь вполне терпим_ естественност_ нетрудно_ и в рамк_ цел_ выражен_ обычн_ ЯП. Для эт_ достаточн_ вместо изменяем_ част_ слов_ писать какой-нибудь "_".✅ 2022/12/14 20:22, MihalNik #79 И это тоже неумно. Минус — он для вычитания и смены знака. Тот же символ нижнего подчёркивания — и то лучше. Дефис-то набирается одним пальцем, а подчерк — двумя, потому что в верхнем регистре. Этим он хуже.✅ 2022/12/17 11:49, Автор сайта #80 Неслучайный читательПрочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку.
✅ 2022/12/17 12:29, Gudleifr #81 А как же каноническое FORTRAN-овскоеВ программе на Фортране, вместо "DO 3 I = 1,3" было набрано "DO 3 I = 1.3", что было воспринято компилятором как присвоение значения 1.3 переменной DO3I Все ещё хотите пробелы?✅ 2022/12/17 14:08, Автор сайта #82 Во-первых, «DO 3 I» и «DO3I» и — это разные идентификаторы. Они отличаются как визуально (разрывы между символами отчётливо видны, для того и пишут текст программы моноширинными шрифтами), так и на уровне двоичного представления: в первом идентификаторе в третьей и пятой позиции — символ с кодом 32, то есть пробел.Во-вторых, очень странно, что в Фортране допускаются идентификаторы в пробелах. Вот читаю документацию по языку: Для обозначения переменной служит идентификатор — последовательность, состоящая не более чем из шести цифр и букв алфавита, причем первым символом должна быть буква. Пробелы в записи идентификаторов не допускаются. Что-то мне кажется, что тут ошибка зарыта в другом месте. Пробелы не виноваты. Возможно, компилятор должен был сообщить об ошибке. Но могу ошибаться, ибо Фортран совсем не знаю.Ну и в-третьих, ключевые слова, идущие впереди идентификатора, не должны входить в этот идентификатор. Например, if i > 0 ✅ 2022/12/19 22:16, Неслучайный читатель #83 забирайте свои слова назад Забираю :) Ну надо же, в таких древних языках такое уже было. Ходим по кругу, можно сказать. А ведь такая узкая прослойка программистов была! Однажды мне одна дама задала вопрос, отчего я с компьютерами «на ты». Ответил, что получил образование в этой области. Удивилась: «Неужели этому учат?». А ведь учат уже более полувека. Дольше, чем ей было лет тогда.✅ 2023/01/19 16:17, void #84 Прочитал у Алексея Недори, что он идею пробелов в идентификаторов взял из языка ЯРМО. Нашёл описание языка, там даже возможен перенос частей идентификатора на другую строку. Спасибо за наглядный пример кода. Вот по этому тексту вопрос: "многословные идентификаторы", или "идентификаторы с пробелами" все в именительном падеже.ПОИСК В ТИ(ДАННОЕ ИМЯ)логично было бы просклонять в родительном или винительном: ПОИСК В ТАБЛИЦЕ ИДЕНТИФИКАТОРОВ (ДАННОГО ИМЕНИ)Можно также придумать 1. В языке 1С, например. Ява-подобные идентификаторы типа СтаршийПомощникМладшегоДворника МенеджерОбъектовДекораторАбстрактнойФабрикиМостаСинглтонаКомпозитораВивисектора и прочие "немецкоязычные" идентификаторы на четыре строки одним словопредложениемсинтетическогословотворчествамокроходовсоснегоступами. ///RTFM: Марк Твен, "Почему немецкий не мой любимый язык". Читается это всё нелепо, не по-русски: никакой лепоты. Например, потому что искусствено навязывается именительный падеж строго везде, даже там где невместно сие. 2. В языке RInform, русский Inform6. Здесь просто отбрасываются окончания. Ну и задаются все словоформы в разных падежах как синонимы. 3. Любопытно, как это было реализовано в русском Алгол-68, есть ли тут какая-то информация. В общем, насколько я понимаю — никто специально не следит за корректностью спряжений, склонений, падежей, времён и прочих словоформ, все либо ограничиваются именительным падежом либо таблицей синонимов. А между тем, можно сделать эту информацию значащей.
Также анафоры типа "оно её", "того на этого","это самое","вот эта фиговина" — тоже можно выводить в раскрытие означаемого полуавтоматически (типа макроса "анафорического if" в лиспе, подставляющего нужное вместо it). Попытаюсь продолжить пример Алгол-68 из Википедии в гипотетический "русский Алгол": # Next day date - english variantНе правда ли, с синонимами, падежами, склонениями стало легче читаться? Отсутствие возможности корректно склонять падежи, сопрягать времена, использовать нужные синонимы, лексемы, морфемы, и, самое главное — семемы приводит к тому, что и читается сей код вымученно, искусственно, не по-русски. Русский язык богат и выразителен. Велик и могуч. Там есть полисемия, синкопа. Анафора, метафора и гипербола. По сути он есть свой собственный метаязык: мы просто ещё не до конца осознаём механизмы его метапрограммирования. Придумывать же очередной Волапюк с навязанным везде именительным падежом "многословных идентификаторов" есть вымученно-вырожденно-вынужденный способ потерять всё это богатство и выразительность. Хватит нам уже одной Явы или ихнего хтонично тевтонского ABAP-а. ✅ 2023/01/19 16:32, void #85 Попробуйте, для начала, описать правила русского языка в БНФ, а потом эту формализацию воплотить в транслятор. Запрограммируйте "падение редуцированных гласных" и чередование гласных в БНФ, слабо? То-то же. То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше.✅ 2023/01/19 17:00, void #86 Пример кода на ABC, определение функции: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 (или наоборот). ✅ 2023/01/21 17:38, Автор сайта #87 логично было бы просклонять в родительном или винительном Оно-то логично. И патриотично, и культурно, и интеллигентно. Однако ж как сделать, чтобы мой компилятор отслеживал, где правильно, а где нет? Чтобы если правила русского языка диктуют необходимость родительного падежа, то попытки иных употреблений пресекались? Ведь даже формальное соблюдения синтаксиса не достаточно: выбрать между «это жеребёнок» и «это же ребёнок» можно, только зная семантику.Чтобы компилятор понимал такие вещи, нужно делать мощнейший анализ и иметь большие ресурсы. А значит, компьютер программиста будет тормозить. Либо это будет делаться на сервере, но тогда будет тормозить из-за ограниченности канала связи. Если кто-то добьётся успехов на этом пути, то я буду рад пользоваться такой продвинутой технологией. Но сам я не филолог, не лингвист и не корифей всех наук. Поэтому буду браться только за то, что мне по силам. Отсутствие возможности корректно склонять падежи, сопрягать времена, использовать нужные синонимы, лексемы, морфемы, и, самое главное — семемы приводит к тому, что и читается сей код вымученно, искусственно, не по-русски. На данный момент у нас два варианта.
Русский язык богат и выразителен. Велик и могуч. Так не портьте его. Я очень много времени провожу, исправляя за Вами ошибки. А то Вы радеете, чтоб в языке программирования комар носа не подточил, а сами пишете тяп-ляп. Могу сказать, что если появится безупречный с Вашей точки зрения русский Алгол, то Вам придётся исправлять за собой много ошибок: там пунктуация страдает, сям Вы не любите писать с большой буквы имена собственные или начало предложения и т.д. Вы будете несовместимы с таким совершенным инструментом.То ли дело W-грамматики: они же Тьюринг полны и там возможно это и даже больше. Значит, надо перейти от слов к делу и написать W-грамматику для русского языка.«ДЛЯ ПРИВЕТСТВИЯ» — это укладывается в один идентификатор. А раз так, то ничего сложного, здесь никто не контролирует падежи. «ПИШИ [Привет, мир!]» — а вот это не по-русски! Правильно писать так: «Пиши: "Привет, мир!"». После «Пиши» необходимо двоеточие. Квадратные скобки в русском языке играют совсем другую роль. прокрустово ложе ограничений искусственного языка Николай Лобачевский, русский математик: «Чему одолжены своими блестящими успехами науки, слава нынешних времен, торжество ума человеческого? Без сомнения, искусственному языку своему!»Вообще, любопытно было возродить Алгол-68 на Dylan (или наоборот). Это праздное любопытство или побуждающее засучить рукава?✅ 2023/01/30 23:16, Автор сайта #88 Добавил в список язык программирования с многообещающим названием Rave , что в переводе с английского означает «бред». Авторами языка (согласно Гитхабу) являются 4 человека.✅ 2023/03/15 00:30, Автор сайта #89 Добавил язык COLAMO разработки Научно-исследовательского центра супер-ЭВМ и нейрокомпьютеров, г. Таганрог.✅ 2023/06/06 00:31, Автор сайта #90 Пополнил список уже не новыми языками Cj и ПОП.✅ 2023/07/26 00:06, Автор сайта #91 Пополнил список новым языком Argentum и довольно старым GAZ.✅ 2023/10/18 13:52, Автор сайта #92 Дополнил список языком Клаус, который назван в честь Никлауса Вирта. Правда, название языка не уникально, в энциклопедии эзотерических языков программирования esolangs.org можно найти точно так же названный язык. Предположу, что "Клаус" отличается от "Никлаус" тем же, чем "Коля" от "Николай".✅ 2023/10/19 22:30, Деньги на WWWетер #93 Когда же назовут какой-нибудь язык в честьЛюбопытно, как пополняется Ваш список? О некоторых языках вообще был ни слухом, ни духом. Откуда?! ✅ 2023/10/19 23:49, Автор сайта #94 Да, Ритчи достоин этого. Хотя мой грядущий язык до сих пор названия не имеет, но называть его в честь Ритчи не буду. В конце концов, он сын американского народа, вот пусть американцы и думают над этим.Его язык нравится честностью, если это можно так назвать. Программа на нём делает ровно то, что предписано. Мне много подсказывают. Мои читатели и соавтор по написанию статей Д. Ю. Караваев. Сами авторы языков иногда просят включить сюда. Даже родственники подсказывают :) Много берётся на Хабре. Последнее время в Дзене можно встретить что-то уникальное. Общего алгоритма нет :) ✅ 2023/11/04 20:57, Автор сайта #95 Добавил язык программирования Sound. Интересно, зачем такое название дано языку? Чтобы найти его на пятисотой странице поисковой выдачи?✅ 2024/02/26 22:08, Ivan #96 Я — разработчик языка программирования GAZ Иван Горчаков. Компилятор продолжает развиваться, добавились новые команды — например, работа с Microsoft Excel через OLE, работа с BMP-файлами. Множество скриптов написано на языке GAZ, которыми постоянно пользуюсь. Виртуальная машина языка GAZ в 2024 году работает быстрее, чем версия от 2011/2012 года.Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход. P.S. В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ, что делает софт настраиваемым. Но также существует и отдельная сборка компилятора GAZ, которая периодически обновляется. Язык написан, т. к. в своё время темой компиляторов меня заинтересовал известный доцент Свердлов Сергей Залманович, который 20 февраля 2024 года умер в 69 лет профессором. ✅ 2024/02/27 22:07, Автор сайта #97 больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано А не пытались разобраться, почему он не вызвал интерес? Ведь не у всех так. У Котлина как-то вышло пробиться в люди.Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем. Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический. В моём проекте — системе автоматизации магазинов Client Shop — активно используется встроенный язык программирования GAZ На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно.известный доцент Свердлов Сергей Залманович По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал.✅ 2024/02/28 22:02, Бурановский дедушка #98 Иван Горчаков, а Ваш язык назван не в честь Горьковского автозавода? :)✅ 2024/03/01 00:45, Деньги на WWWетер #99 Иван Горчаков:Сам активно пользуюсь компилятором, иногда добавляю небольшие новые функции. Но больше не выкладываю новые версии компилятора в Интернет, так как это не востребовано и не приносит доход. И другие тоже пишут "для себя": https://habr.com/ru/articles/311604/#comment_9839894Я тоже писал свой язык программирования лет 10 назад, поэтому не вижу в вашем начинании ничего плохого, но выносить его из песочницы все же следует после того, как вы поймете, что это действительно может быть полезно. ✅ 2024/03/02 16:34, Ivan #100 Известный доцент Свердлов Сергей Залманович. По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал. Я был его студентом. ВГПУ, выпуск 2007 года, учился в 2002-2007. У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время.Почему начал писать компилятор — работал в таком месте, где работа не бей лежачего. Но присутствовать на рабочем месте обязан. Вот и занимался всякой фигнёй. Сейчас бы точно не стал писать компилятор. Но поскольку он уже написан и работает — почему бы и не использовать в своих целях, немного дорабатывая время от времени под свои задачи. Почему не пользоваться самому — тем более компилятор работает и показал довольно неплохую стабильность, у меня уже несколько тысяч скриптов на нём уже написано, в том числе около 20 скриптов длиной более 1000 строк кода. В 2021 году пришлось выпустить 64-разрядную версию (тоже для себя), благо Сергей Залманович научил красиво писать код и переход на x64 не вызвал много сложностей. А не пытались разобраться, почему он не вызвал интерес? Думаю в том числе потому, что я не пытался его продвигать и раскручивать. Но что толку вкладываться в рекламу если такое практически невозможно монетизировать?А так может и взлетело бы как какой-нибудь аналог AutoIt. Язык писался именно для практических целей, красота языка и прочее было на 2 месте. Главное для меня не красота, а чтобы работало стабильно, с этим проблем особых нет. С простотой и обратной совместимостью новых версий языка тоже проблем нет. Последняя версия языка от 14 декабря 2023 года, на ней успешно запускаются скрипты 2009 года, например. Чем не может похвастаться компилятор — так это разве что скоростью работы. Например, пустой цикл for выполняется миллион раз на Intel Core i7. Поэтому собственно и приходится добавлять новые функции время от времени в сам компилятор, а не писать их на встроенном языке. Чтобы работало быстрее. Ваш случай является самым распространённым вариантом: разработчик собственного языка является его единственным пользователем Не совсем единственным. Продвинутые пользователи ПО для магазинов тоже могут там что-то на нём настраивать. Но речь в их случае, конечно, не идёт про написание полноценных скриптов или программ.Естественно, возникает вопрос: а почему бы не объединиться 10 разработчикам, чтобы было 10 пользователей у одного языка? Но вопрос этот конечно же риторический. Я, например, вообще не очень-то общительный и коммуникабельный. И думаю многие из тех, кто пишет компиляторы — тоже. Договориться в этом мире о чём-то вообще довольно сложно.На языке ПРОФТ тоже писалось ПО, которое было бухгалтерским, оно где-то применялось. Но программировал на этом языке только сам автор. Проект теперь закрыт. Вот и Ваш язык зависит от одного человека, то есть от Вас. Расхочется Вам — и проект закроется. Жаль, конечно. Проект языка GAZ не закроется — просто не будет развиваться если я на его забью. Например, выйдет какая-нибудь новая версия Windows и приехали. Ну или сайт закроется если мне надоест платить за хостинг. Но сам компилятор в любом случае у меня останется до самой моей смерти, не для того я его писал чтобы потом уничтожить. Варианты взаимодействия и сотрудничества со мной возможны вплоть до моей смерти, даже при закрытии сайта. Мне ещё только 38 лет, так что думаю, ещё поживу.✅ 2024/03/02 17:24, Автор сайта #101 Только сейчас до меня дошло, что Сергей Залманович Свердлов — это тот самый Сергей Свердлов из Вологды, который написал знаменитую статью «Арифметика синтаксиса», с которым у меня была заочная полемика. Тесен мир.Я, например, вообще не очень-то общительный и коммуникабельный. Знаете, не один Вы. Но есть один способ сделать Вас менее замкнутым. Хотя бы на время. Надо просто собраться в одном месте всем таким любителям изобретать языки и писать компиляторы и пообщаться. Между прочим, опыт был. Могу сказать, что прямо-таки вырастают крылья! Уже было предложение о встрече. Некоторые даже готовы приехать аж из Екатеринбурга. Желательно в летнее время и в какие-то длинные выходные. Но в этом году 12 июня приходится на среду, длинных выходных не будет. Так что вопрос пока открыт. Но если у Вас есть предложения, пишите на почту.✅ 2024/03/02 19:10, Ivan #102 Да, жаль, что Сергей Залманович умер. Крутой был человек, рад что был его студентом. Последний раз с ним переписывался 13 сентября 2018 г., на день программиста. Он ответил: "Мне, конечно, приятно, что Вы заинтересовались в своё время тематикой компиляторов и даже не оставляете этот интерес" — буквально так.По поводу встречи — даже не знаю, а что там делать и что обсуждать и кто вообще пойдёт. Изучать чужие невостребованные языки на встрече вряд ли кто-то будет, хотя я может и ошибаюсь. А по поводу просто встретиться в Москве — может и хорошая идея. В 2024 году я точно не смогу никуда приехать. Впрочем, если будет какая встреча в Москве в 2025 году — посмотрим. ✅ 2024/03/02 21:52, Ivan #103 P. S. Еще был выше вопрос, почему GAZ. Название в честь газа, который течёт по трубам; было время хотел назвать bnz, но GAZ больше понравилось.✅ 2024/03/02 22:06, Автор сайта #104 По-моему, он был автором какой-то литературы по теме компиляции. Где-то что-то встречал. Нашёл:
У нас был предмет "Языки программирования и методы трансляции". Очень заинтересовало в своё время. У меня такого предмета не было, методы трансляции проходил среди прочего. Но интерес вырос потом.Изучать чужие невостребованные языки на встрече вряд ли кто-то будет Можно просто поделиться радостью творчества. Мне как-то написали, что образовался некоторый отрыв между теорией, преподаваемой в вузах, и практикой разработки компиляторов:Сотрудники компиляторных фирм мало что публикуют — им некогда. Я это знаю по себе. Ставлю перед языком какие-то задачи, но как воплотить это в компиляторе — непонятно. В учебниках нет таких методов, чтобы взять и прямо сразу с его помощью всё сделать. Приходится придумывать что-то своё.Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми? Вот такие моменты хорошо было бы обсуждать, оказывать взаимную помощь. Лично я не чувствую с чьей-то стороны конкуренцию, какое-то соперничество 😊 Название в честь А у меня до сих пор нет названия у языка. Пока что можно потерпеть, ибо нет самого языка. Но когда-нибудь надо будет определиться.✅ 2024/03/02 22:43, Ivan #105 По сути создать какой-нибудь компилятор, если учился у Сергея Свердлова или читал его книги, — сложностей особых нет. Просто нужен интерес, а также надо много свободного времени, которого у многих нет (у меня ушло около 6 месяцев на написание чисто ядра с базовым набором функций, потом по сути только добавление новых функций в основном). Вот действительно настоящая сложность — сделать, чтобы он работал сколько-нибудь быстро, чтобы был оптимизированным, а в идеале чтобы написанный код транслировался в ассемблер/машинный язык, а не в свою же написанную виртуальную машину (лично мне такое, например, не по силам) — чтобы тот же цикл for выполнялся миллиард раз в секунду, а не миллион. А иначе получается язык для написания скриптов, а не программ, который только и остаётся как периодически наполнять новыми встроенными методами для решения новых задач; писать такие методы на самом языке с приемлемой производительностью не получится (попробуй напиши что-нибудь ресурсоёмкое, например, на встроенном языке PHP) — поэтому придётся периодически выпускать новые версии компилятора для эффективного решения новых задач.✅ 2024/03/03 10:18, MihalNik #106 Вот действительно настоящая сложность — сделать, чтобы он работал сколько-нибудь быстро, чтобы был оптимизированным, а в идеале чтобы написанный код транслировался в ассемблер/машинный язык, а не в свою же написанную виртуальную машину (лично мне такое, например, не по силам) — чтобы тот же цикл for выполнялся миллиард раз в секунду, а не миллион. Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Там везде текст на тексте? Вернее сказать не ошибка, а просчет.✅ 2024/03/03 12:49, Автор сайта #107 в идеале чтобы написанный код транслировался в ассемблер/машинный язык Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код. Если будете транслировать в чистый Си, то могу порекомендовать TinyCC, он быстрее GCC в 9 раз. Но если делать язык исключительно для себя, то может и не стоит заморачиваться. Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет.✅ 2024/03/03 14:06, Ivan #108 Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Стековая виртуальная машина. Как учил Сергей Свердлов. Как я понимаю, это самый простой вариант VM, но не самый эффективный. Но как я понимаю, замедление в любом случае будет в случае виртуальной машины. Вопрос только в том, в 10 раз или в 1000 раз. По правде, в 2012 году замедление было в 5000 раз, сейчас оптимизировал всё, что мог, стало медленнее в 1000 раз — скорее всего, дальнейшее значительное ускорение невозможно в рамках текущей VM.Приближаясь к идеалу, можно для начала транслировать в Си, Паскаль или ещё что-то быстрое. А потом уже получать исполняемый код. Можно, конечно. Но только тогда становится непонятным — зачем тогда нужен свой написанный компилятор. Если всё равно дополнительно придётся таскать с собой компилятор Си, Паскаля и т. д. — не лучше ли тогда сразу писать на Си или Паскале. К тому же у этих самых Си и Паскаля есть свои собственные лицензии, которые могут ограничивать встраивание их компиляторов в сторонние продукты.Хотя после прочтения Вашей статьи на Хабре, а точнее фразы «возможна компиляция в exe», начал сомневаться, актуален ли совет. Да, возможна компиляция в EXE. И скомпилированный файл действительно будет работать и вести себя как EXE во всех смыслах (например, возможен его запуск из командной строки с параметрами, может работать отдельно без необходимости установки компилятора GAZ и т. д.) Но следует понимать, как устроен этот самый EXE. В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ. Поэтому такая "компиляция" в EXE не даст ускорения работы кода. Но работать будет действительно как EXE, что часто может пригодиться. Тот же AutoIt также позволяет, например, компилировать скрипты в EXE похожим образом.Сейчас, начиная с 2015 года создал и GAZ.dll для встраивания компилятора в свои сторонние проекты. ✅ 2024/03/03 14:26, Max Vetrov #109 В конец файла записан исполняемый код программы на языке GAZ. А если попробовать байт-код?✅ 2024/03/03 15:11, Ivan #110 А если попробовать байт-код? Разницы в производительности не будет. Т. к. компиляция самой программы на языке GAZ занимает около 1/10 секунды если размер кода в пределах 2000 строк (а больше писать на таком языке нет особого смысла). При запуске EXE это незаметно.Медленно работает именно сам байт-код. Если на нём писать что-то типа числодробилок, например. Тем не менее, мне для решения 99% задач хватает. Хотя, конечно, хотелось бы и побыстрее, но тут генерацию самого байт-кода надо делать более эффективной и виртуальную машину оптимизировать (а это неизбежно приведёт к багам, которые надо будет устранять и т. д.) ✅ 2024/03/03 16:40, Автор сайта #111 этих самых Си и Паскаля есть свои собственные лицензии TinyCC можно, по-моему, свободно использовать и распространять.В EXE фактически встроен сам компилятор и он занимает 99,9% размера этого самого EXE. В конец файла записан исполняемый код программы на языке GAZ. Когда-то были такие инструменты — FoxPro и Clipper. Первый был интерпретатором, а второй выдавал EXE, а язык был фактически одним и тем же. Но в EXE от Clipper не было исходника, хотя компилятор в него включался, т. к. без него не работала бы функция EVAL.Медленно работает именно сам байт-код. Есть ещё прямой шитый код и косвенный шитый код, это из Форта. Даёт весьма неплохую скорость, хотя и уступает раза в 2 Си-шным программам. Но, думаю, динамическая типизация тоже внесла свой вклад.✅ 2024/03/06 00:39, Ivan #112 Виртуальная машина не должна давать такого замедления. Тут какая-то серьезная ошибка в реализации, может во внутреннем представлении. Я сравнивал производительность различных языков в 2009 году.В общем оказалось, что 1С 7.7, ActionScript 2.0, PHP, Python и вообще языки с нестрогой типизацией оказались с довольно сильным замедлением скорости (сотни тысяч или в пределах миллиона выполнений почти пустого цикла с простыми вычислениями в секунду) в сравнении с Java/Delphi (сотни миллионов выполнений такого же цикла). Что также наводит на мысли, что Java уже на момент 2009 года — это не совсем честная виртуальная машина, а больше нативный код (JIT-компиляция). То есть даже виртуальная машина PHP (которую явно писали профессионалы и явно оптимизировали там всё, что можно) замедляет вычисление числодробилок раз в 100 — если бы всё было так просто — замедление было бы в 2-3 раза, максимум в 10 раз. Конкретно по виртуальной машине GAZ — я полагаю — причины замедления в динамической типизации, большом количестве встроенных команд, в генерации не оптимизированного кода (для тех же циклов), ну и может ещё какие ошибки в реализации виртуальной машины с точки зрения производительности, в совокупности это даёт дополнительное замедление ещё в 10 раз в сравнении с PHP. ✅ 2024/03/07 10:45, Автор сайта #113 причины замедления в динамической типизации Современные процессоры очень не любят переходы, особенно непредсказуемые. И вызовы тоже. Тесты, которые нерепрезентативны, но дают общее представление о проблеме: «C vs Haskell: сравнение скорости на простом примере». На некоторых примерах удалось получить отставание Хаскелла от Си в полторы тысячи раз.создать какой-нибудь компилятор, если учился у Сергея Свердлова или читал его книги, — сложностей особых нет А какие методы компиляции Вы использовали в своей разработке?✅ 2024/03/07 15:14, Ivan #114 Современные процессоры очень не любят переходы, особенно непредсказуемые. И вызовы тоже. Да, а у меня за выполнение команд отвечает один большой CASE с вызовами нужной процедуры для каждой команды. Пробовал делать без CASE, а с помощью прямых переходов на адреса процедур — но это не ускоряет выполнение.Немного ускорило процесс то, что убрал процедуры для наиболее часто используемых команд виртуальной машины (add, sub, goto) и разместил код непосредственно в CASE. В общем, на 99% всё как Сергей Залманович учил. Но он учил писать компиляторы, но не учил, как сделать виртуальную машину быстрой. По языку — я даже знаю сейчас, как можно его ускорить раза в 2 — например, добавить команд для виртуальной машины — для выполнения цепочек последовательных команд одной командой — чтобы уменьшить вызовы CASE и непредсказуемые переходы или оптимизировать генерацию команд для выполнения на виртуальной машине — но честно говоря, не особо есть смысл этим заниматься. А так как компилятор GAZ активно используется в своих разработках — стабильность работы куда важнее, чем мифическое ускорение всего лишь в 2 раза. Очень много лишних команд генерируется ещё, например, для обработки исключений try-except-end и вообще команд генерируется чересчур много и я не занимался оптимизацией этого дела, а занимался тем, чтобы это просто работало и не глючило. Потому, думаю и довольно медленно работает. Но учитывая большое количество встроенных команд и скорости современных процессоров я бы не сказал, что эта медлительность как-то мешает в практических проектах. А какие методы компиляции Вы использовали в своей разработке? Сначала пишем модуль — парсер исходного текста, преобразование его в лексемы. Потом синтаксический анализатор и на его основе и лексический анализатор тоже. Генерируем код для виртуальной машины, потом выполняем его на написанной виртуальной машине.Мне всегда хотелось генерировать код не для своей виртуальной машины, а для процессора x86 — но судя по всему, мне не по зубам такая задача — тем более с динамической типизацией. Да и не учили нас этому. ✅ 2024/03/09 17:10, Автор сайта #115 Да, побороться за ускорение можно. Но нужно ли это — на этот вопрос ответите только Вы.не сказал бы, что эта медлительность как-то мешает Ну да, процессоры быстры как никогда. А на некоторых классах задач основная задержка идёт не от медленного выполнения байт-кода программы, а в силу того, что чтение или запись файлов (к примеру) делается многократно медленнее.x86 ... не по зубам такая задача При некоторой настойчивости и наличии времени эта задача решается. На сайте Андрея Хохлова есть краткое пособие по генерации кода. Но это опять же — нужно ли Вам это? Вы готовы утверждать, что Ваш язык содержит нечто, что даёт ему перспективу?парсер исходного текста ... синтаксический анализатор То есть метод рекурсивного спуска? Правильно понял?✅ 2024/03/11 15:04, Ivan #116 Вы готовы утверждать, что Ваш язык содержит нечто, что даёт ему перспективу? Я думаю: если и есть какие-то перспективы, то от ускорения в 2 раза ровным счётом ничего не изменится (а ускорить в 10 раз малой кровью — скорее всего, не получится). Все равно язык и компилятор будут решать ровно тот же класс задач, что решает и сейчас: по сути, если коротко, это упрощенная и урезанная версия AutoIt (который, кстати сам тоже не блещет скоростью).Если найдётся время, то куда целесообразнее потратить его, например, на добавление новых функций (список того, что хотелось бы доработать, у меня есть. Если всё это реализовать, то хватит как раз до 2030 года), чем на ускорение VM. Почему сам использую свой компилятор, а не AutoIt (который изначально более функционален, например: мне кажется, что язык GAZ выглядит проще (по крайней мере, для меня). Многие небольшие программы выглядят на нём короче, чем на AutoIt, также используется полная компиляция перед выполнением, а не во время выполнения как у AutoIt, что повышает надёжность кода. Также что мне не понравилось в AutoIt — отсутствие массивов с нулевой длиной. Не будь этих недостатков у AutoIt — сам бы использовал именно AutoIt как скриптовый язык для сборки своих проектов и встраивания в свои программы. Но про AutoIt я узнал в 2012 году, а GAZ написал в 2009-2012. То есть метод рекурсивного спуска? Правильно понял? Честно говоря, забыл уже как это называется. Но похоже, оно.Сам транслятор исходного кода в байт-код, кстати, очень быстрый — довольно быстро обрабатываются и программы по 100 000 строк. Что показывает, что этот метод парсинга довольно эффективный. Ну а про медлительность VM и причины этого уже писал ... ✅ 2024/03/11 19:58, Автор сайта #117 Думаю, найдутся языки, программы на которых будут быстрее не в 2, а в 20 раз. И функций там будет на порядки больше. А простота во многом субъективна. Так что ответа на вопрос, что даёт Вашему языку перспективу, пока что нет.метод рекурсивного спуска? сложностей особых нет ✅ 2024/03/12 00:14, Ivan #118 Думаю, найдутся языки, программы на которых будут быстрее не в 2, а в 20 раз. Уверен, найдутся. Например, Python или ещё какие аналоги явно будут работать быстрее. Но всё-таки мой компилятор больше аналог AutoIt, а не Python. На Python многие задачи потребуют гораздо больше кода, чем на AutoIt.И функций там будет на порядки больше. Ну если предположить (что из области фантастики, конечно), что мой язык был бы востребован хотя бы настолько, что я мог бы на нём (а не на других своих проектах) зарабатывать хотя бы тысяч 100 в месяц (рублей) ... поверьте, функционал бы постоянно расширялся и возможно, достиг бы половины возможностей того же PHP. А так, на энтузиазме вижу смысл расширять исключительно по мере своих потребностей, под свои задачи.А простота во многом субъективна. 2) Возможность использования его как простого и урезанного аналога AutoIt, у которого практически нет конкурентов в его классе по простоте кода и обширности функций. 3) Возможность использования как простого и функционального языка для обучения детей, позволяющего быстро и просто писать функциональные скрипты (в сравнении с Pascal ABC) — например, перезагрузить систему или открыть CD-ROM. Правда, не факт, т. к. динамическая типизация привьёт этим детям плохие привычки программирования ... 4) Расширяемость функционала под потребности (да, плюс похоже только для меня самого, так как кто-то другой не будет, скорее всего, готов платить за доработки компилятора с закрытым исходным кодом под него). 5) Большое количество написанных скриптов (уже несколько тысяч), которые я использую в основном для себя. А вообще — конечно, было бы проще и лучше устранить перечисленные мной и другие недостатки AutoIt (который хорош — но имеет множество вариантов выстрелить себе в ногу при написании кода по сравнению с GAZ), чем продвигать мой компилятор. В мечтах было бы выпустить версию компилятора GAZ под Android и большой набор скриптов для работы с файлами. Но 99,9% что эти мечты так и останутся мечтами навсегда ... ✅ 2024/03/13 21:31, Ильдар #119 из области фантастики ... мой язык был бы востребован хотя бы настолько, что я мог бы на нём (а не на других своих проектах) зарабатывать хотя бы тысяч 100 в месяц (рублей) ... поверьте, Поверьте, это из области ненаучной фантастики.✅ 2024/03/15 20:34, Автор сайта #120 А у Вас есть правила Вашего языка, записанные в БНФ? Вопрос к Ивану.✅ 2024/03/15 23:21, Ivan #121 А у Вас есть правила Вашего языка, записанные в БНФ? Вопрос к Ивану. Нет. И вообще я больше практик, чем теоретик. Функциональность интересовала больше, чем красота. Сразу делал всё на компе, без диаграмм и БНФ.За основу языка брал смесь урезанного Паскаля и 1С 7.7 (из 1С взял = вместо := и динамические переменные). Мы на 2 курсе писали свой компилятор языка О — и у меня было задание добавить в него поддержку массивов. Собственно этот язык, но с изначальной поддержкой массивов и стал основной GAZ. Также, разумеется, были добавлены if-then-else, while, repeat как неоходимый базовый функционал. Оказалось в итоге, что разработанный язык был слишком беден и трудноприменим на практике. Пришлось добавить поддержку процедур и функций (с параметрами-переменными и константами), без этого язык был совсем никудышный. Потом пришлось добавить поддержку try-except-end, без этого оказалось, что тоже языком пользоваться неудобно — так как в процессе выполнения команд могут возникать ошибки, надо их как-то обрабатывать. После добавления этого минимально необходимого перечисленного функционала язык уже можно стало называть языком, а не игрушкой и писать на нём программы для себя. Наращивая количество встроенных функций и практически не дорабатывая функционал собственно языка. Потом писал много программ на этом языке и оказалось, что компилятор ведёт себя довольно стабильно. Собственно первой нормальной и стабильной сборкой языка можно считать версию от 2011/2012 года, выложенную на сайте. Что было дальше (крупные изменения): 1) 2015 год — выпуск GAZ.dll для возможности встраивания компилятора в сторонние приложения и пример встраивания для Delphi. Если кому-то нужно, могу скинуть. Удобная вещь. 2) 2017 год — ускорение виртуальной машины языка примерно в 5 раз. 3) 2017 год — поддержка #import — для возможности разбивки программы на несколько файлов-модулей. 4) 2019 год — поддержка OLE для работы с Excel. 5) 2020 год — добавление встроенной поддержки 2-мерных массивов. Очень не хватало до этого. 6) 2021 год — выпуск 64-разрядной версии компилятора GAZ. Можно колбасить практически любые данные без риска получить Out Of Memory. Мелкие доработки нет смысла перечислять, они идут постоянно, раз в 3 месяца, добавление скриптов или встроенных модулей (написанных на языке GAZ) без модификации самого компилятора тоже считается. Хотя компилятор не очень в них и нуждается и уже сам по себе самодостаточен. P.S. Чего бы временами очень хотелось, но этого нет и никогда не будет — поддержка записей, объектов, вложенных процедур. try-finally-end. Впрочем, как показала практика (и объём написанного кода на языке GAZ), и без этого можно неплохо жить — а вот не будь поддержки массивов — было бы действительно грустно. ✅ 2024/03/16 16:12, Советский #122 Ivan, БНФ — это просто.✅ 2024/03/17 00:00, alextretyak #123 Поверьте, это из области ненаучной фантастики. Ну, я бы не был так категоричен. Во многом всё зависит от автора языка и его способности продвигать своё детище. Вы ничего не слышали про язык программирования Zig? Это довольно молодой проект, появившийся менее 10 лет назад.В 2020 году его автор, Эндрю Келли, основал некоммерческую организацию Zig Software Foundation. Посредством только GitHub на данный момент эту организацию спонсирует более 500 человек на общую сумму пожертвований свыше $12000 в месяц (https://github.com/sponsors/ziglang). А итоговая сумма пожертвований составляет свыше $300'000 в год начиная с 2021. Данные за каждый год представлены в файле ‘Finances’ на Google Диске по ссылке: https://ziglang.org/ru/zsf/ При всём при этом, если судить по общему количеству коммитов, основным разработчиком компилятора языка по-прежнему является его автор (https://github.com/ziglang/zig/graphs/contributors). У второго по величине вклада разработчика в 4 раза меньше коммитов, у третьего — в 7 раз меньше. Хотя сейчас основными коммитами автора Zig являются слияния изменений от других разработчиков, общее количество разработчиков на проекте совсем небольшое, и суммы пожертвований хватает, чтобы их содержать. Да, таких успешных примеров совсем не много, и даже Бьёрн Страуструп, наверное, не зарабатывает столько на C++. Но дело в том, что он к этому и не стремился. ✅ 2024/03/18 00:16, Бурановский дедушка #124 даже Бьёрн Страуструп, наверное, не зарабатывает столько на C++. В советское время было популярно такое наблюдение: «Наука — это удовлетворение любопытства за государственный счёт». Страуструп удовлетворил своё любопытство за счёт «AT&T Bell Labs».Пример языка Zig замечателен. Вот только такое не работает в наших палестинах. У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования. ✅ 2024/03/18 12:38, Ivan #125 Тут ещё 1 момент. Если проект GAZ вдруг взлетел бы. То конечно, он оброс бы функциями, как минимум. Как максимум может, что-нибудь добавилось бы и в сам язык вроде поддержки try-finally-end или ускорение виртуальной машины в 5 раз. Но в этом случае есть не только +, но и — лично для меня. Пришлось бы подстраивать интересы языка не под себя, а под сообщество, язык стал бы уже не таким свободным и пластичным для меня лично, каковым является сейчас.Может и баги бы какие-нибудь обнаружились бы, хотя мне и кажется, что их практически нет, последний небольшой баг исправлял в 2021 году (сейчас только что запустил генерируемый скрипт для преобразования 1 папки с файлами в другую на языке GAZ (64-bit), размер скрипта около 700 мегабайт, 113 000 строк кода, в сжатом виде 7z около 25 Мб). Компилятор выдерживает жесточайшие нагрузки и не глючит практически. В отличие от того же cine/fei (имхо и это как мне кажется, конечно — может, дело обстоит не так) — который очень функционален по сравнению с GAZ и даже мог иметь перспективы — будь он отлажен и доведён до ума — но явно самим автором не используется и явно не имеет такой базы юнит-тестов. У меня же больше акцент на качество и стабильность и на активное использование своего компилятора самим собой, а не на количество функций. Может и по той причине, что само ядро компилятора небольшое и несложное, глючить там особо нечему. В самом деле, размер кода самого компилятора в 68 000 строк (на 2012 год) или 126 000 строк (на 2023 год) — притом, что за последние 11 лет добавлялись в основном новые функции (например, Base64Encode), а не дописывалось ядро — это совсем немного чтобы быть функциональным и глючить? У кого есть свои компиляторы и из скольки строк кода они состоят? ✅ 2024/03/18 12:59, Ivan #126 У нас денег на порядок или два меньше. Есть ли какой-то пример того, как у нас хоть какая-то технология взлетела на пожертвованиях? Только и остаётся надеяться государственные пожертвования. Пока знаю только 1 язык, который у нас взлетел — это встроенный язык 1С. На нём на самом деле много чего можно писать и довольно сложное, язык очень функциональный и полностью российский, востребованный чуть ли на 1 месте в России. Но взлетел, увы, только как побочный продукт к системе автоматизации 1С, а не сам по себе.✅ 2024/03/18 13:49, Ivan #127 Можно просто поделиться радостью творчества. Мне как-то написали, что образовался некоторый отрыв между теорией, преподаваемой в вузах, и практикой разработки компиляторов Не заметил такого практически вообще. Кроме 1 момента — в ВУЗе Сергей Свердлов очень большой акцент делал на красоте кода, а мне больше нравится акцент на функциональности. Впрочем, Паскалеподобный язык, как мне кажется, и не может быть как-то особо некрасив.Ещё отдельная тема: допустим, я что-то придумал, но как это записать в БНФ? Чтобы все рекурсии были только хвостовыми? Как я понимаю, эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит?Вот такие моменты хорошо было бы обсуждать, оказывать взаимную помощь. Лично я не чувствую с чьей-то стороны конкуренцию, какое-то соперничество Да какая тут может быть вообще конкуренция. Если встреча авторов с языками, востребованность которых около нуля и на которых авторы не зарабатывают денег. Нет поля для соперничества, нечего друг у друга отжимать, т. к. доля рынка у каждого и так около 0.✅ 2024/03/18 17:45, veector #128 Ivan, хвостовая рекурсия это вот эта тема (там даже примеры есть): https://ru.wikipedia.org/wiki/Хвостовая_рекурсияТема зависит не от языка, а от возможности оптимизации компилятора, т.е. вас это коснется, если будете увлекаться рекурсиями. А если по-простому, по-программистски, то это вариант оптимизации, когда вместо ассемблерной инструкции вызова подпрограммы (call) компилятор ставит инструкцию перехода (jump), т.к. текущий результат (контекст) полностью совпадает с входными параметрами на следующей итерации. Вообще, такая оптимизация возможна, когда рекурсию можно преобразовать в простой for() и компилятор догадывается об этом. Виртуальных машин это тоже касается. ✅ 2024/03/18 23:58, Автор сайта #129 Паскалеподобный язык, как мне кажется, и не может быть как-то особо некрасив. Почитатели языков с вершины рейтингов вряд ли с Вами согласятся. Да и Вы сами от него местами отказываетесь:из 1С взял = вместо := эта проблема только с С-подобных языках? Если я фанат и настоящий ценитель Паскаля — мне это не грозит? Допустим, есть язык с такими правилами:выражение ::= операторы присваивания | условный операторЗдесь наблюдается рекурсия: «выражение» содержит в себе «условный оператор», «условный оператор» содержит в себе «выражение». В Вашем языке есть что-то подобное, скорее всего. Было любопытно, как Вы перестраивали правила, чтоб избежать рекурсии. ✅ 2024/03/19 02:04, Ivan #130 Посмотрел код компилятора GAZ. TryOperator — главный элемент, что есть в языке. Вся программа — последовательность элементов TryOperator. Фактически означает обработку try Operator except end. Кстати, кроме вызова Operator содержит около 40 команд виртуальной машины: команды сохранения регистров стека, регистра базы, регистра для команд прерывания Break и продолжения Continue и прочего. И это в каждом операторе. Может, поэтому в том числе код такой медленный, так как он генерирует много команд виртуальной машины. Видимо, в процессе разработки компилятора добавлял нужные команды, чтобы работало и не глючило. И их стало много. А потом уже непонятно и самому стало, как это чудо оптимизировать.Состоит из элементов типа и является обёрткой Operator, который в свою очередь является одним из:OperatorAssignmentOrProcedure | OperatorIf | OperatorRepeat | OperatorWhile | OperatorIf, к примеру, в секции после then как раз представляет собой TryOperator. Так что, похоже на то, рекурсия как раз есть.Вторым ключевым и рекурсивным элементом языка является OperationOR, что означает Выражение.OperationOR — OperationAND — OperationNOT — OperationCMP — OperationSumma —То есть обрабатывается соблюдение приоритета операторов. OperationElement в свою очередь состоит из OperationOR.Ну а неэффективность и медлительность — это видимо потому, что хотелось хоть какой-то язык написать, и чтобы работало и не глючило. А оптимизация компиляторов — это, похоже, это не моё... ✅ 2024/03/19 02:19, Ivan #131 из 1С взял = вместо := Видимо, долго работал на 1С 7.7 и проникся. По духу и синтаксису язык GAZ, конечно, Паскаль, пусть и немного "улучшенный". Чтобы короче писать:= вместо := и с динамической типизацией, чтобы не нужно было объявлять переменные. И раз уж язык разрабатывался как скриптовый, то было бы странным ещё объявлять переменные. И вообще, краткости кода хотелось по сравнению с Паскалем.Почему по духу, как я считаю, Паскаль: в первую очередь потому, что код на нём простой и понятный, ничего особо сложного и нечитабельного. Как, например, на С++ написать не получится. Синтаксис на 95% как у Паскаля. Никаких || и &&, как в PHP. Никаких долларов в названиях переменных, как на AutoIt. Всё просто и понятно.С++ считаю самым ужасным языком и ужасаюсь, как вообще можно было такое придумать, код совершенно нечитабельный. При этом пробовал писать программы на С++ и даже написал что-то там на 10 тысяч строк. Правда, преподаватель увидел и сказал, что так на С++ не пишут. Фактически код написан как на Паскале, но с использованием операторов С++, но зачёт поставил. ✅ 2024/03/19 23:12, Автор сайта #132 Так что, похоже на то, рекурсия как раз есть. Значит, вы не делали преобразований правил языка, чтобы избежать рекурсии. Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует.С++ считаю самым ужасным языком Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать. Ада, который был для меня четвёртым по счёту и который можно считать более сложным вариантом Паскаля, мне не зашёл, а вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло.✅ 2024/03/20 10:39, Ivan #133 Значит, вы не делали преобразований правил языка, чтобы избежать рекурсии. Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует. Компиляция удивительно быстрая. Проблем вообще никаких нет. Пробовал генерировать и программы по 200 000 и по 500 000 строк, компилируются быстро.По поводу больше памяти. Может и больше, но, скажем, 5 мегабайт или 10 — разницы вообще никакой нет с современными объёмами оперативной памяти. Когда 1 вкладка браузера потребляет 200 мегабайт. Во времена Pentium II может и было актуально. Так что этот пункт, кажется, спорный. Вот что больше всего бесило в процессе разработки, так это утечки памяти. Например, при вызове функции Eval, что мешало ставить программы и скрипты, написанные на языке GAZ на сервера для работы 24/7. И не только при вызове функции Eval, но и, например, при выполнении кода. A[2] = длинная строкапамять не освобождалась. Потом худо-бедно это было решено. ✅ 2024/03/20 15:41, Деньги на WWWетер #134 Паскаль, пусть и немного "улучшенный". Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ)✅ 2024/03/20 22:44, Ivan #135 Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон Только Питон хорошо прокинул пользователей с версиями 2 и 3. Нарушил обратную совместимость. И после выхода версии 3 — вторая версия, полагаю, не развивалась параллельно, как 3-я. Так что тоже в своём роде язык не идеальный.По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык. Вот только я не знаю, что писалось вообще на этом Обероне. Получается — Оберон самый лучший, но почти не используемый на практике, Питон — самый лучший из используемых на практике. ✅ 2024/03/23 18:24, MihalNik #136 Допустим, есть язык с такими правилами: Как пишут в учебниках, это делает компиляцию и медленнее, и памяти она больше требует. Разбор замедляет перегрузка смыслами операторных знаков и идентификаторов, а не рекурсия. Поэтому:Компиляция удивительно быстрая. Проблем вообще никаких нет. Это как раз не удивительно. Компонентный Паскаль, например, у меня парсился со сбором лексики около 100К строк в сек/ядро бюджетного ноута 12-го года с конструкциями вида:case symbol ofСмысла писать БНФ вместо сразу работающего и однозначного кода по сути нет. И перегрузка языка сложными правилами гораздо сильнее замедлит переваривание кода человеком, а не машиной. Вот написали Вы слишком теоретизированный БНФ, а потом по нему пишут такой же код. На деле должно быть: Выражение ::= Выражение с ключевого слова | Выражение с идентификатораИ тогда сразу очевидно — берем слово, его хеш, смотрим в табличке наличие флага ключевого слова, сверяем с ключевым словом: да — проверяем допустимость (по табличке) и переходим к элементу грамматики, нет — работаем с процедурой или переменной, при том уже известно с чем именно, в отличие от "теории", которая, например, при опечатке проглотит вызов функции для идентификатора какой-нибудь целочисленной переменной, оставив проверку "на следующий этап". вот Си пользуюсь до сих пор и ужаса не испытываю. Вы просто не прониклись его духом. Не повезло. Довольно не просто проникнуться слабой типизацией, синтаксисом с трудным вылавливанием точечных опечаток и перегруженностью значков разными смыслами. Глянешь на какой-нубудь оператор "++" — ни краткий (достаточно одиночного +), ни однозначный (постфиксный и префиксный с различным приоритетом) — явно сделан чтобы писать спагетти код. Правда автоматом расплести подобное не представляет такой уж трудности, код любого ЯП можно при желании читать в любом синтаксисе, который программист себе пожелает сделать, да и генерить его из любого синтаксиса не сложно.Другое дело, что да, для своего времени в сравнении с другими средствами язык занял большую рыночную нишу и даже удерживает часть до сих пор. Но многие, используя, его уже не пишут и не читая, лишь скармливая компилятору сгенерированный на нем код. Си был для меня седьмым по счёту языком, а C++ — восьмым. Так что было с чем сравнивать. А для многих он был лишь вторым или третьим, а потом ещё тоже много других и тоже было с чем сравнивать. Также надо понимать, что люди будут говорить о совершенно разных языках и средствах, называя С или ++. Сейчас ++ совсем не те, что были в 90-х, как и, например, 1С с 8-ой версии и до неё — просто небо и земля. Можно попробовать взять "Современное проектирование на С++" Александреску 2001-го года и сравнить с тем, как можно теперь. Было бы неплохо переписать Вашу утилиту транслитерации именно в духе современных ++.По мнению Сергея Залмановича лучший, без сомнения, Оберон. Типа самый красивый язык.Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП, из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая. ✅ 2024/03/24 07:31, kiv #137 Что бы понять восторг от появления в руках Си, попробуйте представить путь автокодно-ассемблерный: Днепр-Урал-Наири-ЕС-СМ2-СМ4-НЕВА501-ИСКРА226 (и ещё кучка малоизвестных спец. архитектур) и, наконец, Си на x86. На рубеже 80-х — 90-х прошлого века я добился покупки и сам забирал ленту в НИЦЕВТ Си транслятора для ОС-ЕС и переписывал стандартную библиотеку под ПДО (СВМ), в которой была чистая паравитуализация и весь ввод-вывод организован не через обращение к каналам, а к гипервизору.Для меня Си это универсальный мультиплатформенный макроассемблер. И кстати указатели и структуры органично сложились в голове на основе помимо ассемблерного опыта, ещё и опыта PL/1, в котором базированная структура "наше всё". Для человека пришедшего в Си из Ассемблеров ++/--переменная или переменная++/-- — это элегантное изображение множества макросов, которые он писал до того, как в руках появился Си.✅ 2024/03/24 13:09, Автор сайта #138 MihalNikРазбор замедляет перегрузка смыслами операторных знаков и идентификаторов, а не рекурсия. Авторы книг по компиляции настойчиво рекомендуют заменять рекурсию на итерацию за счёт приведения рекурсии к хвостовой. От перегрузки смыслами лучше уходить. Но тут ещё может выручить разница между унарными и бинарными операторами.Смысла писать БНФ вместо сразу работающего и однозначного кода по сути нет. Можно и не писать правила в БНФ, если это считать лишней работой, которая лишь расходует время. Но если есть правила в таком виде, то это документация, помогающая1) разработчику языка, «кристаллизуя» его мысли, 2) разработчику компилятора в качестве ТЗ, 3) программисту, пользователю языка и компилятора для лучшего понимания. Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир». Довольно не просто проникнуться . . . перегруженностью значков разными смыслами. Да, Вам тоже не повезло проникнуться духом Си. 🤣 Одни видят в инкрементах/декрементах элегантность, а другие — перегруженность. Но, кстати, от постфиксных операторов я предпочитаю отказаться.для многих он был лишь вторым или третьим Знаю таких, у кого он был первым. 🤣 И ничего, необратимых последствий для мозга не возникло.многие, используя, его уже не пишут и не читая, лишь скармливая компилятору сгенерированный на нем код. И это открывает дорогу новым языкам на очень большое количество платформ. Потому что первым написанным для новой платформы компилятором бывает именно Си.Красота неописуемая. В прямом смысле — никакими метриками. Трудно назвать красивым ЯП [Оберон], из которого лучше просто выкинуть целый ряд ключевых слов, даже грамматики не ломая. Прям мои мысли читаете. 🤣 А набранные заглавными буквами ключевые слова — вообще отдельная песня.kiv сам забирал ленту в НИЦЕВТ Си транслятора для ОС-ЕС А PL/1 Вас не устраивал? Тоже язык высокого уровня. Тем более, что Вы дальше пишите:ещё и опыта PL/1, в котором базированная структура "наше всё". это элегантное Вот именно, сравниваяа = а + 1и ++ ая понимаю, что краткость — сестра таланта. Что Ритчи был гений. Недооценённый, кстати. Если с Виртом сложился «культ личности», то о скромном гении Ритчи вспоминают куда реже. Если языки с синтаксисом Си наверху во всех рейтингах, то упоминаемость этих двух авторов языков являет нам противоположную картину. ✅ 2024/03/24 13:12, MihalNik #139 Что бы понять восторг..., попробуйте представить Так есть более ценные предметы для понимания... Можно, например, представить, что вместо "int,int,int" можно "Ц Ц Ц", "ЦЦЦ" или "3 ц".✅ 2024/03/24 13:37, MihalNik #140 Вам тоже не повезло проникнуться Бывают, люди, которые считают, что им не повезло, от того что другие не "прониклись" тем же чем и они. Таким крайне опасно давать много денег.Авторы книг по компиляции настойчиво рекомендуют заменять рекурсию на итерацию за счёт приведения рекурсии к хвостовой. Авторам КНИГ можно порекомендовать написать КОМПИЛЯТОР, который это делает автоматически.Но если есть правила в таком виде, то это документация, помогающая Или мешающая. Потому что это будет лишь часть правил, вырванная из контекста. А потом к ним надо будет приложить другие, и всё это будет разбросано по разным частям и быстро начнет расходится с реализацией...Ещё такой пример. Когда конкурс МО США на разработку языка Ада завершился, то одним из итогов конкурса была сформулированные правила в БНФ. Первый компилятор языка появился не раньше, чем через 2 года. Но уже до его появления начали издаваться книги по этому языку, а в книге в справочных материалах были правила в БНФ. С одной из таких книг можно познакомиться: П. Вегнер, «Программирование на языке Ада», издательство «Мир». Отличный пример. И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом?✅ 2024/03/24 14:11, kiv #141 А PL/1 Вас не устраивал? Тоже язык высокого уровня. Очень бы устроил, если был бы доступен на других платформах. Как-то почти всю мою жизнь одновременно приходилось работать всегда на нескольких. Устроил бы даже очень, но именно тот PL/1 который я знаю и помню, где помимо базированных структур была встроенная в язык многозадачность и асинхронный ввод/вывод. Я уже много раз писал в разных местах о том, что современные упоминания асинхронности вызывают у меня улыбку, ибо в середине 1980-х меня "фигурально били" в курилке, за то, что я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами. :)✅ 2024/03/24 15:27, Автор сайта #142 Таким крайне опасно давать много денег. Но Вы-то денег не даёте. Поэтому эта опасность Вас не касается. 🤣И где же горы любительского СПО от сообщества, "восторженного" этим гениальным бюрократическим продуктом? Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел.Очень бы устроил, если был бы доступен на других платформах. На x86 он был, вот только лично я узнал относительно недавно, когда поезд давно ушёл. Кстати, Орлов Владимир Николаевич, говоря о своём переходе с PL/1 на Си, отмечал, что для x86 не было компилятора PL/1, поэтому при переходе с ЕС ЭВМ на x86 пришлось переходить с PL/1 на Си. На что Дмитрий Юрьевич заметил, что компилятор таки был. Но это тоже было недавно, когда поезд уже ушёл.я в разгар рабочего дня асинхронно и многозадачно работал с двумя лентами. ОС ЕС была присуща многозадачность, поэтому у компилятора PL/1 была простая задача: сгенерировать код, который формирует параметры, а затем вызывает прерывание с нужным номером. Вот и всё. А DOS не была многозадачной, поэтому сомневаюсь, чтоб всё было так просто.✅ 2024/03/24 15:59, MihalNik #143 Типичный пример неудачной «революции сверху». В отличие от «революции снизу», вызванной Си. Но неуспех одного и успех другого от описания правил в БНФ никак не зависел. А где ещё успешно применяется БНФ?✅ 2024/03/24 18:01, Автор сайта #144 БНФ применяется в генераторах синтаксических анализаторов. Yacc, ANTLR, JavaCC и прочих. Правда, формат записи разнится, но легко приводится от одного вида к другому.✅ 2024/03/24 19:26, MihalNik #145 БНФ применяется в генераторах синтаксических анализаторов А те применялись в разработке каких-то успешных ЯП, или это чисто академические игрушки?✅ 2024/03/24 19:35, Автор сайта #146 Конечно. Более того, игрушками считают компиляторы, сделанные вручную, а вот сгенерированные такими инструментами — надёжными и с некоторым уровнем гарантированного качества.✅ 2024/03/24 19:38, Metasyntax #147 БНФSoftware that accepts BNF (or a superset) as input• ANTLR, a parser generator written in Java• Coco/R, compiler generator accepting an attributed grammar in EBNF • DMS Software Reengineering Toolkit, program analysis and transformation system for arbitrary languages • GOLD, a BNF parser generator • RPA BNF parser.[16] Online (PHP) demo parsing: JavaScript, XML • XACT X4MR System,[17] a rule-based expert system for programming language translation • XPL Analyzer, a tool which accepts simplified BNF for a language and produces a parser for that language in XPL; it may be integrated into the supplied SKELETON program, with which the language may be debugged[18] (a SHARE contributed program, which was preceded by A Compiler Generator[19]) • bnfparser2,[20] a universal syntax verification utility • bnf2xml,[21] Markup input with XML tags using advanced BNF matching • JavaCC,[22] Java Compiler Compiler tm (JavaCC tm) — The Java Parser Generator Similar software• GNU bison, GNU version of yacc• Yacc, parser generator (most commonly used with the Lex preprocessor) • Racket's parser tools, lex and yacc-style parsing (Beautiful Racket edition) • Qlik Sense, a BI tool, uses a variant of BNF for scripting [23] • BNF Converter (BNFC[24]), operating on a variant called "labeled Backus–Naur form" (LBNF). In this variant, each production for a given non-terminal is given a label, which can be used as a constructor of an algebraic data type representing that nonterminal. The converter is capable of producing types and parsers for abstract syntax in several languages, including Haskell and Java Кроме того существуют другие формы записи КС грамматик . ✅ 2024/03/24 20:23, MihalNik #148 Более того, игрушками считают компиляторы, сделанные вручную. Интересно было бы провести соответствие со списком TIOBE.✅ 2024/03/24 23:32, Автор сайта #149 TIOBE — это про языки, а Yacc — про реализацию компиляторов. Тот же Си или C++ имеют множество реализаций как с помощью инструментов типа Yacc, так и написанных вручную.✅ 2024/03/25 00:36, MihalNik #150 TIOBE — это про языки, а Yacc — про реализацию компиляторов. Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать.Тот же Си или C++ имеют множество реализаций как с помощью инструментов типа Yacc, так и написанных вручную. Так это следствие/часть обрастания популярностью. В т.ч. как часть академической работы — разработчики генераторов, например, должны показать работоспособность своих изделий, студенты — умение ими пользоваться.В теории генератор может создать более быстрый анализатор. Но уже сейчас можно и не почувствовать разницу до нескольких сотен тысяч — миллиона строк кода на большинстве современных устройств. Задача это легко разделимая между вычислительными мощностями. Когда-то машины были медленнее и дороже в тысячи раз — разница ощутилась бы значительно раньше. Зато процесс внесения изменений в язык может стать в разы утомительнее. Не выйдут ли дороже неизбежные ошибки его проектирования, прототипирование? ✅ 2024/03/25 00:44, MihalNik #151 Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ) Разработчик самого верхнего языка в этом перечне вряд ли так считает.✅ 2024/03/25 12:01, Metasyntax #152 Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать. Если сейчас такого нет, это не значит что это будет всегда. Всё может поменяться. Ранее люди думали что черных лебедей не существует.✅ 2024/03/25 15:23, Ivan #153 Когда упрётесь, когда улучшать уже больше нечего, то увидите, что у Вас получился Питон (ツ) И в чём так уж хорош Питон? Что ввиду его медлительности постоянно приходится думать, как его ускорить всякими psyco, PyPy и прочими извращениями. В этом плане как раз куда лучше C++/Delphi/Java — для написания серьёзных программ. Или речь про интерпретируемые языки для написания скриптов, а не программ? Если так — тогда может и в самом деле Питон самый лучший.✅ 2024/03/25 18:23, Автор сайта #154 Если знаете примеры соответствия "успешный язык — успешный компилятор — генератор синтаксического анализатора" — можно и написать. Никто ж не афиширует методы реализации своих компиляторов. В основном молчат, хотя бывают исключения: Уолтер Брайт, разработчик компиляторов Zortech C++ и D, делал это вручную. А вот TinyCC сделан с помощью какого-то генератора: во-первых, об этом писали, во-вторых, это чувствуется по очень неинформативным сообщениям об ошибках.как часть академической работы — разработчики генераторов, например, должны показать работоспособность своих изделий, студенты — умение ими пользоваться. Это давно вышло за рамки вузов. Разработчики коммерческих компиляторов пользуют средства автоматизации в хвост и гриву.В теории генератор может создать более быстрый анализатор. Это одно из преимуществ табличных методов разбора, которые применяются в средствах типа Yacc. Одно дело иметь компактную табличку, а другое — размазать логику на множество функций.Но уже сейчас можно и не почувствовать разницу до нескольких сотен тысяч — миллиона строк кода на большинстве современных устройств. Насколько я знаю, Microsoft не хватает ночи, чтобы откомпилировать новые версии своих продуктов. Но у них и объёмы кода такие, что превзойдут всё, что наработано в РФ. У небольших организаций вряд ли будут проблемы.Зато процесс внесения изменений в язык может стать в разы утомительнее. Не выйдут ли дороже неизбежные ошибки его проектирования, прототипирование? Когда логика сосредоточена в одном месте, а не размазана по функциям, то вроде бы должно быть легче.Разработчик самого верхнего языка в этом перечне вряд ли так считает. И в чём так уж хорош Питон? Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв. Динамическая же типизация, интерпретация и связанная с этим медлительность — это несущественно на фоне этой революции. Александр Третьяк взял в свой язык 11l из Питона самое главное — синтаксис (дорабатывая его). И делает, если не ошибаюсь, язык со статической типизацией; компилятор, а не интерпретатор.✅ 2024/03/25 20:52, Ivan #155 Для меня Питон — это именно синтаксис с отступами, который почти лишён визуального, лексического мусора. В этом его прорыв. Да, кстати — совсем забыл — но зависимость компиляции от отступов — вот это как раз меня это выбесило ещё в первый день знакомства с Питоном. Нет — я, конечно, понимаю, нужно писать красивый и понятный код, правильно расставлять отступы и т. д. Но во время отладки, например — когда нужно временно закомментировать один код и раскомментировать другой — эта особенность Питона будет адски неудобной.Тем более не могу назвать язык "лучшим в мире", который страдает болезнью зависимости компиляции от отступов и тем более позволяет if-блоки оформлять отступами — громадное поле для багов. ✅ 2024/03/25 22:14, Деньги на WWWетер #156 игрушками считают компиляторы, сделанные вручную Я бы даже сказал «кустарным способом».зависимость компиляции от отступов — вот это как раз меня это выбесило А кого-то взбесила бы зависимость компиляции от «then» и «end». А в Питоне «end» вообще не нужен.✅ 2024/03/25 23:22, Ivan #157 Си был для меня седьмым по счёту языком, а C++ — восьмым Для меня Си++ был вторым языком после Паскаля. Я был уверен, что Профессионал и Си++ это синонимы, поэтому даже написал на Си++ программу на 10 тысяч строк в 11 классе. Но при этом воспринимал Си++ как недопаскаль, фактически писал на Си как на Паскале, не используя дух Си++. А после того как Сергей Залманович раскритиковал Си++ на лекциях и вовсе перестал на нём писать.✅ 2024/03/25 23:47, Автор сайта #158 Да, у Си был в своё время такой ореол: ты крут и суперпрофессионал, если хорошо знаешь Си. Это двигало преодолевать трудности при его изучении.Кстати, встретил книгу Свердлова «Конструирование компиляторов». Очень хорошие первые впечатления. ✅ 2024/03/27 10:22, Ivan #159 Вчера понял. Вместо написания многих языков "энтузиастами" можно использовать готовый известный язык Lua. Который можно напичкать функциями — кусками кода основной программы, вызываемыми из Lua. Будет как раз встраиваемое решение во внешние программы, чем так гордятся многие разработчики собственных компиляторов, в том числе я. По крайней мере, сам язык не придётся писать, а только необходимые функции.Разработчики игр, например, явно не дураки, не пишут свои языки, а используют готовые. Не знаю, правда, возможна ли в этом случае компиляция в EXE, но других минусов не вижу. Lua.dll распространяется по нормальной BSD-лицензии, а не какой-нибудь GPL, поэтому библиотеку можно встраивать в свои компиляторы, не раскрывая исходный код. ✅ 2024/03/27 13:40, Автор сайта #160 Разработчики игр, например, явно не дураки, не пишут свои языки, а используют готовые. Можно сказать, что это разные если не профессии, то специализации. Требует разных знаний и навыков. Но знаю одно исключение: один из читателей и комментаторов этого сайта раньше разрабатывал игры, а теперь учится в аспирантуре и разрабатывает свой язык. Не буду показывать пальцем. 🤣В AutoCAD применяют AutoLISP. Проторенная дорожка. Lua нашёл применение в наших импортозамещающих офисных пакетах вместо VBA. Хотя жаль, но не отечественный язык. ✅ 2024/03/27 18:44, MihalNik #161 Если сейчас такого нет, это не значит что это будет всегда. Всё может поменяться. Именно. Поменялось. ЭВМ почти не было, ЯВУ не было и опыта программирования на них не было. Языки программирования разрабатывали на бумаге. Вы можете зачеркнуть кусок БНФ и дописать кусок в конце — БНФ не сломается.Поэтому для бумаги это отличный формат. Да, это не вся необходимая информация. Да, синтаксис и прочее получается разбросанным как попало, а вовсе не как тут писали, что, мол, "всё в одном месте". Но переписывать БНФ прям целиком прям каждый раз не нужно. Ещё догадались вырезать из бумаги/картона кусочки и складывать/прикреплять к чему-то, но это занимает большое рабочее пространство. Как ползали по полу и кого "поставили на колени" можете прочитать в мемуарах. Да, были языки, сделанные на коленках в прямом смысле этого слова. Сейчас же у всех суперЭВМ с отличными клавиатурами, мониторами, текстовые редакторы, работающие мгновенно и, наконец, 100500 работающих языков программирования. Но можно по-прежнему неосознанно имитировать физические ограничения работы с бумагой. Примерно как с неэффективной раскладкой клавиатуры, по-прежнему рассчитанной на имитацию зажатий давно несуществующих шестеренок) С таким же успехом можно симитировать разработку какой-нибудь Ады: а давайте сейчас тоже напишем БНФ, издадим учебники к несущствующему языку программирования... Подумаешь, ну, займет это несколько лет. ✅ 2024/03/27 19:06, Ильдар #162 Недостатки синтаксического анализа методом рекурсивного спуска:
✅ 2024/03/27 22:48, MihalNik #163 Это одно из преимуществ табличных методов разбора, которые применяются в средствах типа Yacc. Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. И табличку вполне cгенерируют вместо цепочки последовательных сравнений одной и той же переменной, хеш-функцию подберут, даже могут строку в оператор выбора. Так или иначе в языках есть соответствующие возможности. Потому что парсеров всяких пишется на них куча. Именно на них.Как минимум странно создавать высокоуровневый язык, который этого не умеет и при этом на выходе также не делегирует задачу умеющему это делать языку. Опять же, используя не умеющий этого делать язык. ✅ 2024/03/28 13:26, Ivan #164 Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. Как минимум странно создавать высокоуровневый язык, который этого не умеет Да, мы — разработчики-энтузиасты, люди вообще странные. Для примера — GAZ — очень высокоуровневый язык (куда уж ещё более высокоуровневый), но этого не умеет.✅ 2024/03/28 15:50, MihalNik #165 Наоборот, странно было бы писать на интерпретируемом языке алгоритмы оптимизации.Да, мы — разработчики-энтузиасты, люди вообще странные. Для примера — GAZ — очень высокоуровневый язык (куда уж ещё более высокоуровневый), но этого не умеет. Ну, как видите, есть куда. Только у Вашего языка своя определенная специализация. Прошло много лет с момента его создания, отслеживать развитие множества других технологий, поддерживая основной продукт, не являющийся собственно самим ЯП, просто выглядит нереально. Для сравнения — в какой-нибудь С++ завозят достижения даже не одного десятка лет свежести.В Питоне, например, оператор выбора по строкам работает. И даже у некоторых из перечня энтузиастов. Но какая там может быть оптимизация при интерпретации понятия не имею. Однако, разработчикам компиляторов Питона с этим уже приходится что-то делать. ✅ 2024/03/28 21:36, Ivan #166 У меня не интерпретируемый, а компилируемый ЯП. Просто компилируется в код VM, а не x86. Интерпретируемые языки я видел. Например, AutoIt, как мне кажется, компилирует "по ходу" а не полностью перед выполнением, т. к. во время работы скрипта в рантайме могут быть странные вылеты из-за синтаксических ошибок.✅ 2024/03/29 14:26, Советский #167 Просто компилируется в код VM, а не x86. Можно попробовать JIT-компиляцию для увеличения скорости.✅ 2024/03/29 14:49, Ivan #168 Можно попробовать JIT-компиляцию для увеличения скорости. На таком языке, где каждая переменная — это динамический массив с длиной 1 динамического типа (integer|float|string), боюсь, что JIT-компиляцию в принципе не сделать.✅ 2024/03/29 15:42, Советский #169 ... что JIT-компиляцию в принципе не сделать. Мне кажется, что вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Всё, что интерпретируется, может быть откомпилировано.✅ 2024/03/30 01:22, Ivan #170 Мне кажется вы ставите себе много барьеров, куда не стоит идти. .NET так работает. Все что интерпретируется может быть откомпилировано. Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Отдельная структура под исполняемый код и отдельная под переменные. И регистров у виртуальной машины пара десятков. Хорошо поговнокодил в своё время в попытках добиться стабильной работы компилятора (главным образом, реализация try-except-end потребовала много инструкций), очень много лишних инструкций. По правде говоря, стабильности работы добиться удалось.Если всё это переводить на JIT — фактически придётся всё переписывать с нуля. И займёт по времени это раз в 10 больше, чем написать с нуля ещё пару компиляторов как у меня. И точно также будет не востребовано, ровным счётом ничего не изменится. Не говоря про то, что писать это всё придётся 10 лет и уже в процессе написания это всё устареет. Как я понял, JIT — это вообще серьёзная штук а, довольно мало для каких языков она в принципе существует, только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT. Если реально хочется использовать JIT и встраиваемый язык — как я выяснил, проще использовать готовый язык Lua, добавив в него свои процедуры и функции, которых там не хватает. И я думаю, это правило можно применить ко многим языкам, которые в списке. Сам так бы и сделал, если бы вернулся в 2009 год. ✅ 2024/03/30 23:45, Автор сайта #171 Современные ЯП это уже сразу умеют — оптимизировать операторы логические, условных ветвлений и выбора, хешировать строки. Шла речь об оптимизации методов разбора для создаваемых компиляторов.Просто компилируется в код VM, а не x86. А если в код JVM или MSIL?Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Как так? Вроде бы писали по заветам С.З.Свердлова.Если всё это переводить на JIT — фактически придётся всё переписывать с нуля. Если компиляция разбита на фазы, то так не должно быть, по идее.писать это всё придётся 10 лет и уже в процессе написания это всё устареет. Если Ваш язык не содержит новых идей, то он устарел до написания.только крупные организации вроде Sun(Oracle)/Microsoft могут себе позволить разработку JIT. Д.Ю.Караваев много лет в одиночку пишет компилятор PL/1 под x86. Не JIT, конечно, но по скорости программы почти не уступают MS C++.✅ 2024/03/31 20:34, Ivan #172 Вы не знаете, из какого говнокода у меня состоит VM. Там одних стеков штук 6. Как так? Вроде бы писали по заветам С.З.Свердлова. Свердлов не учил писать Continue и Break для циклов. А также try-except-end. А именно это потребовало добавления дополнительных стеков и регистров. Без добавления нескольких стеков пришлось бы активно копаться в едином, активно применяя команды drop, swap, over и т. д., что ещё больше бы увеличило объём говнокода и замедлило скорость.В целом штука получилась стабильно работающая. Но сейчас что-то добавлять туда (в плане расширения синтаксиса) кроме доп. функций — увольте, неохота больше в этом говне копаться. Да и от стабильности работы этого языка у меня можно сказать, жизнь сейчас зависит, т.к. язык встраиваемый в мой коммерческий продукт. Но тут надо отдать должное Свердлову: благодаря его заветам компилятор-таки дописан до конца. А без его заветов я бы скатился в говнокод куда сильнее и куда раньше, утонул бы в сложности и забросил компилятор, так и не написав. Если Ваш язык не содержит новых идей, то он устарел до написания. Может быть. Но если вместо добавления новых идей (например, добавлял было 2-мерные массивы и OLE) потратить время на JIT, то он устареет ещё быстрее. Новые идеи так-то были — замена стандартных BAT-файлов Windows. Простым языком. Язык существенно проще аналогов, а перед BAT имеет только один минус, что не встраиваемый. Ну я даже попробовал его "встроить" ещё в процессе написания — он инсталлируется в папку c:\windows\entry, а не в какие-нибудь "Program Files".А если в код JVM или MSIL? Честно говоря, такой же тёмный лес, как и x86. В JVM вообще смысла нет, т. к. язык потеряет одно из преимуществ — встраиваемость. И компилируемость в EXE.Если компиляция разбита на фазы, то так не должно быть, по идее. Может и можно сделать возможность ассемблерных вставок или вставок на языке С++/Delphi. Даже всерьёз думал об этом, причём в 2020 году. Но так руки и не дошли. Идея куда более простой кажется, чем полноценный JIT. Но толку от этого JIT всё равно особо не будет. На GAZ серьёзные программы и игры писать всё равно не получится, это изначально скриптовый язык. А для скриптов скорости хватает за глаза.✅ 2024/04/01 00:51, Автор сайта #173 активно применяя команды drop, swap, over и т. д. Языку Форт хватает двух стеков. Но рассуждать, не зная причин Ваших решений, конечно легко, а вот с чем боролись на практике — трудно представить.неохота больше в этом говне копаться... я бы скатился в говнокод куда сильнее и куда раньше Вы так рекламируете своё детище, прямо диву даёшься.замена стандартных BAT-файлов Windows... перед BAT имеет только один минус, что не встраиваемый. Не знаю, какие задачи Вы ставили перед собой. Но доводилось обеспечивать взаимодействие своих программ как с «*.bat», так и с «*.exe» и «*.com». В Си есть функцияspawnl, которая обеспечивает вызов файлов перечисленных выше типов. Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу. Но это решаемый вопрос. Такие же вызовы делал из Форта (слово RUN) и Клиппера (функция RUN).✅ 2024/04/01 11:30, Ivan #174 Вы так рекламируете своё детище, прямо диву даёшься Сам компилятор работает стабильно и проверен лично мной на сроке использования более 10 лет, сейчас сам его активно использую, этого достаточно. Не все энтузиасты могут это сказать о своих компиляторах, некоторые проекты создавались изначально как нечто амбициозное, а потом загнулись, как я понимаю, утонув в своей сложности и глюках. Не верю я, чтобы какой-либо разработчик забросил свой компилятор, если он в целом работающий и отлаженный.Но внутренний код генерации команд для виртуальной машины такой, что заново не захочется туда лезть и что-то там править, чтобы ничего не сломать. Тем более через 12 лет после написания этого кода. И почему-то думаю, не у меня одного так, тут у многих людей в списке гораздо более сложные компиляторы написаны. Соответственно и потенциальных глюков там может быть больше. Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only. К добавлению новых команд в виртуальную машину это, конечно, не относится. Но в большинстве случаев вместо добавления новых команд в виртуальную машину пишу модули на своём же языке. Правда, приходится иногда добавлять и команды в VM, как это случилось, например, с Base64Encode в 2019 году (сначала написал на своём языке, но потом производительность не понравилась для больших строк — например, размером в 100 Кб). ✅ 2024/04/01 12:38, Ivan #175 Не знаю, какие задачи Вы ставили перед собой. Язык изначально создавался как командный интерпретатор для запуска программ, копирования, переименования файлов и т. д. Очень уж мне не понравился в этом плане BAT, захотелось что-то получше. Команды для работы со строками, числами, try-except и прочее, что сделало язык полноценным, было добавлено уже потом, в процессе.На 99% возможностей для скриптов хватает, благо прошло уже более 10 лет, особо ничего дорабатывать не приходится. Если надо что доработать — процедуры легко пишутся на самом языке. Очень редко что-то приходится добавлять именно в VM — как правило, в основном случае нехватки производительности. Синтаксис же языка и генерация кода вообще не меняется, да и попробуй поменяй, свои же скрипты, накопленные за годы могут перестать работать или начать глючить. Да, надо обеспечивать как-то передачу информации из вызываемой в вызывающую программу Как правило, через командную строку, через параметры запуска. А вывод результата — либо также, в командную строку, либо в файл, который задаётся в параметрах запуска вызываемой программы, потом выполняется RunWait. Таким образом интегрируются почти все языки между собой, даже 1С. Но способ, конечно, не лучший и не самый удобный.У меня, например, многопоточность поддерживается тоже с обменом данными через файлы. Хочется временами сделать возможность взаимодействия с DLL, возможность подключения внешних DLL, это более реально, чем заморачиваться с JIT, для этого не придётся лезть в сам язык, в генератор кода и т. д., а просто придётся добавить новые методы в VM. Но всё руки не доходят. ✅ 2024/04/02 00:09, Автор сайта #176 Не верю я, чтобы какой-либо разработчик забросил свой компилятор, если он в целом работающий и отлаженный. Да запросто. Поинтересуйтесь языком Глагол. Автор языка написал компилятор и исчез. Но им продолжают пользоваться. И даже есть сайты пользователей языка, посвящённые Глаголу.на Ассемблере программы изначально write-only. Не скажите. У опытного программиста даже ассемблерные программы хорошо читаются.✅ 2024/04/02 00:40, Max Vetrov #177 Этот код похож на Ассемблер, только для виртуальной машины, а на Ассемблере программы изначально write-only. Почему write-only?
Синтаксис же языка и генерация кода вообще не меняется, да и попробуй поменяй, свои же скрипты, накопленные за годы могут перестать работать или начать глючить. Энтузиазм пропал. Напишите новый язык (с учетом вашего опыта код, возможно, будет лучше) или используйте готовый и сделайте миграцию.✅ 2024/04/03 13:33, Ivan #178 Можно и читать, комментарии же есть, нормальные имена модулей, функций. В принципе, у меня примерно также. Может и не говнокод такое называется. Но тем не менее, желания туда лезть (в код подобного рода) и что-то там менять особо не возникает.✅ 2024/04/03 17:24, Max Vetrov #179 Но тем не менее, желания туда лезть (в код подобного рода) и что-то там менять особо не возникает. Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть.✅ 2024/04/03 18:32, Ivan #180 Так и не нужно туда лезть каждый раз. Имеет смысл туда лезть если нужно что-то исправить или улучшить (ускорить). Главное чтоб модульность была, интерфейс, чтобы можно было легко найти проблемы если они есть. Ускорить там что-то практически нереально без потенциального добавления багов. В случае проблем — да, относительно легко всё находится и исправляется, модульность есть.Исправлял небольшие проблемы, было дело в 2016, 2017 и 2020. Возможно и сейчас что-то есть, чего я не знаю, но на компиляторе для себя написано уже более 200 тысяч строк кода. Как правило, проблемы исправляются за счёт дополнительной генерации кода для виртуальной машины. Хотя, зная глюки, можно было их просто обходить, а не исправлять, но предпочитаю исправлять. ✅ 2024/04/03 20:06, Max Vetrov #181 Медленно работает именно сам байт-код. ... Хотя, конечно, хотелось бы и побыстрее, но тут генерацию самого байт-кода надо делать более эффективной и виртуальную машину оптимизировать (а это неизбежно приведёт к багам, которые надо будет устранять и т. д.) но на компиляторе для себя написано уже более 200 тысяч строк кода. Вы боитесь изменений в виртуальной машине, так как это может повлиять на выполнение старого кода. А почему бы просто не написать другую версию виртуальной машины? Старый код будет работать на старой версии, новый код — на новой версии виртуальной машины. И всё работает стабильно. Старый код будет постепенно отмирать. Что в итоге вы хотите получить?✅ 2024/04/04 10:31, Ivan #182 Собственно, никакой проблемы особо нет. Я сделал компилятор, теперь пользуюсь, кайфую :)Почему не удаётся особо править VM и генератор кода — в первую очередь потому, что у меня код компилятора, можно сказать, в 2-х экземплярах. Один в качестве отдельного, автономного компилятора (а также GAZ.dll), другой встроен в программу Client Shop. И доработав что-то в одном месте, по идее эти же изменения нужно вносить и в другое место. Всё осложняется тем, что после встраивания компилятора в программу Client Shop были времена, что нарушал это правило: внеся доработки в автономную версию компилятора, не вносил в программу и наоборот. Поэтому программный код этих 2-х компиляторов разошёлся, хоть и совпадает на 95%. Да, пробовал выравнивать код с помощью WinMerge и т. д., но всё равно полностью не выравнивается и код немного отличается. Ещё выравнивание отсложнено тем, что в сборке для программы в компилятор добавлено множество характерных именно для программы функций. А в автономной сборке есть функции, которых нет в программе. Некоторые методы (по правде, их немного, всего 1%), доработанны в 1 месте, но не доработанны в другом. Отличаются количеством параметров, например. Реализация InputString отличается в автономном компиляторе и в программе, хотя функциональность одинакова.По этой причине собственно, добавление новых функций сразу в 2 места всегда пожалуйста, а любые правки кодогенератора или VM сильно осложнены. И никакие системы контроля версий не помогают удобным способом править код сразу в 2-х местах. ✅ 2024/04/04 13:02, Max Vetrov #183 Собственно, никакой проблемы особо нет. Я сделал компилятор, теперь пользуюсь, кайфую :) Что-то не похоже :)Да, пробовал выравнивать код с помощью WinMerge и т. д., но всё равно полностью не выравнивается и код немного отличается. Ещё выравнивание отсложнено тем, что в сборке для программы в компилятор добавлено множество характерных именно для программы функций. А в автономной сборке есть функции, которых нет в программе. Некоторые методы (по правде, их немного, всего 1%), доработанны в 1 месте, но не доработанны в другом. Отличаются количеством параметров, например. Реализация InputString отличается в автономном компиляторе и в программе, хотя функциональность одинакова. Я так понимаю автономная версия использовалась для разработки. Текущую автономную версию — в архив, зачем бороться за этот 1%? От основной версии создаете новую ветку для разработки.По этой причине собственно, добавление новых функций сразу в 2 места всегда пожалуйста, а любые правки кодогенератора или VM сильно осложнены. И никакие системы контроля версий не помогают удобным способом править код сразу в 2-х местах. Ну не знаю, системы контроля версий помогают.https://nvie.com/posts/a-successful-git-branching-model/ https://tleyden.github.io/blog/2014/04/09/a-successful-git-branching-model-with-enterprise-support/ ✅ 2024/04/12 19:41, Бурановский дедушка #184 Читаю вот такой пассаж одного товарища из списка выше:Развитие Русского Языка Программирования мне уже не интересно, так как я стал (и уже был) космополитом. Прекратить развивать русский язык программирования, чтобы не рос российский ВПК, но при этом позволить развиваться остальным языкам, чтобы росли остальные ВПК — это, конечно, тоже позиция. А может это и не позиция вовсе, а поза? Поза страуса, например. ✅ 2024/04/12 22:13, Вежливый Лис #185 У автора того мнения о ненужности РЯП дрейф мотивации, и дефекты в логике. У Бурановского Дедушки дефекты в логике тоже есть и мотивации тоже нехватает. Это жизнь.✅ 2024/04/13 11:03, Автор сайта #186 Всё-таки лучше критиковать научные и технические аспекты, а не людей. И придерживаться тематики сайта.✅ 2024/04/16 17:55, Ivan #187 Я так понимаю автономная версия использовалась для разработки. Текущую автономную версию — в архив, зачем бороться за этот 1%? От основной версии создаете новую ветку для разработки. Проект стабильный. Нет смысла уже в нём что-то глобально исправлять на данной стадии, оно того не стоит и не окупится. Нестандартный велосипед, на котором захочет ездить человек может 50 так и останется нестандартным велосипедом, что там ни меняй.Есть ли смысл самому использовать как инструмент и встраивать в свои продукты, иногда добавляя немного новых встроенных функций — пожалуй, отвечу "да". Выжимать прибыль и удобства из уже сделанного определённо стоит. По крайней мере на данном этапе. Но лучше стремиться использовать какие-то более стандартные решения — тот же Lua, например. Писать с нуля что-то подобное точно не стоит, лучше изучать что-то типа 1С/С++ или хотя бы Python и зарабатывать по 150 тысяч в месяц, чем бултыхаться в своём болоте с самописными компиляторами. Впрочем, если это приятно, доставляет удовольствие и приносит какие-то деньги — почему бы и нет ... ✅ 2024/04/18 00:21, Ильдар #188 если это приятно, доставляет удовольствие и приносит какие-то деньги Кому-то это приятно и без денег :)✅ 2024/04/18 11:14, Ivan #189 Кому-то это приятно и без денег :) Безусловно приятно — иначе бы не было столько проектов от энтузиастов, половина из которых, наверняка, вообще ничего от своих проектов не получили. И вообще приятно применять и использовать полученные знания — в моём случае знания, полученные от Сергея Свердлова. В моём случае хотя бы получилось применять и использовать.Но факты упрямы. Жизнь такая, что нужны деньги — платить за свет, газ, ипотеку, хочется куда-то съездить, особенно пока молодой, потом будет поздно. В какой-то момент я понял, что просто просираю время и жизнь и надо остановиться. Да, компилятор по сути написан по большей части в рабочее время, работа была не бей лежачего. Но с другой стороны и платили там соответствующим образом. Пока я там сидел и балдел за 20 тысяч в месяц и писал компилятор, мои однокурсники уже по 40-60 тысяч зарабатывали (да, это были приличные суммы, скажем, в 2010 году), накупили квартир, машин, поездили по разным странам. Сейчас же мне гораздо более приятно, что я работаю удалённо, а не сижу в офисе 9/5 (с перерывом на обед). Ну и то, что компилятор уже написан и не лежит бесполезно, а его можно использовать — хоть немного, но всё равно греет душу. ✅ 2024/04/20 10:34, Ivan #190 Кстати, без шуток. Увлёкся я тут в последний месяц этими всякими Lua, Python и прочим. Казалось бы, простейшую задачу нужно решить, но не получается:
Может, кто подскажет стандартные решения: как можно выполнить задачу, описанную выше, не прибегая к использованию языков "энтузиастов" или к самописным решениям? ✅ 2024/04/21 00:03, Автор сайта #191 Я уже говорил, как бы сделал я. Наверняка в Делфи есть подобное. Я бы ещё подумал использовать Си в качестве скриптового языка: компилятор TinyСС настолько быстр, что пауза на компиляцию почти незаметна. Был прецедент такого использования: кто-то из «наших» израильтян использовал его вместо скриптов на PHP. Вариантов, на самом деле, немало. Но всё равно окончательный выбор только за Вами.Вы писали, что язык и компилятор появились из-за того, что работа была не бей лежачего. А сейчас этот компилятор не является тем якорем, который держит Вас на текущей работе? ✅ 2024/04/21 00:48, Ivan #192 Я уже говорил, как бы сделал я. Наверняка в Делфи есть подобное. Я бы ещё подумал использовать Си в качестве скриптового языка: компилятор TinyСС настолько быстр, что пауза на компиляцию почти незаметна. Был прецедент такого использования: кто-то из «наших» израильтян использовал его вместо скриптов на PHP. Вариантов, на самом деле, немало. Но всё равно окончательный выбор только за Вами. У моего компилятора есть преимущество. Можно на нём писать скрипты и модули и почти без изменений потом встраивать в основную программу, при этом функционала для моих задач достаточно. В этом плане — как я полагаю, сходство с Python — только встраивается проще и поддерживает все операционные системы Windows и все версии Delphi. Lua слишком малофункционален и отдельно как скриптовый язык его использовать сложно. С++ слишком сложный и перегруженный. Нашёл ещё какой-то PascalScript — вроде функциональный язык для встраивания, надо разбираться. Можно бы использовать AutoIt, на который я во многом равнялся, но у него тоже есть минусы. А сейчас этот компилятор не является тем якорем, который держит Вас на текущей работе? Думаю, нет. Я уже не на той работе. И если что и держит на текущей работе — то что-то другое.✅ 2024/04/22 21:56, Ильдар #193 на компиляторе для себя написано уже более 200 тысяч строк кода. Ну и зачем тогда париться? Язык самому нравится, компилятор вылизан (протестирован аж на 200 000 строк кода), чего ещё надо? Зачем PascalScript? Первая заповедь инженера: если работает — не трожь.✅ 2024/04/23 15:57, Ivan #194 Просто интересно — какие ещё есть варианты внедрения компилятора кроме моего в Delphi-софт. Нет, не для отказа от своего решения. Скорее чтобы параллельно добавить в софт возможность выполнения скриптов ещё на одном языке. Возможности которого, возможно, больше, чем в моём варианте. Например, возможность менять свойства VCL в Runtime, если включен RTL и т. д.А то мне кажется, что я себя ограничиваю в чём-то своим компилятором. Не потому что его использую. А потому, что используя только его, упускаю некоторые возможности, которые могут быть в других, стандартных решениях. Хотя в случае с Delphi (в отличие от С++) нормальных встроенных решений, как я понял, в принципе, немного. ✅ 2024/04/25 21:05, Ttimofeyka #195 К слову, для меня до сих пор сложной частью является совместимость с cdecl64. Обычно мало кто говорит об этой проблеме, но соглашение о вызовах C для структур работает крайне неоднозначно — важен не только размер структуры, но и порядок размещения типов внутри её (протестировано с помощью godbolt на компиляторах C/C++, clang).✅ 2024/04/28 14:50, Автор сайта #196 Пополнил список языков безымянным языком программирования. Интересно, какие задачи помогает решать отсутствие названия у языка?Решился на пополнение списка диалектом Си от Андрея Николаевича Терехова — РуСи. Его отличает от оригинального Си как ограничения, так и расширения. Язык предназначен как для обучения студентов, так и для разработки высоконадежного ПО. ✅ 2024/05/02 18:24, Ильдар #197 РуСи... для разработки высоконадежного ПО. Неужели в нём запретили void* и приведение типов (void*)?✅ 2024/05/03 22:19, Ivan #198 C++ — мой нелюбимый язык. За его сложность и плохую читаемость. Хуже него только Perl — там всего в 10 строчках можно такое написать, что без бутылки не разберёшься. Слава Вирту, что придумал Паскаль.✅ 2024/05/03 22:29, Прохожий #199 Паскаль в утиль.Слава Вирту Не сотвори себе кумира!✅ 2024/05/03 22:38, Ivan #200 Паскаль в утиль. Не могу так сказать. Т. к. учился на Турбо-Паскале с 2001 по 2006. Потом перешёл на Delphi в 2006-м и по 2024-й на нём и сижу. 23 года стажа на языке Паскаль! Ненамного меньше, чем стаж езды на велосипеде.Это хороший, продуманный и понятный язык. Непонятно только, почему вакансий на Delphi так мало и эти вакансии не сказать, что хорошие. ✅ 2024/05/04 00:59, Автор сайта #201 Не сотвори себе кумира! Да, выше на эту тему уже высказывались:Когда же назовут какой-нибудь язык в честь Это хороший, продуманный и понятный язык. Языку более полувека. За это время многое придумано, что помогает разработке. Тольяттинской «копейке» тоже более полувека. Её несовременность вроде бы всем очевидна. А вот несовременность Паскаля (да и Си тоже) почему-то очевидна не всем. Как, к примеру, из Паскалевской функции вернуть результат, если всё пошло по плану, а если пошло не по плану, то как-то передать информацию об этом в вызывавшую функцию? Да так, чтобы было невозможно обратиться к результату, если вычисления пошли не по плану. Если быть короче, то как в Паскале выполнить обработку особых ситуаций, аналогичных монадам Maybe и Either в Haskell? И таких примеров несовременности немало.✅ 2024/05/04 01:08, Паскалюб #202 Паскаль для аристократов, плебеям здесь не место. Только ценители осознают красоту Паскаля.✅ 2024/05/04 10:22, Прохожий #203 Тольяттинской «копейке» тоже более полувека. Её несовременность вроде бы всем очевидна. Людей держит не функциональность, а что-то другое. Эмоции(связь со своей старой жизнью), инерция(нежелание что-то менять), лень.✅ 2024/05/06 11:29, Ivan #204 Как, к примеру, из Паскалевской функции вернуть результат, если всё пошло по плану, а если пошло не по плану, то как-то передать информацию об этом в вызывавшую функцию? raise Exception.Create — подойдёт?Кстати те, кто много лет работал на Delphi — часто и на C++ пишут в таком же стиле, как на Паскале, не используя возможности С++ в полной мере. И просто считая Си испорченным Паскалем. Людей держит не функциональность, а что-то другое. Миграция с Delphi 7 на Delphi XE8 и то была геморроем и заняла месяц почти + исправление багов ещё около года. А миграция совсем на другой язык это значит переписать всё с нуля. Поэтому нет особого смысла. Вот если писать что-то новое — стоит ли использовать Delphi — тут уже вопрос. Если и использовать, то не версию 7, а какой-нибудь XE10, скорее всего. А вообще альтернатив Delphi не видно — чтобы была быстрая компиляция и быстрое получение EXE. Чтобы не требовалось устанавливать разные .NET или Java (которая, кстати, тоже имеет уязвимости и баги), про Си++ вообще молчу. Чтобы программа работала на любых ОС начиная с Windows XP. Непонятно только при этом — почему у Delphi такая низкая популярность. ✅ 2024/05/06 16:10, Автор сайта #205 raise Exception.Create — подойдёт? Нет, не пойдёт. Вот что пишут про Delphi:не смотря на то, что существует возможность создавать исключения практически в любой ситуации, защищая любой блок исходного кода заключением его в структуру try...except или try...finally, на практике эти инструменты лучше применять только в особых случаях. Видите, это не повседневный инструмент.Инструкции условных переходов зачастую являются лучшим способом обработки ошибок. Например, если перед тем как открыть файл, вы хотите убедиться, что файл существует, можно сделать это следующим образом: try Но для экономии ресурсов можно использовать и другой способ: if FileExists(FileName) then // возвращает False если файл не найденНо есть третий способ, который берёт лучшее от двух перечисленных, я приводил в пример монады Maybe и Either в Haskell. Он сочетает как обязательность проверки, которая присуща обработке исключений, так и легковесность обычных условных выражений. Это как раз и отличает современные языки от устаревших. если у меня написано 550 000 строк кода — мне что, на другом языке это всё переписывать? Можно сделать, чтобы Ваш компилятор генерировал не байт-код, а код на другом языке программирования.Я понимаю, что новые языки волшебно-крутые по сравнению с Delphi — но они при этом не поймут даже 10% кода, написанного на Delphi несмотря на их крутость. Кто они, которые не поймут? Новые волшебно-крутые языки? Ну так их компиляторы понимают свои тексты, на не Объектного Паскаля.А вообще альтернатив Delphi не видно — чтобы ... программа работала на любых ОС начиная с Windows XP. И заканчивая KasperskyOS?Непонятно только при этом — почему у Delphi такая низкая популярность. Не пробовали найти тех, кто перешёл с Delphi на что-то другое, чтобы стаж разработки на чём-то другом был не меньше предыдущего опыта?✅ 2024/05/06 21:33, Прохожий #206 Вот как интересно. А если у меня написано 550 000 строк кода — мне что, на другом языке это всё переписывать? Я понимаю, что новые языки волшебно-крутые по сравнению с Delphi — но они при этом не поймут даже 10% кода, написанного на Delphi несмотря на их крутость. Поймут если будет подходящий интерфейс. Можно же вызывать код, написанный на других языках.Миграция с Delphi 7 на Delphi XE8 и то была геморроем и ... Может, поэтому у Delphi проблемы. Может также проблема, что Delphi занимается только одна контора.Вот если писать что-то новое — стоит ли использовать Delphi — тут уже вопрос. Если и использовать, то не версию 7, а какой-нибудь XE10, скорее всего. Задаетесь вопросом — стоит ли использовать Delphi для нового и сразу же отвечаете, что нужно использовать версию Delphi не X, а Y. Немного странно.А вообще альтернатив Delphi не видно — чтобы была быстрая компиляция и быстрое получение EXE. Если безопасность отключить, то ещё быстрее будет. Это просто привычка. Кроме Delphi сколько вы языков ещё знаете?Чтобы не требовалось устанавливать разные .NET или Java (которая, кстати, тоже имеет уязвимости и баги), про Си++ вообще молчу. Чтобы программа работала на любых ОС начиная с Windows XP. А какие могут быть проблемы с ними? Что-то я не понимаю? Просто холивар.Непонятно только при этом — почему у Delphi такая низкая популярность. Потому что есть другие альтернативы. Кому как удобнее, тот так и пишет. Мне как бы все равно, что вы любите Delphi, нравится — пишите. Зачем вам других обращать в свою веру?Я в своё время в институте столкнулся с Паскалем. Но он мне не зашел — переменные надо писать в определенном месте, а не в месте использования, begin-end — вместо простых скобок. В общем это всё вкусовщина и холивар. Пишите на том, на чём удобно, главное чтобы сам язык хорошо поддерживался, появлялись новые библиотеки. Вот если задаться вопросом: зачем новые языки? Что вы ответите на него? Ведь кода на новом языке всегда написано меньше, чем на старых. Может, они создаются потому, что они устраняют какие-то фундаментальные проблемы старых языков и нет груза написанного кода. ✅ 2024/05/07 13:02, Ivan #207 Можно сделать, чтобы Ваш компилятор генерировал не байт-код, а код на другом языке программирования. Смысла в таком компиляторе в случае моего языка не вижу. Уж лучше тогда сразу писать программы под этот другой язык программирования, зачем лишнее звено.Не пробовали найти тех, кто перешёл с Delphi на что-то другое, чтобы стаж разработки на чём-то другом был не меньше предыдущего опыта? Не пробовалЕсли безопасность отключить, то ещё быстрее будет. Это просто привычка. Кроме Delphi сколько вы языков ещё знаете? Насколько знаю? Знаком с PHP, JavaScript, CSS, Node, C++, Java, AutoIt, BAT, SQL — писал небольшие программы на этих языках.А какие могут быть проблемы с ними? Что-то я не понимаю? Просто холивар. То, что не у всех пользователей .NET и Java установлены. И нужно либо встраивать это в общий инсталлятор. Либо терять часть клиетов.Вот если задаться вопросом: зачем новые языки? Что вы ответите на него? Ведь кода на новом языке всегда написано меньше, чем на старых. Может, они создаются потому, что они устраняют какие-то фундаментальные проблемы старых языков и нет груза написанного кода. Когда ещё программировал на Турбо Паскале, хотел написать Паскаль на Паскале. Просто так, чтобы почувствовать себя крутым. Потом с сожалением выяснил, что многие этого хотят, а работа по написанию компиляторов вообще практически не оплачивается.Не обязательно при создании своего языка и компилятора чтобы он был чем-то лучше других. Одно из важных преимуществ в том, что он свой. Можно сделать, чтобы Ваш компилятор генерировал не байт-код, а код на другом языке программирования. Сергей Залманович — кстати, сделал язык Оберон и компилятор, транслирующий код в Java. Но я так и не понял, зачем мне использовать его Оберон если можно сразу писать на Java. Всё равно без установки Java его Оберон работать не будет. Получается фактически та же Java, только с меньшим функционалом, ограниченным возможностями Оберон. И код, скорее всего, будет работать медленнее, чем если писать непосредственно на Java.Если быть короче, то как в Паскале выполнить обработку особых ситуаций, аналогичных монадам Maybe и Either в Haskell? Почему именно Delphi с Haskell сравниваем? У тех же Java и .NET тоже популярность выше, чем у Delphi. А преимущества их не очевидны.✅ 2024/05/07 20:11, Ильдар #208 Задал вопрос YandexGPT:Почему среда программирования Delphi перестала пользоваться популярностью? Ответ такой:Среда программирования Delphi перестала пользоваться популярностью из-за смещения акцентов в сторону мобильной разработки и веб-разработки, отсутствия значительных изменений в процессе разработки и высокой стоимости продукта. Если же набрать этот вопрос в обычном поиске, то выдаётся много чего поучительного. Было бы желание разобраться.✅ 2024/05/07 23:08, Автор сайта #209 Смысла в таком компиляторе в случае моего языка не вижу. Уж лучше тогда сразу писать программы под этот другой язык программирования, зачем лишнее звено. Если Вы однажды решили, что надо переходить на новый язык программирования, например Rust или любой другой, то у Вас возникнет вопрос: а как перенести эти 550 000 строк кода на новый язык? Переписать, что ли? Да не обязательно. Просто надо научить Ваш компилятор генерировать не байт-код, а код на Rust. Один раз перенесли 550 000 строк, а дальше просто продолжаете пополнять свои наработки уже на новом языке.Не обязательно при создании своего языка и компилятора чтобы он был чем-то лучше других. Одно из важных преимуществ в том, что он свой. У Герберта Шилдта как-то прочитал рассуждение в таком духе: «Если Вам не нравятся существующие языки программирования — напишите свой! Современное состояние инструментов для написания компиляторов позволяет это сделать сравнительно легко и быстро».Почему именно Delphi с Haskell сравниваем? У тех же Java и .NET тоже популярность выше, чем у Delphi. Знакомство с другими парадигмами может оказаться очень полезным. Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело.✅ 2024/05/08 06:37, Вежливый Лис #210 Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело. Но топчик почему-то Python...✅ 2024/05/08 12:44, Ivan #211 Просто надо научить Ваш компилятор генерировать не байт-код, а код на Rust. Один раз перенесли 550 000 строк, а дальше просто п7родолжаете пополнять свои наработки уже на новом языке. Не всё так просто. Код в 550 000 строк таким образом не перенести на другой язык. Хотя бы по той причине, что код Delphi-специфичный, аналогичного функционала на Java или .NET может и не быть (хотя могут быть другие возможности). Все эти обработчики событий на Delphi, overread методы, DBGrid и прочее.Насколько я знаю, готовых работающих решений по переносу больших проектов на другой язык, не существует. Знакомство с другими парадигмами может оказаться очень полезным. Delphi и Java и — это одна и та же императивная парадигма. А вот Haskell — совсем другое дело. Неужели код на Haskell, например, пустой цикл, может выполняться миллиард, а не миллион раз, как на Python? Если производительность кода ниже на порядок — то нечего и сравнивать с Delphi — значит, это не для написания больших программ.Но топчик почему-то Python... Это ещё почему? Интерпретатор, а не компилятор, который в разы медленнее Delphi. Потому и сравниваю с Java и .NET, а н с каким-ниюудль Python.✅ 2024/05/08 15:34, Автор сайта #212 Был упомянут Haskell, а не Python не потому, что он лучше или производительнее, а потому что он из совсем другой парадигмы. Задачи решаются другим способом. Знакомство с другими подходами расширяют кругозор, что, в общем-то, желательно для людей, придумывающих новые языки программирования. Однако словаНеужели код на Haskell, например, пустой цикл говорят о незнакомстве с Haskell, в котором нет циклов. Но даже если считать это оговоркой, что имелась в виду рекурсия, с помощью которой в Haskell повторяются вычисления, то всё равно пустая рекурсия невозможна. Хотя бы по причине ленивых вычислений.Если производительность кода ниже на порядок — то нечего и сравнивать с Delphi — значит, это не для написания больших программ. Haskell, по некоторым утверждениям, уступает Си в скорости в 3,5 раза («Функциональное программирование»). Однако на некоторых задачах мне удалось добиться разницы в полторы тысячи раз («C vs Haskell: сравнение скорости на простом примере»). Это говорит о том, что Haskell не универсален и нужно понимать, на каких задачах он может тормозить. Но если программа будет в 3,5 раза медленнее, то это не очень большая цена, учитывая прогресс процессоров. Тем более, что «правильность важнее эффективности», как утверждает Лидия Васильевна Городняя. С чем я на 90% согласен.Насколько я знаю, готовых работающих решений по переносу больших проектов на другой язык, не существует. Существуют. Например GnuCOBOL:Свободный проект GnuCOBOL позволяет транслировать программы на языке COBOL в представление на языке C для последующей компиляции при помощи GCC или других компиляторов C. Весьма востребованное решение:Общий объём написанного на COBOL кода оценивается в сотни млрд строк, из которых более 100 млрд строк до сих пор активно используются, в основном в финансовых учреждениях (по состоянию на 2017 год 43% банковских систем продолжали использовать COBOL, код на COBOL применялся при обработке около 80% персональных финансовых транзакций и в 95% терминалов для приёма платежей по банковским картам). ✅ 2024/05/08 21:04, Ivan #213 Я вообще всегда думал, что Haskell — экзотический язык, на котором пишут проекты на пару тысяч строк и обсуждают в курилке. Но чтобы на нём писали большие, серьёзные программы ...✅ 2024/05/08 22:16, Автор сайта #214 Это далеко не эзотерический язык, не для потехи. В рейтинге Tiobe он на 28 месте. Выше, чем Julia, Perl, Lua, Lisp, Forth, Bash. Наверное, это о чём-то говорит. Здесь описано одно мнение: «Один разработчик на Haskell заменяет пять программистов на JavaScript».✅ 2024/05/08 22:55, Ivan #215 говорят о незнакомстве с Haskell, в котором нет циклов Поэтому нет смысла сравнивать Delphi с Haskell, называя Haskell более современным языком. Haskell — это язык с другой парадигмой, функциональный, а Delphi — императивный. И сравнивать поэтому его надо только с другими императивными языками.✅ 2024/05/09 00:06, Автор сайта #216 Так Вы же задавались вопросом, отчего Delphi теряет популярность. Вам отвечают, что он не шагает в ногу со временем. Тот же Haskell, который предложил что-то новое, поднялся в рейтинге Tiobe за 8 лет на 10 мест. Котлин предложил немало нового, он в этом рейтинге 19-й. Он ещё не догнал Delphi, но, видится, это лишь вопрос времени.✅ 2024/05/09 13:05, Прохожий #217 Интерпретатор, а не компилятор, который в разы медленнее Delphi. Все в этом мире относительно. Существует байт-код Python .✅ 2024/05/11 16:33, Автор сайта #218 Иван, про Delphi пишут. Возможно, Вам будет, что сказать.✅ 2024/09/07 00:29, Иван #219 Обновил страницу (компилятор GAZ). Добавлено — GAZ.dll (3.30) актуальной версии от 26 августа 2024 г. + пример встраивания в Delphi: https://osinavi.ru/gaz/GazDll_3_30.zip✅ 2024/09/29 13:27, Иван #220 Как разработчик компилятора скажу.Как только найдёшь время улучшать и дорабатывать компилятор — остановиться практически невозможно, это можно делать бесконечно. Весь тёплый сентябрь 2024 практически на это ушёл, доход по основной работе даже упал. Надо как-то принудительно себя останавливать, это как алкогольная зависимость. ✅ 2024/09/29 13:52, Автор сайта #221 Понимаю и сочувствую, это увлекательное занятие. Позвольте полюбопытствовать: Вы, Иван, который пишет свой ассемблер, и Ivan (Иван Горчаков), который написал интерпретатор GAZ, — это одно и то же лицо? Загадка :)✅ 2024/09/29 21:14, Иван #222 Понимаю и сочувствую, это увлекательное занятие. Позвольте полюбопытствовать: Вы, Иван, который пишет свой ассемблер, и Ivan (Иван Горчаков), который написал интерпретатор GAZ, — это одно и то же лицо? Загадка :) Да, я Иван Горчаков.Только я не писал свой Ассемблер. Я написал сайт — учебник "Ассемблер для квалифицированных чайников" на 3м курсе — т.к. очень интересовался этой темой. Довольно объёмная работа получилась и даже кому-то помогла, судя по всему. Учебник после этого не обновлялся и не дополнялся, сейчас меня Ассемблер больше не интересует. Никто не знает об этом, но была до этого в 2008 году неудачная попытка написать интерпретатор Config (а там был именно интерпретатор без встроенной VM) — но закончилось всё плохо — в какой-то момент стало понятно, что дорабатывать дальше нет смысла, лучше код выбросить и начать писать новый с нуля, по-нормальному уже как компилятор. Компилятор GAZ начал писать в 2009 году. Фактически GAZ 2024 года — это продолжение наработок версии 2009 года, компилятор каждый год дополняется новыми функциями. Скрипты 2009 года запускаются на версии 2024 года, сохранена обратная совместимость. Работ было много сделано и OLE и перевод на x64, поддержка модулей, ускорение работы в 5 раз и много других функций. Штука оказалась довольно стабильная в отличие от Config, который постоянно глючил. Сейчас дорабатываю в основном по необходимости — когда какой-то функции мне лично не хватает — добавляю её в компилятор и пользуюсь новой версией. Если добавлять по делу и это идёт на пользу работе — как в этом случае то ничего плохого в этом нет. Но иногда сам процесс затягивает — начинаешь делать, притом что даже клиентам и по работе этот функционал не нужен, вот с этим пытаюсь бороться — с доработкой ради доработки. С нуля такое писать сейчас бы точно не стал, да и нереально уже — всё-таки 15 лет работы и уже 126 290 строк кода в проекте. И более 150 000 строк скриптов , написанных на самом компиляторе, который при этом постоянно используется. ✅ 2024/09/29 23:58, Автор сайта #223 сам процесс затягивает Иллюстрация к главной станице сайта — как раз про мастера, который увлёкся созиданием 😇126 290 строк кода в проекте... более 150 000 строк скриптов, написанных на самом компиляторе Вот это да! Вы действительно увлеклись созиданием 🤣✅ 2024/09/30 00:32, Иван #224 По поводу количества строк кода. Изначально в 2009 году было 44 763 — когда всё уже работало и можно было писать работающие скрипты и программы. В 2012 году — после которого практически забил на эту тему (активная доработка компилятора) количество строк кода было 68 777.Сейчас 126 290 строк. Получается, с 2012 по 2024, когда не особо и интересовался этой темой (и уж точно в этот период не стал бы такое писать с нуля) количество написанных строк кода было не меньше, чем за первые 3 года, хотя по количеству строк в год процесс замедлился. Вроде бы тема и не интересует особо, а количество строк кода всё равно постепенно растёт, вода камень точит. Появляются новые потребности, приходится добавлять новый код. Например, в 2019 появилась потребность в Base64Encode. Что делать? Писать на самом языке — пробовал, работает довольно медленно для длинных строк (например, длиной в 1 мегабайт). Остаётся встраивать в сам компилятор, а не во внешние мод ули . Ведь скрипты должны работать быстро если уж использовать язык в практических целях. Но дело тут ещё в том, считать ли количество строк, написанных на самом компиляторе. Оно, по-моему, растёт непрерывно и скорость в этой области не уменьшается практически. Да и хороший компилятор не особо требует, чтобы в него добавляли новый код, суть компилятора как раз в том, чтобы писать на нём, а не добавлять в его исходный код новые строки. ✅ 2024/09/30 00:37, Иван #225 Кстати, по описанию разработчиков-энтузиастов компиляторов заметил интересную вещь, что вообще нет ни одного, реально работающего и при этом написанного какой-нибудь девушкой/женщиной. Хотя женщин, работающих в IT сейчас немало.✅ 2024/10/02 21:00, Автор сайта #226 нет ни одного... написанного какой-нибудь девушкой/женщиной Исправляю эту несправедливость. Лидия Васильевна Городняя разработала учебный язык параллельного программирования Синхро.✅ 2024/10/13 23:35, Иван #227 Кстати, интересный вопрос. Всё-таки, я написал интерпретатор или компилятор. Вы, наверное, в этом лучше разбираетесь и можете сказать точно.Как я думаю, интерпретатор выполняет команды на ходу, по ходу синтаксического анализа кода программы. Компилятор же транслирует всё в машинный код, либо в виртуальную машину. Или трансляция в виртуальную машину не считается и трансляция в виртуальную машину — это интерпретатор? Но в этом случае могу сказать, что мой транслятор позволяет создавать EXE. Да, EXE-файл — это фактически тот же самый файл компилятора/интерпретатора — но с прошитым в него исходным кодом программы на языке этого интерпретатора/компилятора — то есть никакой трансляции в машинный язык x86/64 как бы нет — тем не менее файл получается EXE и может запускаться и ведёт себя как обычный EXE — например, через BAT-скрипты, через Планировщик Задач и т. д. Так всё-таки интерпретатор или компилятор? Пора кончать с неграмотностью. ✅ 2024/10/13 23:56, ИванАс #228 Вики:Генерация байт-кода Байт-код может интерпретироваться, т.е. на какой-то байт-код будет выполняться какой-то машинный код в самом интерпретаторе. Либо байт-код может компилироваться непосредственно в машинный код, который будет запускаться независимо от виртуальной машины.Результатом работы компилятора может быть программа на специально созданном низкоуровневом языке двоично-кодовых команд, выполняемых виртуальной машиной. Такой язык называется псевдокодом или байт-кодом. Как правило, он не есть машинный код какого-либо компьютера и программы на нём могут исполняться на различных архитектурах, где имеется соответствующая виртуальная машина, но в некоторых случаях создаются аппаратные платформы, напрямую выполняющие псевдокод какого-либо языка. но с прошитым в него исходным кодом программы на языке этого интерпретатора/компилятора — то есть никакой трансляции в машинный язык x86/64 как бы нет Значит интерпретатор.✅ 2024/10/14 11:49, veector #229 @ИванТак всё-таки интерпретатор или компилятор? Пора кончать с неграмотностью. Я предпочитаю оценивать таким образом:
EXE-файл — это фактически тот же самый файл компилятора/интерпретатора — но с прошитым в него исходным кодом программы на языке этого интерпретатора/компилятора Т.к. написанный код внутри EXE-файла это текст и он явно использует информационную модель, которую предоставляет исполняющий компонент (который сам же исходный текст и интерпретирует), то у вас явно — обычный интерпретатор, но с полезной фишкой в виде одного exe-файла с прилинкованным ресурсом в виде текста программы.Если бы вы отделили исполнитель от транслятора, использовав байт-код, и помещали в EXE-файл только исполнитель, то у вас бы получилась обычная виртуальная машина. Вообще, все x86 процессоры по сути являются виртуальными машинами, исполняющими микрокод, который исполняет инструкции процессора (своеобразный байт-код). https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html ✅ 2024/10/14 12:49, ИванАс #230 Вообще, все x86 процессоры по сути являются виртуальными машинами, исполняющими микрокод, который исполняет инструкции процессора (своеобразный байт-код). Таким образом, любой машинный код можно превратить в макрокомманды(байт-код).А также справедливо и обратное утверждение. Смотри PicoJava, Java Processor. ✅ 2024/10/14 13:06, Вежливый Лис #231 ИванАс, если ты зарегистрируешься на этом сайте и угадаешь, как правильно ввести поля профиля, то тебе не надо будет вводить капчу и имя всегда будет правильно подставляться само.✅ 2024/10/14 13:23, ИванАс #232 Ценное замечание, подумаю. А тебя я бы попросил не проявлять великодержавный шовенизм по отношению к другим народам России.✅ 2024/10/14 13:37, Вежливый Лис #233 Но я не проявлял. Я писал "в соответствии с законодательством". Русский язык привёл в качестве примера. Имею на это право по праву рождения и по закону. У татар свои законы в их Татарстан Республикасы-ах. Поэтому, когда сервер полиции будет искать куда отправлять заявление у него будет возможность выбрать доступные языки. Но это важно только жителям Аляски, когда её будет присоединять Россия. Ведь в татарстане письменность на кириллице и она и так пройдёт проверку. А делать альтернативу юникоду для всех алфавитов на базе кириллицы я уже предлагал раньше.✅ 2024/10/14 13:49, ИванАс #234 Но я не проявлял. Лис, контекст был таков: Вас там какие-то 3%, поэтому ваше мнение мы не учитываем. Что скажут другие народы на такое отношение?✅ 2024/10/14 13:56, Вежливый Лис #235 Вам показалось. Интерпретация. Мнение иметь можете, ложно обвинять — это статья (УК РФ Статья 128.1. Клевета)✅ 2024/10/14 14:05, ИванАс #236 Но это важно только жителям Аляски, когда её будет присоединять Россия. Высказывания в духе Жириновского.✅ 2024/10/14 14:12, Вежливый Лис #237 Вот вам ссылка: https://remdev.mybb.ru/viewtopic.php?id=38#p275, где я учитываю структуру государства: «Поскольку мы живём в одном союзном государстве, надо учитывать два алфавита». Была потом и более общая тема, с примером для карельского, только я её пока найти не могу.Теперь ждём ответа на интересный вопрос — извинится ли ИванАс за клевету, или извиняться перед русским это унижение для татар, потому что они сверхлюди. ✅ 2024/10/14 14:36, ИванАс #238 Теперь ждём ответа на интересный вопрос — извинится ли ИванАс за клевету, или извиняться перед русским это унижение для татар, потому что они сверхлюди. Наверное, это в вашем духе, сначала угрожать УК, а затем ожидать извенений. Наверное, в вашем духе проводить разъяснительную беседу с программистами за использование С, С++. Наверное, это в вашем духе иметь ссылку на случай чего. Ссылка старая, ваше мнение могло измениться.С чего вы решили, что я татарин? Я отвечу как Президент РФ: "Я русский, я дагестанец, я чеченец, я ингуш, татарин, еврей": https://www.mk.ru/politics/2022/03/03/putin-ya-russkiy-ya-dagestanec-ya-chechenec-ya-ingush-tatarin-evrey.html ✅ 2024/10/14 14:44, Вежливый Лис #239 Ну, русские от вас получили ответ, как с ними поступят татары (или они татаро-монголы?). Неважно при этом, узбек вы, или таджик. В пост-советских республиках русских изгнали все. У меня есть личная история. Учился в ВУЗе с татарином за одной партой. Сначала дружили, я ему задания делал по информатике, потом он мне угрожал огнестрельным оружием. Сейчас, естественно, не дружим. А потом приходится запрещать русскую народную игру в городки (это в которой выбивают чурок палками из города), потому что она видите ли разжигает рознь.а затем ожидать извенений ИзвИнений. И это нормальная практика. Называется "досудебное урегулирование". Ещё бывает внесудебное (если судебное не удалось).✅ 2024/10/14 15:07, ИванАс #240 У меня есть личная история. Учился в ВУЗе с татарином за одной партой. Сначала дружили, я ему задания делал по информатике, потом он мне угрожал огнестрельным оружием. Сейчас, естественно, не дружим. У меня была другая история. У меня был друг татар, у утонул и мне было все равно на его национальность.А потом приходится запрещать русскую народную игру в городки (это в которой выбивают чурок палками из города), потому что она видите ли разжигает рознь. У каждого свое восприятие. Таким макаром можно и дереобрабатывающую промышленность запретить. Дураки найдутся.✅ 2024/10/14 15:14, Вежливый Лис #241 Ссылка старая, ваше мнение могло измениться. Она не одна такая, мнение не изменилось. Я по-прежнему за действия в правовом поле. Внеправовое урегулирование считаю неправильным (но к СВО это не относится). Тем не менее, русские не обязаны реализовывать татарский язык (потому что ещё свой не сделали). Я так и написал, что татары сами могли бы (если бы в ВУЗе нормально учились). Уверен, что программист у них не один, ещё найдутся.✅ 2024/10/14 15:34, Вежливый Лис #242 и мне было все равно на его национальность Тут ещё не известно, как это в другую сторону работает. У меня был друг еврей. И таки что вы думаете? Всё равно ему было или нет? Свалил в Израиль.✅ 2024/10/14 15:59, ИванАс #243 Тут ещё не известно, как это в другую сторону работает. У меня был друг еврей. И таки что вы думаете? Всё равно ему было или нет? Свалил в Израиль. гАлкин? Если отключить фильтр национальностей, то можно увидеть что-то другое — есть определенные группы людей со своими верованиями, идеями. Т.е. все дело в идеях в голове, в "прошивке".✅ 2024/10/14 16:05, Вежливый Лис #244 национальности <-> национальные идеи. Хм, нет ли тут связи?✅ 2024/10/14 16:14, ИванАс #245 национальности <-> национальные идеи. Хм, нет ли тут связи? Есть другие группы — богатые, бедные. У этих групп тоже свои разные идеи. Есть много разных фильтров.✅ 2024/10/14 16:20, Вежливый Лис #246 Но именно вы почему-то развели весь этот дискуссий, просто из-за того, что язык был назван русским. Ну назвал бы я его российским, что бы поменялось?✅ 2024/10/14 18:05, MihalNik #247 Лис, контекст был таков: Вас там какие-то 3%, поэтому ваше мнение мы не учитываем. Неправда, контекст там был другой, что татары могут свободно программировать на татарском языке. В рамках доступной им ниши. Почему нет? Зачем Вы разжигаете межнациональную рознь? Вот пришел пользователь с именем Ильдар (возможно, татарин) и задал вполне очевидный вопрос безо всяких обвинений, кстати. Но почему-то Вы с другим пользователем тут же начали фантазировать о нарушениях законов РФ.✅ 2024/10/16 18:02, veector #248 @ИванАсТаким образом, любой машинный код можно превратить в макрокомманды(байт-код). А также справедливо и обратное утверждение. Смотри PicoJava, Java Processor. Технически-то все так, но ява процессоры так и не взлетели.Ещё, помнится, были слухи, что у VmWare был проблеск или помутнение, они хотели сделать/купить виртуальный процессор с новой универсальной системой команд, но это не точно (т.к. ссылок не нашел, ибо сейчас все результаты поиска просто про современную виртуализацию). Это всё не взлетело по понятным причинам: необъятный объем работ и отсутствие достаточного числа сторонников таких идей. ✅ 2024/10/19 18:11, Иван #249 Если бы вы отделили исполнитель от транслятора, использовав байт-код, и помещали в EXE-файл только исполнитель, то у вас бы получилась обычная виртуальная машина. Изначально транслятор и исполнитель были 2 отдельных модуля, но в одной программе.Код может компилироваться в BNZ — байт-код виртаульной машины. Правда не удаётся поддерживать обратную совместимость этого BNZ-кода. Например, в новой версии добавляешь в какую-нибудь функцию необязательные доп. параметры и всё — старый байт-код больше не работает. А обратная совместимость самого программного кода (а не байт-кода) хорошо поддерживается. Правда тут такая ситуация: в байт-код-то компилируется, но это не значит, что этот байт-код будет работать для любой написанной программы. Изначально работал любой код, а потом стал добавлять удобные фишки, например, чтение исходных кодов процедур по имени и т. д. То есть получилось так, виртуальная машина может использовать объекты транслятора. В общем, не смог удержаться и нарушил принцип отделимости ради добавления удобных фишек. В этот момент нарушился принцип отделимости. Да и как я думаю, не особо этот байт-код и нужен (кроме случаев, когда нужно от кого-то скрыть исходный код) — какая разница, встраивать в готовый EXE байт-код или исходный текст программы. Компиляция всё равно происходит очень быстро, а поддерживать обратную совместимость исходных кодов всяко проще, чем у байт-кода. ✅ 2024/10/22 15:20, veector #250 @ИванПолучается, что у вас компилятор исходного кода в байт-код + интерпретатор байт-кода, т.е. согласно рекламе — два-в-одном! :) ✅ 2024/10/23 18:12, Автор сайта #251 Как хорошо, что мне над этим не надо голову ломать. Раз сайт назывется compiler.su, значит делаю компилятор. 😄P. S. Доменное имя compiler.ru продаётся. А вот доменное имя interpreter.ru не продаётся; зарегистрировано в 2001 году, но сайт с таким именем так и не заработал. Доменное же имя interpreter.su зарегистрирован только в этом году, и сайт работает. ✅ 2024/10/24 13:31, Иван #252 @Иван Получается, что у вас компилятор исходного кода в байт-код + интерпретатор байт-кода, т.е. согласно рекламе — два-в-одном! :) Пусть даже если при этом байт-код может использовать объекты синтаксического анализатора (для некоторых типов программ, где используется такой байт-код). Так у меня были в 2010 году реализованы многострочные строки. Создаём процедуру, в ней комментарий на весь код процедуры, а в комментарии нужный текст. По ходу выполнения программы просто читаем исходный код нужной процедуры вместе с комментариями (для этого байт-код обращается к объектам транслятора, без этого никак, либо писать ещё один дополнительный транслятор. Что разумеется бред: зачем, если он уже написан. В 2022 году сделал по-нормальному многострочные строки. >>>1— так у меня выглядят многострочные строки сейчас. Тогда я не знал про Delphi 12 (а может, его тогда ещё и не было), где ввели многострочные строки. Иначе сделал бы так, как сделано там (впрочем и сейчас не поздно ещё, одно другому не мешает. ✅ 2024/10/28 14:06, veector #253 @ИванПусть даже если при этом байт-код может использовать объекты синтаксического анализатора (для некоторых типов программ, где используется такой байт-код). М-м-м, я так понимаю, что вся затея не из-за доступа к комментариям... Подгружаете и выполняете код на лету (а-ля плагины)? ;)... Создаём процедуру, в ней комментарий на весь код процедуры, а в комментарии нужный текст. По ходу выполнения программы просто читаем исходный код нужной процедуры вместе с комментариями ✅ 2024/10/28 20:13, Клихальт #254 РуСи Почитал документацию на него и русский язык в идентификаторах и ключевых словах РуСи таки поддерживается.Диалект Си — РуСи Автор: Андрей Николаевич Терехов. Статус: развивается, поддерживается. Русский язык в идентификаторах и/или ключевых словах: нет. ✅ 2024/10/29 00:06, Вежливый Лис #255 Почитал документацию Вы, безусловно, молодец. Но было бы вообще прекрасно, если бы вы разместили инструкцию о том, как проверить этот факт. Откуда скачать инструкцию, какое её место надо прочитать (глава, абзац, что-то такое). Цитата была бы неплоха.✅ 2024/10/29 01:28, Иван #256 Почитал документацию на него и русский язык в идентификаторах и ключевых словах РуСи таки поддерживается. Я вам больше скажу. Оказывается и у меня русские идентификаторы поддерживаются, а я-то и сам об этом не знал! И сам их никогда не использовал, хотя написал уже более 150 000 строк кода на своём языке.Например, такой код будет работать и выведет сообщение 3: Procedure Сообщить(Текст)Сделать аналоги ключевых слов на русском языке — причём с сохранением обратной совместимости — вообще никаких проблем. Перевести встроенные процедуры и функции на русский тоже можно. А тем более те, что в Глобальном Модуле. Только вот смысла в этом ноль. Тк в отличие от 1С язык изначально создавался с англоязычными идентификаторами. Русские будут смотреться коряво и неуместно в этом случае, дубли процедур на русском писать это вообще бред — кроме замедления работы компилятора из-за анализа доп. кода + глюков это ничего не даст. И я сам больше тяготею к Delphi, чем к 1С — ну нравится мне он. Из 1С там только динамическая типизация, по духу всё ближе к Delphi. М-м-м, я так понимаю, что вся затея не из-за доступа к комментариям... Вы не поверите — но как раз из-за доступа к комментариям. Очень потребовались многострочные строки — и решил в своё время реализовать их именно таким способом, чтобы сделать многострочные строки и внести минимум доработок в компилятор при этом. Решение, конечно, рукожопное и ни о каком минимуме доработок речи не идёт. И работать с такими многострочными строками неудобно — тк нужно городить целые огороды — вот такие конструкции:Подгружаете и выполняете код на лету (а-ля плагины)? ;) Procedure QueryContainer() /*вместо того чтобы написать query =(как делаю сейчас) Причём 2й вариант можно использовать в любом месте программы, в том числе внутри процедур в отличие от первого, тк язык не позволяет писать вложенные процедуры. Как такое могло в голову придти в 2009-2010 году понятия не имею. Но вообще мечтаю реализовать многострочные строки как в Delphi 12. Как руки дойдут сделать именно это. А может вместо этого что-то другое лучше сделаю — работы там непаханый край ещё — список доработок расписан, что хватит на 10 лет если реально всё, что мне хочется сделать. С комментариями у меня особый шик. Похоже на то, что все виды комментариев из всех языков взял и себе встроил чтобы было. ✅ 2024/10/29 10:38, Клихальт #257 Откуда скачать инструкцию, какое её место надо прочитать (глава, абзац, что-то такое). Цитата была бы неплоха. Вежливый Лис, ссылка на гитхаб проекта есть в его описании на этой странице. На гитхабе в каталоге RuC/docs/ находится файл Language.md — это описание языка. Вы хотели цитат? Вот они.6.6. Ключевые словаПо поводу идентификаторов: 6.7. ИдентификаторыВам этого мало? ✅ 2024/10/29 15:50, Вежливый Лис #258 До этого было мало. Теперь нормально. Спасибо за уточнение.✅ 2024/10/30 11:24, Иван #259 М-м-м, я так понимаю, что вся затея не из-за доступа к комментариям... Подгружаете и выполняете код на лету (а-ля плагины)? ;)
x1=10Иногда нужно установить значение переменной динамически по её названию (а переменная, кстати, может существовать или не существовать в зависимости от ситуации), но не обращаясь напрямую к идентификатору. Например, установить значение переменной x2. У меня так выглядит: SetGlobal('x2', 15)А можно так:for i=1 to 3 doКто, как не транслятор знает адреса переменных по их именам? Вот для этого и возможность обращений байт-кода к объектам транслятора — чтобы менять переменные по имени в Runtime. Конечно, если я напишу пример с использованием SetGlobal на GAZ — в байт-код он скомпилируется, но такой байт-код отдельно от исходного кода работать не будет. Но я в основном запускаю исходный код, а байт-код запускаю редко. Единственный пример, когда байт-код лучше, чем исходный код — когда нужно скрыть исходный код — но в этом случае можно написать код таким образом, чтобы он не использовал подобных SetGlobal и т. д. — тогда байт-код будет работать отдельно от исходного. 3. Появилась давно идея сделать возможность вызовов процедур по имени. Типа Call(НазваниеПроцедуры...), а потом список её параметров. Очень нужно бывает иногда. Но как оказалось, такое сделать сложно, чтобы работало в Runtime. Так как код вызова с передачей параметров нужно писать в этом случае снова и уже в Runtime генерировать и проверять соответствие параметров. Но можно ли переделать то, что уже есть, добавив динамический вызов процедур? Появилась идея сделать так:Procedure Proc1(var x, y)То есть добавить вторые скобки при вызове процедуры — чтобы при вызове CALL просто подменялся вызов Proc1 на Proc2 и проверялось соответствие параметров процедуры. Хорошая ли идея сделать так если по-нормальному сделать сложно, а динамический вызов процедур хочется? ✅ 2024/10/30 11:58, ИванАс #260 SetGlobal('x'+i, 7+i) Массивов нет?✅ 2024/10/30 14:37, Иван #261 Массивов нет? Массивы есть и изначально были с самого создания, без них даже не знаю вообще как можно было бы использовать язык и компилятор для практических целей. Более того, каждая переменная является динамическим массивом с длиной 1. А вот записей, объектов и прочего нет.Но даже в случае с массивами может потребоваться доступ по имени переменной. Т. к. может быть несколько массивов x1[], x2[], x3[] и т. д., а 2-мерных массивов нет. И не только в ситуации с массивами может быть удобно обращение с переменной по динамическому имени, такие ситуации периодически встречаются, в этих ситуациях байт-код без исходного кода работать не будет. Вообще, кстати, редко, это SetGlobal использую на практике — только тогда, когда без этого совсем сложно обойтись. Например, когда динамически генерируемый код не может быть уверен, что нужная переменная заранее объявлена выше по коду, а заранее объявить переменную тоже не всегда возможно, тк если переменная уже есть и объявлена ранее — старое её значение будет перезаписано в момент объявления по коду ниже. Для работы с 2-мерными массивами такое лучше, конечно, не использовать. Так как обращение к переменной по имени — довольно затратная по ресурсам процедура. Лучше в этом случае логику скрипта переделать на 1-мерный массив. ✅ 2024/10/30 14:44, ИванАс #262 Т. к. может быть несколько массивов x1[], x2[], x3[] и т. д., а 2-мерных массивов нет. Есть куда развивать.✅ 2024/10/30 18:19, Иван #263 Есть куда развивать. Да, есть куда. Но многомерные массивы — вещь не приоритетная, без этого можно жить. И даже настрочить 150 тысяч строк кода, как видите. Без обычных массивов вряд ли это получилось бы, язык был бы быстро заброшен.При наличии обычных массивов, процедур и возможности include достаточно легко можно работать с многомерными массивами на базе обычных, написав процедуры-обёртки, причём работать это всё будет не сильно медленно. А если нужно, чтобы где-то работало быстро, то и без процедур обёрток, используя операторы умножения и сложения. Без поддержки массивов я бы никак не смог пользоваться нормально компилятором и написать на нём 150 тысяч строк. Вообще было бы непонятно, как можно на таком языке что-то серьёзное вообще написать. Моё мнение сложилось на собственном опыте, что для языка обязательно, а что желательно и без чего можно обойтись (опустим всякие функциональные языки, где другая парадигма). ОБЯЗАТЕЛЬНО (у меня это всё есть, разумеется):
✅ 2024/10/31 00:20, Автор сайта #264 русский язык в идентификаторах и ключевых словах РуСи таки поддерживается. Клихальт, спасибо за неравнодушие, за то, чтобы всё соответствовало правде. Исправил.Сделать аналоги ключевых слов на русском языке ... — вообще никаких проблем... Только вот смысла в этом ноль. Типа Call(НазваниеПроцедуры. Иван, а Вы сами не замечаете, что сами непроизвольно переходите на русский? Может, и для Вас смысл совсем не нулевой?✅ 2024/10/31 01:49, Иван #265 Типа Call(НазваниеПроцедуры. Иван, а Вы сами не замечаете, что сами непроизвольно переходите на русский? Может, и для Вас смысл совсем не нулевой?В самом языке я отрицательно отношусь к русским идентификаторам, кроме проблем с кодировками и разными несовместимостями плюсов от этого нет и мозг хуже отделяет программный код от текста в этом случае. Наоборот, программный код на английском языке мозг воспринимает как программный код, а текст на русском как текст. По этой же причине — как мне неудобно писать программный код на русском языке — точно также неудобно читать обычный текст/документацию на английском языке. Сейчас опять решаю очередные проблемы. Поскольку всю рабочую среду завязал на свой компилятор — возникли проблемы с запуском сгенерированных скриптов размером 150 мегабайт программного кода. Да, 64-битный режим решил бы вопрос, но нужен запуск именно под WinXP (32-bit), где максимум 4 Гб. ✅ 2024/10/31 22:41, Автор сайта #266 мне неудобно писать программный код на русском языке Жаль, что русский язык неудобен Вам для работы. Большинству профессий он удобен.✅ 2024/11/01 00:00, alextretyak #267 ИванИ не только в ситуации с массивами может быть удобно обращение с переменной по динамическому имени Для этого используют «ассоциативные массивы». Они же «словари». (std::map/std::unordered_map в C++, dict в Python.) Насколько я понимаю, в Паскале их нет, а в Delphi они появились не так давно вместе с System.Generics.Collections. Поэтому Вы не добавили их в GAZ? Зря, очень полезная штука.✅ 2024/11/02 01:31, Иван #268 Жаль, что русский язык неудобен Вам для работы. Большинству профессий он удобен Да, неудобен на Винде, которая так или иначе, но заточена изначально под английский язык. Кроме того, мозг разделяет код на английском, а текст на русском, так проще переключаться, чем когда и то и то на одном и том же языке.Копирование кода на английском происходит без искажений даже если программа не на Unicode и множество таких мелочей, что делают английский удобнее. Фактически программный код воспринимается как программный код, а не как язык, что выучил и на чем привык писать то и удобнее. А вот документация на русском это очень хорошо, причем для любого языка программирования. Да, ещё один момент. Компилятор GAZ создавался в 2009 году, когда не было ещё этой истерии по поводу русофобии и прочего, что с этим связано (не будем развивать тему). Наоборот была идея о том, что надо больше пользоваться английским чтобы его выучить. Для этого используют «ассоциативные массивы». Они же «словари». (std::map/std::unordered_map в C++, dict в Python.) Насколько я понимаю, в Паскале их нет, а в Delphi они появились не так давно вместе с System.Generics.Collections. Поэтому Вы не добавили их в GAZ? Зря, очень полезная штука. У меня даже записей нет. И объектов. Какие тут могут быть ассоциативные массивы? Язык и VM изначально заточены под обычные динамические массивы. А переделать это — как переделать первый этаж в доме, который уже почти построен.Всё, что можно построить (записи, объекты и прочее) — можно построить только на базе обычных массивов. Типа хранить в массиве структуру объекта и данные объекта. Написать под это дело процедур (благо они есть) и имитировать работу более сложных объектов — например, записей, объектов, вложенных или ассоциативных массивов на базе обычных массивов. Правда если писать такие процедуры на встроенном языке — получается жутко медленно (пробовал уже такой ерундой заниматься) — поэтому вариант тут может быть только 1 — если такое делать — то добавлять такие процедуры в VM (что сложнее, чем писать на самом языке GAZ, тк для тестирования каждый раз придётся перекомпилировать сам компилятор). Можно под это дело даже синтаксического сахару добавить, что бы такие процедуры-имитаторы автоматически вызывались и в программном коде всё было красиво. Только мне кажется, это уже похоже на скрещивание ежа с ужом и изобретение Python заново, который уже написан. Хотя нет, можно просто добавить в язык новый объект ведь есть же уже объекты Файл, OLE итд и работать с ним как с таблицей значений в 1с 7.7. Не обязательно строить все на базе массивов и хранить данные в них. ✅ 2024/11/04 10:58, Иван #269 С запуском 150-мегабайтного скрипта разобрался. Оказывается, у меня строки в виртуальной машине хранились по 1 символу ANSI на целую 4-байтную команду. Поэтому и не хватало 3,5 Гб оперативы для запуска 150-мегабайтного скрипта. Сейчас сделал 4 символа на команду, чтобы память не пропадала — потребление памяти сильно сократилось. Почему сразу так не сделал в 2009 году — потому что надо было хоть что-то сделать чтобы работало, не до оптимизаций было. В общем, есть куда оптимизировать сейчас.✅ 2024/11/04 13:13, Неслучайный читатель #270 Возился как-то с языком Эйфория. Там символы хранятся в 32-битной ячейке. Полагаю, в кодировке utf-32. Дёшево и сердито, решает многие проблемы. От перерасхода памяти никуда не деться, но многим приложениям это не мешает.Иван, если не секрет, какие проблемы решает Ваш GAZ, что их нельзя решить другими средствами? Си или Питоном, Джавой или Лиспом? Когда аспиранты защищают диссертации, им первым делом задают вопрос: «В чём научная новизна Вашей работы?». А в чём новизна и уникальность Вашего GAZ? ✅ 2024/11/04 16:28, Иван #271 Иван, если не секрет, какие проблемы решает Ваш GAZ, что их нельзя решить другими средствами? Си или Питоном, Джавой или Лиспом? Когда аспиранты защищают диссертации, им первым делом задают вопрос: «В чём научная новизна Вашей работы?». А в чём новизна и уникальность Вашего GAZ? Питон уже не работает на всех ОС. Например, я скачал самый новый дистрибутив, а он не работает на Win XP. Си и Java — это вообще из другой область — это компилируемые языки (да, Java в VM — но там уже давно JIT так что не сильно отличается от тех же Delphi. По крайней мере, скрипты на Java не написать). Вообще такого языка нет, без которого нельзя жить и который нельзя заменить средствами других языков.По поводу GAZ — я уже перечислял выше (за базу сравнения можно выбрать, скорее всего, AutoIt): 1) Простота устройства. Каждая переменная — динамический массив с длиной 1. Ничего сложного нагородить в принципе невозможно, код хорошо читается, а не Write-Only. 2) В сравнении с AutoIt имеет VM и скрипт не вывалится посередине из-за синтаксической ошибки. 3) Работает на всех Windows начиная с XP. 4) Полная обратная совместимость всех версий начиная с 2009 года. Правда, к обратной совместимости VM это не относится. Периодически скомпилированные в BNZ скрипты перестают работать. В сентябре-октябре, когда меня понесло на доработки это случилось аж 4 раза — крайний раз вчера, когда сделал хранение строк по 4 байта на команду, а не 1. Но обычно обратная совместимость VM ломается не более раза в 1-2 года. 5) Основной плюс лично для меня — то, что я чего захочу нового в язык — то и добавлю. Что понадобится в работе, то и добавлю, с другими языками так не получится. Например, работу с DLL/полноценную работу с OLE и т. д. Да, т. к. исходный код закрыт — этот + только для меня. Но всё равно я энтузиаст, а страница про энтузиастов :) Пишите свой язык если кому нужно и также добавляйте. Только, наверное, стоит это делать не как я, а на базе Lua. ✅ 2024/11/04 16:36, Иван #272 Возился как-то с языком Эйфория. Там символы хранятся в 32-битной ячейке. Полагаю, в кодировке utf-32. Дёшево и сердито, решает многие проблемы. От перерасхода памяти никуда не деться, но многим приложениям это не мешает. Тоже не мешало. Но как написал генерацию скрипта преобразования одной папки в другую на GAZ (ещё в 2012) — потребление памяти стало большим и проблемы с нерациональным расходом памяти вылезли наружу. Как я писал, мне нужен запуск таких скриптов на Win XP, где максимум 4 Гб RAM. На 64-bit всё замечательно работало, но не везде есть 64-bit. Для сложно устроенных папок скрипт преобразования одну в другую может занимать и 150 мегабайт (20 Мб в архиве) — но это всё равно выгодно использовать, тк сами исходные папки могут занимать по 300 Мб, даже с сжатом виде, а скрипт преобразования 20- Мб. Решилось малой кровью — ничего там серьёзно не оптимизировал вчера. Просто как полагается — раз команды у меня 4-байтные, то и строки надо хранить по 4 символа на команду, а не 1. Потребление оперативной памяти упало с почти 4 Гб до 1,2 Гб — что тоже конечно много и надо бы ещё оптимизировать чтобы 300 Мб хватало. Но с другой стороны, пока необходимости в этом нет, так как если оперативной памяти на WinXP максимально возможные 4 Гб, то не жалко позволить скрипту сожрать 1,2 Гб зная, что скрипт не упадёт. Кстати кто знает, как сделать скрипт для преобразования 1 каталога в другой под Windows начиная с XP? Если учесть, что много файлов в обоих каталогах одинаковые, но могут перемещаться внутри каталогов? Скрипт это должен учитывать и не хранить содержимое файлов папки 2, которые уже есть в папке 1. Кроме того если в большом файле папки 2 файл такой же как в папке 1 но например, изменён 1 килобайт и скрипт должен хранить только изменения, а не весь файл. Возможно, я рукожоп и зря велосипед изобрёл, да ещё и написав его на GAZ. У меня много таких велосипедов. Фактически весь мой опыт за 20 лет помещён в компилятор. А в чём новизна и уникальность Вашего GAZ? Вопрос для меня лично уже даже не в этом. Вопрос уже в том, что каким бы компилятор не был — я так просто уже не могу от него отказаться. Слишком много у меня уже на него завязано. Поэтому и приходится временами продираться через трудности, исправляя проблемы если таковые обнаруживаются. Работает всё на удивление стабильно в целом. Может как раз по той причине, что использую каждый день написанный код.✅ 2024/11/06 00:31, Автор сайта #273 Кстати кто знает, как сделать скрипт для преобразования 1 каталога в другой Вопрос как-то общо поставлен. Меня однажды попросили как-то написать утилитку для борьбы с последствиями работы шифровальщика. Но он какой-то детский оказался: он ничего не шифровал, а только добавлял символ в расширение имени файла. Ничего смертельного, но поди-ка ты переименуй вручную тысячи файлов. Сделал рекурсивную функцию обхода каталогов и приведения расширения имени к норме. Речи ни о каких гигабайтах не было. Написал на TinyCC, который можно запросто использовать как скриптовый. TinyCC компилирует почти мгновенно, работает в 9 раз быстрее GCC. Был какой-то проект у одного израильтянина, который использовал TinyCC для скриптования вэб-страниц. Думаю, используй Вы TinyCC для скриптования, много бы не потеряли. Кроме радости творчества, конечно.✅ 2024/11/06 02:35, Иван #274 Не знаю, я бы на GAZ такой скрипт по массовому переименованию написал быстрее всего, если поставить задачу и включить часы.У меня компилятор просто изначально заточен на работу с массивами и файлами. Мощные функции GetFiles, GetDirFiles и команда Sort для сортировки массивов. Всё это, кстати, было уже изначально в 2009 году. Рассмотрим другие варианты. Первое, что приходит на ум — это Delphi, но там методы FindFirst, FindNext слишком перегружены и не так лаконичны. Язык компилируемый, что затрудняет тестирование скриптов. Но в принципе вариант. AutoIt. Вроде язык и заточен под такие скрипты, но на практике стоит начать что-то писать — так выходят какие-то странные ошибки, иногда в середине скрипта, так как похоже, что там нет VM. Тестировать явно дольше, чем даже на Delphi. Функции диалогов перегружены лишним. Python. Этот суперязык даже не смог установить на Win 7, на XP тем более не встанет. Видимо, по мнению разработчиков у кого меньше, чем Win 11 — это недолюди. С++, PHP, Java, Node.JS и т. д. даже не стал бы всерьез рассматривать. Написание и отлов багов заняло бы очень много времени. То же самое с VBS. GAZ. Быстрее всего можно написать. Медлительность VM не имеет значения, основное время занимает собственно работа с файлами, а не интерпретация команд VM. Из минусов — не поддерживает utf-8 имена файлов, только ANSI и вообще основная среда для него ansi. Да, может строки перекодировать в utf-8 и Unicode, но все равно строка хранится как массив 1-байтных символов со всеми вытекающими. Но на практике у меня файлов с utf-8 именами практически нет, поэтому скрипты не падают. Но если шифровальщик переименует в utf-8 имена, то моему компилятору станет плохо. Если кроме простого переименования надо как-то обрабатывать файлы и обработка сложная, то это не для GAZ. Либо добавлять сначала новые команды в GAZ, а потом использовать их в скрипте, как я впрочем часто делаю. Так дела, например, с md5 и Base64Encode. TinyCC вряд ли столько функций имеет, сколько тот же AutoIt. А именно AutoIt мне больше всего нравится. Если бы не его изъяны некоторые перешел бы полностью на него для скриптов. А в общем хоть я и любитель Delphi, но на чистой чужой машине не будь GAZ либо были бы не ANSI файлы а с Unicode в именах, то для такого скрипта выбрал бы именно AutoIt. Так как Delphi — это монстр, который ещё надо скачать и он ещё платный, кстати, причём цена кусается. Версия 7 не подойдет, так как она ANSI. Нужен монстр вроде Rio. AutoIt скачивается за минуту, содержит встроенную справку, за полчаса, час, максимум два часа любой уважающий себя программист разберётся. Кстати, у TinyCC лицензия GPL, поэтому встраивать его в свой коммерческий софт нельзя. Только если писать скрипты для себя или на заказ. Написать автору можно на электронную почту |
Продолжение цикла и выход из него