Pull to refresh

Comments 157

Код на этом «языке» сложноват. Чем сложно написать fun, def или что то в этом роде? Зато более понятно и глаз не режет

Согласен, нет смысла экономить на размере ключевых слов. Код должен быть понятен (хотя бы немного, на структурном уровне) даже программисту не знакомому с этим языком.


Новые языки должны создаваться, если есть новые концепции, которые хочется реализовать. При этом совершенно не обязательно коверкать базовый синтаксис. Можно просто взять знакомый всем си-подобный или питоно-подобный и немного изменить/докинуть ключевых слов. Это вполне может увеличить аудиторию заинтересованных (хотя бы на процент тех людей, которые закрыли статью, ужаснувшись от кода на первой картинке)

есть новые концепции, которые хочется реализовать.

А если нет новых концепций [не лично у меня, а вообще/‘в принципе’ не осталось больше новых концепций (вы ведь допускаете такой вариант в будущем?)], но хочется структурировать уже имеющиеся концепции.


Можно просто взять знакомый всем си-подобный или питоно-подобный и немного изменить/докинуть ключевых слов. Это вполне может увеличить аудиторию заинтересованных (хотя бы на процент тех людей, которые закрыли статью, ужаснувшись от кода на первой картинке)

Верно, можно. Но это могут[/должны] делать разработчики соответствующего языка программирования (того же Python). А что делать мне и тем, кто хочет создать новый язык программирования?

А если нет новых концепций ..., но хочется структурировать уже имеющиеся концепции.

Ну структурируйте, только зачем синтаксис то свой, никому не понятный, придумывать?


А что делать мне и тем, кто хочет создать новый язык программирования?

Создавайте, используя модифицированный синтаксис уже существующих языков.

Есть замечательная фраза ‘‘критикуешь — предлагай’’. Какой конкретно язык вы предлагаете взять за пример образцового синтаксиса?
И к тому же, предполагается поддержка русского языка хотя бы на уровне проверки жизнеспособности идеи о том, что ‘Программирование на кириллице может повысить производительность [труда [русских программистов]]’.
Вам не обидно, что
https://navalny.com/p/4875/:
В десятке лидеров — пять (!!) команд из России.
и при этом нет ни одного достойного языка программирования с русскими ключевыми словами?
А на русском многие ключевые слова при прямом переводе с английского звучат не очень. Как бы вы перевели, к примеру, this на русский? этот?
Какой конкретно язык вы предлагаете взять за пример образцового синтаксиса?

Я уже говорил, си-подобный или питоно-подобный, для императивного ооп языка самое то.


Вам не обидно, что… нет ни одного достойного языка программирования с русскими ключевыми словами?

Нет, я наоборот очень рад что для меня конструкции языка программирования не имеют дополнительного смысла, как это было бы, если бы язык был моим родным.

Ну хорошо. А если посмотреть с точки зрения не вас, как уже имеющего опыт программирования человека, а точки зрения нового поколения детей. Какому языку программирования вы бы стали их учить?

Лично я считаю, что многие обозначения операторов языков выбраны неправильно, например ^ у новичков в программировании ассоциируется с операцией возведения в степень.

Я понимаю, что операция возведения в степень используется крайне редко, но… если и вводить в язык оператор для её обозначения, то это должно быть соответствующее обозначение (и я предполагаю, что основной причиной отказа от ^ в качестве оператора возведения в степень является использование этого символа для операции поразрядного XOR (исключающего ИЛИ), что я считаю неудачной идеей — ну, во всяком случае новичков в программировании это точно сбивает с толку)

Хотя я могу понять разработчиков языка Си… у них просто не было времени на качественный выбор символов для операторов языка [другими словами, в их время это была неприоритетная операция, гораздо важнее были другие задачи]. Но я бы взял обозначение операции исключающего ИЛИ как (+), так как эти три символа похожи на символ ⊕, который используется в алгебре логики\Boolean algebra для обозначения операции ‘исключающего или’/сложения по модулю 2: . И хотя ⊕ используется чаще для одноразрядных значений, в Википедии встречается его применение для указателей и для массивов из байт
Лично я считаю, что многие обозначения операторов языков выбраны неправильно, например ^ у новичков в программировании ассоциируется с операцией возведения в степень.

… а почему, учитывая, что вне программирования этот символ так не используется?


Но если вам очень хочется, то вот: https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/operators/exponentiation-operator


если и вводить в язык оператор для её обозначения, то это должно быть соответствующее обозначение

Соответствующее чему?

вне программирования этот символ так не используется?

Вычисления в Excel — это вне программирования?

Нет (в контексте обсуждения).

то вот: [ссылка на документацию к exponentiation\экспоненциальному-operator’\оператору в языке программирования Visual Basic]
Вы думаете я этого не знаю?
┌──────────┬────────────────────────────────────────────────────────────────────────────────────────────┐
│ Оператор │ В каких языках используется                                                                │
├──────────┼────────────────────────────────────────────────────────────────────────────────────────────┤
│    **    │ Perl, PHP, Python, Ruby, CoffeeScript, Haskell                                             │
│    ^     │ BASIC, MATLAB, Lua, TeX (в свою очередь используется в <math> в Wikipedia), Julia, Haskell │
└──────────┴────────────────────────────────────────────────────────────────────────────────────────────┘
Соответствующее чему?
Просто соответствующее (или можно сказать консистентное).
Просто соответствующее (или можно сказать консистентное).

Не бывает "просто соответствующего", соответствовать можно только чему-то. Не бывает "просто консистентного", бывает консистентной в рамках чего-то или с чем-то.


Так вот, обычно в рамках языков, которые вводили этот оператор, это было консистентно.

С другими операторами в рамках языка.

По поводу символов русского/любого другого языка (кроме общепринятого латинского алфавита) в качестве допустимых в идентификаторах:
1. А что делать с подобной программой, поддержку или развитие которой собираются передать индусам, бразильцам или китайцам? Фактически, над ней смогут работать только те, кто 1) хотя бы знаком с кириллицей и 2) имеет клавиатуру с соответствующими символами и 3) в ОС кириллица поддерживается и установлена.
2. Видите разницу между идентификаторами «myVar» и «myVаr»? А она есть :) P.S. Так что или делать чисто русский язык программирования (без латиницы в идентификаторах ВООБЩЕ), или забыть про эту неумную идею ВООБЩЕ :)
Использовать русскую версию языка предполагается [если говорить серьёзно] в основном в отечественных военных разработках. (Я как раз думаю над тем, как сформулировать предложение для военных.)
Использовать русскую версию языка предполагается [если говорить серьёзно] в основном в отечественных военных разработках.

