ну да, но не суть :)

Полностью согласен с идеей что одним курсом покрыть всё невозможно. Сюда же можно добавить курс про сопутствующие системные инструменты (отладчик, компоновщик, профилировщик, ассемблер и т.п.)

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

Вот, например, взгляд на обучение компиляторам со стороны такого компиляторщика-самоучки, который в Apple работает над clang:

https://belkadan.com/blog/2016/05/So-You-Want-To-Be-A-Compiler-Wizard/

вспоминается цитата про дятла и цивилизацию

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

Тут интересно сравнить между собой темы, которые предлагает академист Dan Ghica и настоящий промышленный компиляторщик :)

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

1. Пишутся не по стандарту, но должны работать
2. Содержат ошибки (много ошибок), но должны работать
3. Написаны самым тупым и непредсказуемым образом, но должны работать и быстро
4. Время компиляции и потребляемая память оказываются конечными
5. Ошибки в алгоритмах оптимизаций могут всплывать через 10-15 лет, и их надо как-то исправлять, не ломая совместимость и производительность

Вот это, имо, совсем лишнее Write snprintf in assembly. полезнее ривёрс инжинерить код, сгенерированный компилятором и пытаться понять его логику.

Вспоминаются посты майка полла.

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

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

Вот моя любимая его заметка. Здесь он мечтает о dataflow-архитектурах с позиции компиляторщика. Это приятно читать :) https://www.freelists.org/post/luajit/Ramblings-on-languages-and-architectures-was-Re-any-benefit-to-throwing-off-lua51-constraints

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

Это ответ на пост про прозу жизни.

Кстати, из всего этого можно сделать следующий вывод. Он касается нашего канала по компиляторным вакансиям. В принципе, существует два вида compiler engineer-вакансий: разработка нового компилятора и поддержка существующего компилятора. И, вообще говоря, это _очень_ разные вещи, требующие различных навыков. Первый вариант может оказаться несравненно интереснее, но и значительно сложнее.

Для первого должен быть нужен ещё один универсальный навык построения софта, который живёт десятилетия. (а может быть и не нужен)

Могу сказать по собственному скромному опыту, что самое нервирующее в первом варианте — доказывать себе и окружающим, что разработка нового компилятора действительно оправдана. Что в проекте нельзя просто обойтись условным LLVM %)

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

)))) понимаю )

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

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

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

То есть, фактически, надо проработать подзадачи с самым высоким риском.

Но если у нас нет взгляда на проект с высоты птичьего полёта (см статью Дайсона Birds and Frogs), мы не можем быстро убрать тупиковые ветви в архитектуре. И проект может умереть под собственным весом.