мне стало интересно, как вы пишите компиляторы (выберите один из двух вариантов, желательно с объяснением чем подход нравится больше)
1. "широкий подход". Как компилятор компилирует, в таком порядке и иду - сначала лексер, парсер, потом всякие оптимизаторы и в конце трансляцию.
2. "длинный подход". Выбираю несколько фичей, которые запиливаю до конца, добавляя постепенно новые.
кмк у обоих подходов есть свои плюсы и минусы. В первом ты сосредоточен постоянно на конкретной части, что повышает концентрацию. во второй ты пилишь фичи постепенно, благодаря чему можно сразу проверять гипотезы на месте, и не переписывать целый layer если что-то пошло не так.

2. Не получается сразу угадать всю архитектуру. Откатываться приходиться

Ну да, 2 всегда работает лучше когда пишешь что-то новое, 1 если сразу знаешь что и как собираешься получить.

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

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

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

На практике компиляторы создают, все же, чаще методом нисходящего проектирования. И проектирование общей архитектуры начинается с проектирования основного промежуточного представления, особенно, если компилятор многоязыковый. Так было во времена системы БЕТА Ершова, так обстоит дело и сейчас в LLVM/MLIR и libFirm.

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

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

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

Couldn't agree more

я тут курс на ютубе нашел по компиляторам и смотрю с удовольствием: https://www.youtube.com/watch?v=DKr45aBUtFU&list=PLlb7e2G7aSpQ4Ym2TWTYyMcfMevxpKoxj&index=1 . По идее, курс для старшекурсников

Это они проектируются так. А в разработке, всё равно, приходится подгонять компоненты друг к другу и перестраивать код по всему стеку. Хотя, конечно, дело может быть в практике. После 10 компиляторов архитектура может просматриваться сразу вся на все уровни

Всегда можно воспользоваться классическим подходом http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.170&rep=rep1&type=pdf

Хм... Может быть, так и нужно поступать

Нубский вопрос от инженера к людям из академической среды: подскажите plz, какие есть источники "state of the art" в плане компиляторов и языков программирования? Т.е. где чаще всего публикуют новые научные статьи по этим темам? И есть ли какие-нибудь дайджесты или обзоры этих статей?

arXiv... 😂

Наверное, можно на scholar.google.com поискать или даже подписаться на тему.

А PLComp Вам не подходит? :)

смотрите proceedings следующих конференций: Principles of Programming Languages (POPL), Programming Language Design and Implementation (PLDI), Object-Oriented Programming, Systems, Languages & Applications (OOPSLA).
Можно прям заходить на сайт конференций, смотреть accepted papers и потом их искать на scholar.google.com  (многие авторы выкладывают препринты своих работ в открытый доступ).

Есть ещё несколько конференций чуть поменьше (в плане импакта): ECOOP, ICFP, ESOP, VMCAI и много других, которых я не знаю :)

Да, я подписан на ваш канал. Но мне скорее про первоисточники было интересно