Rust 1.49

В треде всё объяснили.

Почему в новостях про rust всегда столько срача.

Это да.
Местами похоже на споры

Остроконечников и тупоконечников

Владимир

И зачем на практике нужно такое «сокращение»? Кроме как затруднить чтение исходника?

Какие IDE посоветуйте для данного ЯП? Какие графические фреймворки поддерживаются?

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

В начале-середине десятых зафакапила последняя методичка убогих - фп-скриптуха - птушное говно отказывалось работать как в мечтах бездарностей, выглядело как говно и сливало во всём си и крестам. Это означало, что опущенные более ничего не смогут блеять про «скоро умрёт», «устаревшее», «легаси» и пр. в контексте C и C++.

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

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

Как редактор для начала можно взять VSCode либо vim с LSP-плагином rust-analizer.

GUI - gtk-rs

Это паста?

CLion или VSCode с соответствующими плагинами.

С гуями всё сложно. Были конечно биндинги к GTK+ и Qt, но про их состояние ничего сказать не могу.

Смотри www.areweguiyet.com

Rust силён своими хейтерами. У которых сочетания от четырёх латинских букв начинает жечь пониже спины и они набегают в соответствующие темы и повышают рейтинги просмотров.

Ну и зачастую ловят банхаммер в лицо.

Rust силён своими хейтерами.

Когда других достоинств нет, то приходится гордиться своими хейтерами. 😿

О, вот ещё один прибежал.

Давно ли были времена когда здесь крестовиков множили на ноль?

Чено ты кидаешь, никчемное создание, не отличающее языки от типов данных. Иди отсюда, дилетант.

Царя забанили за то, что он тупой дошколенок.

peregrine в каменте Xfce, Voidlinux: ни в одном терминале не работает ввод русских букв (комментарий) писал:

Куда делись тёплые ламповые посиделки в девелопменте с царём и железным жуком.

Я же говорил, что он — вернётся!

И зачем на практике нужно такое «сокращение»? Кроме как затруднить чтение исходника?

Я не знаю. Мне shadowing не нравится. Наверное, это было очень нужно в Ocaml, так как там нет ключевого слова mut. А в Rust и F# это перешло просто так, как некоторые фичи из C в C++…

В F# и Rust можно просто объявить:

// F#
let mutable x = 5;
x = 6;

// Rust
let mut x = 5;
x = 6;

Но вот например чел хочет, чтобы в Kotlin добавили такую же фичу: https://discuss.kotlinlang.org/t/rust-style-variable-shadowing/16338

Может там есть примеры зачем это нужно…

Выражаю наилучшие пожелания разработчикам и сообществу в связи с новым релизом!

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

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

Вот и набежала файрфокс погань в тред, доколе?

Артисты с прыщами будут заходить в новости systemd, rust и выдавать своё нытьё за экспердное мнение ?

Файрфокс токсики так горят, как будто их заставляют использовать раст, но нет.

При этом если посмотреть на этих царьков, то вся их аргументация уровня «Смотри как я знаю Файрфокс», но почему им так плохо?

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

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

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

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

Что же делать? Решение пока не найдено, всевозможные попытки объяснить нужность файрфокс сводятся к фанатичному вываливанию помоев в темах других браузеров.

Но почему именно на расте сконцентрировано внимание? Верно, титулы.

Файрфокс синтаксис обезьяна уже не может похвастаться, что осваивает что-то сложное, тяжелое, умное, единственное и особенное.

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

«Ты не осилил», «Вы не понимаете» и другие отговорки все видели не раз, но теперь всё поменялось местами и мы наблюдаем битву сортов говна.

Зачем? Цель

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

Критерий нормальности определяют сами создатели и сообщество раста. Как собственно и критерии нормальности для С++, сообщество С++.

Нет, конечно. Для майкрософт С++ образца нулевых кодов был нормален, и в том числе благодаря им немало нужных вещей ежегодно не попадает в стандарт. Спорить с тем, что тот С++ – невыносимое убожество, ты никак не можешь. Вместе с тем они составляют значительную часть как создателей, так и сообщества С++. Мнение создателей раста меня вообще не волнует. Пусть сперва адепты ответят на заданные им вопросы прямо и по существу, не изобретая новые определения в процессе разговора.

Заявляется наличие того, за отсутствие чего ты его критикуешь.

О чем ты вообще? Ты на русском языке разговаривать умеешь? Какое наличие отсутствия?

