I think there is s.th. wrong when people working on type systems can't write compilers.
I think there is s.th. wrong when people working on type systems can't write compilers.
Compilers are moving targets because hardware changes. There's a considerable maintenance upkeep in a compiler.
So if you are interested in programming language semantics, you can opt to skip the compiler part. This lets you iterate language designs without the added baggage of translating said program to machine code.
You can also argue there's no need. If you present your programming language in operational semantics, then it's trivial to write that up as a prolog program and run it on a prolog interpreter. Then you can employ a partial evaluator, and the first Futamura-projection gives you a compiler. You can choose to host your prolog program in a programming language which already has access to a partial evaluator, and you are essentially done before you even started.
[1] - https://static.aminer.org/pdf/PDF/001/006/665/partial_evalua...
It doesn't have to be production grade, just as a communication tool.
https://people.mpi-sws.org/~rossberg/1ml/
The thing is that this is a research prototype, not a real compiler. It's not usable in the same degree as a language like SML or Haskell. There is a lot more work beyond a grammar that goes into creating a compiler for a high level language.
Martin Odersky I think influenced many other mainstream languages (including Java) that picked up functional concepts and integrated them with OOP.
Pure research is fine, but being right in a vacuum usually ends up reducing the impact and value of the research (or at least postponing it).
Language and compilers are more of an applied part of science, and I think it's best if they're treated more like engineering.