PL Theory makes you start looking at everything like a PL problem. APIs become little languages, and rich APIs become larger ones. Parsing becomes trivial, lexing even moreso, and everything sort of devolves into thinking about interpreter state. Then it gets frustrating because you can't just pick up the API interactions and rewrite them more-efficiently, and you end up chasing your own tail wishing you could.<p>I think it's made me a better programmer, but it must be tempered by understanding the limitations of how and when languages are worth building.
This is an 84 minute audio file. Direct download link is here: <a href="https://www.typetheoryforall.com/episodes/episode29.mp3" rel="nofollow">https://www.typetheoryforall.com/episodes/episode29.mp3</a><p>I didn't listen to it (I prefer reading) but yeah, if you're using typed languages, understanding some PLT can help quite a lot. Harper's PFPL book is a fairly accessible text, somewhere between the Haskell Wikibook and truly pointy headed texts in terms of accessibility: <a href="https://www.cs.cmu.edu/~rwh/pfpl/" rel="nofollow">https://www.cs.cmu.edu/~rwh/pfpl/</a><p>The Little Typer is supposed to also be good, but I haven't yet tried it.
I love myself a good language. But! It’s very, very easy to get pulled into the puzzle solver mindset, I’ve seen people become obsessed and forgetting about balancing the goals of the puzzle solving with the real-world goals. It’s so satisfying to say “look, $bad_thing *cannot even be expressed* in this language!” that it’s easy to forget that there are diminishing returns all while the complexity cost increases exponentially.<p>Personally, I find the sweet spot for most problems somewhere between JavaScript hippie and Rust[1] tyrant. A bit of basic types can go a long way, just some interfaces or struct fields that are guaranteed to exist of a certain type. Helps with autocomplete and typos too! The missing pieces can be annoying to the soul, but rarely constitute a terminal decease in practice.<p>[1]: You can use Rust in different dialects, here I’m talking about the most correct- and performance-obsessed flavor (think no dynamic dispatch, only static borrowing etc).
Learning programming language theory and then putting it into practice by writing a compiler will 100%, without a doubt in my mind, make you a better software engineer. This is because you will have to put many complex systems into working and coordinated order to have a working compiler, even if you use something like LLVM. And you will get a better understanding of a fundamental aspect of computer science: modeling ideas into a language and then directly speaking that language.
Maybe but you can say the same thing about learning almost anything new which is related to software. And since you have limited time and attention, $x making you a better engineer isn’t enough, it has to be better than the alternatives. Or you can do it just because you’re interested but in that case who cares whether it makes you a better engineer at all.
It helps learning new languages (but doesn’t help much learning how to use their libraries etc) and forces you to learn a lot of useful techniques.<p>But it can became a rabbit hole if you try to approach everything as a language problem with over general solutions.