Каким должен быть язык программирования?Программисты делятся на тех, кто уже сделал компилятор своего языка программирования, и на тех, кто это сделать только собирается. Этот сайт сделан как раз для тех, кто только собирается. Итак, у сайта следующие цели:
А теперь по-подробнее по пунктам. Обсуждение существующих языков программированияВо многих языках есть некая «изюминка», привлекающая к себе сторонников. Есть и недостатки. Выявляя и обсуждая и то, и другое, можно нарисовать те контуры, в которые должен вписаться идеал языка программирования. В нём необходимо избежать уже совершённых ошибок. У них были разные причины, но в них надо разобраться.Создание идеального языка программирования.Идеальный язык программирования — это такая же недостижимая мечта, как и идеальная жизнь. Но стремление к совершенству приводит к появлению вещей, которые делают нашу жизнь лучше. Скептики могут увидеть в этом изобретение очередного велосипеда. Но и это не бывает напрасным: если очередной велосипед не стал лучше прежнего, то сам процесс улучшает изобреталей. Велосипед может быть забыт и выкинут, а вот изобретатели приобретут инженерный опыт.Для начала вашему вниманию предлагаются мысли и идеи, которые уже есть на сайте. Надеюсь, что это вызовет интерес и желание это обсудить, прокомментировать или же возразить. И предложить такую альтернативу, которую и лучше, и понятнее. Часто проекты новых языков программирования либо нигде не обсуждаются и существуют только в голове авторов, либо обсуждаются в узком кругу. Затем пишется компилятор и общественность ставится перед фактом: есть новый язык, есть компилятор, пользуйтесь им; если он вам не нравится, то это ваши проблемы; мы никогда не обещали, что он вам будет нравится. Предлагается другой путь:
Надеюсь, в результате дискуссий у нас появится на бумаге такой язык, который действительно стоит воплотить в компилятор. Без внесения в язык свежих идей и изюминок, которые помогут снискать языку популярность, к работе над компилятором даже не стоит приступать. В противном случае этот язык программирования годиться только для курсовой или дипломной работы. Или будет продуктом для узкой ниши, вторым языком «1С». История создания языков программирования знает примеры коллективного обсуждения будущих языков. Языки Алгол-68 и Ада разрабатывали созданные для этого комитеты. Результатом их работы было формальное и неформальное описание будущих языков, для которых в последствии были разработаны компиляторы. Коллективный принцип работы не гарантирует успешности, но он:
Пособие «Как придумать язык программирования»По ходу обсуждения будут вноситься исправления в уже написанный материал. Ожидаемо появление статей программистов, у которых существует к этой теме интерес — как профессиональный, так и любительский. Ведь всегда есть место для озарений. В результате весь ход наших дикуссий можно будет расценить, как пособие «Как придумать язык программирования».На сегодняшний день существуют тысячи языков программирования. Но ещё ни один автор языка не объяснил, почему это сдалано именно так, и не доказал, что это наилучшее решение. Никлаус Вирт, один из самых «плодовитых» языкописателей, профессор, автор многих книг, не посчитал нужным комментировать процесс изобретения своих языков. Что же говорить об остальных, которые придумали один единственный язык программирования? Восполняя этот пробел, будем стараться комментировать ход своих мыслей, аргументировать свои предложения. Создание языка начинается не с описания грамматики. Должны родиться какие-то идеи, потом они должны пройти, как минимум, проверку на непротиворечивость концепций. Затем должны выкристаллизоваться основные идеи как синтаксиса, так и семантики языка. И лишь потом — формальное описание.
Существуют ли книги или сайты на тему
Вполне может быть, что материалы на тему «Как придумать язык пpогpаммиpования» всё-таки существуют,
просто автор этих строк с ней не знаком.
Тем не менее, как не бывает двух одинаковых прожитых жизней, так и не бывает двух одинаковых опытов разработки языка программирования.
И если наш опыт будет интересен, то он достоин письменного описания.
|
| Оцените | Оценки посетителей |
| Нравится | ███████████████████████ 113 (53.5%) |
| Неплохо | ██████ 29 (13.7%) |
| Так себе | ████ 20 (9.47%) |
| Не нравится | ██████████ 49 (23.2%) |
Отзывы
✅ 2014/11/28 02:42, Санал #0
Почему не использовать ДРАКОН в написании? Может, облегчится труд?✅ 2014/11/28 10:59, Автор сайта #1
Потому что «Дракон» далеко не идеален.✅ 2014/11/29 16:05, Nadolin #2
Здраствуйте всем! Благодарю за Этот Сайт, и содержащуюся на нем информацыю тех, кто к этому приложил усилия авторства, разработки,написания, и размещения здесь.✅ 2014/11/29 11:16, Автор сайта #3
Спасибо за тёплые слова. Но хочется сделать больше, чем сделано, и работы предстоит ещё много.✅ 2015/02/09 17:43, Павел #4
Здравствуйте! В статье упомянут коллектив авторов. Где можно с вами связаться? Где идёт обсуждение идей? Форум какой то или что? Кто входит в коллектив? Имею интерес послушать и частично поучаствовать в обсуждении.✅ 2015/02/09 22:03, Автор сайта #5
Пишите на электронную почту, указанную ниже, после этого поговорим.✅ 2015/02/19 10:22, programmer #6
Какова стоимость проекта? Пока что здравого смысла вижу мало, что указывает на отсутствие средств и, собственно, необходимого профессионализма. Напомню, что реальная выгода создателей популярных языков исчислялась в сотнях тысяч долларов, даже если они ради рекламы этого скромно не сообщали публике.✅ 2015/02/19 14:27, Автор сайта #7
Опыт других проектов говорит о том, что нужно несколько человеко-лет. Отсутствие средств указывает на отсутствие здравого смысла? Интересное мнение…реальная выгода создателей популярных языков исчислялась в сотнях тысяч долларов
Пожалуйста, факты в студию со ссылкой на источники.✅ 2015/02/19 14:26, programmer #8
По фактах нужно посмотреть доказательства — на какие средства приобретена недвижимость или прочее имущество тех или иных разработчиков. Прямых статей я не видел, в которых бы это указывалось — нужна заинтересованность. Если очень нужно — могу подобрать по нескольких разработчиках информацию об их доходах в виде статьи, которая непосредственно указывает о приобретенной выгоде в указанной сумме — естественно, если у меня будет какая-то заинтересованность в потраченном времени. Например, если Вы хотите предложить обоснованное сотрудничество в коммерческих разработках чего-то подобного, то в качестве обоснования указанной стоимости я могу собрать необходимую информацию о разработчиках и их полученном доходе, исходя из фактов, указывающих на приобретение различных ценностей, таких как недвижимость, машины, поездки и прочее, с указанием стоимости аналогичных в США и Европе. Аналогично я могу обосновывать стоимость нишевых проектов, базируясь на доходах разработчиков чего-то подобного — вот вам одна составляющая обоснования требований разработчика в нишевых проектах — а судя по вашим заявлениям о фрилансе, вы не знакомы с такой практикой. Проще говоря — потенциальному заказчику в качестве одного из обоснований представляется информация об аналогичных нишевых проектах, которую можно проверить, их фактической стоимости. Не согласен — иди лесом, текущих проектов хватает.Отсутствие здравого смысла рассматривается как признак недостатка финансирования и профессионализма или как совокупность признаков, указывающих на бесперспективность проекта.
✅ 2015/02/20 13:25, Автор сайта #9
Давайте вот о чём договоримся. Если Вы готовы профинансировать проект — Вы можете рассуждать о деньгах. Не готовы — значит деньги не затрагиваем, это не Ваша забота. Идём дальше. У вас есть какие-то новые идеи в программировании? Есть у Вас есть конкретная критика предложенных здесь новшеств? Если да — высказывайте идеи, критикуйте предложенное. Если нет — не тратьте своё и моё время.✅ 2015/02/20 11:59, programmer #10
В данном случае последнее лучше — слишком много ошибок, чтобы самому финансировать. Толку со всего этого, если разработки, собственно, уже имеются у меня, я изначально указал, что на данном этапе скорее смотрю на ошибки разработчиков других проектов, чтобы понять собственные недочеты.✅ 2015/02/20 12:18, programmer #11
Финансирование, в общем случае, предлагает наличие крупного заказчика или группы заказчиков, которые могут предоставить гарантии и надеются извлечь из этого прибыль, имея уже все необходимое для этого — это в случае нишевых проектов. Самому финансировать бессмысленно, потому что это приводит к значительным рискам — кражи кода, кидалова, конкуренции и прочих неприятных вещей, а крупные заказчики уже имеют средства противодействия таким неприятностям. Кроме того, написать код, направленный на максимальный ущерб отдельному заказчику, который может кинуть, намного легче и можно прощупать почву для получения выгоды от конкурентов в таком случае.А как раз критика уже была, по очевидным моментам. Как можно надеяться на коммерческую перспективность, допуская столько ошибок в статьях ? А вот если все просто делается, как персональное увлечение, то, собственно, вам придется ограничится тем уровнем что есть, без конкретики критических замечаний — потому что конкретика будет означать как раз раскрытие новых подходов и идей.
✅ 2015/02/20 15:38, Автор сайта #12
Вам же писали: не готовы финансировать — не пишите о деньгах. Если для Вас «конкретика будет означать как раз раскрытие новых подходов и идей», а раскрывать Вы не хотите, то пишите на своём сайте. Зачем Вам мой сайт?✅ 2015/02/20 12:54, programmer #13
Изучение чужих ошибок и реакции на них. Т.е. если вы допускаете ошибку, существует значительная вероятность, что вы как-то к ней пришли. Меня это интересует, откуда это взялось.Для Вас лично я бы порекомендовал изучить ошибки результатов шизанутого творчества создателей 1С финансовых программ — язык программирования. Их ошибки очень характерны, хотя и происходят из жадности, тупости и прочих элементарных вещей.
✅ 2015/02/20 16:11, Автор сайта #14
Если Вы пишите, указывая на ошибки — это критика. Но Вы пишите об ошибках, не указывая на них — это критиканство. А Вам лично я бы посоветовал давать рекомендации на своём сайте. Там пишите о тупости, жадности, максимальном ущербе заказчикам.✅ 2015/03/18 07:43, Е.В.Геній #15
"Для Вас лично я бы порекомендовал изучить ошибки результатов шизанутого творчества создателей 1С финансовых программ — язык программирования. Их ошибки очень характерны, хотя и происходят из жадности, тупости и прочих элементарных вещей."Пока вижу только критиканство — очень похоже что 1С своимъ встроеннымъ РЯП кого-то оставило безъ миски супа...
✅ 2015/04/07 10:50, misha_shar53 #16
Из рассмотрения выпал очень важный язык программирования MUMPS. Не рассматривая его нельзя вообще говорить об идеальном языке программирования. Я уже 3 года на идеях MUMPS пытаюсь создать идеальный язык программирования. Уже много сделано. Есть спецификация языка(MSH). Многие обсуждаемые в этом разделе проблемы мне понятны. Но писать комментарии к отдельным конструкциям языка бессмысленно без изложения концепций языка. Некоторые проблемы в моем языке просто отсутствуют как таковые. Некоторые опираются на традиции MUMPS. Я постараюсь подготовить статью с моим представлением об идеальном языке. Мне будет интересно ваше мнение о моих исканиях. По поводу текущего обсуждения. Я считаю принципиальной ошибкой то, что за основу обсуждаемого языка взят язык Си. Уже создано огромное множество вариантов языков на его основе. ничего принципиально нового на этом пути нет. Идти в этом направлении бессмысленно.✅ 2015/04/07 15:38, Автор сайта #17
Этот язык 1) старый, 2) малопопулярный. О чём это говорит, если руководствоваться общепринятыми стереотипами? Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины. Чем-то он не нравится людям, скорее всего и мне не понравится. А ещё в нём нет чистых функций, лямбд и всего того, что вошло в широкую практику в последнее время.Чтобы преодолеть эти стереотипы, надо просто описать его характерные черты, которые высвечивают его преимущества над остальными. Вы готовы изложить это, только конспективно, чтобы люди не устали читать?
Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку. Отсутствие типизации (все данные хранятся как строки), низкий уровень абстракции, нечитабельность синтаксиса, отсутствие обязательного объявления переменных и поддержки приоритетов арифметических операций. Ключевые слова языка не зарезервированы, лишний пробел может совершенно изменить смысл синтаксической конструкции.
Я считаю принципиальной ошибкой то, что за основу обсуждаемого языка взят язык Си
С чего Вы это взяли?постараюсь подготовить статью с моим представлением об идеальном языке
А Вы не хотите сделать свой сайт на эту тему?✅ 2015/04/07 14:44, misha_shar53 #18
Этот язык 1) старый, 2) малопопулярный. О чём это говорит, если руководствоваться общепринятыми стереотипами?
Если руководствоваться стереотипами то ничего нового не получишь.Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины. Чем-то он не нравится людям, скорее всего и мне не понравится.
Причины, возможно, есть. И вам он тоже может не понравиться. Но от этого язык не станет хуже. Чтобы оценить достоинства, надо хотя бы немного с ним поработать. И чтение Вики недостаточно.А ещё в нём нет чистых функций
Странно? Почему это нет?лямбд и всего того, что вошло в широкую практику в последе время.
В практику в последнее время вошло много всякого мусора. Не всегда полезного.Лямбд — точно нет и зачем они в MUMPS я не понимаю. Кстати я их не встречал и в Си. А что ещё вошло в широкую практику в последе время? Анатации Java? Языки начинают напоминать кучу мусора. Ломается стиль языка и его обзорность.
Чтобы преодолеть эти стереотипы, надо просто описать его характерные черты, которые высвечивают его преимущества над остальными. Вы готовы изложить это, только конспективно, чтобы люди не устали читать?
Попробую.Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку. Отсутствие типизации (все данные хранятся как строки),
Это как раз его достоинство. Типизация языка порождает 80% его проблем. А как хранятся данные — в виде строк или в каком другом виде — неизвестно и языком не определяется и зависит от конкретной реализации.низкий уровень абстракции,
Утверждение в корне неверно.нечитабельность синтаксиса
Не хуже чем в других языках программирования. В нем нет нечитабельных конструкций. И вообще это сильно зависит от стиля написания программы.отсутствует обязательное объявление переменных
Это его основное достоинство. Управление данными полностью переложено на язык. Решается целая куча проблемм. Функции пишешь по смыслу, не вникая в тип аргументов✅ 2015/04/07 14:56, misha_shar53 #19
А Вы не хотите сделать свой сайт на эту тему?
Вы хотите чтобы я убрался с вашего сайта?И не хотите даже выслушать мои аргументы? Открывать свой сайт я не планирую. Все свободное время я трачу на разработку языка MSH.
✅ 2015/04/07 19:46, Автор сайта #20
Языки, в которых отсутствует типизация, менее эффективны. Они не найдут применения в некоторых сферах, например, в системном программировании. Но это не значит, что они не имеют право существовать. Просто у них другая ниша. Поэтому эту нишу надо чётче обозначать, чтобы меньше было вопросов.Утверждение в корне неверно.
Меня не надо переубеждать, лучше подправьте Википедию и будьте готовы отстоять свою точку зрения, ссылаясь на авторитетные источники.Вы хотите чтобы я убрался с вашего сайта?
Нет. Если Вы не хотите пользоваться своим языком в одиночку, Вам рано или поздно придётся сделать свой сайт. Сделайте его заранее, у Вас будет канал общения с Вашими будущими пользователями. И на этом сайте Вы можете изложить свои аргументы в наилучшем виде.Все свободное время я трачу на разработку языка MSH
Всё-таки отщипните кусочек времени, напишите о языке, Вы получаете полную свободу изложения!(см. выше).✅ 2015/04/07 17:28, misha_shar53 #21
Языки, в которых отсутствует типизация, менее эффективны.
Спорное заявление.Они не найдут применения в некоторых сферах, например, в системном программировании.
Утверждение ошибочное. MUPMS в OS DSM11 использовался в качестве системного. Мне трудно представить чтобы на нем нельзя было сделатьВсё-таки отщипните кусочек времени, напишите о языке, Вы получаете полную свободу изложения!(см. выше).
Я этим сейчас и занимаюсь. И обязательно завтра послезавтра напишу.✅ 2015/04/08 05:16, misha_shar53 #22
Мне кажется прежде чем приступать к обсуждению нового языка, надо определиться с целями его создания. Зачем это делать. Я вижу 2 цели:1. Создать традиционный язык, хорошо себя зарекомендовавший, который легко воспримет широкая аудитория, но более эстетически выглядящий.
2. Создать Новый язык обладающий новыми свойствами. Тогда надо определиться будет ли он нишевым или нет. И если да, то для какой ниши он создается. Какими свойствами он должен будет обладать?
Мне кажется вы склоняетесь к 1 варианту. Но тогда это будет ещё один 10001 Си или С++ подобный язык и перспективы его выживания мне кажутся сомнительными. Может я не прав.
✅ 2015/04/08 08:59, misha_shar53 #23
Хотелось бы более подробно разобраться с якобы недостатками MUMPS и его критикой.Этот язык 1) старый, 2) малопопулярный.
Это не аргументы. Даже ещё более старый Аналитик совершенней большенства современных языков программирования. Эти аргументы никак не относятся к свойствам языка.Чем-то он не нравится людям, скорее всего и мне не понравится.
Странное заявление. Причем здесь люди? Надо получить собственное мнение о языке.О чём это говорит, если руководствоваться общепринятыми стереотипами? Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины.
А вот при создании нового желательно стереотипами не пользоваться.Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку.
Нечитабельность синтаксиса.
Ключевые слова языка не зарезервированы, лишний пробел может совершенно изменить смысл синтаксической конструкции.
низкий уровень абстракции.
Ну совсем не в тему. Уровень абстракции у MUMPS выше, чем у остальных языков. В литературе даже он упоминался как язык 4-го поколения. Организация данных тому подтверждение.поддержки приоритетов арифметических операций.
Да приоритеты отсутствуют. Это конечно не достоинство языка, но и не недостаток. Дело привычки у программистов и выбор модели у разработчиков. Если это включено в стандарт языка то это допустимая модель работы с данными.Отсутствие типизации (все данные хранятся как строки), отсутствие обязательного объявления переменных.
А вот собственно из за этого я и начал писать этот комментарий. По моему это и есть одна из причин по которой этот язык старательно замалчивается. Это язык ревизионист. Он покусился на самое святое в теории программирования на его бога — декларирование переменных. Откуда взялся этот бог уже никто и не помнит. Я думаю что все началось с первых трансляторов.✅ 2015/04/08 13:36, Автор сайта #24
Но подправить синтаксис проблем не составляет.
Да, но тогда это будет другой язык, вовсе не MUMPS, о достоинствах которого Вы хотите рассказать.В принципе, языки с некоторой долей погрешности можно разделить на две категории.
- Языки, допускающие эффективную реализацию. Их эффективность направлена либо на наибольшую скорость исполнения, либо на наименьшее использование вычислительных ресурсов. Последнее важно для мобильных применений: меньшая производительность процессоров, требования энергоэффективности (чтобы батарея меньше разряжалась).
- Языки, которые ставят целью наибольшую скорость работы программиста, а не программы. Поэтому на некоторые неэффективные решения закрываются глаза. Ну и что, что в PHP массивы реализованы посредством ассоциативных массивов: нет прямого обращения по индексу 2 в массиве $arr[2], но есть обращение к элементу ассоциативного массива по ключу 2. Ведь работает, не правда ли?
C/C++ ещё много лет будет здравствовать. Но и у конкурентов есть хорошие шансы: ведь C/C++ не может освободиться от своих «плохих» черт по причине обратной совместимости. Если бы Вы познакомились с языками Oberon-2, D, Rust, то не говорили, что это «ещё один Си». Скажите сторонникам Oberon-2, что этот язык такой же, как Си, и Вы узнаете, что они о Вас думают.
Он покусился на самое святое в теории программирования на его бога — декларирование переменных. Откуда взялся этот бог уже никто и не помнит.
Если кто и не помнит — так это Иваны, не помнящие родства. Всё дело в эффективном использовании памяти. Статическая типизация позволяет зарезервировать память ещё на этапе компиляции. Программы с динамической типизацией резервируют память на этапе исполнения. Более того, эту память приходится выделять в «куче», когда размер памяти под объект становится известен в момент его создания. А выделение в «куче» — достаточно «дорогостоящее» занятие: Двухстековая модель: тесты на скорость Так что декларирование переменных — не блажь.о что декларирование переменных является злом и не только не помогает но и сильно мешает некоторые из разработчиков языков начинают понимать.
Такое «понимание» связано с тем, что закон Мура работает на тех, кто уверен, что «пипл чип всё схавает». А ещё появилась типизация Хиндли — Милнера, которая зачастую создаёт иллюзию, что типизации нет. Это специально для тех танцоров, которым всегда что-то мешает.
✅ 2015/04/08 13:34, misha_shar53 #25
Насчет лучшей эффективности декларативных языков я не спорю. И возможно языку Си ничего не грозит. Но насчет мобильных приложений вы явно передергиваете. Там конечно необходимы эффективные языки. Но как ни странно используется не самый эффективный из них Си, а язык очень далекий от него по эффективности Java.✅ 2015/04/09 00:57, misha_shar53 #26
Скажите сторонникам Oberon-2, что этот язык такой же, как Си, и Вы узнаете, что они о Вас думают.
Извините что затронул ваши религиозные чувства. Ладно не Си, Алгол или Паскаль.А ещё появилась типизация Хиндли — Милнера, которая зачастую создаёт иллюзию, что типизации нет. Это специально для тех танцоров, которым всегда что-то мешает.
Вообще-то я хотел сказать не о танцорах и что им мешает. А о существовании фантомов вроде декларирования переменных и GOTO, которые тормозят развитие языков программирования. Мне просто искренне жаль, что колоссальные ресурсы уходят в никуда. Хотя ваше обсуждение языка мне было полезно и интересно.✅ 2015/04/10 15:06, Автор сайта #27
Печально, что Вы не видите разницы между C/С++ и Oberon-2 и объясняете это религией. Жаль, что Вы считаете, что «goto» и статическая типизация являются одинаковыми тормозами в развитии. А Вы не пробовали понять, в чём заключаются плюсы Haskell, языка со строгой статической типизацией?✅ 2015/04/10 14:38, misha_shar53 #28
В принципе, языки с некоторой долей погрешности можно разделить на две категории.
Языки, допускающие эффективную реализацию. Их эффективность направлена либо на наибольшую скорость исполнения, либо на наименьшее использование вычислительных ресурсов. Последнее важно для мобильных применений: меньшая производительность процессоров, требования энергоэффективности (чтобы батарея меньше разряжалась).
Языки, которые ставят целью наибольшую скорость работы программиста, а не программы. Поэтому на некоторые неэффективные решения закрываются глаза. Ну и что, что в PHP массивы реализованы посредством ассоциативных массивов: нет прямого обращения по индексу 2 в массиве $arr[2], но есть обращение к элементу ассоциативного массива по ключу 2. Ведь работает, не правда ли?
Каждая философия имеет право на жизнь, особенно если у языков непересекающиеся ниши.
✅ 2015/04/10 19:10, Автор сайта #29
Согласен с Вами. Вот поэтому в ближайшее время будет сформулирована «философия» проекта. Поскольку изобрести универсальную «серебряную пулю» не удастся, придётся сделать выбор: «Это нам подходит, а вот это — нет».P.S. Философия языка сформулирована.
✅ 2018/10/29 10:15, 96383 #30
А что, существует мало языков программирования?Что за контрольное число такое: "дтвяносео пять тысяч девсти девянсото девять"
✅ 2018/10/29 11:44, kt #31
Сразу видно, что Вам не приходилось бороться с ботами :))Языков программирования уже больше, чем обычных живых и мертвых вместе взятых. С языками — так же, как и с программами. Почти всё, что нужно, уже есть. Но того, чего хотелось бы, ещё не написали.
И обычные языки, и языки программирования продолжают развиваться. Это процесс, а не свод законов.
✅ 2018/10/29 13:17, Автор сайта #32
Лучшая песня ещё не спета :) Человек — существо творческое. Вот и сочиняются новые песни и новые стихи, новые ОС и новые языки. А будет ли новое лучше старого — это жизнь рассудит.✅ 2019/02/24 23:14, MihalNik #33
Можно почитать/пособирать хотелки разных людей (особенно в обсуждении), например, хабр:"Субъективное видение идеального языка программирования":
https://habr.com/en/post/435300/
✅ 2019/11/23 22:54, Сергей #34
Друзья! Давайте создадим переводчик программ . Аналогично переводчику программа будет иметь свой словарь. Переводчик будет транслировать с русского на английский текст программы и обратно. Словарь можно будет изменять и дополнять. Словари можно будет менять под разные языки программирования. Я думаю такая программа понизит среднестатистический возраст входа россиян, интересующимся программированием.Что такое компьютер? Это куча ключей, которые знают только 1 или 0, каждому ключу присваивается смысловое описание, описание на английском. И чем глубже будем копать тем больше иностранных граблей будет вылазить.
Интересно родился ли русский Линус Торвальдс?
✅ 2019/11/26 18:57, Автор сайта #35
Хотелось бы увидеть в вашем предложении побольше технических деталей. Что будет представлять из себя этот самый словарь? Базу данных? Wiki-словарь? Файл в формате djvu? Как процесс пополнения словаря будет выглядеть с точки зрения человека? А как будет обращаться к словарю компилятор?В наших палестинах произрастают кулибины, левши, келдыши. Линусы — это не у нас.
✅ 2019/11/30 20:55, Сергей #36
База данных. Словарь будет в текстовом формате для удобства добавления новых слов и редактирования. На каждой строчке слово и перевод.✅ 2021/03/26 14:17, Виталий Монастырский #37
В рамках данной темы обсуждения, считаю, что здесь не идет речь о создании нишевого языка программирования. Нишевые ЯП, как правило, довольно успешно создаются специалистами, которые работают в соответствующих сферах, а так же компаниями, которые в них заинтересованы. Здесь однозначно речь идет именно об универсальном языке программирования. То есть таком, который применим в наиболее широком спектре решаемых программистами задач.Считаю, что на сегодняшний день скопилось более, чем достаточно опыта для того, чтобы собрать подобную концепцию и воплотить её в жизнь. На данный момент проблемы с созданием такого языка программирования следующие:
1) Априорный критический настрой. Современный мир нас всех погрузил в некоторый мрак сознания, из-за которого, в большинстве случаев, люди просто не могут договориться друг с другом ни по какому поводу. Для решения этой проблемы, изначально входя в подобный проект, нужно снизить индивидуальный порог критики в отношении идей других людей и настроиться на поиск компромиссов.
2) Несогласованность разработчиков. Разный практический опыт, а иногда и необоснованное влияние мнения авторитетов, приводит к тому, что разные разработчики могут диаметрально противоположно смотреть на различные вопросы в архитектуре языка и даже в его фундаментальных принципах. Для решения этой проблемы необходимо собрать закрытую группу, которая изначально будет сходиться хотя бы в некотором числе базовых идей и в дальнейшем согласует все вопросы по концепции языка. То есть — группа нужна изначально, так как приход в проект каждого нового участника будет сопровождаться повторением процесса пересмотра всех концепций языка. А так как идеальный ЯП создать априори невозможно, в конечном итоге проект растянется ещё на этапе концептуального наполнения настолько, что просто никогда не будет завершено. Значит нужно сразу собрать некую группу энтузиастов, и закрыть её до тех пор, пока они не выдадут законченный концепт. По ходу создания концепта могут поступать новые предложения от других разработчиков, которые можно будет рассмотреть уже после создания концепта, хотя на сегодняшний день, я считаю, уже достаточно опыта для того, чтобы собрать вполне вменяемую концепцию сразу.
3) Отсутствие финансирования. Естественно, что на разработку нового ЯП никто никаких денег не даст. Значит все придётся делать исключительно на голом энтузиазме и строго в свободное время. Значит те, кто не готов тратить свое время, сразу же исключаются из проекта.
4) Сложность задачи. На самом деле создание ЯП по типу TunyC — не проблема даже для одного разработчика. Но создание современного ЯП, которым можно было бы пользоваться для решения практических задач — это огромный кусок работы. Тем более, если делать его с умом, с изначально продуманной архитектурой и всеми согласованными вопросами, от принципов наименования до распределения файлов в дереве проекта. А это значит, что изначально создать ЯП с уровнем возможностей современного С++, Java или Python — просто не реально. Отсюда исходит понимание того, что язык нужно разделить на уровни. То есть на первом уровне должно быть некоторое максимально примитивное микро-ядро, которое на уровне ассемблера способно решить любые задачи, доступные на большинстве архитектур, но которое будет лишь первым уровнем абстракции в отношении остального языка. Это будет предельно краткий и примитивный low-синтаксис для разработчиков языка. Он будет что-то вроде кубиков, из которых мы потом сможем собрать любые другие концепты. На втором уровне будет создаваться базовый синтаксис языка, с которым уже будут работать все остальные программисты. Он будет шире и в его сферу будет входить достаточное для большинства задач количество примитивов. Ну и третий уровень будет позволять программистам создавать свои собственные структуры языка, используя возможности второго уровня, которые, естественно, в него нужно будет изначально заложить. (На этот счет у меня есть кое-какие идеи). Таким образом мы получим структуру языка, которую вполне реально разработать даже небольшой группе разработчиков в свободное время, без каких либо финансовых вливаний со стороны. Так же это позволит в приемлемые сроки выпустить прототип для широкого пользования, а не затягивать эту песню на долгие 20-30 лет.
5) Высокие требования по количеству готовых инструментов. Да, сегодня без большого числа библиотек, доступных языку из коробки — никуда. А это значит, что необходимо создать транслятор, который позволит без потери важных данных об исходном коде (наименования объектов и структура программы) транслировать готовые библиотеки, написанные на популярных языках (пока за основу достаточно взять тот же С), в некий универсальный ассемблерный код, а затем из этого кода сразу портировать их в исходный код на нашем ЯП. Учитывая запутанность современных ЯП, это дело не лёгкое, но возможное. Тем более, что некоторые наработки в этом плане уже существуют.
6) Необходимость мультиплатформенности. Да, изначально ЯП должен позволять выполнять сборку под максимально доступное количество платформ — от микроконтроллеров до серверных станций. Только так можно завоевать популярность и тем самым дать языку шанс на выживание и дальнейшую доработку. Из всех мне известных инструментов, на сегодняшний день, как я считаю, подобные возможности предоставляет только LLVM. Конечно, это не родной компиллятор/интерпретатор, но на начальном этапе он позволит запустить язык в жизнь с гораздо меньшими затратами усилий.
7) Противоречивость требований и исполнения. Многие требования к языку программирования изначально противоречивы. Например. С одной стороны для читабельности и понимания кода он должен быть максимально сжат и прост, а с другой, по той же причине, наименования используемых элементов должны быть максимально подробны, а значит — длинны. И подобных противоречий довольно много. Решить их на уровне концепции языка невозможно. Их вообще невозможно решить на уровне синтаксиса, поэтому в других языках программирования изначально выбирают ту или иную сторону "силы" в каждом отдельном вопросе, или идут на некоторые компромиссы. Но и тот и другой вариант плох.
Раз задачу нельзя решить на уровне синтаксиса, значит её нужно вынести на более высокий уровень и решать на нём. Моё предложение простое — среда разработки. Изначально необходимо, чтобы идея среды разработки включала требования и задачи, решаемые языком. Без этого просто никак. Например, применительно к тем же наименованиям элементов, IDE вполне может решать эту задачу путём сокрытия длинных имен элементов и заменой их на аббревиатуры или сокращения. В случае, если необходимо посмотреть расшифровку имени, среда должна позволять при наведении на аббревиатуру курсора, выдавать полное имя элемента в виде подсказки. Точно таким же образом она может обрабатывать комментарии и высвечивать их в отдельном окне в виде уже готового описания алгоритма программы. То есть, формально исходный код программы сам по себе будет выполнять все обычные функции ЯП, но без IDE читабельность такого кода будет весьма проблематичной, а вот IDE как раз и будет решать все проблемы по разделению кода и приведению его к удобоваримому виду. На этом же этапе можно решить и множество других задач, например таких как мультиязычность платформы, позволяющая переводить исходный код на родной язык разработчика и многое другое.
8) Широта задач. Для современного языка программирования требуется решить большое количество задач, что является практически неподъемным за номинально допустимое время для небольшой группы энтузиастов. Для решения этой задачи необходимо принять некоторый ограниченный список максимально востребованных требований и разрабатывать концепцию языка с учетом всех этих требований. Однако, для практической реализации языка, изначально необходимо выделить из этого списка тот сокращенный набор, который позволит создать законченный и работоспособный прототип и заниматься только им. Остальные же требования внедрять уже после его запуска. Например, многие парадигмы программирования имеют свою пользу, но реализовывать изначально и функциональное программирование, и ООП, и рефлексию и многое другое — просто не реально. Значит должно быть выделено предельно сжатое подмножество того, что наиболее необходимо, и только эти элементы языка нужно включать в процесс разработки прототипа.
СУММИРУЕМ.
а) Необходима команда энтузиастов, которые в большей или меньшей степени уже имеют согласие по общим принципам и готовы идти на компромиссы и уступки ради общего дела. Команда должна собрать концепцию в закрытом режиме. По ходу пьесы можно принимать идеи со стороны, но решение по ним должна принимать уже сформированная команда, иначе мы так никогда ни до чего не дойдём.
б) Принимаем концепцию многоуровневого языка и разрабатываем концепцию ядра, ещё более простого, чем С, но в то же время, позволяющее стать основой для более широкого синтаксиса. Это будет закрытый уровень языка, на котором будут писать только разработчики. Без этого шага дойти до результата так же будет очень тяжело и долго.
в) Принимаем на вооружение в качестве первоначального инструмента LLVM IR, как базовый ассемблерный синтаксис, на который мы будем опираться в ходе разработки.
г) Разрабатываем принципиальную модель обратимого транслятора, который позволит транслировать код в LLVM IR и обратно, с учетом служебных комментариев, в которых будет храниться структура изначальной программы, наименования переменных, схема алгоритма и т.д. ... и вот мы уже имеем рабочее ядро, которое позволит создавать примитивы второго уровня ЯП.
д) Разрабатываем односторонний транслятор С в LLVM IR, который будет сохранять структуру программы, в соответствии с требованиями нашего первичного двустороннего транслятора.
е) Транслируем наиболее важные библиотеки из С сначала в IR, а затем в исходный код нашего ЯП. ... и вот мы уже получаем множество готовых инструментов, которые могут быть использованы на первых порах в практической работе.
ж) Разрабатываем базовый синтаксис ЯП для программистов
✅ 2021/03/27 02:53, zx_90 #38
Согласен с предыдущим комментарием процентов на 80. Поэтому сначала немного критики, а затем свои предложения. Критика:- Абсолютно согласен, что разработка современного промышленного языка программирования невозможна в одиночку. Значит нужна команда, значит надо уметь иногда наступить на горло собственной песне, научиться находить компромиссы, договариваться. Я как раз хочу найти группу единомышленников, с которой можно было бы разработать такой язык.
- Не совсем понятна концепция многоуровнего языка программирования (назовем эти уровни ассемблер, ядро и язык). Если ассемблер — это LLVM IR, ядро — это первая версия языка, а язык — это первая версия плюс разные свистоперделки, то тогда это хороший вариант. Если ядро и язык — это два разных языка, то боюсь на написание двух разных языков просто уйдёт в два раза больше времени. Тогда для ядра лучше взять уже готовый язык и программировать сразу на нём.
- С библиотеками гораздо проще можно поступить. Непонятно, зачем их транслировать на разрабатываемый язык. У нас грубо говоря есть готовая библиотека в виде *.dll файла и заголовочники в виде *.h файлов. Достаточно будет "перевести" только заголовочные файлы. Тогда пункты г, д, е не нужны, а вместо них достаточно разработать прямой транслятор и затем трансляцию заголовочников.
Теперь предложения. Сразу скажу, что уже начал разрабатывать свой язык, так как не знаю когда найду команду и найду ли вообще. Есть черновик стандарта, исходный код, сайт. Их можно использовать как основу, либо просто как источник идей для обсуждения. Но обо всём по порядку.
1) Общая концепция. В разработке языков программирования мы находимся в стадии догоняющего развития. Это с одной стороны сильно облегчает работу, так как есть уже готовые теоретические и практические наработки. Можно взять много готовых вещей, учесть ошибки, обойти подводные камни. С другой стороны, это ограничивает полет фантазии, потому что во основном надо просто повторить, что уже было. Не нужны никакие изотерические языки программирования и уникальная архитектура компилятора. Надо взять наиболее популярные языки, проанализировать их и создать что-то похожее на один из них или промежуточный между ними. С архитектурой примерно также. Берём книжку а-ля "Как писать компиляторы" и на её основе пишем компилятор. Всё по классике: лексер, парсер и т.д. и т.п. Главное реализовать всё это на качественном уровне. Ну и другие основные моменты примерно в таком же ключе.
2) Для кого/чего писать язык? Ниши можно по-разному делить. Я очень крупными мазками опишу, так что не сильно придирайтесь. Грубо говоря, я разделил ниши 4 категории:
1 — assembler, C, C++ (компиляторы, типизация, ручное управление памятью). Работа с микроконтроллерами, драйверами, расчеты и прочие низкоуровневые штуки + ААА игры.
2 — Java, C# (компиляторы?, типизация, сборщик мусора). Корпоративные и мобильные приложения, игры.
3 — Python, Basic, 1С (интерпретаторы, отсутствие типизации, сборщик мусора?). Корпоративные приложения, небольшие скрипты и макросы для автоматизации процессов.
4 — HTML, CSS, Javascript, PHP (интерпретаторы, отсутствие типизации, сборщик мусора?). Выделил отдельно, так как сайтостроение — отдельная вселенная.
В первой категории русский язык программирования не будет сильно полезным. Если очень кратко, то из-за того, что микроконтроллеры производятся за границей, сложные и низкоуровневые библиотеки универсальны и лучше писать мировым сообществом, а локализовать только заголовочники.
Вторая категория очень интересна. У нас есть приложения для предприятий, банков, в том числе и мобильные, игры, различные редакторы. Если такие приложения пишут русскоязычные команды (даже для заграницы), то такой язык будет полезен.
В третьей категории также есть поле для деятельности, но возможно надо поискать нишу. Бухгалтерия уже занята 1С, а вот что на этом поле ещё осталось — вопрос.
Четвёртая категория также интересна. Там крутится много художников и верстальщиков, которым русский язык программирования сильно облегчил бы жизнь. Но лично я с WEB не сильно знаком, как конкретно реализовать реально полезный язык в WEB, я не могу сказать.
В общем, я для себя выбрал 2-ю категорию: некий аналог C# и Java. У меня пока скорее выходит C++ с умными указателями, что позволяет немного отщипнуть от ниши из первой категории.
3) Синтаксис должен поддерживать не русский язык, а русскую раскладку клавиатуры. То есть, в синтаксисе языка очень нежелательно иметь фигурные скобки, знаки больше/меньше, знак $. То есть всё то, что заставляет постоянно переключать раскладку. Это очень сильно утомляет, если в таком режиме работать целый день. Такой язык не взлетит.
4) Упор на уже существующие библиотеки. Очень важно, чтобы язык позволял достаточно легко подключать сторонние библиотеки, написанные на других языках программирования. Без хорошего набора библиотек в современной разработке делать нечего.
Вот такие получились тезисы.
Немного о том языке, который я сейчас разрабатываю. Название Картарика или Картарский язык. С открытым исходным кодом, пишу на C с использованием библиотеки LLVM. Черновик документации и ссылку на исходный код можно найти в группе в ВК. Там же можно со мной связаться:
https://vk.com/public197948706
✅ 2021/03/27 21:16, Виталий Монастырский #39
Да, совершенно верно, имеется ввиду один и тот же язык, но разделенный на примитивный и пользовательский уровень. Ну совсем грубо, в ядре не будет даже циклов, они будут реализовываться комбинациями условного и безусловного перехода. Разные комбинации будут соответствовать различным же вариантам оператора цикла, который будет применяться в пользовательском языке.Что это значит... это значит, что пользователь тоже сможет организовать цикл с помощью примитивных операторов if и goto, но это будет востребовано только в тех случаях, когда нужно будет построить какую-то сложную для классических операторов цикла систему, которая в тоже время гораздо лаконичнее получается через банальные проверки и метки возврата. Лично я иногда в Go так и делаю, и уверяю Вас, что такие случаи периодически случаются.
Такой код просто не будет никаким образом изменяться транслятором и будет включен в компилируемый исходник в своем изначальном виде. Все же остальные операторы цикла из пользовательских исходников будут заменены транслятором на их аналоги, собранные из if-ов, меток и goto переходов. И так будет с каждым! :)
Что это дает? Это позволяет изначально разработать максимально сжатый и примитивный синтаксис, сделать для него компилятор, отладить и получить в приемлемые сроки рабочий инструмент, а затем уже по ходу пьесы потихоньку добавлять плюшки. При этом данные плюшки будут не в виде библиотек, а в виде дополнений к транслятору. Все можно будет собирать блочно, не разрушая общую работу транслятора.
Так же нельзя забывать о том, что имея подобную систему, мы значительно облегчаем возможности портирования нашего чуда на различные платформы, ведь чем более краток базовый синтаксис, тем меньше труда требует его перенос на другие архитектуры, я уже не говорю о том, что реализация примитивных команд на любой архитектуре проста, а сложные команды требуют гораздо больше усилий, времени и тестирования. Как Вы помните, именно этим Си взял всех остальных в оборот — он был ко всему остальному намного проще многих других языков и весьма близок к ассемблеру, что облегчило его портирование на различные платформы, а значит и популярно, а отсюда и развитие.
Если кого-либо испугает такой муторный вариант ядро-языка, то не нужно особо напрягаться, по большей части он будет написан только один раз, когда будет создаваться родной компилятор, ну и может быть на первых порах, пока не будет готов полноценный транслятор, кто-то захочет на нем написать какие-то небольшие скрипты или программки... Так что все эти мучения не на долго. Дальше с ядро-синтаксисом будет возиться только транслятор и все исходники для компилятора будет собирать в автоматическом режиме. В лучшем случае мы сможем на них просто поглазеть, если кому будет интересно. Но они будут довольно объемными и больше похожими к какому-нибудь высокоуровневому ассемблеру.
В общем я считаю, что у нас по сути вообще другого выхода нет — только такой путь. Иначе создание языка растянется на годы. Не нужно забывать, что всем нам ещё и кушать что-то нужно, пока вся эта канитель будет тянуться в долгий ящик.
Далее по пунктам.
Считаю, при всей моей патриотичности, что при создании международного языка вообще нет смысла заморачиваться по поводу русского синтаксиса. Я лично решил этот вопрос просто — у меня синтаксис международный знаковый, но он скрытый, его видеть никто не будет. Вместо него в последствии IDE будет подставлять операторы на родном для программиста языке и их же в таком виде принимать.
То есть грубо, русский программист пишет: если то иначе все, IDE-шка это принимает и показывает именно в таком виде, но в исходный код вносит: ? -> ?? ->. Когда эту программу захочет рассмотреть американец, он загонит её в IDE, в котором у него стоит по умолчанию английский язык, и его IDE-шка превратить знаки вопроса из исходников в: if then else. И так с каждым языком. Библиотека операторов весьма мала, так что перевести их на десяток-другой языков не будет никакой проблемы. Тем самым я просто отсекаю все проблемы с языками и в тоже время не привязываю синтаксис и концепцию разработки к конкретному национальному языку, как это делает уважаемый автор, пытаясь из-за русской раскладки лишить нас кучи специальных знаков и обеднить тем самым синтаксис до неприличия.
НО! Это в идеале, когда деревья снова станут большими. А на первых порах мы просто замучаемся реализовывать подобное, я уже не говорю, что IDE-шка, даже на базе уже готовых продуктов — это отдельная песня. А значит, концепция мультиязычности просто остается в виде идеи до лучших времен, а первую версию делаем на банальной латинице и не заморачиваемся. Наша задача получить готовый продукт, а все мы здесь прекрасно владеем английскими операторами. Думаю годик-другой потерпим. В данном случае — получить хороший инструмент гораздо важнее, чем мечтать о будущих чудесах.
Так, чтобы сразу не забыть. Зачем нужна трансляция библиотек... все очень просто — качественный компилятор должен быть раскручен. А я, дак и вообще считаю, что нужно ввести новую тему — абсолютную раскрутку компилятора. Сейчас пока не буду объяснять что это за зверь и с чем его едят, но это единственный с логической точки зрения, способ абсолютной валидации корректности исходного кода компилятора и самого языка. Обычная раскрутка не полноценна и стопроцентной проверки не дает, чему свидетельство — куча багов ВО ВСЕХ языках программирования, которые я знаю. Ну разве что в мини-бейсике я их не находил. А это значит, что все библиотеки, которые будут использоваться, если не сейчас, то в перспективе должны быть полностью транслированы на наш чистый язык. Но это потом, ясное дело...
По третьей категории сразу скажу, что там море работы. Сейчас на Python уже пишут сайты и он везде лидирует по разработкам связанным с машинным обучением. Так что в той нише, что сейчас, что на будущее, работы — мама не горюй...
По четвертой категории... Это тоже ниша, но она сугубо интерпретаторская и её занять тоже будет весьма полезно (как сейчас это делает Python), но для этого нужна рантайм библиотека, заточенная под это дело, на подобии реакта или джанго. А её писать — отдельная история, так что это все перспективы.
Я вообще считаю, что нужно разработать единый алгоритмический язык и развивать его во всех направлениях, начиная с системного уровня. Так что вопрос про ниши сразу можно забыть — направление в перспективе на все ниши.
3) Пока все языки, которые взлетают — как раз написаны на латинице. Русская раскладка крайне обеднит синтаксис, а это сделает его убогим, избыточным и плохо читаемым. Считаю, что нужно немного потерпеть и первое время работать в привычном режиме. Что касается частых переключений, то я лично переключаюсь только для написания комментариев, да и то только потому, что реально плохо знаю английский и пока ещё не поднаторел так, чтобы писать все комменты на нём. Но даже в этом случае самое простое, что я знаю — пишу на английском, чтобы избежать проблем с этой самой раскладкой.
НО!!!Если вдруг я не правильно понимаю Вашу проблему и она заключается в том, что Вы просто банально владеете слепым набором в русской раскладке и не владеете в английской и это вызывает у Вас проблемы, то... u menya estq rewenie. :) Я давно и кардинально решил для себя этот вопрос, просто разработав обратную латинскую раскладку, в которой все латинские буквы находятся на месте русских. R там где Р, D там где Д, V tam gde В.
Так что если проблема только в этом — могу просто дать свою раскладку. Она имеется под XP, работает под 7 и так же имеется специальный файлик для Линуха, ибо там сие реализовано немного по-другому. Так что если что — обращайтесь, там всего пару символов нужно будет подучить, а все остальное — с коробки на автомате пойдет, проверено многими людьми.
4) Ну это понятно, однако нужно понимать, что даже в начале проекта для этих целей потребуется специально написанный компилятор, который сможет их линковать с файлами на нашем языке. А это, как известно, даже в родных языках геморрой ещё тот. В частности поэтому я решил идти немного другим путем. Я пока пишу язык на том языке программирования, который уже имеет некоторый набор библиотек и они будут подключаться автоматом без всякой там линковки, заголовочных файлов и прочих танцев с бубнами. А в перспективе, конечно, можно будет их портировать на наш язык. Для этой цели я пишу отдельный транслятор, который сможет переписывать код из одного языка на другой.
По поводу Картарики. Ну, с русским я уже все объяснил, для международного языка это не подойдет, как бы нам всем ни хотелось.
Второе. База на С — это сразу ужас, потому что он унаследует все баги и проблемы С. Танцевать с бубном каждый раз при сборке проекта ни у меня ни у кого-либо ещё никакого желания нет. А это неизбежно. В Вашем случае, единственная причина его создания — это русский язык. В остальном — это будет почти тот же С. Доказательства дальше — тот же сборщик мусора, всего-лишь немного более строгая типизация и запрет кольцевых зависимостей. В остальном тот же С++.
Да, база библиотек там большая, но они все такие же кривые и глючные, как и все, что когда-либо было написано на С. По этой причине я давно ушел на более продвинутые и продуктивные языки, в которых решены многие детские болезни С, хотя добавлены свои новые... из-за чего и приходится заниматься созданием своего языка. Но все-равно, немного кривоватый, но едущий сам без толкателя мопедик всегда намного лучше, чем старый поломанный велосипед, который нужно разгонять как самокат и запрыгивать на раму, пока он катится с горки.
Дальше по отдельным пунктам.
Я концептуально давно разработал концепцию Абсолютной типизации, и считаю, что никакая строгая её не заменит.
Второе, сборщик мусора — самое худшее решение, которое только может быть, и вызвано оно именно отсутствием АСУП, которую нужно просто написать и включить в стандарт языка.
Третье — ООП — это отдельная парадигма программирования, которая иногда полезна в отдельных случаях. Создание ООП языка — это изначально исключительно специализированная для фанатов ООП, которые не в состоянии писать нормальный алгоритмичный процедурный код и гонятся за дешевыми вау-эффектами. С таким подходом универсальный ЯП не создать просто по умолчанию. ООП может быть включена ПОТОМ, после того, как будут реализованы все остальные необходимые для языка системы, как одна из поддерживаемых парадигм, и то над ней ещё нужно хорошо подумать, потому что господа фанатики ООП превратили современный ООП в такое чудовище, что ни поднять, ни обхватить умом.
Так что если у Вас основная направляющая взята не на создание языка, а на реализацию ещё одного ООП движка любой ценой, я точно ничем не смогу Вам помочь.
Ну вот, пожалуй, и все по Вашему ответу. Я в контакте подписался на Вашу группу, но сразу скажу, что я им не пользуюсь по объективным причинам, так что писать туда мне безполезно.
Ну и вот сразу ссылочка на мой пост в контакте по поводу новой раскладки клавиатуры, можете зайти, качнуть, поставить и попробовать. Если нужна будет под линукс, дайте знать — я отдельно скину.
https://vk.com/flamehowk?w=wall402408127_6
✅ 2021/04/01 23:00, Александр Коновалов aka Маздайщик #40
Второе, сборщик мусора — самое худшее решение, которое только может быть, и вызвано оно именно отсутствием АСУП, которую нужно просто написать и включить в стандарт языка
Предлагаемое Вами АСУП имеет ли отношение к стратегии управления памятью, предложенной Рафаэлем Прустом ASAP (As Static As Possible)? ASAP предполагает полностью статичное управление памятью без сборки мусора и счётчиков ссылок. В работе есть изъяны (недостаточная проработка изменяемых данных и параметрического полиморфизма), но в целом она интересная и стоит изучения. По ссылке выше диссертация, которая может быть сложна для неподготовленного человека.✅ 2021/04/04 18:04, Александр Коновалов aka Маздайщик #41
В предыдущем комментарии можно включить ссылку?✅ 2021/06/10 22:07, Comdiv #42
А что насчёт своего проекта? Недавно отмечали 10-летие. Если провести экстраполяцию с учётом нынешней готовности, через какое время будет готово что-то осязаемое из похожего на намеченное?✅ 2021/06/11 00:09, Автор сайта #43
На моих глазах десятки проектов бодро стартовали, но так же быстро угасали. Да, чаще всего компилятор/интерпретатор был готов. Вот только что нового мог сказать миру автор свежеиспечённого языка? Как правило, ничего. Чаще всего новшества исчерпывались синтаксисом. Не удивительно, что язык оказывался никому не нужен. Естественно, энтузиазм быстро угасал.Поэтому торопиться с новым синтаксисом старых языков — дело безнадёжное. Я уже касался этой темы тут и тут. Без критической массы нововведений, без новых идей в семантике старт в разработке легко станет фальшстартом. Сегодня прочитал:
Михаил Булгаков работал над романом «Мастер и Маргарита» 10 лет. Все это время он редактировал и дорабатывал рукопись. На обложке последней тетради автор сделал надпись: «Дописать раньше, чем умереть».
Последние слова надо держать в уме.✅ 2021/06/17 21:10, Comdiv #44
Начались и неуспешно закончились, конечно, многие проекты, но ещё больше так и не начались. И для того, чтобы переделывать и доделывать, нужно чтобы было что переделывать.А такой подход, на мой взгляд, предопределяет неуспешность проекта с точки зрения результата, и если и подходит для рассуждения о том, как создать язык программирования, то в той её части, которая должна называться, как не надо создавать язык программирования. Кстати, нет ли уже такой заметки?
✅ 2021/06/18 13:57, Автор сайта #45
Да, Вы правы, за 10 лет можно было сделать больше. Тому есть и субъективные причины. И сложность недооценил, и собственные возможности переоценил. В ближайших планах — заметки по функциональному программированию. А планов написать «Как не надо создавать язык программирования» пока нет.✅ 2021/08/19 19:38, kt #46
Попалась тут мне на глаза заметка «Нельзя так просто взять и вычислить абсолютное значение» (https://habr.com/ru/post/573080/), где автор на Java пытается создать функцию ABS для чисел в формате IEEE-754. Он показывает подводные камни и даже предлагает использовать этот пример, как ловушку на собеседовании. Статья получила одобрение читателей.Понятно, что примеры могут быть самые разные: тривиальные, бессмысленные, каверзные и т.п. Но я бы хотел обратить внимание, что с точки зрения, каким должен быть язык программирования, это означает, что в данном случае в языке, вообще говоря, не хватает встроенных функций. Тех, которые бы не допустили подобных затруднений вообще. При этом автор начинает с использования операции «унарный минус» и приходит, в конце концов, к правильному решению — гашению знакового разряда. Но ведь операции «унарный минус» и «абсолютное значение» — близкородственные. Например, в компиляторе PL/1-KT они реализованы (когда число IEEE-754 уже находится в стеке) так:
унарный минус:
XOR B PTR [RSP]+7,80Hабсолютное значение:
AND B PTR [RSP]+7,NOT 80HКак же оказалось, что имея в языке минус, не имеется абсолютного значения? В нормальном языке эта пара действий не должна быть разорвана. В PL/1 почти все встроенные функции имеют пары, как в детской карточной игре в «Акулину». Такая парность способствует лучшему охвату требуемых программисту инструментов.
P.S. Гашение знакового разряда, которое автор статьи родил на Java, на PL/1 выглядело бы так:
abs:proc(x) float(53);Никаких преобразований double в bit не требуется, но, конечно, требуются знания о формате IEEE-754 и о порядке байт в x86.
dcl (x,y) float(53),
b bit(8) def(y+7);
y=x;
b &= '7f'b4;
return(y);
end abs;
✅ 2021/08/19 20:34, Gudleifr #47
2 ktТут в принципе нерешаемая проблема — иметь в языке "язык выражений", ориентированный на конкретный процессор, или на "универсальную модель". Видимо, проще всего вообще отделить "язык выражений" от "языка операторов" и иметь оператор переключения с одного типа выражений на другой (третий, четвертый...)
✅ 2022/05/06 13:28, Лис #48
Статья про языки: «Доказательное программирование»✅ 2022/05/06 13:56, Gudleifr #49
Статья про языки
Бурление планктона. Будьте проще. Один пост — одна мысль. Отсылка к "анализам" за мысль не считается.✅ 2022/05/06 16:36, Автор сайта #50
Статье больше года, перечитывал её не раз. Главный посыл «доказательного программирования», на мой взгляд, — это необходимость доказать, что новый изобретаемый язык лучше, чем все старые. Что он, допустим, сокращает расходы на разработку. То есть новый язык должен пройти клинические испытания и доказать большую эффективность. Вот тогда он имеет право на жизнь. А всё остальное — это очередное обнаружение фатального недостатка.Примерное об этом я писал в «философии»:
Разрабатывая язык, нужно постоянно задавать себе вопрос: «А что в нём есть такого, чтобы заинтересовать будущих пользователей?» Для успешности новому языку программирования нужна критическая масса удачных нововведений.
Доводилось дискутировать с одним разработчиком собственного языка. Высказал ему мнение, что шлифовка синтаксиса — недостаточно веский повод для появления нового языка, что нужны новые идеи. На это он отвечал, что новый синтаксис — вполне достаточный повод. Потом читаю его статью на Хабре о своём языке. Критики от читателей было много. Было бы интересно узнать, защитил ли он диссертацию на эту тему.Вообще языков, в которых отсутствуют принципиальные новшества, много. В перечне отечественных — почти все такие, за редким исключением. Языки с виду новые, а подходы к их устройству — совершенно старые, что дало повод порассуждать о признаках устаревшего языка.
На Хабре довольно-таки много статей о новых языках от их создателей. Скоро такие статьи надо будет начинать словами: «Извините люди добрые, что я к вам обращаюсь. Я создал свой язык программирования». С другой стороны, по закону Дарвина среди сорняков могут прорасти неплохие зёрна.
✅ 2022/05/06 16:53, Gudleifr #51
С другой стороны, по закону Дарвина среди сорняков могут прорасти неплохие зёрна
Вряд ли. Ведь единственная современная творческая мысль создателей языков: "Еще он будет автоматически делать то, что я не понимаю, как делается".Мы, в конце концов, живем в среде, где возможности компьютеров резко сокращаются, нам нужны не новые языки, а средства не потерять старые наработки.
✅ 2022/05/06 18:11, MihalNik #52
необходимость доказать, что новый изобретаемый язык лучше, чем все старые.
Языки часто решают слишком разные задачи. Не может Хаскел быть вообще лучше чем ассемблер и наоборот. Только в контексте определенных задач.Для успешности новому языку программирования нужна критическая масса удачных нововведений.
Это коммерческая успешность, но целями разработки какого-то языка могут быть совершенно иными.Например, испытание какого-то отдельного механизма.
✅ 2022/05/06 21:37, Автор сайта #53
Мы ... живем в среде, где возможности компьютеров резко сокращаются
Не приведёте факты?нам нужны не новые языки, а средства не потерять старые наработки.
Регулярное резервное копирование не поможет в сохранении наследия? Или имеете в виду, что старые наработки уходят вслед за старыми людьми?Не может Хаскел быть вообще лучше чем ассемблер и наоборот. Только в контексте определенных задач.
Да, у каждого языка — своя ниша. Внутри этих ниш есть конкуренция. Например, в нише языков системного программирования конкурируют C, C++, D, Rust и другие. В нише Web-разработки свои языки. Новоявленные языки пытаются выдавить конкурентов из ареала обитания. Для этого им надо доказывать, что они лучше старых. В свой время говорили, что D — убийца C++. Потом этот титул перешёл Rust. |
Это коммерческая успешность
Наверное, лучше сказать просто успешность. Не знаю примеров, чтоб на языках разбогатели. Ну может на Хаскелле получили косвенные бонусы, защитив диссертации. А так языки бесплатны. За деньги продают не языки, а компиляторы. И то далеко не все.испытание какого-то отдельного механизма
Ну да, есть исследовательские языки. Например, не очень давно была закрыта разработка языка Cyclone. Объявлено, что проект был исследовательским, цели исследования достигнуты, на этом закругляемся. Наверняка есть другие проекты, например, в вузах. От Л.В. Городней знаю, что у неё есть экспериментальный язык.✅ 2022/05/06 22:10, Gudleifr #54
Не приведёте факты [сокращения возможностей компьютеров]?
Попробуйте найти книжку 80-х про компьютеры (например, на моем форуме) и сравните. С тех пор сильно усовершенствовались средства писания программ, но сами программы стали гораздо слабее. В 60-х американцы долетели до Луны с тем, что по нынешним временам не потянет даже на калькулятор. А современный компьютер лишь позволил послать автомобиль "примерно в сторону Марса". Общаясь с современными IT-шниками я понял, что единственное их занятие — это приведение в "безопасный" и "переносимый" вид алгоритмов 70-х. Причем проверка показала, что этот перенос сводится лишь к обфускации и часто вызывает потерю смысла программы.Или имеете в виду, что старые наработки уходят вслед за старыми людьми?
Гораздо быстрее. Например, недавно на одном из форумов один из стариков спросил, как ему восстановить рабочее состояние его старых FORTRAN-наработок. И все рекомендованные ему способы весили гораздо больше, чем переписывание всех его алгоритмов на совершенно новый язык с тщательной перепроверкой точности и погрешности вычислений.https://gudleifr.forum2x2.ru/t138-topic
Я уже раньше это излагал, но там добавил картинок.
✅ 2022/05/07 08:22, MihalNik #55
Гораздо быстрее. Например, недавно на одном из форумов один из стариков спросил, как ему восстановить рабочее состояние его старых FORTRAN-наработок. И все рекомендованные ему способы весили гораздо больше, чем переписывание всех его алгоритмов на совершенно новый язык с тщательной перепроверкой точности и погрешности вычислений.
Вполне закономерный итог типичного программисткого подхода — "работает — не трогай", известного у работодателя как экономия на штате сотрудников. Копировать исходный код программы недостаточно — нужно копировать и поддерживать её окружение — аппаратную часть или её эмуляторы. Нужно поддерживать штат специалистов.В 60-х американцы долетели до Луны с тем, что по нынешним временам не потянет даже на калькулятор. А современный компьютер лишь позволил послать автомобиль "примерно в сторону Марса".
Ну долетели и флаг им в... грунт удалось воткнуть. Стоимость лунной программы была колоссальной нагрузкой для экономики. Исчез ментально конкурент — свернулась лунная программа.Общаясь с современными IT-шниками я понял, что единственное их занятие — это приведение в "безопасный" и "переносимый" вид алгоритмов 70-х. Причем проверка показала, что этот перенос сводится лишь к обфускации и часто вызывает потерю смысла программы.
Потому что ПО оказывается недостаточно документированным из-за разделения труда — узких специалистов научили писать программы на готовом оборудовании и ПО, но не научили делать, поддерживать и воспроизводить эти средства разработки. Надо учитывать, что если сгорит микросхема по технологии несколько нанометров — её никто не сможет починить, технологии на это не рассчитаны в принципе. Так что с ПО все гораздо лучше.Что касается обфускации — надо ещё заметить, что многие эти старые языки не являются полностью документированными, а их синтаксис — математически строгим. Там огромное количество неопределенного поведения и зависимостей от платформы, которые крайне сложно перенести. Проблема усугубляется тем же в "более современных". Эти толстенные расходящиеся контексты при переводе в исходниках нигде наглядно не выражены, строго формально не обработаны и не задокументированы.
✅ 2022/05/07 10:09, Gudleifr #56
Вполне закономерный итог типичного программисткого подхода — "работает — не трогай",
Дык, по условиям задачи оно не работает! За последние 30 лет перестало работать гораздо больше, чем появилось нового. Например, 20 лет назад я ещё вполне мог получить халявный хостинг с доступом по ssh.Там огромное количество неопределенного поведения и зависимостей от платформы, которые крайне сложно перенести
Плохо не это, а то, что с этим не умеют справляться.✅ 2022/05/07 11:42, MihalNik #57
Дык, по условиям задачи оно не работает!
А кто-то ранее доказал что оно будет работать и вообще переносимо? Все лицензии open-source — отказ от отвественности. Нельзя просто так взять и прописать какой-нибудь машинно-зависимый тип целого числа думая, что оно будет работать на машинах разной разрядности. Потому что где-то алгоритм может быть прибит на переполнение, которое не сработает, а где-то нелинейные зависимости по размерности.Плохо не это, а то, что с этим не умеют справляться.
Потому что это очень дорогое удовольствие. Это тянет на целую науку, нужно разрабатывать средства, специальные среды и языки, обучать специалистов. Плюс унаследованная низкая культура кодирования. Неспроста с нуля делать дешевле. Вы просто игнорируете экономическую стоимость труда тех специалистов и сопровождения продукта.мог получить халявный хостинг с доступом по ssh
Ну так за поддержку халявы для Вас должен кто-то платить. Зато сейчас можно сделать небольшой форум чуть ли не в два щелчка или собрать миллионы подписчиков без особых затрат на ПО и оборудование — современные технологии это позволяют. Все дело в спросе и цене.✅ 2022/05/07 12:25, Gudleifr #58
А кто-то ранее доказал что оно будет работать и вообще переносимо?
Вы путаете "не работает, потому, что больше никому не нужно" и "не работает, потому, что мы больше не можем себе это позволить".Потому что это очень дорогое удовольствие
Нет, просто мы пошли другим путем. Назад.Плюс унаследованная низкая культура кодирования
Высокая культура кодирования === обфускация.Зато сейчас можно сделать небольшой форум чуть ли не в два щелчка
В один. Что я и сделал. Но цена за это — нужный мне интерактив приходится тащить через Альпы, подобно Суворову.✅ 2022/05/07 15:08, MihalNik #59
Вы путаете "не работает, потому, что больше никому не нужно" и "не работает, потому, что мы больше не можем себе это позволить".
Тут нет путаницы. Когда одним станет не нужно — другие уже не смогут себе позволить пожинать плоды чужого труда. Люди в целом плохо понимают, за счет чего они получают многие ресурсы и какова полная цена потребляемого. В будущем многие не смогут себе позволить гораздо больше, чем могут вообразить.✅ 2022/05/07 16:21, Gudleifr #60
Тут нет путаницы
Есть. Просто Вы ещё и путаете "не можем этого купить" с "не можем этого сделать".другие уже не смогут себе позволить пожинать плоды чужого труда
Лучше всего про это сказал Ньютон: мол, видел дальше других только потому, что стоял на плечах гигантов.Вам все мерещится коммерция. А коммерческие продукты — это всегда третий сорт.
✅ 2022/05/07 16:34, MihalNik #61
Вам все мерещится коммерция. А коммерческие продукты — это всегда третий сорт.
У любой технологии есть жизненный цикл, включая её закат. И всегда каждую кто-то оплакивал. Люди и перьями писать разучились, но теперь пишут как курицы лапами. Я так в этом году ещё ручку в руки не брал.✅ 2022/05/07 17:23, Gudleifr #62
У любой технологии есть жизненный цикл
Да и для программирования "окно" — это необходимость автоматизации производственных процессов. Но сейчас, в большинстве развитых стран производства практически нет. А для "продвинуто креативного инновационного попила бабла" никакого программирования не надо.✅ 2022/05/11 14:04, Автор сайта #63
Секреты строительства египетских пирамид утеряны. Конечно, это всё окутано тайнами и легендами. Но нуждаемся ли мы в этих навыках с практической точки зрения? Кому, кроме историков, они нужны?Вот и ушедшее от нас железо вместе с программами живет либо в эмуляторах, либо в компьютерных музеях. В штатах таких музеев много, и экспонаты многочисленны и многообразны. Есть «цифровая археология» и «цифровые археологи».
У нас в стране музеев куда меньше. Многие артефакты утеряны навсегда. Например, нет ни одного экземпляра ЭВМ «Сетунь».
О цифровом наследии многое, наверное, может рассказать Дмитрий Юрьевич Караваев. Он переносил библиотеки с БЭСМ-6 и ЕС ЭВМ, написанные на PL/1, на свой компилятор для x86. Которые в своё время переписывались с Фортрана на PL/1. Думаю, ему есть чем поделиться.
На Хабре есть пользователь Орлов Владимир, он же saipr. В программировании он уже 50 лет. Ему тоже есть, что рассказать. Например, он когда-то разработал транслятор языка PRG, с которым он был знаком на ЕС ЭВМ, под более древнюю отечественную архитектуру («Урал», если мне память не изменяет). Наверняка у него тоже есть мнение, насколько трагична утрата цифрового наследия.
Есть знакомый, которому пошёл 8 десяток лет, работает техническим директором в какой-то связанной с Тайванем конторе. Когда-то он сделал из ПК «Ириша» музыкальный инструмент. Программа считывала ноты, подавала сигналы на электромагниты, которые нажимали клавиши на баяне. Оставалось только растягивать на нём меха. Уникальная вещь! Люди заслушивались! На этом он не остановился и повторил примерно тоже самое для гитары. Всё это конечно прикольно и было бы достойным экспонатом компьютерного музея. Но кто сейчас купит такое себе домой?
нужный мне интерактив приходится тащить через Альпы, подобно Суворову.
Это процитирован текст после исправления, которое я внёс. Зачем употреблять слова, которые здесь не уместны? Наш язык богат, выбирать есть из чего.коммерческие продукты — это всегда третий сорт.
Огласите, пожалуйста, продукты двух первых сортов. И найдите аналог для третьесортного Фотошопа, который бы его превосходил и был бы некоммерческим. Пользуясь LibreOffice, сделал вывод, что он глючнее MSOffice. Но я то могу обойти глюки, а как быть неискушённому пользователю? Да, есть примеры плохого качества ПО как в ту, так и в другую стороны. Поэтому делать однозначные выводы не получаетсяписать разучились ... пишут как курицы лапами. Я так в этом году ещё ручку в руки не брал.
Знакомая картина! Обратная сторона медали прогресса в ИТ.✅ 2022/05/11 14:46, Gudleifr #64
Секреты строительства египетских пирамид утеряны
Как будут утеряны завтра сегодняшние гаджеты. Причем, "завтра" здесь буквально. Поэтому "современное программирование" — это по большей части переписывание вчерашнего. Особенно хорошо это видно на рынке игрушек. Но, обратите внимание, большинство римейков уже совершенно новые игры, с совершенно другим настроем и игровым интересом. В инженерных программах это менее заметно, т.к. программы там живут столько же, сколько их автор. Потом обычно вспоминают: был такой дед, голыми руками/в кодах такое писал, что никто больше повторить не смог. Отсюда и вопрос: можно ли сохранить аппаратно-независимую суть? Например, смысл тех самых пирамид.Огласите, пожалуйста, продукты двух первых сортов
Первый сорт — это то, что Вы делаете для себя.Второй — то, что вы можете накопать в залежах третьего сорта, если есть возможность порыться.
Дарение и взятие трофеев сортности не понижают.
Например, до последнего времени использовал, вместо Фотошопа, PhotoStyler, найденный довеском на рекламном сидюке какого-то древнего сканера/принтера. Перестал только с отказом Win-64 поддерживать программы Win-16. Яркий пример II-го сорта. I-й? Это, например, моя программа сборки/разборки GIF-ов, нужная мне для хранения баз данных и рисования на лету в обход версионно-зависимых и платных сетевых средств. Корявая? Да, но она моя и умеет делать то, что мне надо здесь и сейчас.
✅ 2022/05/11 16:08, Автор сайта #65
Ну что ж, если вчерашнее лучше сегодняшнего, то остаётся пожелать Вам успехов во вчерашней жизни. У меня тоже иногда бывает ностальгия по ушедшему. Вы, наверное, чувствуете это острее.✅ 2022/05/11 16:41, Gudleifr #66
У меня тоже иногда бывает ностальгия по ушедшему
Да, программы раньше были зеленее.✅ 2022/05/20 19:29, Клихальт #67
Да, программы раньше были зеленее.
Gudleifr, что, что, а зеленее программы точно не были и ваш любимый Aldus Photostyler тому прямое подтверждение (кстати у вас версия 2.0 SE, которая шла со сканерами, или полная). Программы все времена были примерно одинаковые, просто надо чем-то задействовать имеющиеся вычислительные мощности и симулировать неуклонный прогресс в отрасли.✅ 2022/05/20 20:42, Gudleifr #68
кстати у вас версия
1.0 1991Программы все времена были примерно одинаковые
Именно. Т.е. когда нам требуется написать новую программу, я начинаю с нуля. Нет, конечно, "по методу масштабирования" я могу накачать библиотек. Но все они касаются только простых алгоритмов и интерфейсов, нет никакого способа сохранить даже свои архитектурные решения, не говоря уже о доступе к чужим. Ни один язык программирования не позволяет отделить "суть дела" от машиннозависимых частностей. Переносимость? Перенесите оконную программу на консоль. Перенесите CGI в клиентский-JS.✅ 2022/05/24 23:50, Неслучайный читатель #69
Тут выше упоминается статья «Доказательное программирование». Её автор явно хочет сказать, что хватит писать новые языки. С таким же успехом можно призывать, что хватит писать новые ОС, новые браузеры, офисные, бухгалтерские и любые другие программы. «Мы написанное освоить не можем, а вы опять пишите». Ещё не нужна новая электроника, бытовая техника. Хватит уже изобретать! Дайте старое освоить. Я ещё на лошади не научился ездить, а вы уже автомобиль изобрели.✅ 2022/12/20 21:30, kt #70
В библиотечку сайтаhttps://dmkpress.com/catalog/computer/programming/978-5-93700-140-5/
✅ 2022/12/20 21:38, Gudleifr #71
В библиотечку сайта
А какую нишу затыкает эта книга?✅ 2022/12/23 01:13, Автор сайта #72
В библиотечку
Спасибо, Вы мне плохого никогда не советуете :) Интересно, как Вам на глаза попалось такое?Название книги многообещающее :) Теперь задача иметь её у себя. К сожалению, в открытом доступе её не найти. Что удалось наскрести — введение и главу 1 из английского оригинала. Увы, после знакомства с началом книги эйфорию как рукой сняло. Хотелось бы ошибиться, но кажется, что автор книги повторяет распространённую ошибку: под созданием языка программирования он, в основном, подразумевает написание компилятора к нему. Фокус внимания удерживается на теории компиляторов, то есть на реализации. Но не на создании собственно языка. Это как если бы я купился на заголовок «Я вас научу писать красивые стихи», а получил бы поучения про красивый почерк, перья, чернила и глянцевую бумагу. Надеюсь, что оставшиеся главы меня переубедят.
какую нишу затыкает эта книга?
Не затыкает, а заполняет. Автор книги Клинтон Джеффри пишет, что потребность в языках программирования растёт, в том числе и новых. И опровергает тезис, чтоВсе согласны с тем, что область языков программирования мертва. Все важные языки уже изобретены.
Это очень похоже на заявление главы патентного бюро США (в XIX веке), что «все изобретения уже сделаны». Впрочем, всё это уже обсуждалось в связи с «доказательным программированием».✅ 2022/12/23 01:30, Gudleifr #73
Не затыкает, а заполняет. Автор книги Клинтон Джеффри пишет, что потребность в языках программирования растёт
Нет, я именно про "затыкает". Ведь есть книга дракона, были многочисленные проекты вокруг машин 5-го поколения, есть Ваша позиция, есть, наконец, моя... Где точка приложения этого нового творения? Не про "новые языки нужны", а кем надо быть, чтобы их создавать?✅ 2022/12/24 12:50, kt #74
Интересно, как Вам на глаза попалось такое?
Да все из того же "соревнования по крику" в linux.org.ru. Исходная тема "Сколько зарабатывает Паскаль-программист?" породила 23 страницы комментариев, причем страниц пять посвящено спору, что есть список в Питоне. Оцените корреляцию с исходной темой ))На разных околокомпьютерных форумах я обращаю внимание на сравнительно новые темы, где сразу много комментариев: значит что-то зацепило.
✅ 2022/12/25 15:24, Автор сайта #75
"соревнования по крику" в linux.org.ru
Не бываю там. Наверное, мешает логика «Раз у меня стоит Windows, то на linux.org.ru мне не надо» :) Спасибо, буду поглядывать.Оцените корреляцию с исходной темой
Да, у нас тут тоже с корреляцией бывают завихрения :)✅ 2023/01/15 16:51, void #76
В библиотечку сайта
https://dmkpress.com/catalog/computer/programming/978-5-93700-140-5/
Тут следует напомнить о таких языках как Icon: Unicon, Icon, Snobol, Spitbol, Snowball.
- Unicon — объектно ориентированный Icon
- Icon — скриптовый язык с паскалевским синтаксисом с парой самобытных идей в развитие Snobol4
- Snobol — язык для разбора строк, довольно простой, но при этом достаточно мощный
- Spitbol — оптимизированный Snobol
- Snowball, Snowstorm — вариант Snobol для описания алгоритмов stemming естественного языка
- также следует упомянуть библиотеки для Ada: GNAT.Spitbol и Matching http://www.dmitry-kazakov.de/match/match.htm Дмитрия Казакова
- goal-oriented execution
- coexpressions, generators
obj foo bar baz xyzzyЭто означает примерно следующее:
(x ? x : ( y ? y : (z ? z : (w ? w : NULL))))где
(x=obj.foo,y=obj.foo.bar,z=obj.foo.bar.baz,w=obj.foo.bar.baz.xyzzyвычисляемое по ленивой схеме, то есть:
- послать объекту obj сообщение foo,
- если он его обрабатывает так, что цель достигнута (возвращает true), обработка заканчивается. Примерно как вычисление «||» в Си, то есть, дизъюнкция по короткой схеме: не вычислять второй аргумент если ясно из первого.
- Если же цель не достигута, то вычислять последующую цепочку выражений.
Как пример подобного использования goal-oriented execution и ковыражений можно посмотреть исходники и "фильтры" в Noweb от Norman Ramsey: https://www.cs.tufts.edu/~nr/noweb/ https://github.com/nrnrnr/noweb — исходники на Icon здесь: https://github.com/nrnrnr/noweb/tree/master/src/icon. Например, в конце файла https://github.com/nrnrnr/noweb/blob/master/src/icon/pipedocs.nw every — это ковыражения (идея 2), это cопоставление с образцом, вычисляемое лениво (идеи 1 и 2).
Но лучше, на мой взгляд, смотреть практическое применение идеи грамотного программирования, literate programming на примерах таких книг/программ. Например, Ulix OS — учебный клон OS Unix, реализованный одновременно и как книга, и как компилируемая программа:
http://www.hgesser.de/ulix/,
http://ulixos.org/ https://github.com/hgesser/ulix
https://www.cs1.tf.fau.de/research/security-education/ulix-a-literate-os/
Вот это (https://github.com/hgesser/ulix/blob/master/ulix-book.nw —
Из него вот этим Makefile (https://github.com/hgesser/ulix/blob/master/tex-build/Makefile) генерируется weave документация в формате PDF, то есть, книга: https://github.com/hgesser/ulix/blob/master/ulix-book.pdf и вот этим Makefile (https://github.com/hgesser/ulix/blob/master/bin-build/Makefile) генерируется tangle сами исходники проекта, которые потом компилируются, собираются в образ OS через ldscripts.
Так же в этих makefile можно заметить вызов filters в noweb, например в weave для синтаксической раскраски исходников. Noweb замечателен, например, тем, что относительно легко позволяет добавлять новые проходы постобработки в виде filters, не сложнее, чем конвеейрный pipe нескольких программ. Которые могут быть написаны на том же Icon как ленивые ковыражения.
Так же в контексте идеи "грамотного программирования" языков программирования полезно посмотреть, например, на вот такую связку инструмент + книга/программа:
- FunnelWeb в качестве инструмента грамотного программирования, например его форк с поддержкой utf-8: https://github.com/loa-in-/fw-utf8.
- xelatex + latex тексты в utf-8 на русском + стандартные TrueType шрифты.
- Книга/программа https://eli-project.sourceforge.net/ для генерации парсеров.
или HTML https://eli-project.sourceforge.net/a60_html/a60.html и исходники https://eli-project.sourceforge.net/a60_html/ALGOL60.tar.gz, генерирующее всё это через weave/tangle.
Из исходников примера ALGOL60.tar.gz в частности, видно как пользоваться FunnelWeb: для каждого вида PDF/HTML создаётся свой грамотный *.fw исходник, его генерирующий. Здесь остро не хватает, на мой взгляд, грамматики PL/1 в таком же, откомментированном, грамотном виде.
Хотелось бы ошибиться, но кажется, что автор книги повторяет распространённую ошибку: под созданием языка программирования он, в основном, подразумевает написание компилятора к нему. Фокус внимания удерживается на теории компиляторов, то есть на реализации. Но не на создании собственно языка. Это как если бы я купился на заголовок «Я вас научу писать красивые стихи», а получил бы поучения про красивый почерк, перья, чернила и глянцевую бумагу. Надеюсь, что оставшиеся главы меня переубедят.
Как лично я бы писал реализацию своего языка программирования (если бы так уж сильно приспичило)? Я писал бы её- обоснования необходимости нового языка программирования и его концепции, унифицирующей сильной идеи,
- расписывая примеры трансляции: мой язык -> стандартный язык (например, Си, Лисп или Форт).
Меня часто спрашивают: "как стать писателем". А я им отвечаю: "берите ручку и пишите"
✅ 2023/01/15 17:10, void #77
Ещё немного про язык Снобол. Реализация была написана изначально на ассемблере OS/360, затем на ней написана реализация ассемблера и минималистичной виртуальной машины. Потом в подобном виде было портировано на все остальные архитектуры. SPITBOL реализация использует для того же язык Си вместо ассемблера. То есть, сама реализация достаточно эффективна.Язык довольно мощный: можно определять свои функции, типы данных, динамические символьные таблицы, плагины и модули — интерфейс к системным Си функциям и библиотекам (например, поддерживаются сокеты).
При этом сам язык довольно простой. Программа на Сноболе — это конечный автомат, управляемый сопоставлением с образцом. Есть базовые типы данных: строки, паттерны, типы, числа, определяемые пользователем ADT. Есть довольно развитый язык паттернов. При сопоставлении можно деструктурированно присваивать совпавший образец с новой переменной, то есть захватить совпавшее в новую переменную. Есть встроенные массивы и хештаблицы. Можно делать деревья, списки и проч. Поддерживается сборка мусора.
Каждая строка на этом языке имеет вид
МЕТКА foo=bar baz :s(УСПЕХ):f(НЕУД):(anyway)То есть: если foo совпало с bar выполнить захват и выполнить baz и всё остальное. Затем случае успеха goal-oriented execution перейти после выполнения на метку УСПЕХ, в случае неуспеха --а на метку НЕУД, иначе (в любом случае) — на метку anyway. Получается конечный автомат, управляемый сопоставлением с образцом.
Основной тип — строки, но в Snobol4 (и SPITBOL, Snowball/Snostorm) можно вводить нормальные структуры данных. Для чего следует почитать книжки. Например, в книге
A L G O R I T H M S I N S N O B O L 4приводится такая реализация ассемблера OS/360:
-----------------------------------------
by James F. Gimpel
ISBN 0-939793-01-6
ISBN 0-939793-00-8 (paperback)
* ASM360 - Parse IBM 360 assembly-language statement.и более продвинутая, более другого ассемблера
*
* This code fragment develops the pattern ASM360
* which can then be applied to a subject to break
* the subject into NAME, OPERATION, OPERAND, and
* COMMENT fields. It follows all of the contorted
* rules of the IBM assembly-langauge manual.
*
LETTER = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ$#@'
SP.CH = "+-,=.*()'/& "
SCOTA = SP.CH
SCOTA '&' =
Q = "'"
QLIT = Q FENCE BREAK(Q) Q
ELEM = QLIT | 'L' Q | ANY(SCOTA) | BREAK(SCOTA) | REM
F3 = ARBNO(ELEM FENCE)
B = (SPAN(' ') | RPOS(0)) FENCE
F1 = BREAK(' ') | REM
F2 = F1
CAOP = ('LCL' | 'SET') ANY('ABC') |
+ 'AIF' | 'AGO' | 'ACTR' | 'ANOP'
ATTR = ANY('TLSIKN')
ELEMC = '(' FENCE *F3C ')' | ATTR Q | ELEM
F3C = ARBNO(ELEMC FENCE)
ASM360 = F1 . NAME B
+ ( CAOP . OPERATION B F3C . OPERAND |
+ F2 . OPERATION B F3 . OPERAND)
+ B REM . COMMENT
* ASM.SNO - Assembler for machine M described in chapter 18 ofIcon — это Снобол с человеческим паскалеподобным синтаксисом; Unicon — это объектно-ориентированный Icon.
* "Algorithms in SNOBOL4." A discussion of the
* assembler is beyond the scope of these comments;
* consult the book for information.
*
* Input must be blank (not tab) delimited, and
* upper case. File ASMTEMP is used as a work file.
* Listing is written to OUTPUT, "binary" is assigned
* to variable PUNCH, which can be I/O associated
* if capturing that result is desired.
*
-MODULE ASM
-INCLUDE "rpad.inc"
-INCLUDE "baseb.inc"
LIST = 'LOAD 21,STORE 22,ADD 31,FADD 71,SUB 32,'
+ 'FSUB 72,MUL 33,FMUL 73,DIV 34,FDIV 74,LOADA 2A,LOADN 2F,'
+ 'BR A0,BRGT A1,BRLT A2,BREQ A3,BRNE A4,BRGE A5,BRLE A6,'
OPS = TABLE()
OPS_INIT LIST BREAK(' ') . OP ' ' BREAK(',') . CODE ',' =
+ :F(INIT1)
OPS<OP> = CODE :(OPS_INIT)
INIT1 SYMS = TABLE()
LABEL.L = BREAK(' ') . L SPAN(' ')
LOC = 0
OUTPUT(.DISK,10,,'ASMTEMP')
PASS1 X = INPUT ' ' :F(INIT2)
DISK = X
X LABEL.L =
SYMS<L DIFFER(L)> = BASEB(LOC,16)
LOC = DIFFER(X) LOC + 1 :(PASS1)
INIT2 REWIND(10)
DETACH(.DISK)
INPUT(.DISK,10,,'ASMTEMP')
NO_OP = POS(0) BREAK(' ') SPAN(' ') RPOS(0)
P.OP.AC.A.X = NULL $ OP $ AC $ A $ X NULL . CAUSE
+ POS(0) BREAK(' ') SPAN(' ')
+ BREAK(' ') . OP SPAN(' ')
+ (BREAK(' ,') . AC ',' | NULL)
+ BREAK('( ') . A
+ ('(' BREAK(')') . X ')' | NULL)
DEFINE('CVTSYM(SYM,TABLE,LENGTH,TYPE)') :(CVTSYM_END)
CVTSYM SYM = INTEGER(SYM) BASEB(SYM,16) :S(CVTSYM_1)
SYM = TABLE<SYM>
CAUSE = IDENT(SYM,NULL) 'U' TYPE ' '
CVTSYM_1
SYM = LPAD(SYM,LENGTH,'0')
CVTSYM = LE(SIZE(SYM), LENGTH) SYM :S(RETURN)
CAUSE = CAUSE 'L' TYPE ' '
SYM = :(CVTSYM_1)
CVTSYM_END
PASS2 CAUSE = 'S '
LINE = DISK ' ' :F(END)
LINE NO_OP :S(PASS2A)
LINE P.OP.AC.A.X
OP = CVTSYM(OP,OPS,2,'O')
AC = CVTSYM(AC,SYMS,1,'R')
X = CVTSYM(X, SYMS,1,'X')
A = CVTSYM(A, SYMS,4,'A')
PUNCH = OP AC X A
OUTPUT = RPAD(CAUSE,15) OP ' ' AC ' ' X ' ' A
+ ' ' LINE :(PASS2)
PASS2A OUTPUT = DUPL(' ',32) LINE :(PASS2)
END
✅ 2023/01/15 19:56, void #78
Вот исходники на Сноболе, реализующие атрибутивную сеть переходов (ATN, Attributive Transition Network). ATN используется для парсинга текста на естественном языке.Отсюда: https://github.com/fortikeco/AI-cdrom-r3, "The AI CD-ROM r3", public domain, compiled by Network Cybernetics Corporation 1995"
https://github.com/fortikeco/AI-cdrom-r3/blob/master/PROG/AISNOBOL.ZIP :
ATN.SNO:
* ATN.SNO
* SNOBOL4 program to implement a compiler for an
* Augmented Transition Network Language.
*
* This program is slightly modified from the version in the report
* to provide faster compilation of the network.
*
* Sample input in the ATN source language is contained in file ATN.IN.
*
* Run the program by typing:
*
* SNOBOL4 ATN /I:ATN /1:SLIST
*
* where /1 specifies an optional listing file for the ATN compiler, and
* may be omitted. The program requires a minimum of 192K bytes.
-PLUSOPS 1
-CASE 0
* Keyword settings
&ANCHOR = 0
&DUMP = 0
&FTRACE = 0
&FULLSCAN = 0
&MAXLNGTH = 32767
&STLIMIT = -1
&TRACE = 0
&TRIM = 1
*
* Set CODE_PRINT to 1 to get listing of generated code
*
CODE_PRINT = 0
* I/O Associations
INPUT(.ATNSOURCE)
OUTPUT(.SLIST, 1)
* Defined data types
DATA( \\\\'STACK(TOP,REST)\\\\' )
* Global constants
null = \\\\'\\\\'
nil = STACK()
TOP(nil) = nil
REST(nil) = nil
SENTENCES = nil
LEX_STACK = nil
LEXICAL_FEATURES = TABLE()
* Utility patterns
BLANK = \\\\' \\\\'
SC = \\\\';\\\\'
Q1 = "\\\\'"
Q2 = \\\\'"\\\\'
COMMA = \\\\',\\\\'
STAR = \\\\'*\\\\'
LP = \\\\'(\\\\'
RP = \\\\')\\\\'
UL = \\\\'_\\\\'
PUSHER = \\\\'>\\\\'
POPPER = \\\\'<\\\\'
TAB = CHAR(9)
LEFT_END = POS(0)
RIGHT_END = RPOS(0)
BLANKS = SPAN(BLANK)
OPT_BLANKS = BLANKS | null
BB = BREAK(BLANK)
BXB = BREAKX(BLANK)
BBSC = BREAK(BLANK SC)
SPSC =
SPAN(SC)
SPBSC = SPAN(BLANK SC)
SPBSCN = SPBSC | null
BSC = BREAK(SC)
LEN1 = LEN(1)
L1REM = LEN1 REM
BRP = BREAK(RP)
BRPN = BRP | null
* Utility functions
* Print X to the source listing file and output file
DEFINE(\\\\'PRT(X)\\\\') :(PRT_END)
PRT OUTPUT = SLIST = X :(RETURN)
PRT_END
* Error MSG to source listing file and output file
DEFINE(\\\\'ERROR(MSG)\\\\') :(ERROR_END)
ERROR ( PRT() PRT(MSG) PRT() ) :(RETURN)
ERROR_END
* Readable display of SNOBOL4 code
DEFINE( \\\\'DISPLAY(SNOCODE)S,L\\\\' ) :(DISPLAY_END)
DISPLAY EQ(CODE_PRINT,0) :S(RETURN)
(PRT() PRT(\\\\'------ Code ------\\\\') PRT())
DISPLAY1
SNOCODE LEFT_END (BSC $ S) SPSC = :F(DISPLAY3)
S LEFT_END (NOTANY(BLANK) (BB | null)) $ L = :F(DISPLAY2)
PRT(\\\\' | \\\\' L)
DISPLAY2
S LEFT_END BLANKS =
S = TRIM(S)
NULL(S) :S(DISPLAY1)
PRT(\\\\' | \\\\' S) :(DISPLAY1)
DISPLAY3
(PRT() PRT
(\\\\'------ End of Code ------\\\\') PRT()) :(RETURN)
DISPLAY_END
* Succeeds if X is nil, null, or zero
DEFINE(\\\\'NULL(X)\\\\') :(NULL_END)
NULL (IDENT(X,nil),
+ IDENT(X,null),
+ INTEGER(X) EQ(X,0)) :S(RETURN) F(FRETURN)
NULL_END
* Put COAT on RACK using HANGER
DEFINE( \\\\'PUT(RACK,COAT,HANGER)\\\\' ) :(PUT_END)
PUT PROP<RACK> =
+ DIFFER(\\\\'TABLE\\\\',DATATYPE(PROP<RACK>)) TABLE()
ITEM(PROP<RACK>,HANGER) = COAT :(RETURN)
PUT_END
* Get contents of HANGER off RACK
DEFINE( \\\\'GET(RACK,HANGER)\\\\' ) :(GET_END)
GET PROP<RACK> =
+ DIFFER(\\\\'TABLE\\\\',DATATYPE(PROP<RACK>)) TABLE() :S(RETURN)
GET = ITEM(PROP<RACK>,HANGER) :(RETURN)
GET_END
* Program text semi-constants used in code generation
&ALPHABET POS(1) (LEN1 $ MAGIC_CHAR)
REPLACE_LIT = MAGIC_CHAR \\\\'RePlAcE\\\\' MAGIC_CHAR
BEGIN_TEXT =
+ \\\\' HOLD = REMAINING_WORDS ;\\\\'
+ \\\\' REMAINING_WORDS (BREAK(&
quot; ") $ CURRENT_WORD) ;\\\\'
+ \\\\' THIS_NODE = GENNAME("\\\\' REPLACE_LIT \\\\'") ;\\\\'
+ \\\\' :(\\\\' REPLACE_LIT \\\\'_START) ;\\\\'
WIN_TEXT =
+ REPLACE_LIT \\\\'_WIN\\\\'
+ \\\\' TESTF(THIS_NODE,FEATS) :F(\\\\' REPLACE_LIT \\\\'_LOSE) ;\\\\'
+ \\\\' ATTACH(THIS_NODE,PARENT) ;\\\\'
+ \\\\' LAST_PARSED = THIS_NODE :(RETURN) ;\\\\'
LOSE_TEXT =
+ REPLACE_LIT \\\\'_LOSE\\\\'
+ \\\\' REMAINING_WORDS = HOLD ;\\\\'
+ \\\\' REMAINING_WORDS (BREAK(" ") $ CURRENT_WORD) :(FRETURN) ;\\\\'
INITIAL_ROUTINE =
+ REPLACE_LIT BEGIN_TEXT
+ WIN_TEXT LOSE_TEXT REPLACE_LIT \\\\'_START ;\\\\'
* Patterns used in COMPILE routine
COMMENT_PAT = (LEFT_END OPT_BLANKS STAR) | (LEFT_END RIGHT_END)
KEYWORD_PAT = \\\\'NETWORK\\\\' | \\\\'FUNCTION\\\\' | \\\\'LEXICON\\\\'
+ | \\\\'SENTENCES\\\\' | \\\\'EXEC\\\\'
NAME_PAT = (BB $ NAME) BLANKS FENCE
LEGAL_PAT = LEFT_END KEYWORD_PAT . KEYTYPE BLANKS (BB | REM) . TNAME
COMPLETE_PAT = LEFT_END OPT_BLANKS \\\\'END\\\\' OPT_BLANKS *TNAME RIGHT_END
* Definitions o
f semantic (code-generating) functions
DEFINE( \\\\'S(NA)\\\\' )
DEFINE( \\\\'S_(NA)T\\\\' )
* Recognizer/compiler patterns for the five types of blocks:
* EXEC, SENTENCES, LEXICON, FUNCTION, and NETWORK
* Recognizer for EXEC statement
EXEC_PAT = LEFT_END \\\\'EXEC\\\\' BLANKS (REM $ NAME) S(\\\\'EX\\\\')
* Recognizer/Compiler for SENTENCES block
SENTENCES_LIT = \\\\'SENTENCES\\\\' BLANKS FENCE
SENTENCES_HEADER = LEFT_END SENTENCES_LIT NAME_PAT
SENTENCE_PAT = (BSC $ SENT) SPBSC S(\\\\'SENT\\\\')
SENTENCES_BODY = ARBNO(SENTENCE_PAT)
SENTENCES_ENDER = \\\\'END\\\\' OPT_BLANKS *NAME RIGHT_END
SENTENCES_PAT = SENTENCES_HEADER SENTENCES_BODY SENTENCES_ENDER
* Recognizer/Compiler for LEXICON block
LEXICON_LIT = \\\\'LEXICON\\\\' BLANKS FENCE
LEXICON_HEADER = LEFT_END LEXICON_LIT NAME_PAT
LEX_PUSH_PAT = PUSHER (BB $ F) BLANKS S(\\\\'PSH\\\\')
LEX_POP_PAT = POPPER (BB $ F) BLANKS S(\\\\'POP\\\\')
WORD_PAT = NOTANY(PUSHER POPPER) (BB | null)
LEX_W_PAT = (WORD_PA
T $ W) BLANKS S(\\\\'LEX\\\\')
ENTRY_PAT = LEX_W_PAT | LEX_PUSH_PAT | LEX_POP_PAT
ENTRIES_PAT = ARBNO(ENTRY_PAT)
LEXICON_ENDER = SENTENCES_ENDER
LEXICON_PAT = LEXICON_HEADER ENTRIES_PAT LEXICON_ENDER
* Recognizer/Compiler for FUNCTION block
FUNCTION_LIT = \\\\'FUNCTION\\\\' BLANKS FENCE
FUNCTION_HEADER = LEFT_END FUNCTION_LIT NAME_PAT
ARG_PAT = (( LP BRPN RP ) $ ARG ) BLANKS S(\\\\'ARG\\\\')
LOC_PAT = LP (BRPN $ LOC) RP BLANKS S(\\\\'LOC\\\\')
FUNCTION_HEADER = FUNCTION_HEADER ARG_PAT LOC_PAT
STATEMENT_PAT = BSC SPSC
STATEMENTS_PAT = ARBNO(STATEMENT_PAT) $ BODY BLANKS
FUNCTION_ENDER = SENTENCES_ENDER
FUNCTION_PAT = FUNCTION_HEADER S(\\\\'FN\\\\') STATEMENTS_PAT
+ FUNCTION_ENDER S(\\\\'F\\\\')
* Recongnizer/Compiler for NETWORK block
* The IF part
IF_LIT = \\\\'IF\\\\' BLANKS FENCE
* The conditional clause
CLAUSE_PAT = BXB
COND_PAT = (CLAUSE_PAT $ COND) BLANKS
* The GOTO clause
GOTO_LIT = \\\\'GO\\\\' OPT_BLANKS \\\\'TO\\\\' BLANKS F
ENCE
GOTO_LABEL_PAT = (BB $ GOTO_LABEL) BLANKS FENCE
GOTO_PAT = GOTO_LIT GOTO_LABEL_PAT
* The AFTER clause (which may be null)
AFTER_LIT = \\\\'AFTER\\\\' BLANKS FENCE
SIDE_PAT = (CLAUSE_PAT $ SIDE) BLANKS
ENDIF_PAT = \\\\'END\\\\' OPT_BLANKS \\\\'IF\\\\' BLANKS FENCE
AFTER_PAT =
+ ((null $ SIDE) ENDIF_PAT)
+ | (AFTER_LIT SIDE_PAT ENDIF_PAT)
IF_PAT = IF_LIT COND_PAT GOTO_PAT AFTER_PAT S(\\\\'IF\\\\')
* The labelled set of IF statments (the RULE)
LABEL_PAT = (BB $ LABEL) BLANKS FENCE
IFS_PAT = ARBNO(IF_PAT)
END_LABEL_PAT = \\\\'END\\\\' OPT_BLANKS *LABEL BLANKS FENCE
RULE_PAT = LABEL_PAT S(\\\\'LAB\\\\') IFS_PAT END_LABEL_PAT S(\\\\'ELB\\\\')
* The set of RULEs (the NETWORK)
NETWORK_LIT = \\\\'NETWORK\\\\' BLANKS FENCE
NETWORK_HEADER = LEFT_END NETWORK_LIT NAME_PAT
RULES_PAT = ARBNO(RULE_PAT)
NETWORK_ENDER = SENTENCES_ENDER
* Defer compilation of network to COMPILE code, where each labelled IF block
* will be compiled separately. This
prevents the stack overflow which
* occurs if RULES_PAT were used here directly.
*
NETWORK_PAT = NETWORK_HEADER
+ ARB
+ NETWORK_ENDER
* Grand pattern for compiling any legal block
COMPILE_PAT = NETWORK_PAT
+ | FUNCTION_PAT
+ | LEXICON_PAT
+ | SENTENCES_PAT
+ | EXEC_PAT
* Read and compile all text from ATNSOURCE
* (source listing with comments goes to SLIST)
DEFINE( \\\\'COMPILE()NEXT,TEXT\\\\' ) :(COMPILE_END)
* Comment or first line of block
COMPILE TEXT = ATNSOURCE :F(RETURN)
* List the record, trim leading blanks, and check for legal syntax
COMPILE1
PRT( TEXT )
COMP6 TEXT TAB = BLANK :S(COMP6)
TEXT COMMENT_PAT :S(COMPILE)
TEXT LEFT_END BLANKS = null
TEXT LEGAL_PAT :S(COMPILE2A)
ERROR(\\\\'Illegal record\\\\') :(FRETURN)
COMPILE2A
IDENT(KEYTYPE,\\\\'EXEC\\\\') :S(COMPILE4)
COMPILE2
NEXT = ATNSOURCE :S(COMPILE3)
E
RROR(\\\\'Unexpected end of file on ATNSOURCE\\\\') :(FRETURN)
* List the record, convert leading blanks to a single blank,
* and concatenate with TEXT
COMPILE3
PRT( NEXT )
COMP7 TEXT TAB = BLANK :S(COMP7)
NEXT COMMENT_PAT :S(COMPILE2)
NEXT LEFT_END BLANKS = BLANK
TEXT = TEXT NEXT
* Check for a complete block. If block is incomplete, keep reading
NEXT COMPLETE_PAT :F(COMPILE2)
* Use COMPILE_PAT to compile TEXT
COMPILE4
TIME_ZERO = TIME()
IDENT(KEYTYPE,\\\\'NETWORK\\\\') :F(COMP8)
* Handle networks special:
TEXT NETWORK_HEADER S(\\\\'NTW\\\\') = :F(COMPILE5)
* Do network by r
✅ 2023/01/15 19:57, void #79
файл ATN.SNO, продолжение* The end of a labelled rule: If none of the IF statements
* has been satisfied, then the LOSE branch is take
S_ELB ROUTINE = ROUTINE \\' :(\\' REPLACE_LIT \\'_LOSE) ;\\' :(NRETURN)
* Wrap-up network: (1) insert NAME in all the right places;
* (2) translate into machine language via CODE.
S_ENW ROUTINE REPLACE_LIT = NAME :S(S_ENW)
DISPLAY( ROUTINE )
CODE( ROUTINE ) :S(NRETURN)
ERROR(\\'Compilation error\\') :(FRETURN)
* Push a sentence onto the stack of sentences
S_SENT SENTENCES = STACK(SENT,SENTENCES) :(NRETURN)
* Push F onto the stack of lexical features
S_PSH LEX_STACK = STACK(F,LEX_STACK) :(NRETURN)
* Pop lexical features up to, NOT INCLUDING, F
S_POP NULL(LEX_STACK) :S(NRETURN)
IDENT(F,TOP(LEX_STACK)) :S(NRETURN)
LEX_STACK = REST(LEX_STACK) :(S_POP)
* Attach all stacked features to W
S_LEX LEX_STACK_SAVE = LEX_STACK
S_LEX1 NU
LL(LEX_STACK) :S(S_LEX2)
LEXICAL_FEATURES<W> = TOP(LEX_STACK) BLANK
+ LEXICAL_FEATURES<W>
LEX_STACK = REST(LEX_STACK) :(S_LEX1)
S_LEX2 PRT(\\' | \\' W \\': \\' LEXICAL_FEATURES<W>)
LEX_STACK = LEX_STACK_SAVE :(NRETURN)
* Remove all blanks from the formal argument list for a FUNCTION
S_ARG ARG BLANKS = :S(S_ARG)F(NRETURN)
* Remove all blanks from the local variable list for a FUNCTION
S_LOC LOC BLANKS = :S(S_LOC)F(NRETURN)
* Initialize FUNCTION
S_FN DISPLAY(\\' DEFINE(\\' Q1 NAME ARG LOC Q1 \\') ;\\')
DEFINE( NAME ARG LOC ) :(NRETURN)
* Compile a FUNCTION
S_F BODY = BODY " ERROR(\\'No return from \\' "
+ Q1 NAME Q1 ") :(END) ;"
DISPLAY( NAME BLANK BODY )
CODE( NAME BLANK BODY ) :S(NRETURN)
ERROR(\\'Compilation error\\') :(FRETURN)
* For EXEC, call MAIN with NAME = name of first network to be called
S_EX ( PRT() PRT() )
PRT
( \\'****** EXECUTION BEGINS WITH \\' NAME \\' ******\\') PRT()
MAIN(NAME) :(NRETURN)
S_END
* This routine is triggered by the EXEC statement
DEFINE( \\'MAIN(FIRST_PROC)LAST_PARSED,\\'
+ \\'CURRENT_WORD,REMAINING_WORDS,S,PROP\\' ) :(MAIN_END)
MAIN NULL(SENTENCES) :S(RETURN)
S = TOP(SENTENCES)
SENTENCES = REST(SENTENCES)
( PRT() PRT() )
PRT(DUPL(\\'-\\',SIZE(S)))
( PRT() PRT(S) PRT() )
PRT(DUPL(\\'-\\',SIZE(S)))
PRT()
LAST_PARSED = null
CURRENT_WORD = null
REMAINING_WORDS = S BLANK
PROP = TABLE()
TIME_ZERO = TIME()
EVAL(FIRST_PROC) :S(MAIN1)
( PRT() PRT(\\'Parsing failed\\') PRT() ) :(MAIN)
MAIN1 ( PRT() PRT(\\'Parsing Succeeded\\') PRT() )
( PRT(TIME() - TIME_ZERO \\' milliseconds used\\') PRT() )
DUMP_PROP() :(MAIN)
MAIN_END
* Dump registers after parse is completed
DEFINE( \\'DUMP_PROP()T,N,R,M,TN1,TN2,RM1,RM2\\' ) :(DUMP_PROP_END)
DUMP_PROP
T = CONVERT(PROP, \\'ARRAY\\')
:F(RETURN)
PROP = null
N = 1
DUMP1 TN1 = T<N,1> :F(RETURN)
TN2 = T<N,2>
T<N,1> = null
T<N,2> = null
R = CONVERT(TN2, \\'ARRAY\\') :F(DUMP3)
PRT()
PRT( \\'NODE: \\' TN1 )
M = 1
DUMP2 RM1 = R<M,1> :F(DUMP3)
RM2 = R<M,2>
PRT( DUPL(\\' \\',10) RM1 \\' = \\' RM2 )
M = M + 1 :(DUMP2)
DUMP3 N = N + 1 :(DUMP1)
DUMP_PROP_END
* Compile main program starts here
COMPILE() :S(END)
ERROR(\\'****** FATAL ERROR ******\\')
END
✅ 2023/01/15 19:59, void #80
входной файл ATN.IN, начало**********************************
NETWORK PARSE_CLAUSE
**********************************
S1
IF PARSE_NOUN_GROUP(THIS_NODE) GOTO S2
AFTER SETR(\\'SUBJECT\\',LAST_PARSED)
ENDIF
END S1
**********************************
S2
IF PARSE_WORD(THIS_NODE,\\'VERB TENSED \\') GOTO S3
AFTER SETR(\\'VERB\\',LAST_PARSED)
ENDIF
END S2
**********************************
S3
IF TESTF(LAST_PARSED,\\'BE \\')
PARSE_WORD(THIS_NODE,\\'PASTPARTICIPLE \\') GOTO S4
AFTER SETR(\\'OBJECT\\',GETR(\\'SUBJECT\\'))
SETR(\\'SUBJECT\\')
SETR(\\'VERB\\',LAST_PARSED)
ENDIF
IF TESTF(GETR(\\'VERB\\'),\\'TRANSITIVE \\')
PARSE_NOUN_GROUP(THIS_NODE) GOTO S4
AFTER SETR(\\'OBJECT\\',LAST_PARSED)
ENDIF
IF TESTF(GETR(\\'VERB\\'),\\'INTRANSITIVE \\') GOTO S4 ENDIF
IF ~NULL(GETR(\\'OBJECT\\')) GOTO
S4 ENDIF
END S3
**********************************
S4
IF ~NULL(GETR(\\'SUBJECT\\'))
NULL(REMAINING_WORDS) GOTO WIN
ENDIF
IF NULL(GETR(\\'SUBJECT\\'))
IDENT(CURRENT_WORD,\\'BY\\')
PARSE_WORD(THIS_NODE) GOTO S5
ENDIF
IF NULL(GETR(\\'SUBJECT\\')) GOTO S4
AFTER SETR(\\'SUBJECT\\',\\'SOMEONE\\')
ENDIF
END S4
**********************************
S5
IF PARSE_NOUN_GROUP(THIS_NODE) GOTO S4
AFTER SETR(\\'SUBJECT\\',LAST_PARSED)
ENDIF
END S5
END PARSE_CLAUSE
**********************************
NETWORK PARSE_NOUN_GROUP
**********************************
S1
IF PARSE_WORD(THIS_NODE,\\'DETERMINER \\') GOTO S2
AFTER SETR(\\'NUMBER\\',
SELECT(\\'SINGULAR PLURAL \\',
GETF(LAST_PARSED)))
SETR(\\'DETERMINER\\',
SELECT(\\'DEFINITE INDEFINITE \\',<
br> GETF(LAST_PARSED)))
ENDIF
END S1
**********************************
S2
IF PARSE_WORD(THIS_NODE,\\'ADJECTIVE \\') GOTO S2
AFTER ADDR(\\'ADJECTIVES\\',LAST_PARSED)
ENDIF
IF PARSE_WORD(THIS_NODE,\\'NOUN \\') GOTO WIN
AFTER SETR(\\'NUMBER\\',
SELECT(\\'SINGULAR PLURAL \\',
GETF(LAST_PARSED)))
SETR(\\'NOUN\\',LAST_PARSED)
ENDIF
END S2
END PARSE_NOUN_GROUP
**********************************
NETWORK PARSE_WORD
S1
IF NULL(null) GOTO WIN
AFTER PARSE_WORD_1()
ENDIF
END S1
END PARSE_WORD
**********************************
FUNCTION PARSE_WORD_1 () ()
THIS_NODE = CURRENT_WORD ;
REMAINING_WORDS BREAK(" ") SPAN(" ") = ;
REMAINING_WORDS (BREAK(" ") | null) $ CURRENT_WORD :(RETURN) ;
END PARSE_WORD_1
***
*******************************
FUNCTION SETR (REGISTER,VALUE) ()
PUT(THIS_NODE,VALUE,REGISTER) :(RETURN) ;
END SETR
**********************************
FUNCTION GETR (REGISTER) ()
GETR = GET(THIS_NODE,REGISTER) :(RETURN) ;
END GETR
**********************************
FUNCTION ADDR (REGISTER,VALUE) ()
SETR(REGISTER,GETR(REGISTER) VALUE " ") :(RETURN) ;
END ADDR
**********************************
FUNCTION GENNAME (X) ()
GENNAME =
\\'*\\' X \\'_\\' &STCOUNT \\'*\\'
:(RETURN) ;
END GENNAME
**********************************
FUNCTION ATTACH (C,P) ()
PUT(C,P,\\'PARENT\\') ;
PUT(P,GET(P,\\'CHILDREN\\') C " ",\\'CHILDREN\\')
:(RETURN) ;
END ATTACH
**********************************
FUNCTION SELECT (S,T) ()
S (BREAK(" ") $ SELECT) SPAN(" ") = :F(FRETURN) ;
T (POS(0) | " ") SELECT &q
uot; "
:S(RETURN)F(SELECT) ;
END SELECT
**********************************
FUNCTION TESTF (X,F) (W,G)
NULL(F) :S(RETURN) ;
G = GETF(X) ;
TESTF1
F (BREAK(" ") $ W) SPAN(" ") = :F(RETURN) ;
G (POS(0) | " ") W " " :S(TESTF)F(FRETURN) ;
END TESTF
**********************************
FUNCTION GETF (X) ()
GETF = LEXICAL_FEATURES<X> :(RETURN) ;
END GETF
**********************************
LEXICON L1
<* >NOUN >SINGULAR BLOCK BOY
<* >DETERMINER >SINGULAR >INDEFINITE A
<SINGULAR >DEFINITE THE
<* >VERB >TENSED >TRANSITIVE >INTRANSITIVE >PASTPARTICIPLE DROPPED
<TENSED >BE WAS
<* >ADJECTIVE BIG RED
<* >PREPOSITION BY
<*
END L1
**********************************
SENTENCES S1
A BIG RED BL
OCK WAS DROPPED BY THE BOY ;
THE BOY DROPPED A BIG RED BLOCK ;
A BLOCK WAS DROPPED ;
THE BLOCK DROPPED ;
END S1
**********************************
EXEC PARSE_CLAUSE("SENTENCE",null)
✅ 2023/01/15 20:03, void #81
То есть: работает это как парсер естественного языка на основе атрибутивной сети переходов (ATN, Attributive Transition Network). Во входном файле исходники конечного автомата, построенного на этом заданном языке. Аналогичным образом можно выделять Verb-Subject-Object, Noun-Adjective и т.п.Этот текст
SENTENCES S1разобран посредство парсера на ATN, грамматика которого задана выше.
A BIG RED BLOCK WAS DROPPED BY THE BOY ;
THE BOY DROPPED A BIG RED BLOCK ;
A BLOCK WAS DROPPED ;
THE BLOCK DROPPED ;
END S1
✅ 2023/01/15 19:57, Автор сайта #82
Тут следует напомнить о таких языках как Icon: Unicon, Icon, Snobol, Spitbol, Snowball.
К старым языкам (в том числе к Сноболу) у меня скепсис: у них было столько времени, чтобы доказать своё превосходство, но они этого не сделали. Значит, превосходства нет. С одной стороны, большинство алгоритмов не устаревают, а часть — вообще бессмертна. Но языки — это форма записи этих алгоритмов, а вот форма может стареть, потому что находится лучшая форма. Вот поэтому не хочется засучив рукава изучать Снобол.вычисляемое по ленивой схеме
Расходы на поддержание ленивости порою превышают выгоды от него. Ленивый Хаскелл не даст соврать.Примерно как вычисление «||» в Си
В Си-шной ленивой операции «||» есть один изъян: второй операнд может, выдавая значение «истина» или «ложь», производить побочные эффекты. Опуская вычисление второго операнда, мы отключаем (возможно ошибочно) побочный эффект. Поэтому без последствий можно опускать вычисление второго операнда, только в том случае, если это чистая функция. К тому же здесь ставится задача разработки языка для системного программирования, поэтому ленивые вычисления будут там, где они явно нужны.Но лучше, на мой взгляд, смотреть практическое применение идеи грамотного программирования
Вы повторяетесь, Вы об этом уже писали.Как лично я бы писал реализацию своего языка программирования (если бы так уж сильно приспичило)?
Думаю, говорить о «приспичило» некорректно. Вот вам писать тут комментарии приспичило или нет?обоснования необходимости нового языка программирования и его концепции, унифицирующей сильной идеи
Об этом уже писалось:Для успешности новому языку программирования нужна критическая масса удачных нововведений.
Здесь остро не хватает, на мой взгляд, грамматики PL/1 в таком же, откомментированном, грамотном виде.
Кому её не хватает? Кому так остро «приспичило»? Дмитрий Караваев, разработчик компилятора PL/1-KT, который занимается им больше 30 лет и чьи статьи есть на этом сайте, вроде бы не нуждался. А у Вас откуда такая информация?Язык [Снобол] довольно мощный: можно определять свои функции
А что, на Си уже нельзя? Он есть для всех платформ поголовно. Очень удобно делать трансляцию в Си, чтобы потом твой язык работал на множестве платформ. С допиливанием напильником, но тем не менее.Программа на Сноболе — это конечный автомат, управляемый сопоставлением с образцом.
Пишу лексер, и мне надо, чтобы он выдавал для числовых констант достаточный тип. Например, для константы «1» достаточный тип — uint(1), для «-7» — int(3), для «31» — uint(5), для «-127» — int(7) и т. д. Как это сделать регулярными выражениями, конечными автоматами, грамматиками типа 3? Даже не задаю себе этот вопрос. Просто написал на Си то, что нужно, и это работает.✅ 2023/06/29 05:25, kt #83
Как известно, баг, который нельзя исправить, называется фичей. Правда, мне всегда при этом вспоминается цитата:Кузьмич, ты поверил что-ли? Так ведь это была хохма!
Тем не менее, читаю в статье (https://habr.com/ru/companies/ncloudtech/articles/743930/)
Когда задумываешься о проблеме неопределённого поведения, одним из первых в голову приходит вопрос: зачем оно вообще нужно? Есть же промышленные языки вроде Java, C# и множества других, обходящихся без этой фичи. Между тем это именно фича, и вот почему.
С моей точки зрения, С и С++ довольно продуманные языки, и наличие в них UB, конечно же, логически обосновано. Среди прочего оно позволяет:
Не реагировать компилятору на некоторые ошибки, трудные в диагностике
Избегать определения запутанных мест в пользу одной из стратегий реализации и в ущерб другой
Иметь своё определение неопределённого поведения в случае с каждой реализацией компилятора
Устранить накладные расходы на проверку разных граничных случаев
✅ 2023/06/29 22:52, Автор сайта #84
Си был первый язык программирования высокого уровня, который программисты написали «для себя». Фортран был написан для математиков и физиков, Кобол — для финансистов, PL/1 пытался объединить и тех, и других. Их создали в силу какой-то необходимости. Это была «революция сверху». А Си — «революция снизу». Он родился «по любви». По любви без обязательств и уз Гименея. Ну и не избежал генетических дефектов.Если за предшественниками Си стояли «Голубой гигант» и учёные со степенями, то Си разрабатывала шпана. Первый подход можно назвать «креационизмом», это когда всю вселенную создаёт всевышний. У Творца был замысел и видение, и они реализовывались. А Сишный подход — эволюционный, он развивался за счёт отбраковки дефектных, неэффективных средств. Тяп-ляп, «эволюция сама порешает». В итоге, человек хоть и вершина эволюции, но микробов и насекомых всё равно больше. Если сравнить язык изначальный Си (который я пропустил и не изучал) и «причёсанный» Си конца 1980-х, то разница сильно заметна. И когда случайно сталкиваешься с изначальным Си, то волосы дыбом: «Разве так можно?! Так было приято раньше?!»
Ещё было бы хорошо, чтобы стандарты языка содержали какие-то нормативы по сообщениям об ошибках. Простой пример. В подключаемом #include файле встречаются непарные скобки:
{
(. . .(. . .(. . .) )
}Казалось бы, внутри {. . .} можно отследить непарность скобок. Ан нет! Выдаётся сообщение, что ожидается запятая в конце головного файла!Читаю в статье:
компилятор, видя, что условие цикла ведёт к переполнению типа int и зная, что случиться этого не может, делает условие всегда true
Гм... Не логичнее ли выдать при компиляции ошибку или предупреждение? В PL/1, насколько мне известно, проблема решается явно. Обработку исключительных ситуаций на этом сайте уже рассматривали.По стандарту С++, использование неинициализированной переменной приводит к неопределённому поведению
В современных языках переменные создаются инициализацией, что исключает эту проблему.✅ 2023/07/01 14:14, Ильдар #85
Во многих случаях неопределённое поведение на самом деле определённое. То есть оно не определено в стандарте языка и оставлено на усмотрение разработчиков компилятора. Разработчики сами должны определиться с реализацией. Ну а программисты, использующие компилятор, должны либо читать документацию на него, либо выяснять реализацию неоднозначных моментов экспериментально. Да, неприятно, хотя и не драматично.✅ 2023/07/05 19:16, kt #86
Читаю о языке Solidity в заметке https://habr.com/ru/companies/otus/articles/745916/Но как-то странно подаются его достоинства (в комментариях):
...
Асинхронность: Solidity синхронен, что упрощает понимание потока выполнения кода, в отличие от асинхронного JS.
Параллелизм: Solidity не поддерживает многопоточность или параллелизм, что упрощает логику кода.
Отсутствие чего-либо, часто — это вовсе не достоинство. А то так можно много достоинств отыскать. Например, если нет float — не будет ошибок округления, если нет индексируемых массивов — не может быть выхода индекса за пределы и т.п. Под девизом: "Если у Вас нету тёти, то Вам её не потерять"
✅ 2023/07/06 21:55, Неслучайный читатель #87
Пишут про Solidity:запись значений в эти слоты может быть дорогой процедурой (до 20 000 газа при использовании "холодной" записи).
используется на один слот меньше, что позволяет экономить 20 000 газа.
в случае сбоя в работе контракта все потраченные на его выполнение средства (газ) не возвращаются
требует затрат газа (21000 газа за простую передачу эфира)
++i просто увеличивает значение, не создавая временной переменной, что экономит газ.
Использование функции selfdestruct снижает стоимость транзакции на 24 000 газа, но не более половины стоимости газа транзакции.
Удаление переменной возвращает 15 000 газа, но не более половины стоимости газа транзакции
Не требует газа для объявления, но для изменения переменной памяти требуется газ (меньше, чем для хранения).
✅ 2023/07/10 02:19, avisv #88
Посоветуйте что-нибудь из нишевых ЯВУ для написания двупроходных ассемблеров. Это простая "хотелка". Но есть и куда более сложная. Есть ощущение тупика ИИ в технологии "машинного обучения". Возможно это связано с реализациями на Python или чем-то из этого ряда. Тест, который не проходит эта технология при обработке текста. Даем ей в качестве дата сетов рассказы раннего Чехова. Как сделать, чтобы она по сюжету или даже развернутому плану рассказа выдала на выходе нечто похожее на раннего Чехова? Ну или просто даем ей на вход произвольный текст литературного произведения и просим завершить начатое. Всё, что сейчас представлено в Интернете, даёт ничтожный результат. Стоит решение этой проблемы создания нового языка программирования? Если ответ отрицательный, то на каком из существующих ЯП посоветуете это делать?✅ 2023/07/10 09:43, kt #89
Странное сочетание "хотелок" )) На мой взгляд, для создания относительно простой штуки — транслятора с ассемблера, достаточно любого универсального языка. Да и не знаю я "нишевых" языков для написания трансляторов. Разве что, вспоминается шутка, что транслятор с Паскаля нужен для написания трансляторов с Паскаля. Любой универсальный язык обрабатывает тексты и годится для написания обработчика текста, коим и является транслятор.Есть ощущение тупика ИИ
Правильное ощущение. Того ИИ, которое хотели, пока нет и не факт, что он будет устроен как GPT4.Пока это всего лишь "Т9 на стероидах". С тем же успехом можно читать попугаю рассказы Чехова и ждать, что в ответ попугай сочинит и произнесет новый рассказ.
✅ 2023/11/28 20:15, kt #90
На хабре появилась заметка, где немного касаются именно создания языков, а не только написания трансляторов: «Об изучении компиляторов и создании языков программирования»✅ 2023/11/29 14:31, Автор сайта #91
Спасибо за ссылку. Очень в тему.Разработка языка программирования и написание компилятора — это два почти совершенно разных навыка.
Казалось бы — очевидная вещь, но очень редко об этом говорят.✅ 2023/11/29 20:37, Ильдар #92
Казалось бы — очевидная вещь
Не до всех доходит. Читаю на Дзене название статьи: «Язык программирования весом в 1 кб, который работает». Не видят разницы 😃✅ 2023/12/01 19:03, Comdiv #93
На самом деле это настолько слабая мысль, что сам автор заметки, заявив её в 1-м абзаце, не понимая того опровергает уже в 3-м.Научиться разрабатывать хороший язык программирования будет сложнее, если у вас нет опыта решения задач разработки компиляторов
То есть сам же и говорит, что навык создания языка программирования ≈ навык создания компиляторов + ещё что-то, что совершенно точно не почти совершенно разные навыки.Практически все успешные языки либо подогнаны под известные методы трансляции (хороший подход), либо вообще без затей определяются напрямую реализацией (плохой подход). В обоих случаях навык создания дизайна языка оказывается тесно связан с навыком создания исполнителя языка.
Описывал эту тему, только в обобщённом виде, в заметке «Дизайн, отделённый от воплощения — либо ложь, либо проблема».
✅ 2023/12/02 16:43, Автор сайта #94
Ваша статья правдива и опровергнуть её невозможно. С другой стороны, в Вашей статье нет всей правды, да и не могло быть хотя бы потому, что статья имеет ограниченный объём текста, а правда очень велика.Продолжая Ваши «транспортные» аналогии, могу добавить, что всем конструкторам транспорта без сопромата и физики — просто никуда. И чем лучше их знаешь, тем лучше соотношение цена/возможности. Но вот только одни знатоки сопромата и физики конструируют автомобили, другие корабли, а третьи самолёты. Но ведь конструирование этих разных видов транспорта помимо сопромата и физики требует других очень разных знаний и навыков. А некоторые люди знают сопромат и физику, но совсем не конструируют, они просто проверяют или испытывают уже готовые изделия. И к конструкторской работе они зачастую не способны.
Так и с разработчиками языков программирования: знать теорию формальных языков и методы построения трансляторов обязаны все, но одни относятся к ним как к веригам, ограничивающим полёт фантазии, а другие — наоборот:
Более того, дизайн, созданный под простую реализацию, нередко становится предметом особой гордости разработчиков (порой, в ущерб другим важным свойствам).
Например, разработчики Алгол-68 придумали такой сложный язык, что для него пришлось разрабатывать двухуровневые грамматики, обычных было недостаточно. И это вызвало сложности с реализацией. Разработчики достаточно простого языка Си не захотели прогибаться подХотя реализация языков плюс-минус схожая, но языки, несмотря на это, получаются очень разные. У кого-то получился Паскаль, а у кого-то Пролог. У кого-то Питон, а у кого-то Хаскелл. И тут можно вспомнить, к примеру, что контекстно-свободные грамматики хоть и накладывают ограничения, тем не менее допускают бесконечное множество языков. Так что выбор есть. Не даром говорят: «Кибернетика — это неограниченные возможности и возможные ограничения».
P.S. Применение слова «дизайн» по отношению к языками программирования мне не нравится. Традиционно это слово в русском языке имеет узкий смысл, в отличие от английского. Но, к сожалению, это слово всё чаще становится смысловой калькой с английского. «Дизайн» — это то, чем занимаются дизайнеры. Если этим занимаются не дизайнеры, то это не дизайн. Не сочтите за занудство, просто трепетно отношусь к родному языку.
✅ 2023/12/02 22:09, Comdiv #95
Тут очень много ошибок, отвечу только на несколько.Грамматика ван Вейнгаардена была нужна для уменьшения неформального текста в спецификации, сам Алгол-68 не требовал строгого отказа от БНФ.
С — это сплошной компромисс под простую реализацию. Многие «странные» возможности, которые изумляют разработчиков с точки зрения «зачем», это просто следствие простых правил.
И Паскаль, и последующие языки Вирта тоже подразумевают лексические уловки с построением таблицы.
Также, простота не тождественна прямому следованию формализмам. Лексическая уловка может покоробить чувства любителей чистых концепций, но воплощение не усложняет.
Воплощения разных языков тоже очень разные. Кроме того, часто дизайн языка говорит очень многое об умении его автора воплощать исполнитель языка. Например, динамическую типизацию многие «мастера» выбирали потому, что это гораздо проще воплощается, особенно, с учётом всех возможностей.
✅ 2023/12/03 15:06, Автор сайта #96
Отвечать тоже буду не на всё. Могу только заметить, что сталкиваешься с противоречиями и невозможностью что-то реализовать из идей не потому, что мешают реалии построения компилятора, а из-за того, что одна концепция вступает в противоречия с другой. При проектировании «сверху вниз» новизна, бывает, застревает из-за противоречий на верхнем и среднем уровне, а до нижнего, то есть синтаксиса, даже не доходит. Но кому-то больше подходит способ «снизу вверх».Хотя и на уровне синтаксиса бывает не всё однозначно. Например, хотелось бы иметь идентификаторы, состоящие из нескольких слов. Но когда хочется ещё и мягких (контекстных) ключевых слов, то одновременная реализация и того, и другого делают таким сложным синтаксис, что лучше выбрать что-то одно.
часто дизайн языка говорит очень многое об умении его автора воплощать исполнитель языка.
Как говорили классики, практика — критерий истины. Если компилятор точно реализует описанный язык, то разработчик умеет писать компиляторы или интерпретаторы. А уж с лексическими уловками или без — это уже никого не волнует, Победителей не судят.✅ 2023/12/06 17:16, Comdiv #97
Если вы сталкиваетесь с противоречиями, значит уже думаете о реализации, потому что чистый незамутнённый дизайн всё стерпит. Эксперт вы или нет, в конце-то концов? (https://youtu.be/8BctbPxfVQ8).Противоречия, к слову, могут быть и мнимыми, потому что могут быть следствием неудачного выбора реализации. Пример с синтаксисом об этом. Достаточно было бы хранить исходный код в насыщенном формате текста, и ключевые слова, включая будущие, никогда не пересекались бы с идентификаторами, потому что отличались бы от них видимо различимым атрибутом, а не литерным наполнением. Но так как над дизайном висит подгон под реализацию с исходными текстами в примитивном плоском тексте, а это именно что часть реализации, пусть никого не обманывает фальшивое "да я сам так и хотел", то и появляются такие сложности. Так что это ещё и пример того, что часто разрыв реализации и дизайна — это ложь.
И как будто этого мало, но просто многословные идентификаторы оказываются ещё и иллюстрацией того, что разрыв реализации и дизайна — это проблема, если речь идёт о человеческой реализации. В естественных языках многословные идентификаторы или слова, обозначающие не совсем то, что обычно, совсем не спроста берут в кавычки — так легче понять особость термина.
Потому что не только программе, но и человеку будет легче распознать
if `if` = `then` then `then` = `else`; else `else` = `if`;Многословные идентификаторы можно не брать в кавычки, если они не соприкасаются со служебными словами, а разделяются другими знаками, то есть вместо
если `размер выхода` ⩽ `размер входа` томожно написать
если (размер выхода ⩽ размер входа) тоА ещё лучше избавиться от скрытой структурности(и от лишней литературности), и вынудить программиста обозначать структуру явно, а не засовывать её в имя. Но эта идея требует тщательной отработки.
если выход.размер ⩽ вход.размер то
✅ 2023/12/07 23:54, Автор сайта #98
уже думаете о реализации, потому что чистый незамутнённый дизайн всё стерпит
В том и дело, что отбраковка идей начинается именно на стадии задумок. Мысленным экспериментом без всякой связи с реализацией. Например: «Программа, целиком состоящая из чистых функций, не нужна». А где-то — на уровне лексем, то есть реализации. Но она, реализация, на первом месте тогда, когда ближе к делу, при формулировании правил и написании лексического и синтаксического анализатора.Достаточно было бы хранить исходный код в насыщенном формате текста, и ключевые слова, включая будущие, никогда не пересекались бы с идентификаторами, потому что отличались бы от них видимо различимым атрибутом, а не литерным наполнением.
Тут вопрос вполне философский, можно сказать, диогеновский:— Если бы ты льстил царю, тебе не пришлось бы есть чечевицу.
На что ответ Диогена:
— Если бы ты приучил себя к чечевице, тебе не пришлось бы льстить царю.
В таком случае думают в первую очередь о реализации дерева, а не о том, как бы составить правила языка так, чтобы распознавать всё это LL(1)-грамматикой.
Но так как над дизайном висит подгон под реализацию с исходными текстами в примитивном плоском тексте
Ну во-первых, это опять об отношении к чечевице. Во-вторых, если отекстовка передового по всем меркам дерева в примитивный текст возможна, то возможно и обратное преобразование. Несмотря на то, что текст примитивен. Суть — в дереве, а текстовое представление — это лишь одна из форм существования программы. Спор о том, что первичнее — дизайн или реализация — схоластичен (Яйцо или курица? Тупым концом или острым?). И никто не собирается внедрять в умы ложные утверждения на сей счёт.многословные идентификаторы оказываются ещё и иллюстрацией того, что разрыв реализации и дизайна — это проблема
С разбором многословных идентификаторов успешно справились полсотни лет назад в языке ЯРМО. У Алексея Недори в своём языке идентификаторы тоже такие. Мой лексер вполне успешно справляется с разбором этих идентификаторов в точности с описанием. Да, разбор получился длинноват. Однако работает. Выкладывать исходники пока не собираюсь. Можно было бы выложить наработки для тестирования. Но это дополнительные хлопоты и расход времени: будут нужны описания и т. д.Многословные идентификаторы можно не брать в кавычки, если они не соприкасаются со служебными словами
Так нет проблем, если всё-таки соприкасаются. Ключевые слова спереди и сзади успешно изымаются из состава многословных идентификаторов. А внутри — и не надо их искать. Не потому, что «подгоняю» задумки под возможности анализаторов, а потому что никогда не нравились конструкции видаif <условие> then <выражение>Ваше мнение мне понятно. Но у меня есть своё. Хотя и складывается впечатление, что Вы уговариваете меня не делать последний шаг перед пропастью.
SELECT <идентификатор> WHERE <выражение>
✅ 2023/12/08 03:02, Comdiv #99
Опять много ошибок.Так нет проблем, если всё-таки соприкасаются
Я наверно недостаточно ясно выразил, что проблема не для трансляторной реализации, а для человеческой — главной реализации. Человеку смотреть неприятно на салат из многословных идентификаторов и служебных слов, хоть с винегретной раскраской, хоть без. Комментарии же и переносы строк в идентификаторах — это вообще мрак дизайнерской мысли.С другой стороны, Вашу идею можно обвинить в половинчатости:
1) Есть разница между "достаточно" и "возможно" 2) насыщенный текст — это абстрактно выраженная идея, которая не противоречит никаким "неполовинчатым" идеям, в том числе и автоматической раскраске.При этом допускается разнообразие синтаксисов — по вкусу. Кому-то надо в стиле Си, а кому-то Питон по душе.
Язык не может иметь разнообразный синтаксис, иначе это не один язык. Писал и об этом — https://comdivbyzero.blogspot.com/2019/11/syntax-base-of-lang.html. Синтаксическое дерево программы строится по одним и тем же правилам, и эти правила и есть синтаксис. А так называемый стиль C или Python находится на уровне около лексики и незначительных перестановок.Спор о том, что первичнее — дизайн или реализация — схоластичен (Яйцо или курица?). И никто не собирается внедрять в умы ложные утверждения на сей счёт.
Само утверждение о схоластичности вопроса — это уже ложное утверждение, так как на самом деле он предельно физичен. Без лишних предложений подумать о том, как появились Вселенная, Земля, жизнь и человек, сразу напишу, что дизайн — это часть реализации, причём необязательная часть. Это предельно практический вопрос, и от ответа на него во многом будет зависеть, будет ли человек заниматься реализацией адекватно или через задницу курицы с яйцами.И боже мой, даже вопрос про курицу и яйцо имеет точный ответ. Это не философские вопросы, а дурь "как я не понимаю философию".
✅ 2023/12/09 14:33, Автор сайта #100
Человеку смотреть неприятно на салат из многословных идентификаторов и служебных слов, хоть с винегретной раскраской, хоть без.
То есть Вам неприятно видетьсумма платежаДля Вас лучше
дата оплаты
СуммаПлатежаили
ДатаОплаты
сумма_платежаНо так считают не только лишь все. Могу заметить, у меня переход на многословные идентификаторы прошёл безболезненно.
дата_оплаты
Комментарии же и переносы строк в идентификаторах — это вообще мрак дизайнерской мысли.
Всё разумно в меру. В этом примере вполне уместно:скорость (*км/ч*) автомобиля = коэффициент пересчёта * скорость (*м/с*) автомобиля
Я наверно недостаточно ясно выразил, что проблема не для трансляторной реализации, а для человеческой — главной реализации.
Да нет же, Вы выразились чётко и недвусмысленно, там невозможно найти скрытый смысл:Практически все успешные языки либо подогнаны под известные методы трансляции (хороший подход), либо вообще без затей определяются напрямую реализацией (плохой подход).
И теперь уходите от темы, сильно её увеличив её в очертаниях:не для трансляторной реализации, а для человеческой — главной реализации.
Я же доказываю, что когда заходит речь о фундаментальных вещах, о парадигме, философии языка, то нет речи ни о каком «подгоне под известные методы трансляции»! И привёл пример, где это совсем не так. Но Вы второй раз ушли от темы, начав осуждать ошибочность моих воззрений на функциональное программирование. Хотя в этом месте должны были быть Ваши слова — идёт ли там «подгон под известные методы трансляции» или не идёт.Часть Вашего сообщения о ФП я перенесу в ту статью, которую Вы обсуждаете. Там же отвечу Вам.
Вы ещё недавно критиковали примитивный плоский текст:
над дизайном висит подгон под реализацию с исходными текстами в примитивном плоском тексте
И предлагали насыщенный форматированный текст:Достаточно . . . хранить исходный код в насыщенном формате текста, и ключевые слова . . . отличались . . . видимо различимым атрибутом, а не литерным наполнением.
Я же говорю, что примитивный плоский текст можно разными способами подсвечивать и разукрашивать. Но текст всё равно останется плоским и примитивным, а всё медиаэффекты достигаются сторонними средствами. Но Вы опять уходите от темы, расширяя её очертания:насыщенный текст — это абстрактно выраженная идея
Тогда нужно сделать вывод, что примитивный плоский текст — частный случай насыщенного форматированного текста.Язык не может иметь разнообразный синтаксис, иначе это не один язык.
Так никто ж не спорит. Я привёл пример, как программа может взаимообратимо трансформироваться из одного представления в другое. Из дерева в плоский текст и обратно. И примитивность текста тому не помеха.Само утверждение о схоластичности вопроса — это уже ложное утверждение.
Это характеристика моего личного отношения к спору вокруг темы, которая для меня особой ценности не имеют. Это не то, что не даёт спать по ночам. И моё отношение допускает существование чужой правды.✅ 2023/12/11 22:45, Ильдар #101
Практически все успешные языки либо подогнаны под известные методы трансляции (хороший подход), либо вообще без затей определяются напрямую реализацией (плохой подход).
Так можно подогнать и под неизвестные. Берём LL(1)-грамматику и меняем в ней все, что было «левым», на «правое». И выходит RR(1)-грамматика. Теоретическая база не меняется, просто всё делается справа налево, а не слева направо. Делаем под это разбор. Формально совершенно новый метод. Грамматика становится шыворот-навыворот. И языки такие же. А что, компьютеру всё равно, в какую сторону читать, скорость чтения будет одинаковой. Вуаля! Используйте неизвестный метод трансляции, подгоняйте под него языки!✅ 2023/12/12 00:41, Бурановский дедушка #102
Ильдар, у многих желающих защитить диссертацию, в этих диссертациях научной новизны кот наплакал. Они Вам должны проставиться!скорость чтения будет одинаковой
Они даже докажут, что скорость трансляции RR(1)-грамматик для определённых языков будет выше!✅ 2023/12/12 18:52, Ильдар #103
У меня есть ещё более сумасшедшая идея. Ещё можно попробовать чтение слева и справа навстречу друг другу, пока позиции чтения не встретятся. И наоборот: читать от центра к краям :) Идей — на 3 диссертации :)✅ 2023/12/12 21:18, Вежливый Лис #104
Была уже идея парсить с двух сторон в 2017-м году: http://plana.mybb.ru/viewtopic.php?pid=214#p214:Если сделать допущение, что в текстовом редакторе только одна область текущего редактирования, где синтаксис нарушен, то можно строить два частичных дерева — с начала и с конца (а в месте ошибок с обоих сторон как раз область редактирования и будет находится).
✅ 2024/01/23 11:52, Неслучайный читатель #105
«Дизайн, отделённый от воплощения — либо ложь, либо проблема»
Как минимум в научной фантастике дизайн (если быть точнее, то идея) существует отдельно от воплощения. Идеям позволено быть оторванными от реальности. Не думаю, что Циолковский сначала изучил сопромат, химию и физику горения и прочие технические детали и только потом ему пришла в голову идея космических полётов. Было всё наоборот: сначала он сформулировал идеи и теорию, и лишь после его смерти инженеры нашли, как это воплотить в жизнь.✅ 2024/02/03 10:20, kt #106
На мой взгляд, неплохая статья «Зачем делать новый язык программирования?»✅ 2024/02/04 17:45, Автор сайта #107
Спасибо, хорошая статья.в российской индустрии в настоящее время не видно тенденции к сохранению и развитию навыков в указанной области. Мы пользуемся инструментами, созданными в других странах, что в текущем политическом моменте несколько самонадеянно. Имеющиеся же проекты или не воспринимаются серьезно, или игнорируются.
Нет никаких ни теоретических, ни практических препятствий для того, чтобы в компиляторах оставить закладки. Конечно, найдутся такие люди, которые скажут, что это паранойя и надо одевать шапочку из фольги, мол никогда такого не было. Но такое возможно, а не сделано только потому, что есть другие, более простые и дешёвые способы кибератак. Когда круг возможностей у недругов будет сужаться, то в ход могут пойти и компиляторы.Логичным развитием ситуации с языками и компиляторами в стране считаю дополнение нормативной базы о реестре отечественного ПО таким образом, чтобы компаниям было выгодно разрабатывать софт с помощью инструментария, сделанного в России.
Ну так надо постепенно, но неизменно сужать возможность пользоваться чужим ПО. Вводить аналог «утилизационного сбора», который, надеюсь, будет эффективнее, чем в автопроме.✅ 2024/02/04 18:26, kt #108
А вот, на мой взгляд, гораздо менее интересная статья "Каково это, создавать язык программирования сегодня?"https://habr.com/ru/companies/ruvds/articles/790868/
Общая ошибка и беда таких статей, что реально речь идет не о создании языка, а всего лишь о создании простого транслятора по шаблону.
✅ 2024/02/04 23:06, Автор сайта #109
гораздо менее интересная статья
Да, так и есть. Пишут:Создание языка в шесть шагов... Шаг 1: из текста в синтаксическое дерево
Не видят разницы между созданием языка и реализацией компилятора.реально речь идет не о создании языка, а... о создании простого транслятора
И эту ошибку допустили зарубежные авторы (статья переводная), а не наши.✅ 2024/02/05 10:26, kt #110
Эту ошибку совершают многие. Например, число плюсов к данной статье, показывает, что большинство читателей также не понимают разницы и не видят несоответствия заголовка и содержания.Написать автору можно на электронную почту
mail(аt)compiler.su
Продолжение цикла и выход из него