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

Каким должен быть язык программирования?

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

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

  •   Обсуждение и разработка «на бумаге» такого языка программирования, который бы большинство программистов сочло бы идеальным или близким к тому. Обсуждения, дискуссии, притирка концепций — дело не одного дня и не одного месяца. Главное тут не скорость, а тщательность. К обсуждению приступить прямо сейчас, комментируя страницы этого сайта.

  •   Просветительская миссия. Существует множество книг на тему «Как написать компилятор». Диапазон авторов — от Ахо и Ульмана до Джека Креншоу. Но не существует книги «Как придумать язык программирования». Надеюсь, в результате дискуссий здесь появится материал, который можно будет озаглавить именно так.

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

            
Проект по созданию идеального языка программирования
Ernest Normand, 1886.
Пигмалион и Галатея.
Только тому, кто работает как
Пигмалион, будет своя Галатея.
Для попавших сюда случайно и/или неинтересующихся тематикой сайта есть возможность развлечь себя «чтивом»: статьи на компьютерные темы и компьютерный юмор. Надеюсь, это не позволит вам покинуть этот сайт с чувством разочарования.

             А теперь по-подробнее по пунктам.

Обсуждение существующих языков программирования

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

Создание идеального языка программирования.

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

             Для начала вашему вниманию предлагаются мысли и идеи, которые уже есть на сайте. Надеюсь, что это вызовет интерес и желание это обсудить, прокомментировать или же возразить. И предложить такую альтернативу, которую и лучше, и понятнее.
            
             Часто проекты новых языков программирования либо нигде не обсуждаются и существуют только в голове авторов, либо обсуждаются в узком кругу. Затем пишется компилятор и общественность ставится перед фактом: есть новый язык, есть компилятор, пользуйтесь им; если он вам не нравится, то это ваши проблемы; мы никогда не обещали, что он вам будет нравится.
            
            Предлагается другой путь:
  • публикация идей, мыслей, наблюдений и замечаний,
  • обсуждение опубликованного,
  • формальное и неформальное описание языка,
  • принятие решений о деталях реализации,
  • разработка компилятора, если разработанный язык будет стоить того.
            При обсуждении хотелось бы увидеть конкуренцию идей, поэтому на сайт будут приняты любые, даже бредовые, на первый взгляд идеи. Ожидаются как комментарии к текстам имеющихся статей, так и новые статьи, которые будут присланы непосредственно администратору сайта. К присланным материалам предъявляются лишь три требования:
  • материалы должны быть по теме,
  • они должны быть написаны грамотным русским языком,
  • они должны быть содержательны.
            Помня о том, что «физик должен уметь объяснить простой уборщице, чем он тут занимается», надеюсь, что в наших рассуждениях нам удастся избежать терминов типа «сентенциальная форма», «транзитивное замыкание» и «функциональная декомпозиция». А если возникнет в них необходимость, то постараемся изложить мысли без специальной лексики. Всё гениальное — просто.

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

            История создания языков программирования знает примеры коллективного обсуждения будущих языков. Языки Алгол-68 и Ада разрабатывали созданные для этого комитеты. Результатом их работы было формальное и неформальное описание будущих языков, для которых в последствии были разработаны компиляторы. Коллективный принцип работы не гарантирует успешности, но он:
  • застрахует в какой-то степени от ошибок, противоречий и непродуманности концепций,
  • позволит услышать идеи многих программистов, у которых есть свои мысли, но изложить их некому.

Пособие «Как придумать язык программирования»

             По ходу обсуждения будут вноситься исправления в уже написанный материал. Ожидаемо появление статей программистов, у которых существует к этой теме интерес — как профессиональный, так и любительский. Ведь всегда есть место для озарений. В результате весь ход наших дикуссий можно будет расценить, как пособие «Как придумать язык программирования».
            
             На сегодняшний день существуют тысячи языков программирования. Но ещё ни один автор языка не объяснил, почему это сдалано именно так, и не доказал, что это наилучшее решение. Никлаус Вирт, один из самых «плодовитых» языкописателей, профессор, автор многих книг, не посчитал нужным комментировать процесс изобретения своих языков. Что же говорить об остальных, которые придумали один единственный язык программирования? Восполняя этот пробел, будем стараться комментировать ход своих мыслей, аргументировать свои предложения.
            
             Создание языка начинается не с описания грамматики. Должны родиться какие-то идеи, потом они должны пройти, как минимум, проверку на непротиворечивость концепций. Затем должны выкристаллизоваться основные идеи как синтаксиса, так и семантики языка. И лишь потом — формальное описание.