… это чтобы опыт на военке и на гражданке вообще несовместим был, да?

А зачем, Вы можете объяснить? Назовите ту самую главную причину, по которой НЕОБХОДИМО поддерживать кириллицу в идентификаторах? Незнание английского у программистов, работающих на МО? Так их в шею гнать надо, т.к. по программированию материалов на английском языке на порядки больше и по качеству часто лучше, чем на русском, таким образом программист, который не может этими материалами пользоваться из-за незнания языка необходимым образом оказывается ограниченным программистом. Или причина — «чтоб враг не догадался»?

Когда и если этот Ваш язык программирования завоюет хоть какую-то заметную популярность (не говоря уже о военном применении), [если говорить серьезно] я оставлю программирование и пойду работать подсобником на стройку :D
Назовите ту самую главную причину, по которой НЕОБХОДИМО поддерживать кириллицу в идентификаторах?

Это привлечёт дополнительное внимание к языку у патриотично настроенных граждан, особенно незнающих/‘плохо знающих’ английский язык.

Я вот патриотично настроенный гражданин, который достаточно плохо знает английский. А когда учился программированию, его (английский) вообще не знал. И это никоем образом не мешало учиться программированию. Разве что только над переменными вида otvet, itog и пр, некоторые смеялись )
Создавать язык, которым будут пользоваться лишь «избранные», извините, бред.
И что от этого внимания? Если они умеют только в патриотизм, то ничего приличного из этого не выйдет. Это такой шпионский план похоронить МО?
Мотивация автора странная, но поддержка кириллицы и не только давно есть даже в Си, не говоря про более новые языки. Делается это очень просто и нет причин в языке ограничивать идентификаторы латиницей.
1) Причин ограничивать в языке, действительно, нет. Ну кроме «myVar» и «myVаr» ;) Только незачем отсутствие подобного ограничения выставлять как некую офигенную фичу, отличающую данное поделие от других языков, тем более что
2) Ничего особенного, никакой особой идеи, никакого решения неких проблем предложенный язык не несет. Ну вот кроме этой самой «фичи» и зарезервированных слов длиной в один символ.
Ничего особенного, никакой особой идеи, никакого решения неких проблем предложенный язык не несет
Я уже писал об этом

А мой ответ был на следующее:
А зачем, Вы можете объяснить? Назовите ту самую главную причину, по которой НЕОБХОДИМО поддерживать кириллицу в идентификаторах? Незнание английского у программистов, работающих на МО?
Здесь поддержка кириллицы была преподнесена как что-то позорное для идиотов, которых нужно гнать в шею.
Здесь поддержка кириллицы была преподнесена как что-то позорное для идиотов, которых нужно гнать в шею.

А почему вы так решили? Можете привести конкретную цитату?

Цитату чего? Весь ответ vdem пропитан этим. Вы не заметили в нём злого сарказма?
Не было там никакого сарказма, тем более злого. Я действительно полагаю, что программист обязан знать английский. Не на разговорном уровне, но достаточно, чтобы понимать документацию. Ну и переменные называть не «pochta», а «email». Так исторически сложилось, что английский более международный, чем русский, а от глобализации особо не спрячешься. И, как я уже отметил, документации на английском на порядки больше, чем на других языках, — здесь же на Хабре и на ГТ чуть ли не половина статей — переводы, т.е. контента для разработчиков и вообще технарей больше генерируется на английском.
По поводу поддержки Unicode для идентификаторов. Я тут немного подумал, и решил что это зло. Сам пару раз с UTF-8 в коде встречался — пока в хексе не глянешь, не найдешь где ошибка.
Код на кириллице — смешная помеха для иностранных шпиёнов (если я правильно поняла причину, по которой вы хотите предложить свой язык именно этой аудитории).
Нам тут проект от корейцев прислали — несколько раз пришлось в переводчик скопипастить, заодно поняли что это корейцы, чтобы понять что это (до этого от финнов, там вообще часть букв хексами заменилась, но не помешало разобраться в коде). А условное ЦРУ (или кого автор боится) даже не напряжётся разбирая подобный язык (тем более после компиляции там всё одно будет машинный код, причём не факт что хорошо оптимизированный, а такие паттерны разбирать легче).
Эх. Не умею я шутить, да...
Но с другой стороны, вот пример проекта, который используется военными:
obzor.westsib.ru/article...:
Например, военные на основе нашего движка делают виртуальные тренажеры для работы с новой секретной техникой.

И я уверен, что отечественный разработчик был не последней причиной выбора этого движка.
По поводу символов русского/любого другого языка (кроме общепринятого латинского алфавита)
В современных воплощениях языков общепринятым является поддержка юникодных идентификаторов. Это есть даже в Си, не говоря уже про более современные языки.
а если выбрать язык именно C, а не C++, то компиляция не проходит :)
Отчего же, проходит.
Это gcc поддерживает юникод в неудобном виде. Во-первых, нуждается в параметре -fextended-identifiers, во-вторых, требует записи в виде \uXXXX, что не очень удобоваримо, но для кодогенераторов подходит.
В 10-м gcc есть поддержка юникодных идентификаторов уже и в нормальном виде godbolt.org/z/Pzjd3n
Какой конкретно язык вы предлагаете взять за пример образцового синтаксиса?

Нет такого, потому что разные вкусы и разные задачи.


Вам не обидно, что [...] нет ни одного достойного языка программирования с русскими ключевыми словами?

Нет, не обидно. А почему должно быть?

Какой конкретно язык вы предлагаете взять за пример образцового синтаксиса?
Синтаксис второстепенен. В идеале язык может предлагать синтаксис на выбор.
Но если хочется сосредоточиться на одном базовом, то лучше спросить у потенциальных пользователей.
Чем сложно написать fun, def или что то в этом роде?

< используйте полные версии зарезервированных слов, представленные в 3 и 4 столбцах таблицы базовых слов.


(Вариант fn[‘как в Rust’] обсуждается [возможные варианты: fun[‘как в Kotlin’], func[‘как в Swift’], function[‘как в JavaScript’]]. Вообще такие возможности языка будут отданы на откуп сообществу в процессе его разработки. И определятся результат будет простым большинством голосов. Я уже давно планирую систему голосования через GitHub (один коммит — один голос), но боюсь, что GitHub не выдержит "хабраэффекта".)

