> Прикладные программисты последние лет *дцать

Это же только некоторые прикладные программисты.

> А прикладным разработчикам кажется, что такие грамматики очень удобны.

Т.е. https://xkcd.com/285/ ;)

> @true_grue даже заметку писал на эту тему:

Для использования recursive descent именно и только в этих ситуациях есть конкретные причины, Вам не кажется?

Но это же не в рантайме происходит, а во время построения таблицы

ну я привел список популярных реализаций языков. Чем не цитаты? Это лучше голословного "формализм некрасивый".

> Для использования recursive descent именно и только в этих ситуациях есть конкретные причины, Вам не кажется?

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

я действительно думаю, что тема разбора теоретически решена уж лет 60 как. Последние большие прорывы это GLR/GLL, все остальное это уже упрощение и шлифовка имеющейся теории.

EDIT: 70 -> 60

> Чем не цитаты?

Тем, что "зрелыми" компиляторами область применения parsing не исчерпывается?

> Это лучше голословного "формализм некрасивый".

Почему "голословного"? И не "некрасивый", а в нём есть конкретная проблема, вот и всё.

> После определенного (и довольно низкого) порога становится проще и эффективней сделать рекурсивный спуск.

Вот именно, после. И "порог" этот проходят обычно тогда, когда для этого языка уже напишут гарантированно однозначную (т.е. LL(1)/LALR, чаще всего) грамматику и протестируют её. Естественно, "испортить" такую грамматику ни PEG, ни recursive descent уже не удастся. ;)
Я о том, что существенная часть из упомянутого списка компиляторов на recursive descent перешла, и именно с "классических" parser generators. Т.е. parsing там до этого уже корректно работал, AST не "падали с неба". ;)

> Да и вообще рекурсивный спуск не требует особых объяснений среднему программисту

Да, это плюс.

> не в пример бесконечных и бесплодных теоретических споров о грамматиках.

Мне кажется, что это не так.

>  что тема разбора теоретически решена уж лет 60 как.

А это уже оценочное суждение. Новые подходы / алгоритмы появляются, это факт.
"Существенно" это лично для кого-то или нет — другое дело.

Собственно, вот:

"The advantages  of ALL(*) stem from  moving grammar analysis to parse time, but this choice places an additional burden on grammar functional testing. As with all dynamic approaches,  programmers  must  cover  as  many  grammar position  and  input  sequence  combinations  as  possible  to find  grammar  ambiguities.  Standard  source  code  coverage tools can help programmers measure grammar coverage for ALL(*) parsers. High coverage in the generated code corresponds to high grammar coverage."

https://www.antlr.org/papers/allstar-techreport.pdf

Да

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

Я вот где то читал, что context это примитив синхронизации, а потом оказалось что кое где при сравнении типов он учитывается и строки генерить CreateStringPtr не очень идея

Взять к примеру ГОСТ по языку Ада. Авторы пишут "Переводчики стремились придерживаться терминологических традицый отечественной литературы по программированию, чему способствовала 5-летняя дискуссия по терминалогии в Рабочей группе по языку программирования Ада Комиссии по языкам и системам программирования при ГКНТ СССР".

Или книгу В.Ш. Кауфмана "Языки программирования. Концепции и принципы  2017".

Там используется statement = оператор.

Они реально написали «традицый»?

А, ну хорошо. Видимо, таки сломали spellchecker неуемным употреблением албанского!

В советах с 60-ых ИТ отрасль уверенно саботировалась и по крайней мере я не рекомендую ссылатся на позднесоветский опыт и практику в ИТ отрасли, как пример в горячо известном Ахо+Ульмане и др. переводчик сослался на советский учебник по формальным языкам(переводу учебника), откровенно странный переводчик которого перевёл "production" как "продукция"(большей дикостью языкового характера как по мне является та дичь, что творится с глубоким обучением: как пример читал "Глубокое обучение" Николенко и соавторов и даже не смешно - авторы сами всю книгу оправдывают заимствования, чем позорятся вдвойне, с каждой новой темой птичий язык набирает ход, хотя перед авторами были широкие возможности адаптации нетипичных определений к родному языку) и эта нездоровая традиция пользования несуразных транслитераций, когда я уж прошу меня извинить, но переводчики не чувствуют связей между областями знаний, между явлениями и в учебнике по суть математической дисциплине не могут вспомнить привычное "произведение"(тот же vector product) и "порождение", то у меня вопросы к компетенции таких переводчиков, либо к РАН, которая положила болт на вопрос регулирования теоретической целостности и полноты областей знаний, т.к. если даже для книг на великом и могучем нужно лезть за словарём или в первоисточники термина, изучать исходное значение, то это наталкивает на грустные мысли. Возвращаясь к теме я рекомендую переводить statement как "утверждение", "положение", "предложение" и "выражение" в зависимости от содержания - главное, чтобы перевод вызывал качественно передавал смысл и не дурил голову читателю.

Но ведь есть понятие продукции в экспертных системах

Продукционые правила и тп

Production rules

А когда оно вошло в оборот ?)

Давно

как перевод