Или ты хочешь поспорить с тем, что нельзя написать функцию от произвольного числа переменных? Или то, что panic! подозрительно напоминает throw, и что ему даже хэндлеры можно задавать? Или что fabric constructors в расте нужны только потому, что из обычного конструктора без исключений нельзя было бы вернуть ошибку?

Или ты хочешь поспорить с тем, что нельзя написать функцию от произвольного числа переменных?

В Rust можно прям как в С.

1. Есть varargs (для совместимости с FFI С). Не рекомендуется использовать, также как и в С.

2. Есть макросы с произвольным числом переменных. Рекомендуется использовать, также как и в С.

То есть у С и Rust в этом плане паритет.

В С++ да, там есть ещё Parameter pack. Такого в Rust нет…

Есть макросы с произвольным числом переменных.

функцию

Есть varargs

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

Все хороши — и плюсы и руст(хоть он, конечно, явно выигрывает)

После этих слов в лоровском поезде начался кошмар...

Молодец, здесь оказывается есть пацаны с нормальными заходами. Только по поводу «сгенерированного кода».

Дело в том, что в этом недоязычке нет сгенерированного кода в принципе. Это апогей работы в одну сторону, потому как если в примитивных макросах ещё как-то можно получить куски кода и связать с результатом генерации, то когда генерация приходит из внешнего контекста. Т.е. код есть только в памяти огрызка, которые туда был заслан скриптухой запущенной сбоку.

Здесь проблема не в том, что в этой нелепой скриптухи нет варидика. Даже если бы он был - это бы ничем не помогло.

Вот будет там T ... - дальше что, ты никак не сможешь использовать эта параметры. Они буде все одного типа.

Аналогично со всем остальным. Ну получит дошколёнок этот пак, дальше что? Сложить в тапл он его не может, обйоти не может, вызвать ничего от него не может. Преобразовать и свернуть тоже.

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

В реальности макросня нужна для того, чтобы скрыть эти фундаментальные дыры в скриптухе. Её полную неспособность во что-либо, Кроме убогой скриптушной байды.

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

Ну printf и scanf как-то умудряются что-то с этим делать…

https://en.cppreference.com/w/cpp/utility/variadic/va_arg

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a65328ef9a73b5df0022cb578d310419

Абсолютно неважно, что они там умудряются сделать – все типы затираются, на них нельзя построить никакую логику. Если бы они не затирались, не нужно было бы писать спецификаторы типа ‘%d’ – можно было бы писать произвольную логику.

Нет, никаких альтернатив «убийце C и C++» нет. Во всяком случае, судя по активности в опенсорс мире. Вам нужно окунутся в мир JS/CSS/ это такой зоопарк рукоделия. Если встать на эти рельсы промышленникам, то давно бы цеха превратились в лофты, проги работали на маках, а главный менеджер был бы такой душечкой и колоссальные бюджеты пилились только на иконках.

Интересно бы было посмотреть на царя топящего за раст, может и доживем до этого, он же раньше и плюсы не признавал.

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

и еще, если хочешь пожаловаться на синтаксисы, то посмотри на синтаксис раста https://doc.rust-lang.org/stable/rust-by-example/conversion/try_from_try_into... и скажи что тебе понятнее, си или вот это вот что по ссылке. мне кажется синтаксис раста специально сделали как можно более уродливым и сложным чтобы выделяться и бороду в смузи не пачкать.

Почему в новостях про rust всегда столько срача. Все хороши — и плюсы и руст(хоть он, конечно, явно выигрывает). Пишется вам на плюсах, ну и пишите, об чём разговор-то

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

не конкурент он сям с таким уродливым синтаксисом и никогда не будет. именно поэтому на расте пишет 2.5 человека, а на сях миллионы.

Указатель это объект который связывает программу с кучей. Кучей руководит операционка.

В большинстве случаев нет. Если это сишечка, то это указатели на структуры, чтоб не передавать по значению, это массивы (в том числе и строки), и это структуры, которые вызываемая функция должна заполнить.

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

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

И это пишет фанат плюсов, которые добавили const*, volatile*.

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

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

T &obj = … <- пожалуйста, своего рода ненулябельный указатель

Ага, «своего рода». Только это указатель, для которого невозможно изменить на что он указывает. Прямо скажем, так себе указатель.

В конце концов если ненулябельность это прям такая суперпотребность то в чем проблема сделать обертку над любым ныжным «умным указателем».