используйте полные версии зарезервированных слов, представленные в 3 и 4 столбцах таблицы базовых слов.

Если в язык добавлена возможность, то ей кто-то обязательно воспользуется. И человеку, который ни разу не сталкивался с этим языком будут непонятны все эти L F S, в отличии от общепринятых while/functuon/switch

Как вы оцениваете сложность операции чего-то вроде replace_all('F', 'function', WHOLE_WORD).replace_all('S', 'switch', WHOLE_WORD)...?
Предполагается, что новая среда разработки будет позволять показывать код в удобном пользователю виде.

Вот только код смотрят не только в своей IDE, бывает нужно подойти, показать что-то коллеге. Или просто кто-то пишет в блоге/делает презентацию на конференцию. Какой стиль ему выбирать? То же самое и со stackoverflow.

Ладно, согласен. Пусть стиль для хранения файлов выбирается большинством голосов. Но я бы попробовал попрограммировать в предложенном мной однобуквенном стиле.
Если уж хочется программировать «однобуквенно», то для этого логичней использовать поддержку в IDE, а не наоборот.

Я именно это и имел в виду.
Вообще, как я это себе представляю, будут отдельные голосования:


  • Для того, в каком виде хранить исходные файлы на языке [F, fn, fun, func или function].
  • Для настроек IDE по умолчанию.
Что именно Вы имели ввиду? Я говорил приблизительно о следующем:
Пишите L, жмёте на <Чего-то> и буква раскрывается в полновесную конструкцию с понятными ключевыми словами. То есть на уровне транслятора нет поддержки сокращений. В этой же заметке это представлено именно как возможность языка.
Что именно Вы имели ввиду?
Я допускаю такой вариант, что в результате голосования будет выбрано самое длинное имя для каждого базового зарезервированного слова (например, function\функция). Тогда в IDE я поставлю себе однобуквенные обозначения чисто для проверки жизнеспособности такой записи.

Пишите L, жмёте на -<Чего-то>+F1 и буква раскрывается в полновесную конструкцию с понятными ключевыми словами.
[В том числе] для этого и предназначено Правило одной кнопки.

В этой же заметке это представлено именно как возможность языка.
Как возможностьфича языка представлена иерархичность служебных/ключевых/зарезервированных слов. Просто идея использовать однобуквенные зарезервированные слова послужила отправной точкой к идее иерархичности слов языка.

Операторы, состоящие из одной буквы, могут показаться странными на первый взгляд, но такая краткость даёт возможность полностью отказаться от (полностью дублирующего функциональность) тернарного оператора ?: (например, в Ruby также можно использовать оператор if и в выражениях, но это не так кратко как с ?:, в противном случае (как в данном языке) в операторе ?: не было бы смысла), а также это стимулирует использовать ‘более понятные’\‘more descriptive’ имена переменных вместо кратких однобуквенных.

Также, это в значительной степени сужает поле для выбора имён ключевых слов, частично решая проблему выбора, например: function, func, fun или fn.

К тому же, некоторые ключевые слова на русском языке в неоднобуквенной форме могут звучать довольно глупо, например: авто.

