Почему современные яп делают удобными для парсеров, а не для людей?

минус «let» минус «:». вот ты как воспринимаешь на слух речь, в которой через слово «кароч», «типа», «внатуре» и прочие слова паразиты?

Логично. По крайней мере одного читающего этот тред ты переубедил.

Я нифига не понял

как это делает парсеры удобнее

Ну да, ты реально нифига не понял.

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

или как это делает парсеры удобнее

Правила проще писать. Встретив кейворд fn ты точно знаешь, что дальше должен распарсить function-name, затем опциональный generic-specifier, затем ‘(’, затем function-args, затем ‘)’ и т.д.

Встретив A b ты должен обращаться к контексту, чтобы понять, что это такое.

как это мешает людям

Больше писать, больше мусора в тексте.

Если парсинг делается инструментами типа yacc, то тут дело не в легкости, а в чём-то другом. В моде, например.

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

Оба упомянутых семейства могут мимикрировать под «нормальные» языки.

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

Ассемблероподобные языки тоже можно вытянуть на относительно высокий уровень. Можно рассмотреть пример из темы про Carbon. На ассемблероподобном языке высокого уровня он может выглядеть так:

struct Circle
    *r @double

def print_total_area
    cref circles:array|Circle
    *area 0.0
    for *c in circles
        *a 3.1416 * c.r c.r
        area + a
    @print* "Total area: " area "\n"        

def main
    *circles @array|Circle 1.0; 2.0
    @print_total_area circles

Это даже более лаконично, чем на C++ или Carbon. Примерно в 1,5 раза. Но люди говорят, что им такое сложнее читать.

ФУНКЦИЯ-бла-бла

Вот, а так бы вводил просто бла-бла

Функция она и в Африке функция, а бла-бла что-то там может быть разным)

…и получал бы ещё в довесок кучу нерелевантных результатов. Отличное преимущество 👍

Сколько раз в жизни приходится такое делать? Один? Два? Да даже если три - так себе оправдание.

cast den73

грамматика должна быть класса LL1

Согласен. И однопроходный парсер.

«странное решение», а не «решение странное», не так ли?

une décision étrange

Lisp-подобные языки - они не про парсеры, а про унификацию. Единообразная нотация, избавляющая от необходимости существования синтаксического сахара как класса.

Встретив A b ты должен обращаться к контексту, чтобы понять, что это такое.

Только в C++. В C контекст не требуется.

Да нет, лисп — это про код на голом AST, практически без синтаксиса вообще.

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

если у Вас в базе будет французский, ну или там суахили (хз какой там принят порядок) тогда и приходите, обсудим.

код на голом AST, практически без синтаксиса

Ну и прекрасно. Ведь синтаксис у всех дизайнеров ЯП получается дерьмовый.

Особенно у тех, кто лисп придумал, да.

ML-подобный синтаксис, особенно в какой-нибудь Агде, это просто мимими!

Вброшу сюда слайды из презентации Грейдона Хоара (которыйхРуст придумал) про компиляторы и языки.

http://venge.net/graydon/talks/CompilerTalk-2019.pdf

Виляние жопой пошло. В оригинальном сообщении про английский ничего не было. Но даже если так, то:

the only solution possible, all the tickets available, go somewhere quiet, get something interesting, six feet deep, two miles long, get the children ready 1; поэтическое: Sedately sits the miller stout; идиомы: proved a bridge too far и т.д.

Потому что ты так сказал?

Ага. Чьё мнение тебе ещё нужно?

стремление натянуть сову на глобус пошло. вообще-то мы тут изначально о ЯП, нет?

первые приведенные Вами два примера «the only solution possible, all the tickets available»

Some adjectives ending in -able/-ible can also be used after nouns.

в каком ЯП Вам померещилось int32able?

едем дальше, а дальше «go somewhere quiet, get something interesting»

Adjectives come after words like something, everything, anything, nothing, somebody, anywhere etc.

это опять о ЯП? сова в напряжении.

«six feet deep, two miles long»

In most expressions of measurement adjectives come after the measurement noun.

«get the children ready»

Verb + object + adjective

разжевать?

Вы сами-то в состоянии осознать, что пишут в статье, на которую Вы же и ссылаетесь?

успехов.

Почему современные яп делают удобными для парсеров, а не для людей?

А с чего ты взял, что синтаксис старых ЯП удобен для людей?

Все эти fn, fun, func, val, var и паскалевское указание типа…

C val и var очень удобно указывать мутабельность и иммутабельность, для сравенения тот же C или C++ с его мешаниной const’ов, которые нужно правильно расставлять.

В современных языках val и var удобны как для человека, так и для парсера. В старых языках причуды с const и final неудобны ни для человека, ни для парсера.

Backward declaration тоже удобен для человека во многих местах, типа возврата функций, там где в C++ будет какой-то нечитабельный какерский однострочник на Perl, с тем что ты назвал «паскалевским указанием типа» будет всё лаконично и ясно.

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

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

А, например, множественные операции, которые повешали на символы * и & в C и C++ – не замусоревние синтаксиса? Ну как, удобно учить начинающих программистов жонглировать синтаксисом указателей, адресов и ссылок? Там большинство проблем именно из-за синтаксиса, потому что на один значок повесили с пяток разных операций, запутывающих новичков.

