Каким должен быть язык программирования?Программисты делятся на тех, кто уже сделал компилятор своего языка программирования, и на тех, кто это сделать только собирается. Этот сайт сделан как раз для тех, кто только собирается. Итак, у сайта следующие цели:
А теперь по-подробнее по пунктам. Обсуждение существующих языков программированияВо многих языках есть некая «изюминка», привлекающая к себе сторонников. Есть и недостатки. Выявляя и обсуждая и то, и другое, можно нарисовать те контуры, в которые должен вписаться идеал языка программирования. В нём необходимо избежать уже совершённых ошибок. У них были разные причины, но в них надо разобраться.Создание идеального языка программирования.Идеальный язык программирования — это такая же недостижимая мечта, как и идеальная жизнь. Но стремление к совершенству приводит к появлению вещей, которые делают нашу жизнь лучше. Скептики могут увидеть в этом изобретение очередного велосипеда. Но и это не бывает напрасным: если очередной велосипед не стал лучше прежнего, то сам процесс улучшает изобреталей. Велосипед может быть забыт и выкинут, а вот изобретатели приобретут инженерный опыт.Для начала вашему вниманию предлагаются мысли и идеи, которые уже есть на сайте. Надеюсь, что это вызовет интерес и желание это обсудить, прокомментировать или же возразить. И предложить такую альтернативу, которую и лучше, и понятнее. Часто проекты новых языков программирования либо нигде не обсуждаются и существуют только в голове авторов, либо обсуждаются в узком кругу. Затем пишется компилятор и общественность ставится перед фактом: есть новый язык, есть компилятор, пользуйтесь им; если он вам не нравится, то это ваши проблемы; мы никогда не обещали, что он вам будет нравится. Предлагается другой путь:
Надеюсь, в результате дискуссий у нас появится на бумаге такой язык, который действительно стоит воплотить в компилятор. Без внесения в язык свежих идей и изюминок, которые помогут снискать языку популярность, к работе над компилятором даже не стоит приступать. В противном случае этот язык программирования годиться только для курсовой или дипломной работы. Или будет продуктом для узкой ниши, вторым языком «1С». История создания языков программирования знает примеры коллективного обсуждения будущих языков. Языки Алгол-68 и Ада разрабатывали созданные для этого комитеты. Результатом их работы было формальное и неформальное описание будущих языков, для которых в последствии были разработаны компиляторы. Коллективный принцип работы не гарантирует успешности, но он:
Пособие «Как придумать язык программирования»По ходу обсуждения будут вноситься исправления в уже написанный материал. Ожидаемо появление статей программистов, у которых существует к этой теме интерес — как профессиональный, так и любительский. Ведь всегда есть место для озарений. В результате весь ход наших дикуссий можно будет расценить, как пособие «Как придумать язык программирования».На сегодняшний день существуют тысячи языков программирования. Но ещё ни один автор языка не объяснил, почему это сдалано именно так, и не доказал, что это наилучшее решение. Никлаус Вирт, один из самых «плодовитых» языкописателей, профессор, автор многих книг, не посчитал нужным комментировать процесс изобретения своих языков. Что же говорить об остальных, которые придумали один единственный язык программирования? Восполняя этот пробел, будем стараться комментировать ход своих мыслей, аргументировать свои предложения. Создание языка начинается не с описания грамматики. Должны родиться какие-то идеи, потом они должны пройти, как минимум, проверку на непротиворечивость концепций. Затем должны выкристаллизоваться основные идеи как синтаксиса, так и семантики языка. И лишь потом — формальное описание.
Существуют ли книги или сайты на тему
Вполне может быть, что материалы на тему «Как придумать язык пpогpаммиpования» всё-таки существуют,
просто автор этих строк с ней не знаком.
Тем не менее, как не бывает двух одинаковых прожитых жизней, так и не бывает двух одинаковых опытов разработки языка программирования.
И если наш опыт будет интересен, то он достоин письменного описания.
|
| Оцените | Оценки посетителей |
| Нравится | █████████████████████████████ 48 (68.5%) |
| Неплохо | ██ 2 (2.85%) |
| Так себе | ███ 4 (5.71%) |
| Не нравится | ██████████ 16 (22.8%) |
Отзывы
2014/11/28 02:42, Санал #
2014/11/28 10:59, Автор сайта #
2014/11/29 16:05, Nadolin #
2014/11/29 11:16, Автор сайта #
2015/02/09 17:43, Павел #
2015/02/09 22:03, Автор сайта #
2015/02/19 10:22, programmer #
2015/02/19 14:27, Автор сайта #
реальная выгода создателей популярных языков исчислялась в сотнях тысяч долларов
Пожалуйста, факты в студию со ссылкой на источники.
2015/02/19 14:26, programmer #
Отсутствие здравого смысла рассматривается как признак недостатка финансирования и профессионализма или как совокупность признаков, указывающих на бесперспективность проекта.
2015/02/20 13:25, Автор сайта #
2015/02/20 11:59, programmer #
2015/02/20 12:18, programmer #
А как раз критика уже была, по очевидным моментам. Как можно надеяться на коммерческую перспективность, допуская столько ошибок в статьях ? А вот если все просто делается, как персональное увлечение, то, собственно, вам придется ограничится тем уровнем что есть, без конкретики критических замечаний — потому что конкретика будет означать как раз раскрытие новых подходов и идей.
2015/02/20 15:38, Автор сайта #
2015/02/20 12:54, programmer #
Для Вас лично я бы порекомендовал изучить ошибки результатов шизанутого творчества создателей 1С финансовых программ — язык программирования. Их ошибки очень характерны, хотя и происходят из жадности, тупости и прочих элементарных вещей.
2015/02/20 16:11, Автор сайта #
2015/03/18 07:43, Е.В.Геній #
Пока вижу только критиканство — очень похоже что 1С своимъ встроеннымъ РЯП кого-то оставило безъ миски супа...
2015/04/07 10:50, misha_shar53 #
2015/04/07 15:38, Автор сайта #
Чтобы преодолеть эти стереотипы, надо просто описать его характерные черты, которые высвечивают его преимущества над остальными. Вы готовы изложить это, только конспективно, чтобы люди не устали читать?
Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку. Отсутствие типизации (все данные хранятся как строки), низкий уровень абстракции, нечитабельность синтаксиса, отсутствие обязательного объявления переменных и поддержки приоритетов арифметических операций. Ключевые слова языка не зарезервированы, лишний пробел может совершенно изменить смысл синтаксической конструкции.
Я считаю принципиальной ошибкой то, что за основу обсуждаемого языка взят язык Си
С чего Вы это взяли?постараюсь подготовить статью с моим представлением об идеальном языке
А Вы не хотите сделать свой сайт на эту тему?
2015/04/07 14:44, misha_shar53 #
Этот язык 1) старый, 2) малопопулярный. О чём это говорит, если руководствоваться общепринятыми стереотипами?
Если руководствоваться стереотипами то ничего нового не получишь.Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины. Чем-то он не нравится людям, скорее всего и мне не понравится.
Причины, возможно, есть. И вам он тоже может не понравиться. Но от этого язык не станет хуже. Чтобы оценить достоинства, надо хотя бы немного с ним поработать. И чтение Вики недостаточно.А ещё в нём нет чистых функций
Странно? Почему это нет?лямбд и всего того, что вошло в широкую практику в последе время.
В практику в последнее время вошло много всякого мусора. Не всегда полезного.Лямбд — точно нет и зачем они в MUMPS я не понимаю. Кстати я их не встречал и в Си. А что ещё вошло в широкую практику в последе время? Анатации Java? Языки начинают напоминать кучу мусора. Ломается стиль языка и его обзорность.
Чтобы преодолеть эти стереотипы, надо просто описать его характерные черты, которые высвечивают его преимущества над остальными. Вы готовы изложить это, только конспективно, чтобы люди не устали читать?
Попробую.Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку. Отсутствие типизации (все данные хранятся как строки),
Это как раз его достоинство. Типизация языка порождает 80% его проблем. А как хранятся данные — в виде строк или в каком другом виде — неизвестно и языком не определяется и зависит от конкретной реализации.низкий уровень абстракции,
Утверждение в корне неверно.нечитабельность синтаксиса
Не хуже чем в других языках программирования. В нем нет нечитабельных конструкций. И вообще это сильно зависит от стиля написания программы.отсутствует обязательное объявление переменных
Это его основное достоинство. Управление данными полностью переложено на язык. Решается целая куча проблемм. Функции пишешь по смыслу, не вникая в тип аргументов
2015/04/07 14:56, misha_shar53 #
А Вы не хотите сделать свой сайт на эту тему?
Вы хотите чтобы я убрался с вашего сайта?И не хотите даже выслушать мои аргументы? Открывать свой сайт я не планирую. Все свободное время я трачу на разработку языка MSH.
2015/04/07 19:46, Автор сайта #
Утверждение в корне неверно.
Меня не надо переубеждать, лучше подправьте Википедию и будьте готовы отстоять свою точку зрения, ссылаясь на авторитетные источники.Вы хотите чтобы я убрался с вашего сайта?
Нет. Если Вы не хотите пользоваться своим языком в одиночку, Вам рано или поздно придётся сделать свой сайт. Сделайте его заранее, у Вас будет канал общения с Вашими будущими пользователями. И на этом сайте Вы можете изложить свои аргументы в наилучшем виде.Все свободное время я трачу на разработку языка MSH
Всё-таки отщипните кусочек времени, напишите о языке, Вы получаете полную свободу изложения!(см. выше).
2015/04/07 17:28, misha_shar53 #
Языки, в которых отсутствует типизация, менее эффективны.
Спорное заявление.Они не найдут применения в некоторых сферах, например, в системном программировании.
Утверждение ошибочное. MUPMS в OS DSM11 использовался в качестве системного. Мне трудно представить чтобы на нем нельзя было сделатьВсё-таки отщипните кусочек времени, напишите о языке, Вы получаете полную свободу изложения!(см. выше).
Я этим сейчас и занимаюсь. И обязательно завтра послезавтра напишу.
2015/04/08 05:16, misha_shar53 #
1. Создать традиционный язык, хорошо себя зарекомендовавший, который легко воспримет широкая аудитория, но более эстетически выглядящий.
2. Создать Новый язык обладающий новыми свойствами. Тогда надо определиться будет ли он нишевым или нет. И если да, то для какой ниши он создается. Какими свойствами он должен будет обладать?
Мне кажется вы склоняетесь к 1 варианту. Но тогда это будет ещё один 10001 Си или С++ подобный язык и перспективы его выживания мне кажутся сомнительными. Может я не прав.
2015/04/08 08:59, misha_shar53 #
Этот язык 1) старый, 2) малопопулярный.
Это не аргументы. Даже ещё более старый Аналитик совершенней большенства современных языков программирования. Эти аргументы никак не относятся к свойствам языка.Чем-то он не нравится людям, скорее всего и мне не понравится.
Странное заявление. Причем здесь люди? Надо получить собственное мнение о языке.О чём это говорит, если руководствоваться общепринятыми стереотипами? Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины.
А вот при создании нового желательно стереотипами не пользоваться.Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку.
Нечитабельность синтаксиса.
Ключевые слова языка не зарезервированы, лишний пробел может совершенно изменить смысл синтаксической конструкции.
низкий уровень абстракции.
Ну совсем не в тему. Уровень абстракции у MUMPS выше, чем у остальных языков. В литературе даже он упоминался как язык 4-го поколения. Организация данных тому подтверждение.поддержки приоритетов арифметических операций.
Да приоритеты отсутствуют. Это конечно не достоинство языка, но и не недостаток. Дело привычки у программистов и выбор модели у разработчиков. Если это включено в стандарт языка то это допустимая модель работы с данными.Отсутствие типизации (все данные хранятся как строки), отсутствие обязательного объявления переменных.
А вот собственно из за этого я и начал писать этот комментарий. По моему это и есть одна из причин по которой этот язык старательно замалчивается. Это язык ревизионист. Он покусился на самое святое в теории программирования на его бога — декларирование переменных. Откуда взялся этот бог уже никто и не помнит. Я думаю что все началось с первых трансляторов.
2015/04/08 13:36, Автор сайта #
Но подправить синтаксис проблем не составляет.
Да, но тогда это будет другой язык, вовсе не MUMPS, о достоинствах которого Вы хотите рассказать.В принципе, языки с некоторой долей погрешности можно разделить на две категории.
- Языки, допускающие эффективную реализацию. Их эффективность направлена либо на наибольшую скорость исполнения, либо на наименьшее использование вычислительных ресурсов. Последнее важно для мобильных применений: меньшая производительность процессоров, требования энергоэффективности (чтобы батарея меньше разряжалась).
- Языки, которые ставят целью наибольшую скорость работы программиста, а не программы. Поэтому на некоторые неэффективные решения закрываются глаза. Ну и что, что в PHP массивы реализованы посредством ассоциативных массивов: нет прямого обращения по индексу 2 в массиве $arr[2], но есть обращение к элементу ассоциативного массива по ключу 2. Ведь работает, не правда ли?
C/C++ ещё много лет будет здравствовать. Но и у конкурентов есть хорошие шансы: ведь C/C++ не может освободиться от своих «плохих» черт по причине обратной совместимости. Если бы Вы познакомились с языками Oberon-2, D, Rust, то не говорили, что это «ещё один Си». Скажите сторонникам Oberon-2, что этот язык такой же, как Си, и Вы узнаете, что они о Вас думают.
Он покусился на самое святое в теории программирования на его бога — декларирование переменных. Откуда взялся этот бог уже никто и не помнит.
Если кто и не помнит — так это Иваны, не помнящие родства. Всё дело в эффективном использовании памяти. Статическая типизация позволяет зарезервировать память ещё на этапе компиляции. Программы с динамической типизацией резервируют память на этапе исполнения. Более того, эту память приходится выделять в «куче», когда размер памяти под объект становится известен в момент его создания. А выделение в «куче» — достаточно «дорогостоящее» занятие: Двухстековая модель: тесты на скорость Так что декларирование переменных — не блажь.о что декларирование переменных является злом и не только не помогает но и сильно мешает некоторые из разработчиков языков начинают понимать.
Такое «понимание» связано с тем, что закон Мура работает на тех, кто уверен, что «пипл чип всё схавает». А ещё появилась типизация Хиндли — Милнера, которая зачастую создаёт иллюзию, что типизации нет. Это специально для тех танцоров, которым всегда что-то мешает.
2015/04/08 13:34, misha_shar53 #
2015/04/09 00:57, misha_shar53 #
Скажите сторонникам Oberon-2, что этот язык такой же, как Си, и Вы узнаете, что они о Вас думают.
Извините что затронул ваши религиозные чувства. Ладно не Си, Алгол или Паскаль.А ещё появилась типизация Хиндли — Милнера, которая зачастую создаёт иллюзию, что типизации нет. Это специально для тех танцоров, которым всегда что-то мешает.
Вообще-то я хотел сказать не о танцорах и что им мешает. А о существовании фантомов вроде декларирования переменных и GOTO, которые тормозят развитие языков программирования. Мне просто искренне жаль, что колоссальные ресурсы уходят в никуда. Хотя ваше обсуждение языка мне было полезно и интересно.
2015/04/10 15:06, Автор сайта #
2015/04/10 14:38, misha_shar53 #
В принципе, языки с некоторой долей погрешности можно разделить на две категории.
Языки, допускающие эффективную реализацию. Их эффективность направлена либо на наибольшую скорость исполнения, либо на наименьшее использование вычислительных ресурсов. Последнее важно для мобильных применений: меньшая производительность процессоров, требования энергоэффективности (чтобы батарея меньше разряжалась).
Языки, которые ставят целью наибольшую скорость работы программиста, а не программы. Поэтому на некоторые неэффективные решения закрываются глаза. Ну и что, что в PHP массивы реализованы посредством ассоциативных массивов: нет прямого обращения по индексу 2 в массиве $arr[2], но есть обращение к элементу ассоциативного массива по ключу 2. Ведь работает, не правда ли?
Каждая философия имеет право на жизнь, особенно если у языков непересекающиеся ниши.
2015/04/10 19:10, Автор сайта #
P.S. Философия языка сформулирована.
2018/10/29 10:15, 96383 #
Что за контрольное число такое: "дтвяносео пять тысяч девсти девянсото девять"
2018/10/29 11:44, kt #
Языков программирования уже больше, чем обычных живых и мертвых вместе взятых. С языками — так же, как и с программами. Почти всё, что нужно, уже есть. Но того, чего хотелось бы, ещё не написали.
И обычные языки, и языки программирования продолжают развиваться. Это процесс, а не свод законов.
2018/10/29 13:17, Автор сайта #
2019/02/24 23:14, MihalNik #
"Субъективное видение идеального языка программирования":
https://habr.com/en/post/435300/
2019/11/23 22:54, Сергей #
Что такое компьютер? Это куча ключей, которые знают только 1 или 0, каждому ключу присваивается смысловое описание, описание на английском. И чем глубже будем копать тем больше иностранных граблей будет вылазить.
Интересно родился ли русский Линус Торвальдс?
2019/11/26 18:57, Автор сайта #
В наших палестинах произрастают кулибины, левши, келдыши. Линусы — это не у нас.
2019/11/30 20:55, Сергей #
2021/03/26 14:17, Виталий Монастырский #
Считаю, что на сегодняшний день скопилось более, чем достаточно опыта для того, чтобы собрать подобную концепцию и воплотить её в жизнь. На данный момент проблемы с созданием такого языка программирования следующие:
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 #
- Абсолютно согласен, что разработка современного промышленного языка программирования невозможна в одиночку. Значит нужна команда, значит надо уметь иногда наступить на горло собственной песне, научиться находить компромиссы, договариваться. Я как раз хочу найти группу единомышленников, с которой можно было бы разработать такой язык.
- Не совсем понятна концепция многоуровнего языка программирования (назовем эти уровни ассемблер, ядро и язык). Если ассемблер — это 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, Виталий Монастырский #
Что это значит... это значит, что пользователь тоже сможет организовать цикл с помощью примитивных операторов 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 Маздайщик #
Второе, сборщик мусора — самое худшее решение, которое только может быть, и вызвано оно именно отсутствием АСУП, которую нужно просто написать и включить в стандарт языка
Предлагаемое Вами АСУП имеет ли отношение к стратегии управления памятью, предложенной Рафаэлем Прустом ASAP (As Static As Possible)? ASAP предполагает полностью статичное управление памятью без сборки мусора и счётчиков ссылок. В работе есть изъяны (недостаточная проработка изменяемых данных и параметрического полиморфизма), но в целом она интересная и стоит изучения. По ссылке выше диссертация, которая может быть сложна для неподготовленного человека.
2021/04/04 18:04, Александр Коновалов aka Маздайщик #
Написать автору можно на электронную почту mail(аt)compiler.su