Ну и должна же быть у языка какая-то [фишка/]отличительная черта, сразу бросающаяся в глаза, и возможно даже чем-то отпугивающая. :)(: [Если честно, я боюсь делать слишком хороший[/совершенный] язык, так как это слишком большая ответственность.]

[[Национальная причина: русский язык для однобуквенных ключевых слов обладает преимуществом перед английским и многими другими, так как в русском языке больше букв! ]]

Но для новичков я согласен что полная форма читаться будет легче.
Как возможностьфича языка представлена иерархичность служебных/ключевых/зарезервированных слов.

Только вы ей не пользуетесь. Можно с успехом выкинуть однобуквенные префиксы, и ничего не изменится.


Операторы, состоящие из одной буквы, могут показаться странными на первый взгляд, но такая краткость даёт возможность полностью отказаться от (полностью дублирующего функциональность) тернарного оператора ?:

Нет, возможно отказаться от тернарного оператора дает только if-как-выражение (expression). И в ту же корзинку switch-как-выражение, он же pattern matching (которого у вас тоже нет). Длина радикального значения не имеет.


Также, это в значительной степени сужает поле для выбора имён ключевых слов, частично решая проблему выбора, например: function, func, fun или fn.

А вы знаете, да, что есть языки, в которых это ключевое слово вообще не используется?..


Ну и должна же быть у языка какая-то [фишка/]отличительная черта, сразу бросающаяся в глаза, и возможно даже чем-то отпугивающая

Обычно это все-таки что-то полезное.


Национальная причина: русский язык для однобуквенных ключевых слов обладает преимуществом перед английским и многими другими, так как в русском языке больше букв!

Особенно прекрасны буквы Щ и Ъ. И удачи вам в отличении Ы от ЬI.

Можно с успехом выкинуть однобуквенные префиксы, и ничего не изменится.
Я считаю фичу ‘при нажатии . после F/fn/fun/func/function выводится список/дерево вариантов’ достаточно полезной для новичков.
И как вы предлагаете быть с ключевыми/зарезервированными словами для циклов? Резервировать prev, next, index глобально?

И в ту же корзинку switch-как-выражение, он же pattern matching (которого у вас тоже нет).

А почему вы так решили? Я просто не написал про S.match. Или вы хотите сразу всё изучить про новый язык? Тогда подождите хотя бы годик.

А вы знаете, да, что есть языки, в которых это ключевое слово вообще не используется?

Приведите список новых языков программирования где бы функции объявлялись в стиле Си.

И удачи вам в отличении Ы от ЬI.
Я не планирую отказ от моноширногомоноширинного шрифта.

А буква Ы рассматривается как вариант замены В/вЫбор, так как она располагается на одной клавише с латинской буквой S/switch.

Особенно прекрасны буквы Щ и Ъ.
Если вы не любите русский язык, так и скажите.
Я считаю фичу ‘при нажатии. после F/fn/fun/func/function выводится список/дерево вариантов’ достаточно полезной для новичков.

А для этого тоже не нужны однобуквенные префиксы, для этого нужен синтаксис "сначала определимое, потом определение". Иными словами, вместо public classclass public, тогда IDE после набора class может подсказать видимость. Только это же не читаемо.


И как вы предлагаете быть с ключевыми/зарезервированными словами для циклов? Резервировать prev, next, index глобально?

Ну да.


А почему вы так решили? Я просто не написал про S.match.

Потому что он нигде не упомянут. И еще потому, что отдельное ключевое слово для него, на самом деле, не нужно — что наводит меня на мысли, что вы не очень понимаете, как это устроено.


Приведите список новых языков программирования где бы функции объявлялись в стиле Си.

А откуда внезапно взялось ограничение "новых"? Я вроде бы не про новые языки говорил.


Я не планирую отказ от моноширногомоноширинного шрифта.

А при беглом чтении лучше не станет.


Если вы не любите русский язык, так и скажите.

Я как раз люблю русский язык.

Только это же не читаемо.

Почему? Я лично не вижу разницы с т.з. читаемости.

Потому что в английском языке, который я знаю, первая форма естественна, а вторая — нет.

Ммм… А при чём тут английский? У английского же синтаксис совсем другой, сходство только в лексике.

Совсем другой нежели что? Нежели словосочетание "public function", которое в английском совершенно валидно?

Нежели любой язык программирования.

Понимаете ли, просто не надо сравнивать язык программирования целиком, надо сравнивать фрагменты текста (которые вполне могут читаться). for element in array например.

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

Кстати говоря, в процитированном Вами примере, можете объяснить, почему оператор цикла называется «для»? Где логика?
Если бы я знал английский язык, когда начинал программировать, эта особенность помешала бы мне читать программный код.
Язык программирования не обязан быть похож на естественный язык.

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


Кстати говоря, в процитированном Вами примере, можете объяснить, почему оператор цикла называется «для»? Где логика?

Потому что это вполне себе существующее выражение: "for every something do that". Например, "for every in-text citation of the publication, list the name of the first author".

Например, «for every in-text citation of the publication, list the name of the first author».

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

Мне вот для этого не нужно вовсе никакого труда. Возможно, это вопрос понимания английской конструкции.

Кстати, если воспринимать for не как "оператор цикла", а как оператор перечисления, все становится логичнее (а в качестве "оператора цикла" намного лучше ложится while/until).

Зачем сравнивать фрагменты текста?

(забыл ответить) потому что мы их читаем, когда читаем программу. Чем меньше дискомфорта они вызывают, тем лучше.

Условное выражение, она же троичная операция, он же «тернарный оператор» тоже не нужны, как и безумная краткость.
Ну и должна же быть у языка какая-то [фишка/]отличительная черта, сразу бросающаяся в глаза, и возможно даже чем-то отпугивающая
В этом есть маркетинговый смысл, но, похоже, Вы перестарались, судя по реакции.
Перестарался или нет… время покажет.
но боюсь, что GitHub не выдержит «хабраэффекта»

Вы как себе это вообще представляете?
Все будут в восторге от русского языка программирования, тем более там одним символом можно функции определять. И военка ну просто вообще кипятком ссать будет от такого дела. Но GitHub точно не выдержит.

По поводу "единой конфигурации сборки". Писать свой компилятор это сложно. А хороший компилятор (оптимизации там/разные платформы) ещё сложнее. Кажется легче взять тот же LLVM и попытаться втащить эту возможность в него (в случае успеха пользу будет принесена многим пользователям нескольких уже существующих языков). В крайнем случае можно его форкнуть и перепилить как нужно. По крайней мере всяко проще чем пилить с нуля.

Однобуквенные имена нельзя резервировать: они нужны для локальных переменных.
Тогда используйте полные версии зарезервированных слов, представленные в 3 и 4 столбцах таблицы базовых слов.

Плакал. С чего вы взяли, что optimized out переменная где-то хранится? Возможно даже, соответствующее численное значение ни в какой момент времени не появляется в регистрах.
Более того — и использующего её куска кода может не быть. Или, к примеру, нам фактически нужен один бит из неё, который и вычисляется в релизной сборке — и код этого вычисления не очень-то похож на наш исходник.


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

Это вы верно подметили, но ради краткости статьи я не стал разбирать данный случай.
В подобных ситуациях я хочу предложить:


  • constant unfolding — "деоптимизация", выполняемая отладчиком во время отладки, которая позволяет по шагам показать вычисление констант, которые в реальности вычисляются на этапе компиляции. Например: в A -c = max(1, 2, 3) можно заглянуть в функцию max и виртуально пройти по шагам в этой функции, хотя реально значение c вычисляется на этапе компиляции и во время выполнения функция max не вызывается.
  • loop counter deoptimization — в случае если компилятор как-то оптимизировал работу со счётчиком цикла, при отладке выполняется обратное вычисление, позволяющее посмотреть актуальное текущее значение переменной-счётчика цикла.

Собственно, я как раз хотел сделать акцент на том, что обратное вычисление для "живой" переменной (ещё не вышедшей из области видимости) сделать возможно всегда.
Реальная проблема только с переупорядочиванием операций компилятором, но от него можно отказаться, я считаю.

На минуточку, создатели gcc и llvm, да и msvc в курсе этого. Это — мощные команды профессионалов высокого класса. Однако ж они не реализовали формат отладочной информации, обеспечивающий "обратное вычисление". Как вы думаете, почему?
Призовой вопрос: почему вы не сможете сделать это в одиночку?


Насчёт отказа от переупорядочивания — посмеялся. Это базовая операция, обеспечивающая возможности для других оптимизаций. Как без этого, к примеру, выносить код из цикла?

Однако ж они не реализовали формат отладочной информации, обеспечивающий "обратное вычисление". Как вы думаете, почему?

Legacy code.


Призовой вопрос: почему вы не сможете сделать это в одиночку?

Я верю, что смогу собрать команду профессионалов (и да, это не смотря на тот факт, что в данный момент времени над этим языком работаю я один), причём, надеюсь, что Хабр в этом сыграет не последнюю роль. :)(:


Как без этого, к примеру, выносить код из цикла?

Выносить код из цикла можно не нарушая порядок.
Можете привести конкретный пример?

Какую задачу решает ваш язык программирования?

Такую же, какую решают Python и C++. Только в более компактной форме и с лучшей производительностью и безопасностью по сравнению с Python.
Такую же, какую решают Python и C++

Если такую же, то зачем он нужен? (это не говоря о том, что Python и C++ решают немного разные задачи)


Только в более компактной форме

Зачем это нужно?


с лучшей производительностью и безопасностью по сравнению с Python

Без потерь других характеристик Python?

Оставлю ваши вопросы [пока] без ответа.

в потугах кодо-оптимизаций легко забыть: программный код пишет программист для программиста (человека), а не для машины, последним занимается компилятор.

зачем лишний раз программирование усложнять?

Не знаю, что вам ответить. На ум приходит только такой [мной собранный] стишок:


Hardware and software
Require each other
And neither can be
Without the other.


Вот также программист и машина — не могут друг без друга. :)(:

Тут была статья для особой кодировки русских букв, им надо объединить усилия. Писать на неиспользуемом нигде языке программирования с неиспользуемой нигде кодировкой символов — это никакой враг не догадается. А ещё никаких проблем при устройстве на работу — можно быть уникальным специалистом на целую планету, никто не захочет вас подсидеть чтобы занять это место.
Это что, какой-то эзотерический язык, чтобы усложнить разработку в команде?..
Напомнило какую-то ужасную смесь непонятности Ассемблера и кириллицу 1С.
Задача кода быть понятным, а тут какая-то непонятная экономия, чтобы меньше печатать ключевые слова и увеличивать количество опечаток.
Я вдохновлялся языками программирования Python и C++.
А какой язык программирования вы считаете образцом для подражания?
Вообще глобальная задумка такова, чтобы вместо букв были символы (большие).

Насчёт
увеличивать количество опечаток
прошу, приведите хотя бы один пример кода, где возможно перепутать символы (то есть, вместо одного зарезервированного словосимвола использовать другой, и при этом код останется корректным с точки зрения синтаксиса).

Ответ ‘заменить L.break на S.break’ прошу не предлагать, так как я считаю, что следует заменить одно из этих подслов на другое (например: L.exit).

Это что, какой-то эзотерический язык, чтобы усложнить разработку в команде?

Это дело вкуса. Чтож, вам не понравилась такая запись. Кому-то может понравится…
Для меня скорее Perl — эзотерический язык, но это [моё мнение о Perl] не помешало ему завоевать популярность и найти своих сторонников.

Вы явно не понимаете что такое эзотерический язык, perl ни в коем случае таким не является (в отличии от языка из статьи).

… к разговору, значит, об опечатках:


Префикс ^ — для доступа к переменным из внешней ‘области видимости’ [...] например, есть цикл по i, внутри него ещё какой-то цикл, внутри которого ещё маленький цикл по i, находясь в котором хочется получить текущее значение переменной i верхнего уровня, это можно сделать посредством записи ^i

Вот, значит, у меня пять вложенных циклов (ну по пятимерному массиву я хожу), и в каждом из них индексация по i. Как мне обратиться к индексу второго массива сверху?


… или, скажем, статическая типизация и работа с памятью.


A persons = []
persons [+]= Person("Name", 17)

Какого типа persons, и что конкретно произошло с памятью во второй строчке?

По первому вопросу: прошу назовите хотя бы один язык программирования, в котором возможно ‘обратиться к индексу второго массива сверху’ или приведите код на любом (в том числе несуществующем) языке программирования более красивый, чем в предложенном в статье языке.


По второму вопросу: это успешно реализовано в языке Nemerle, о чём я уже говорил в статье:
< также как тип массива или словаря в Nemerle определяется по типу первого добавленного в него элемента

По первому вопросу: прошу назовите хотя бы один язык программирования, в котором возможно ‘обратиться к индексу второго массива сверху’

Любой язык, в котором возможны вложенные циклы:


foreach(var i in someArray)
foreach(var j in i)
foreach(var k in j)
foreach(var l in k)
foreach(var m in l)
{
  DoSomethingTo(j);
}

приведите код на любом (в том числе несуществующем) языке программирования более красивый

Код чего?


По второму вопросу: это успешно реализовано в языке Nemerle

Что успешно реализовано? Я задал два конкретных вопроса: какого типа persons, и что конкретно случилось с памятью в момент persons [+]=.


Еще кстати, бонусный вопрос про типизацию: как выглядит сигнатура функции, которая принимает в себя один аргумент, являющийся перечислимым (enumerable) множеством от любого типа, на котором определена операция сложения?

Код чего?

Вы и правда не понимаете. Или притворяетесь, что непонимаете? :)(:


Скрытый текст

Вы предлагаете:

пять вложенных циклов (ну по пятимерному массиву я хожу), и в каждом из них индексация по i.
‘Индексация по i в каждом’ означает ‘индексация по i во всех пяти массивах’, а именно:
foreach(var i in someArray)
foreach(var i in i)
foreach(var i in i)
foreach(var i in i)
foreach(var i in i)
{
  DoSomethingTo(i); // как здесь обратиться ‘к индексу второго массива сверху’
}

В предлагаемом языке ваш код можно записать так:


L(i) someArray
   L(i) i
      L(i) i
         L(i) i
            L(i) i
               DoSomethingTo(^^^i)

А можно так:


L(i) someArray
   L(j) i
      L(k) j
         L(l) k
            L(m) l
               DoSomethingTo(j)

Что успешно реализовано?

Type inference для словаря и массива.
Я предлагаю взять реализацию из Nemerle, поэтому ваши вопросы следует задавать разработчикам Nemerle.

foreach(var i in someArray)
foreach(var i in i)
foreach(var i in i)
foreach(var i in i)
foreach(var i in i)
{
  DoSomethingTo(i); // как здесь обратиться ‘к индексу второго массива сверху’
}

К счастью, никак. Более того, в определенных языках этот код даже не скомпилируется, потому что variable shadowing — это зло.


L(i) someArray
   L(i) i
      L(i) i
         L(i) i
            L(i) i
               DoSomethingTo(^^^i)

… и, собственно, получить то, о чем шла речь. Во-первых, опечататься в количестве ^ и не заметить этого — как нефиг делать, особенно если там окажется индекс, а не элемент. Во-вторых, стоит скопипастить эту строчку на уровень выше, как она начнет обращаться не ко второму сверху, а к верхнему — что не то, что было нужно разработчику.


Type inference для словаря и массива.

Type interference для словаря и массива — это как раз легко. Только мой вопрос был не про это.


Я предлагаю взять реализацию из Nemerle, поэтому ваши вопросы следует задавать разработчикам Nemerle.

Э нет, так не взлетит. Это ваш язык, ваши примеры, и вы должны знать, как он себя ведет.


Более того, в Nemerle type interference (в этом месте) сделан для generic parameter, а окаймляющий класс задан явно.

Во-вторых, стоит скопипастить эту строчку на уровень выше, как она начнет обращаться не ко второму сверху, а к верхнему — что не то, что было нужно разработчику.

Судя по описанию оператора ^, поведение изменится, если кто-то где-то создаст глобальную переменную i.
Также непонятно, как поведет себя код, если переменной во внешней области не окажется.

Не очень понимаю синтаксис, но выглядит как «язык курильщика»
L(i) someArray
   L(i) i
      L(i) i
         L(i) i
            L(i) i
               DoSomethingTo(^^^i)

Решили поправить на
L(i) someArray
   L(i) i
      L(i) i
         L(i) i
            L(i) i
              I f(^^^i) == 5
                DoSomethingTo(^^^i)

И вот тут наш ждёт сюрприз после добавления if-а, и хорошо что пример — тут одна невзрачная функция, а если там сложные вычисления и найти где там ^^i, а где ^^^i, где поменял, а где старое осталось (с этим количеством крышечек и крышечка уехать может) и что оно будет делать. Мы даже не знаем что оно считать будет, в какой момент index out of bounds будет или ещё AV какой.
PS(для автора) всё это обращение к уровню выше только вредит абсолютно без плюсов, это как рекламировавшийся Оберон с примерами с переменными A, X, I, J, K — вне переменных цикла неинформативно. Называйте их нормально и никакие ^^^^i не понадобятся.

В целом я с вами согласен, но хочу сделать небольшое пояснение: в приведённом вами примере никакого сюрприза после добавления if-а не случится, т.к. ^i означает не просто "переменную i из вышестоящего [по отношению к текущему] scope", а переменную i, которая была скрыта переменной с таким же именем (i).
Вот пример кода:


F f()
   V i = 1 // первая `i`
   L
      V i = 2 // вторая `i`
      print(i) // выведет значение второй `i`
      print(^i) // выведет значение первой `i`
      I ...
         I ...
            print(i) // также выведет значение второй `i`
            print(^i) // также выведет значение первой `i`
как выглядит сигнатура функции, которая принимает в себя один аргумент, являющийся перечислимым (enumerable) множеством от любого типа, на котором определена операция сложения?

Не очень понял о чём именно вы спросили, можете привести пример кода?


Я смог изобразить только вот этот код пиша ответ на ваш вопрос
T.enum Shape // or T.enum Shape {BOX, CUBE; SPHERE} (`BOX, CUBE` means here that BOX = CUBE and CUBE = BOX)
   BOX, CUBE
   SPHERE

F func(Shape s)
   ...

func(BOX)

F +(Shape s1, Shape s2) // just like in Ruby def +(...)
   Shape r
   ...
   R r
fun sum set ->
  if set |> empty
    None
  else
    r = set |> first
    for x in set |> skip 1
      r += x
    Some(r)

sum []: None
sum [1, 2, 3]: 6
sum [0.1, 0.5]: 0.6
sum [30m, 30s]: 30,5m
sum set(1, 3): 4
[1, 2, 3] |> filter odd |> sum : 4
Что успешно реализовано? Я задал два конкретных вопроса: какого типа persons, и что конкретно случилось с памятью в момент persons [+]=.
[Решил ответить, хоть и поздновато, но вдруг кому-то это не очевидно:] в строке A persons = [] задаётся основной тип переменной persons как массив (в Python — list, а я предлагаю название Array [а List использовать для связных списков]), то есть эту строку можно переписать как Array persons. В C++ бы пришлось указывать тип элементов массива и писать Array<Person> persons.

какого типа persons
В данном языке — Array[Person].

Более того, в Nemerle type interference (в этом месте) сделан для generic parameter, а окаймляющий класс задан явно.
На основе вышесказанного — "окаймляющий класс" в данном примере также задан явно (только в примере Nemerle используется словарь, а у меня массив).

и что конкретно случилось с памятью в момент persons [+]=.
Оператор [+]= как можно догадаться добавляет элемент в массив (аналог Python-овской функции append [или записи arr += [item]] и push_back из C++). Поведение оператора [+]= аналогично, и то что произойдёт с памятью — зависит от реализации (implementation-depend в терминологии C++). Я считаю, что в данном случае можно выделить память для одного элемента массива, а в последующем придерживаться стратегии полуторакратного резерва.
в строке A persons = [] задаётся основной тип переменной persons как массив
Оператор [+]= как можно догадаться добавляет элемент в массив

Вот только в нормальные массивы элементы добавлять нельзя, именно из-за накладных расходов с памятью, которые у вас недетерминированы.


Поведение оператора [+]= аналогично, и то что произойдёт с памятью — зависит от реализации

Спасибо, нет.

Вот только в нормальные массивы элементы добавлять нельзя

Для этого есть кортеж\tuple: (1, 2, 3).

… которые не обязаны быть гомогенными, зато обязаны быть неизменными. То есть на массив похожи только очень издалека.

В данном языке кортежи работают как std::tuple из C++, а не как в Python (хотя и используют синтаксис Python-а). То есть добавлять элементы нельзя, но изменять имеющиеся можно. (При программировании на Python я сам неоднократно сталкивался с потребностью именно в таких tuples\кортежах, и в Python-е приходилось использовать массивы вместо кортежей в этих случаях.)

Кроме того, tuple до 4-х элементов включительно работают как вектора в GLSL: можно например использовать запись (255, 0, 0) для задания красного цвета (т.е. (255, 0, 0).r = 255, а .g и .b равны 0) или трёхмерного вектора ((1, 2, 3).y = 2). Также есть swizzling: (255, 0, 0).bgr = (0, 0, 255). Это [встроенный тип для вектора/точки/цвета] очень удобно для работы с изображениями и вообще с графикой (2D и 3D). В C++ приходится выбирать какую-либо библиотеку (и из-за отсутствия поддержки векторов/точек в языке C++ каждый 3D-движок вынужден предоставлять собственную реализацию векторов [{на правах рекламы: в мной разработанном 3D-движке для ММОРПГ игры вполне успешно использовалась моя же библиотека Handy Math Library}]).
То есть добавлять элементы нельзя, но изменять имеющиеся можно.

То есть на самом деле — как массив.


Кроме того, tuple до 4-х элементов включительно работают как вектора

… а с многомерными пространствами вы не сталкивались?


Это [встроенный тип для вектора/точки/цвета] очень удобно для работы с изображениями и вообще с графикой

То есть внезапно ваш язык заточен под изображения и графику?


и из-за отсутствия поддержки векторов/точек в языке C++ каждый 3D-движок вынужден предоставлять собственную реализацию векторов

Вам не приходило в голову, что при реализации векторов в языке можно упустить какую-нибудь важную деталь? (за исключением, конечно, узкоспециализированных языков)

хорошо, много коментариев за несколько часов

вот первый пример кода из начала статьи

image

что мне нужно сделать, чтобы скомпилировать этот код в бинарник и выполнить его?

В данный момент проект находится на очень ранней стадии и до полноценного компилятора [тем более в бинарник (планируется поддержка только двух архитектур: x86-64 и ARM)] ещё далеко. Лично я отвечаю за трансляцию нового языка в C++17. Данный код странслируется в:


while (true)
{
    switch (instr[i])
    {
    case '[':
        nesting_level++;
        break;
    case ']':
        if (--nesting_level == 0)
            goto break_;
        break;
    }
    i++;

Если транслятор корректно генерирует код на С++, то и исполняемый двоичный файл получить не проблема. В конечном итоге транслятор должен брать на себя возню со сторонним компилятором, но если это сейчас не так, то можно так и написать, что нужно выполнить примерно следующее:
$ newlangtrans booboo.nl > booboo.cpp && g++ booboo.cpp -o booboo
Благодарю за разъяснение, но вы знаете, какая самая популярная операционная система среди программистов? Почему вы пишете только ответ для менее распространённой операционной системы?
[Говоря по простому, приведите пример крупных проектов, кто в "продакшн" использует gcc под Windows?]
Среди программистов GNU/Linux + Mac OS X +(WSL | cygwin ), для которых этот пример верен, не менее популярны. Сам я Windows не пользуюсь.

Аналогичный подход можно применить под любой разумной операционной системой.

Лично я считаю, что многие обозначения операторов языков выбраны неправильно, например ^ у новичков в программировании ассоциируется с операцией возведения в степень.


Префикс ^ — для доступа к переменным из внешней ‘области видимости’


Не находите, что это немного странно?
Обе эти возможности [крайне] редко используемые, просто мне хотелось сразу перечислить все префиксы, обозначающие "области видимости переменных".
Вы про возведение в степень и обращение к области видимости?

Вообще, [судя по Вашей манере писать], Вы бы и пунктуацию, синтаксис и прочие правила и у русского письменного поменяли бы :)

Кстати, где можно ознакомиться со спецификацией Вашего письменного языка? Не совсем понятны подобные вставки
Вы про возведение в степень и обращение к области видимости?

Да. (И я ведь указал это в подсказке к "Обе эти возможности", или вы заходите с планшета или смартфона? [Почему-то в Android практически нет браузеров показывающих всплывающие подсказки при долгом тапе/нажатии.])


К русскому ‘в данный период времени ’|у меня|‘ пока’ лишь две претензии:
Почему запятая не всегда означает паузу и почему не с глаголами пишется раздельно.


Ваша правда, я с телефона.


Мне кажется, что возведение в степень — достаточно частая операция.


Обращение к области видимости — тоже, это обычный вложенный цикл.


Но даже если были бы редкими, то я её понимаю, как это оправдывает неочевидное использование символа ^

Почему запятая не всегда означает паузу и почему не с глаголами пишется раздельно.

Потому что это естественный язык, и такова его логика.

Потому что это естественный язык, и такова его логика.

А вы можете формализовать?
Было бы здорово увидеть грамматику запятой в EBNF/ABNF. :)(:

-'‘запятой’'+'‘русского языка’'

Используйте string.replace уж)
Что у вас в голове вообще творится?