Ты не понял. Ненулябельность не «если». Ненулябельность должна быть свойством указателя по умолчанию. Это надо быть на всю голову контуженым, чтоб считать нормальной ситуацию, в которой любой указатель может оказаться нулевым. При создании плюсов об этом подумали, добавили ссылки, но при этом мув-семантику реализовали на уровне библиотеки, теперь там где компилятор раста скажет, мол, чувак, у тебя тут в одной из веток владение отдано, исправь, компилятор плюсов сделает unique_ptr фактически нулевым. Т.е. одной рукой убираем нулябельность, другой добавляем.

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

За 7+ лет практики впервые услышал о таком. Не знаю как там в Си, но в плюсах эта штука не нужна от слова вообще, поэтому я и не знал о таком.

Значит никогда не обращался к API операционок, там везде такая фича используется в хвост и в гриву. Сходу, например, вспоминаю виндовый хедер для битмапа в случае использования палитры. Эта фича введена в C99, до этого последним членом структуры писали просто item_type items[1], подразумевая, что создатель структуры при выделении памяти выделит sizeof(struct) + (items_count - 1)*sizeof(item_type) Чтоб избавиться от скобок и -1 в 99м году(!) добавили возможность фактически не резервировать под массив место. Это вот как раз пример поощрения плохих практик.

Для меня синтаксис Раста не выглядит страшно, он выглядит уродски.

Ага «для меня» и «выглядит».

А я вот сформулирую утверждение, которое гораздо сильнее: синтаксис C не «для меня», а объективно и не «выглядит», а является уродским. И могу даже это доказать. Набираешь в гугле «правило право-лево» и где-то на первой странице встречаешь объяснение, как разбирать сложные объявления указателей. Это не вопрос каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов, нет, это сраный парсинг типа переменной! А всё почему? Потому что в одном из первых структурных языков алголе решили поместить тип переменных слева от имени. Решение основанное не на чём. А потом в сях (или в каком-то промежуточном языке) решили объявлять массивы скобками после имени, а под конец попытались обобщить правило объявления так, чтоб оно покрывало объяление функций, переменных и массивов. С тех пор наследники алгола и C занимаются тем, что выбирают насколько упростить объявления. Те, кто посмелее (обычно теоретики) просто делают сразу нормально. Те, кто пытается не пугать старых программистов, оставляют тип слева, но от порнографии с описанием типа, который окружает идентификатор, отказались все. Одно только объявление функции осталось в виде исключения.

https://www.youtube.com/watch?v=nhllZWfnXKQ

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

То, что сам язык такой и сякой меня абсолютно не беспокоит, но вот его реализация - это просто ад. Получить воспроизводимые сборки в принципе невозможно. Cargo, скачивающий что-то откуда-то во время компиляции - это никуда не годится. Да и сам раст для установки требует откуда-то скачать какой-то бинарный блоб. Его нельзя собрать из исходников. Это в мире виндовс или макоэс на такое никто внимания не обращает, у них «просто всё работает», но куда они с такой квалификацией в свободный софт лезут, решительно непонятно.

Собственно это легко объясняется чтением растового багтрекера. Складывается ощущение, что авторы уже давно сами запутались что они лепят. И особенно доставляет, как часто они не могут что-то починить, потому что это дурацкий LLVM во всём виноват.

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

А всё почему?

Потому что ты днище и неосилятор. Там всё очевидно парсится. Ничего сложного нет. Если ты до сих пор не можешь читать переменные и их типы: https://youtu.be/NZtr93iL3R0

Там досконально показывают из чего состоит декларация переменной в С/С++ и как читать спецификаторы. Один час и научишься читать и перестанешь годами ныть как всё сложно.

Вся тема состоит из комментов вида: одни не могут осилить синтаксис раста, другие не могут осилить синсис сишки, третьи не могут в синтаксис плюсов.

Получить воспроизводимые сборки в принципе невозможно

Как раз в этой версии вроде починили.

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

Зато для разработки наооборот все очень хорошо и удобно, особенно после С++.

Потому что ты днище и неосилятор

Хорошо он тебя задел, технично. Тебе даже и ответить-то нечего, кроме классического «ниасилили».

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

а что, в расте нет вендоринга чтоли? или это не по-пацански пинить пакеты?

последним членом структуры писали просто item_type items[1], подразумевая, что создатель структуры при выделении памяти выделит sizeof(struct) + (items_count - 1)*sizeof(item_type) Чтоб избавиться от скобок и -1 в 99м году(!) добавили возможность фактически не резервировать под массив место. Это вот как раз пример поощрения плохих практик

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

ты ведь не просто так запоминал это всё.

Там запоминать нечего. Лишь приоритет, что сначала (), затем [], затем всякие спецификаторы. Я просто не вижу большой разницы между

