Probably because most programming languages haven't changed, imperative, loops, pervasive side-effects etc. Writing a compiler for a pure functional language would certainly need new material.

> Writing a compiler for a pure functional language would certainly need new material.

I mean, Haskell is also over 30 years old at this point.

Yes, but it's changed a lot in 30 years.

On top of sibbling comment, Simon Peyton Jones seminal paper is from 1987.

He has spent the last 30 years since publishing more papers on compiling functional languages.

Mostly related to adding new features to Haskell and GHC, not on compiling functional languages in general.

Now functional logic languages like Verse, that is definitely new material.

That's selling him very short. I would say most of his papers are applicable to functional programming in general and not just Haskell.

Only for those that understand functional programming as whatever Haskell does.

No, I think it is because most problems are too hard to solve. Think a simplified case: build a compiler for evaluating arithmetic expressions like "a*3+b" and make the generated code as efficient as possible. It is an NP-hard problem!

There's been a substantial change in compiler testing since then, with high volume randomized testing coming into vogue.

Recent papers with llm Fuzzing appearing e.g. fuzz4all

We are working on projects related with cybersecurity and compilers. A reference we look at is [1] and [2]. I think we can publish the results in the coming months.

[1] https://github.com/rohanpadhye/jqf/wiki/Fuzzing-a-Compiler

[2] https://news.ycombinator.com/item?id=36373410

I disagree. The landscape has significantly evolved into incremental compilation techniques in the past decade. While theoretical developments are mostly confined into parsers, practical implementations do it across the entire pipeline, all the way to whole-program optimizations and code generation.

I'm not well versed in compiler design or implementation. But it seems to me that the target of compilers (machine code, assembly, etc.) has changed dramatically over time. The number of instructions and options on each successive processor generation seems to offer new optimizations or combinations for compilers.

That's just not true.

Just going by the new stuff that you could have taught back in 2004-2006 that you likely didn't, there's SSA construction, SLP vectorization, automatic peephole superoptimization, and that's just things I could name off the top of my head (and were papers for my qualifying exam :-P).

What hasn't changed is the compiler textbooks, which tend to have way too heavy a focus on how to build a parser generator and almost nothing on how you actually architect a compiler, let alone designing modern computer architecture. But this is a gripe which has been around for decades.

Nitpick: SSA is late 80s, early 90s tech.

I'm dating SSA from the "Efficiently computing static single assignment form and the control dependence graph" paper, which came out in October 1991; my understanding is that SSA wasn't heavily used before this technique came out.