Что у вас в голове вообще творится?

Да вообще чёрт знает что. :)(:

А вы можете формализовать?

Берете Розенталя или Мильчина, там правила описаны.


Было бы здорово увидеть грамматику запятой в EBNF/ABNF

Естественный язык.

> Берете Розенталя или Мильчина, там правила описаны.

Я имел в виду точно формализовать (: в БНФ[‘или EBNF/ABNF’] :).

> *Естественный* язык.

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

А как вы относитесь к идее создания нового формализованного языка (имеющего точную БНФ форму), на котором можно и программировать и разговаривать людям одновременно?

И еще. Вы слышали про языки эсперанто и авелидо?
Я имел в виду точно формализовать

Повторяю еще раз: естественный язык.


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

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


А как вы относитесь к идее создания нового формализованного языка (имеющего точную БНФ форму), на котором можно и программировать и разговаривать людям одновременно?

Плохо.


И еще. Вы слышали про языки Эсперанто и Авелидо?

Про первый — да, про второй — нет. Эсперанто — сконструированный язык.

Любой язык разрабатывается с целью решения широкого или наоборот узкого круга проблем. За мои 18 лет опыта никогда не было острой необходимости ‘обратиться к индексу второго массива сверху’. Так что изобретать велосипедный синтакис (который сразу и не понять.) для решения такой редкой проблемы странно как минимум
Это нужно для отладки. Просто будет странным, если такой синтаксис будет работать при отладке, а в коде программы уже не будет работать.
Ну во время отладки (в известных мне отладчиках) можно же просто указать какие переменные/значения выводить… Даже можно прерывать выполнение по изменению значения иногда. И какой смысл дебаг функциональность делать «фичей» нового языка? Как правило, сборки и различают на дебаг/прод именно потому, что задачи запуска сборок разные совсем.
В MS Visual Studio 2013 в C++ это не работает, то есть если навести курсор на внешнюю переменную `i`, то показывается всё равно значение внутренней `i`. [-Хотелось бы таблицу, показывающую в каких IDE показывается верное значение при наведении, а в каких — нет.-]
Intellij… Chrome :) Но опять таки… Как мне кажется сомнительная причина городить язык новый. ПС. Опрос смотрю со мной согласен… :)
Задумывались ли вы над тем, что флаги открытия файла можно не указывать явно, а выводить из его использования?

