> And there's rarely any good stuff on the actual hard problems
So what are those hard problems?
So what are those hard problems?
Types, type inference, function implementations, error handling and recovery, incremental compilation, interfacing with the external world, code generation, fixing problems in code generation tools, CPU architecture concerns...
The toy languages that most learning materials make can be parsed with regexps and is definitely not something to spend a lot of time on at the beginning.
Because actual parsing problems are never addressed in these materials, and can come later (example of concerns: https://matklad.github.io//2018/06/06/modern-parser-generato...).
Isn't that intimately tied to parsing?
I mean, how do you expect to implement a parser if you have no idea if a specific programming construct can actually be parsed, or what are the implications in compilation time of doing things one way or another?
Not entirely
> how do you expect to implement a parser if you have no idea if a specific programming construct can actually be parsed
Every construct can be parsed.
However, there are significantly more aspects to language design than "parsing programming constructs". For example, C++ header/implementation split with no real module system affects compilation orders of magnitudes more than the parsing rules for C++.