Существуют ли книги или сайты на тему
«Как придумать язык программирования»?

            Вполне может быть, что материалы на тему «Как придумать язык пpогpаммиpования» всё-таки существуют, просто автор этих строк с ней не знаком. Тем не менее, как не бывает двух одинаковых прожитых жизней, так и не бывает двух одинаковых опытов разработки языка программирования. И если наш опыт будет интересен, то он достоин письменного описания.

            Существует материал А.В. Хохлова «Как создать язык пpогpаммиpования и тpанслятоp». Хорошая работа, но её правильнее было бы назвать «Как создать тpанслятоp». Андрей не описал, как хотелось бы, процесс выбора решений в ту или иную сторону. Всё-таки хотелось бы понаблюдать за ходом авторской мысли. Но ещё не вечер. Может быть, Андрей как-нибудь найдёт время изложить нам свои соображения.

            Из зарубежных авторов ближе всего, наверное, к нашей тематике подходит книга Роберта Себесты «Концепции языков пpогpаммиpования». Всем рекомендуется её чтение, она того стоит. Однако содержание книги более всего подходит выбранному названию, а не «придумыванию языков пpогpаммиpования».

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

            Из интервью Александра Степанова, автора библиотеки C++ STL, можно узнать интересные подробности создания этой библиотеки (ссылки — ниже). Однако эти воспоминания нельзя признать полными и исчерпывающими с точки зрения проектирования языка. Хотя поднятые темы настолько интересны, что обойти вниманием их нельзя.

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

Создание компилятора

             Написание компилятора — не самая срочная задача, ибо нельзя поставить телегу впереди лошади. К тому же, это задача более практическая, чем этап проектирования языка программирования. Необходимо тщательно обдумать собственно язык. Лишь когда он станет красив «на бумаге», можно будет думать о компиляторе. Позволю в этом месте процитировать Евгения Зуева «Редкая профессия») о личном опыте создания компилятора С++:

  ... через некоторое время от нас ушел третий участник. Он весь был ориентирован на получение результата, а не на процесс его достижения. Само по себе это исключительно ценное качество, его наличие (подкрепленное высокой квалификацией) гарантирует успешное завершение работы в заданные сроки. Однако в данном случае оно обернулось своей худшей стороной — ... принятием важных решений "на ходу", без всякого обсуждения и плохо скрываемым недовольством коллегами, которые непонятно почему копаются там, где надо скорее программировать. Главное — скорее! За один день сделать работоспособный синтаксис, за месяц — добиться трансляции программы «Hello world!». Сложность системы не играет никакой роли, все программы устроены одинаково. Модули должны взаимодействовать согласно своим интерфейсам, обсуждать которые нет смысла, они и так сами за себя говорят — на то они и интерфейсы.

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

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

Опубликовано: 2012.09.25, последняя правка: 2019.01.28    20:48

ОценитеОценки посетителей
   █████████████████████████████ 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С финансовых программ — язык программирования. Их ошибки очень характерны, хотя и происходят из жадности, тупости и прочих элементарных вещей."

Пока вижу только критиканство — очень похоже что 1С своимъ встроеннымъ РЯП кого-то оставило безъ миски супа...

     2015/04/07 10:50, misha_shar53          # 

Из рассмотрения выпал очень важный язык программирования MUMPS. Не рассматривая его нельзя вообще говорить об идеальном языке программирования. Я уже 3 года на идеях MUMPS пытаюсь создать идеальный язык программирования. Уже много сделано. Есть спецификация языка(MSH). Многие обсуждаемые в этом разделе проблемы мне понятны. Но писать комментарии к отдельным конструкциям языка бессмысленно без изложения концепций языка. Некоторые проблемы в моем языке просто отсутствуют как таковые. Некоторые опираются на традиции MUMPS. Я постараюсь подготовить статью с моим представлением об идеальном языке. Мне будет интересно ваше мнение о моих исканиях. По поводу текущего обсуждения. Я считаю принципиальной ошибкой то, что за основу обсуждаемого языка взят язык Си. Уже создано огромное множество вариантов языков на его основе. ничего принципиально нового на этом пути нет. Идти в этом направлении бессмысленно.

     2015/04/07 15:38, Автор сайта          # 

Этот язык 1) старый, 2) малопопулярный. О чём это говорит, если руководствоваться общепринятыми стереотипами? Если этот язык не стал популярен, хотя время у него было, то, значит, есть на это причины. Чем-то он не нравится людям, скорее всего и мне не понравится. А ещё в нём нет чистых функций, лямбд и всего того, что вошло в широкую практику в последнее время.

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

Почитал о нём в Википедии. Раздел «критика» рассказывает о таких вещах, которые охлаждают интерес к языку. Отсутствие типизации (все данные хранятся как строки), низкий уровень абстракции, нечитабельность синтаксиса, отсутствие обязательного объявления переменных и поддержки приоритетов арифметических операций. Ключевые слова языка не зарезервированы, лишний пробел может совершенно изменить смысл синтаксической конструкции.

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

С чего Вы это взяли?

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

А Вы не хотите сделать свой сайт на эту тему?

     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          # 

Мне кажется прежде чем приступать к обсуждению нового языка, надо определиться с целями его создания. Зачем это делать. Я вижу 2 цели:
1. Создать традиционный язык, хорошо себя зарекомендовавший, который легко воспримет широкая аудитория, но более эстетически выглядящий.
2. Создать Новый язык обладающий новыми свойствами. Тогда надо определиться будет ли он нишевым или нет. И если да, то для какой ниши он создается. Какими свойствами он должен будет обладать?