И как вы это предлагаете делать, если файл используется за пределами того юнита, где он открывается?


Или вот, скажем, один программист думал, что открывает файл для чтения (и у него код на это оптимизирован), а другой попозже написал операцию записи в тот же файл — что должен сделать язык?

И как вы это предлагаете делать, если файл используется за пределами того юнита, где он открывается?
Тип файла будет шаблонным. Что-то вроде:
T File[T.enum {
         READ
         WRITE
         READ_WRITE
         } mode]

Или вот, скажем, один программист думал, что открывает файл для чтения (и у него код на это оптимизирован), а другой попозже написал операцию записи в тот же файл — что должен сделать язык?
Открываться файл автоматически и для записи и для чтения в таком случае, скорее всего, не будет.

Но вы согласны с тем, что при таком использовании:
A fstr = File(fname).read()
File(fname).write(contents)
флаги открытия файлов можно однозначно не указывать?

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

И как вам это поможет сделать его автовывод в описанных мной случаях?


Открываться файл автоматически и для записи и для чтения в таком случае, скорее всего, не будет

… и что же случится?


флаги открытия файлов можно однозначно не указывать?

Нет, не согласен. В каком режиме открыт файл во втором случае? Write? Append? Shared atomic append? А в первом — sequential read или random access read?


Вообще, такие вопросы будет решать комитет по разработке языка. Я не достаточно компетентен, чтобы ответственно отвечать на ваши вопросы.

