I've worked in all three sectors. My experience in the federal government suggests that government jobs are clearly defined, but not necessarily easier than a corporate job. If you want to do a specific thing for the next decade, you're better of going gov. But if you want to make a lot of money and don't mind your job changing with every CEO transition, go corporate. And if you want somewhere in the middle, go non-profit.
Racket for sure, it goes straight to the heart of everything. You want simple macro compilers so you can see how simple it all is, not being confused by complex interpreters which totally obscure what is being done here.
Let D be the language used to express the gameplay, C be an implementation of a compiler for D in a language L. You want to minimise the length of D + C across all languages L. This gives you a unique language D (a DSL) for each game which is the most semantically dense and expresses the essence of the problem domain the best.
The language or languages D is discovered (not designed) and is the essence of the problem, will never change and is true in all universes. Any general purpose programming language solving the same problem (a solution using L) will have a structure of D with a bunch of boilerplate and design patterns (design pattern = boilerplate = hints at a special form in D).
Using a hierarchy of these minimal languages D with one compiling into another for each little problem is the only way to get ‘clean code’ free of boilerplate.
Software engineering is minimising D + C for all L