Мне кажется вы склоняетесь к 1 варианту. Но тогда это будет ещё один 10001 Си или С++ подобный язык и перспективы его выживания мне кажутся сомнительными. Может я не прав.

     2015/04/08 08:59, misha_shar53          # 

Хотелось бы более подробно разобраться с якобы недостатками MUMPS и его критикой.

Этот язык 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          # 

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

     2015/04/09 00:57, misha_shar53          # 

Скажите сторонникам Oberon-2, что этот язык такой же, как Си, и Вы узнаете, что они о Вас думают.

Извините что затронул ваши религиозные чувства. Ладно не Си, Алгол или Паскаль.

А ещё появилась типизация Хиндли — Милнера, которая зачастую создаёт иллюзию, что типизации нет. Это специально для тех танцоров, которым всегда что-то мешает.

Вообще-то я хотел сказать не о танцорах и что им мешает. А о существовании фантомов вроде декларирования переменных и GOTO, которые тормозят развитие языков программирования. Мне просто искренне жаль, что колоссальные ресурсы уходят в никуда. Хотя ваше обсуждение языка мне было полезно и интересно.

     2015/04/10 15:06, Автор сайта          # 

Печально, что Вы не видите разницы между C/С++ и Oberon-2 и объясняете это религией. Жаль, что Вы считаете, что «goto» и статическая типизация являются одинаковыми тормозами в развитии. А Вы не пробовали понять, в чём заключаются плюсы Haskell, языка со строгой статической типизацией?

     2015/04/10 14:38, misha_shar53          # 

В принципе, языки с некоторой долей погрешности можно разделить на две категории.
Языки, допускающие эффективную реализацию. Их эффективность направлена либо на наибольшую скорость исполнения, либо на наименьшее использование вычислительных ресурсов. Последнее важно для мобильных применений: меньшая производительность процессоров, требования энергоэффективности (чтобы батарея меньше разряжалась).
Языки, которые ставят целью наибольшую скорость работы программиста, а не программы. Поэтому на некоторые неэффективные решения закрываются глаза. Ну и что, что в PHP массивы реализованы посредством ассоциативных массивов: нет прямого обращения по индексу 2 в массиве $arr[2], но есть обращение к элементу ассоциативного массива по ключу 2. Ведь работает, не правда ли?
Каждая философия имеет право на жизнь, особенно если у языков непересекающиеся ниши.

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

     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, Автор сайта          # 

Хотелось бы увидеть в вашем предложении побольше технических деталей. Что будет представлять из себя этот самый словарь? Базу данных? Wiki-словарь? Файл в формате djvu? Как процесс пополнения словаря будет выглядеть с точки зрения человека? А как будет обращаться к словарю компилятор?

В наших палестинах произрастают кулибины, левши, келдыши. Линусы — это не у нас.

     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          # 

Согласен с предыдущим комментарием процентов на 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, Виталий Монастырский          # 

Да, совершенно верно, имеется ввиду один и тот же язык, но разделенный на примитивный и пользовательский уровень. Ну совсем грубо, в ядре не будет даже циклов, они будут реализовываться комбинациями условного и безусловного перехода. Разные комбинации будут соответствовать различным же вариантам оператора цикла, который будет применяться в пользовательском языке.
Что это значит... это значит, что пользователь тоже сможет организовать цикл с помощью примитивных операторов 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

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

●  Изобретение очередного велосипеда?

●  Все языки эквивалентны. Но некоторые из них эквивалентнее других

●  Признаки устаревшего языка

●  Лень — двигатель прогресса

●  О наименовании проекта и языка программирования

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2021/05/13 23:43 ••• Денис Будяк
Энтузиасты-разработчики компиляторов и их проекты

2021/04/25 08:41 ••• kt
Некошерный «goto»

2021/04/19 17:01 ••• Клихальт
О наименовании проекта и языка программирования

2021/04/17 18:29 ••• Comdiv
Не поминайте всуе PL/1

2021/04/07 17:35 ••• :NONAME
Почему обречён язык Форт

2021/04/04 18:29 ••• kt
Переключатель

2021/04/04 18:04 ••• Александр Коновалов aka Маздайщик
Каким должен быть язык программирования?

2021/04/02 19:32 ••• Александр Коновалов aka Маздайщик
Циклы

2021/04/01 14:07 ••• Александр Коновалов aka Маздайщик
Условные операторы

2021/04/01 13:26 ••• Александр Коновалов aka Маздайщик
Комментарии автоматической генерации документации

2021/04/01 13:13 ••• Александр Коновалов aka Маздайщик
Длинные комментарии

2021/04/01 13:03 ••• Александр Коновалов aka Маздайщик
Некоторые «вкусности» Алгол-68

2021/04/01 12:15 ••• Александр Коновалов aka Маздайщик
Устарел ли текст как форма представления программы

2021/03/28 22:31 ••• Виталий Монастырский
Так ли нужны операции «&&», «||» и «^^»?

2021/03/28 13:39 ••• Виталий Монастырский
Бесплатный софт в мышеловке