Ну то есть вы понаделали кучу громких заявлений, а отвечать на них должен кто-то другой?

И как вам это поможет сделать его автовывод в описанных мной случаях?
Затрудняюсь ответить. Переадресую этот вопрос комитету, когда он будет собран.

… и что же случится?
Ошибка компиляции (: очевидно :).

В каком режиме открыт файл во втором случае?
В таком же как в Python "w"|"wt".
open(fname, "w").write(contents)

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

Мои личные переживания по поводу ответственности [за создание сильного ИИ] изложены здесь:
http://archive.li/hMGCi:

Мне долгое время было плохо физически от осознавания того, к чему приведёт результат моей деятельности в будущем.
Затрудняюсь ответить.

Ну то есть ваш "каркас" ничего не стоит, на самом деле.


Ошибка компиляции (: очевидно :).

Нет никакого "очевидно" в данном случае.


В таком же как в Python "w"|"wt".

… а если мне нужен append, или, того хуже, atomic append?


Отвечать будем все вместе. Я как раз и ищу тех, с кем можно будет разделить ответственность.

А зачем кому-то может быть нужно отвечать за ваши высказывания?

… а если мне нужен append, или, того хуже, atomic append?

‘Это’[‘подобное’], скорее всего, лучше делать через специальное имя файла, например: open(‘ram:myfile’) открывает файл в оперативной памяти (файл доступен до закрытия [приложения или файла] всем подпрограммам/подприложениям, запускающимся из данного приложения/программы). Или так: open(‘memory:myfile’) или open(‘sharedmemory:myfile’) [в первом случае файл виден только данному приложению и всем приложениям, запущенным из данного, а во втором — файл виден всем сторонним приложениям].