Ну, блин. Это всё равно что пристать, почему на разных сайтах юзаются разные шрифты. Хули не юзать 1, если всё равно это текст?

Так само и тут: «Я художник, я так вижу». Тем более синтаксис это не самое раздражающее, когда работаешь с несколькими ЯП-ами.

Нет

В C контекст не требуется.

a * b;

a умножить на b ? b это указатель на переменную типа a?

C val и var очень удобно указывать мутабельность и иммутабельность

только привычка мешает разглядеть, что val и var различаются одной буквой в конце слова. объективно - это не эргономично от слова совсем.

множественные операции, которые повешали на символы * и & в C и C++ – не замусоревние синтаксиса?

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

Нет, его делают для того, чтобы код был плотнее. Есть мысль, которую не понимает, наверное, 90% людей. Как сжать информацию? Самое простое - кодировать более часто повторяющиеся сигналы более короткими сочетаниями точек и тире.

a умножить на b ? b это указатель на переменную типа a?

Да, ты прав.

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

Получается 0 символов это менее плотное сжатие чем 2?

Можно обойтись и без всего остального, однако это не делает всё остальное ненужным мусором.

• сначала прилагательное, затем существительное, не так ли?
• Не так, во французском сначало существительное.
• Я имел в виду английский.
• В английском тоже не так.
• Ко-ко-ко, где названия типов заканчиваются на -able, где переменные называют smth или числительными…

Можешь мастер класс по вилянию давать.

Извини, плохо прочитал пост. Но ведь в человеке должен быть такой же по функционалу парсер, как в компиляторе. Если компилятору сложнее разобрать текст (из-за a * b, которое уже привели), то и человеку сложнее. Т.е. не для просто уплотнения, а для оптимизации функции примерно «плотность текста * его однозначность» или как-то так.

во французском сначало существительное.

во французском тоже по-всякому

une petite ville, un jeune homme, une mauvaise idée

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

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

Но ведь в человеке должен быть такой же по функционалу парсер

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

Неужели этот код хуже читается чем

Это разные вещи. В С понятия функции и указателя на функцию различны. В паскалятине – нет. Этим, в принципе, можно заканчивать.

В С понятия функции и указателя на функцию различны. В паскалятине – нет. Этим, в принципе, можно заканчивать.

Что за бред я сейчас прочитал?..

так в сях просто переобозначили: begin = {, end = }. Разумно, на мой взгляд поступили с точки зрения сокращения часто используемых слов. Кстати, вот идейка, сделать в современных средах разработки прослоечку, которая будет превращать begin/end в « и » на этапе отображения текста, а при сохранении - обратно. Ща опробую:

Program Stepen_chisla;
Var
  Z, А : Real; M : integer;
Function Step (N: integer; X:real): real;
Var
  I: integer; Y: Real;
    Begin
      I:=1; Y:=1;
      While I<=N do
        Begin
          Y:=Y*X; I:=I+1;
        End;
        Step:=Y;
      End; {Конец функции}
Begin
   Write(‘Введи степень и возводимое число’); Readln(Z,M);
   F:=Step(M,Z);
   Writeln(Z, ‘ в степени’, M, ‘=’,F);
End.

.Program Stepen_chisla;
Var
  Z, А : Real; M : integer;
Function Step (N: integer; X:real): real;
Var
  I: integer; Y: Real;
    «
      I:=1; Y:=1;
      While I<=N do «
          Y:=Y*X; I:=I+1;
        »;
        Step:=Y;
      »; {Конец функции}
«
   Write(‘Введи степень и возводимое число’); Readln(Z,M);
   F:=Step(M,Z);
   Writeln(Z, ‘ в степени’, M, ‘=’,F);
».

А SQL прижился.

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

Замусорили код и сделали фигурные скобки неоднозначными. Но в контексте применения си в то время это было оправданно. А потом все стали это воспроизводить просто потому что так привыкли. Особенно феерично получилось в javascript. Хотя ведь begin не сильно нужен, а end можно было и оставить. Ну или другой путь - отступы, но там есть и свои недостатки. Но все равно оба варианта при современных возможностях редакторов намного лучше, чем сишный мусор. Да и begin/end тоже лучше.

Неоднозначность - это другое и не оправдывает того, что begin и end в Паскале - слова. Так-то неоднозначность заложена в самой алгебраической нотации. Круглые скобки отделяют аргументы от имени функции, а также служат для группировки подвыражений. Также они могут означать приведение типа (даже в Паскале) или кортежи (в Питоне). По идее, если неоднозначность кого-то волнует, то нужно с этого было бы начать.

Хотя ведь begin не сильно нужен, а end можно было и оставить.

В Обероне (и Бейсике) как раз begin и убран (почти везде)

Жду указатель на функцию в паскале.

Не оно?..

https://stackoverflow.com/questions/4745703/c-function-pointer-translation-in...

Фигурные скобки визуально лучше отделяют блок кода, чем слова. Понятное дело, что ИДЕ может это компенсировать, например цветом, но всё таки это было придумано до того, как появилась возможность раскрашивать код.

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

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

Наверное, тебе еще нравятся переменные в стиле usersList и loopIndex.

возможно, не буду спорить. Давно с Паскалем не работал...