typedef int32_t (*BinaryOp)(int32_t, int32_t);
int32_t (*const my_func)(int32_t, int32_t) = &add;
BinaryOp const my_func2 = &add;
BinaryOp my_func3 = &add;

и

type BinaryOp = fn(i32, i32) -> i32;
let my_func : fn(i32, i32)->i32 = add;
let my_func2 : BinaryOp = add;
let mut my_func3 : BinaryOp = add;

Ага «для меня» и «выглядит».

А я вот сформулирую утверждение, которое гораздо сильнее: синтаксис C не «для меня», а объективно и не «выглядит», а …

Какая тебе разница как происходит разбор выражения если это делает парсер а не ты? Зачем ты пытаешься выдать проблемы с которыми сталкиваются разработчики языка за проблемы пользовательского программирования?

Значит никогда не обращался к API операционок, там везде такая фича используется в хвост и в гриву. Сходу, например, вспоминаю виндовый хедер для битмапа в случае использования палитры. Эта фича введена в C99, до этого последним членом структуры писали просто item_type items[1], подразумевая, что создатель структуры при выделении памяти выделит sizeof(struct) + (items_count - 1)*sizeof(item_type) Чтоб избавиться от скобок и -1 в 99м году(!) добавили возможность фактически не резервировать под массив место. Это вот как раз пример поощрения плохих практик.

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

Ты не понял. Ненулябельность не «если». Ненулябельность должна быть свойством указателя по умолчанию. Это надо быть на всю голову контуженым, чтоб считать нормальной ситуацию, в которой любой указатель может оказаться нулевым. При создании плюсов об этом подумали, добавили ссылки, но при этом мув-семантику реализовали на уровне библиотеки, теперь там где компилятор раста скажет, мол, чувак, у тебя тут в одной из веток владение отдано, исправь, компилятор плюсов сделает unique_ptr фактически нулевым. Т.е. одной рукой убираем нулябельность, другой добавляем.

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

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

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

Ага, «своего рода». Только это указатель, для которого невозможно изменить на что он указывает. Прямо скажем, так себе указатель.

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

И это пишет фанат плюсов, которые добавили const*, volatile*.

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

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

Все твои претензии к языку это претензии к аппаратной реализации вычислителя, для низкоуровневого кода ты ничего лучше не придумаешь, rust попробовал и обломался, ссучился и ввел unsafe и никуда ты от этого не убежишь. А для кода уровнем выше и С++ хватит со всем набором анализаторов санитайзеров чекеров и прочего хлама, выдумывать «новый» язык не дающий принципиально нового подхода для этого - провал.

Ну что ж ты хэлворды-то привёл. Хотя бы int signal(что-то тут далее…). Там уже разницу и посмотрим.

Какая тебе разница как происходит разбор выражения если это делает парсер а не ты?

Человек код так же читает, идиот малолетний.

легаси оно такое

Это не легаси, дебил. Я выше уже писал, почему такое нужно.

Про «нулябельность» сами сритесь.

🎅+🎁=🤡+👑=🤴

🐧+🤜+🤴=☠

Во какие ребусы.

Box Rc Ref RefMut RefCell лучше обсуди красоту синтаксиса языка в виде вложенного боксинга с этими красавчиками и им подобными, с прописыванием лайфтаймов, вот где красота так красота на пол экрана на одно выражение.

лучше

Нет, не лучше. И да - ПНХ, школьник.

Человек код так же читает, идиот малолетний.

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

Это не легаси, дебил. Я выше уже писал, почему такое нужно

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

Иди салаты доедай, пугало некомпетентное.

И слава богу, что в расте из коробки нормальное метапрограммирование (на макросах), а не убогое (на темплейтах)

То есть я к тому, что иногда c++ темплейтов просто не хватает, они не выразительны. «Концепты» должны улучшить ситуацию, посмотрим..

Поверь мне, аноним, в твоём сообщении нет ни одного утверждения, которое не было бы идиотским. Это просто чудо, сложно написать чушь от первого до последнего слова, но ты смог. Чтоб не тратить время, беру самое первое:

Какая тебе разница как происходит разбор выражения если это делает парсер а не ты? Зачем ты пытаешься выдать проблемы с которыми сталкиваются разработчики языка за проблемы пользовательского программирования?

Разбором выражения занимаюсь именно я. Собственно поэтому и описывают «правило право-лево», чтоб люди, читающие исходник, смогли понять что там написано. Для разработчиков компиляторов существуют другие книги/статьи, по теории формальных языков, например.