Открытие в режиме append я предлагаю заменять дополнительным вызовом функции-члена/метода seek():


A f = File(fname)
f.seek(END)
Это’[‘подобное’], скорее всего, лучше делать через специальное имя файла

Вы, похоже, даже не понимаете, что мне нужно.


Открытие в режиме append я предлагаю заменять дополнительным вызовом функции-члена/метода seek():

То есть то, что файлы (точнее, потоки) бывают без seek, вы даже еще и не думали? И про то, что atomic append так сделать нельзя? Впрочем, вы вообще про потоки, похоже, не думали, вы только о файлах говорите.

Я не достаточно компетентен, чтобы ответственно отвечать на ваши вопросы. Свою главную задачу я вижу в том, чтобы собрать ядро комитета.
Комитет должен собирать достаточно компетентный человек, иначе некомпетентность такого комитета, может оказаться даже выше.
Не соглашусь, [достаточно] разумный — да. Но не обязательно вникать в детали того, как работает компилятор.
Понимание деталей влияет на понимание реализуемости и полезности. Отвлечённое языкотворчество прагматического инструмента — это ошибка.

А мы пока что до компилятора не дошли, мы пока только наблюдаемое поведение обсуждаем.

Вы не согласны с тем, что компилятор неразрывно связан с ‘наблюдаемым поведением’?

Нет, конечно. Можно иметь два компилятора и одно поведение. Можно вообще не иметь компилятора, но иметь спеку на поведение.

Я так и не смог написать хороший вводный текст к данной статье, поэтому начну просто с примеров
Это, скорее всего, означает, что Вам нечем обосновать создание этого языка, кроме как потому что хочется. Обоснование — это и был бы хороший вводный текст.
У меня нет другого обоснования [в данный момент времени] кроме как ‘время пришло’.
Это, кстати, нормальный ответ. Хуже было бы, если «так велели голоса».
Но надеяться под это собрать комитет, на мой взгляд, наивно.
так велели голоса

Ну почти так и есть. :)(: Только я их называю ‘смысловыми импульсами [из будущего [посредством квантовой телепортации]]’.

Отсюда: http://archive.li/hMGCi
Всё дело в том, что исходный код ДЕйВОСи[с] написан на [совершенно] новом языке программирования.
И [мне[?]] необходимо собрать команду для разработки компилятора под этот язык для того, чтобы можно было выполнить/запустить [полученный/принятый из будущего] исходный код [на этом языке].

Разумеется, команду разработчиков компилятора я буду собирать не здесь (: [не в этом месте/сайте/форуме] :).

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

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

И запрет на использование Unicode в идентификаторах, зато можно использовать разные ASCII символы типа +, -, /, etc.

Это был бы язык, отличающийся от других.
И, конечно, минимальный минимум зарезервированных идентификаторов. Например:
class lang.Bit
{
    events: {
        on: {
            send switchedOn;
            switch off;
        },
        off: {
}
    }
}
Упс, время истекло.

И, конечно, минимальный минимум зарезервированных идентификаторов. Например:
class lang.Bit
{
    states: {
        on: {
            setOn: { // Handle setOn signal
            },
            setOff: {
                switch off;
                send switchedOff;
            }
        },
        off: {
            setOn: {
                switch on;
                send switchedOn;
            },
            setOn: {
            }
        }
    }
}
А для языка, основанного на данных и правилах их обработки (типа Пролога) можно вообще не выдумывать никакого особого синтаксиса, и использовать самый обычный JSON или XML, — т.о. парсер не нужен, а AST строится как в Лего.
Sign up to leave a comment.

Articles