As someone who lived in a handful of countries with GDP per capita ranging from $3k to $70k I must say that GDP is a great proxy of the QoL and median citizen wealth. Not the only one and not the perfectly correlated one, but a very good one.
Indeed. "Science-based" lifting become quite popular in the recent years, but the actual science behind it is quite loose with a lot of methodologically weak studies, small samples etc.
Tcc even supports that with `#!/usr/local/bin/tcc -run`, although I don't understand people who use c or go for "scripting", when python, ruby, TCL or perl have much superior ergonomics.
This was a relatively old project that used a C program as build system / meta generator. All you needed was a working C compiler (and your shell to execute the first line). From there, it built and ran a program that generated various tables and some source code, followed by compiling the actual program. The final program used a runtime reflection system, which was set up by the generated tables and code from the first stage.
The main reason was to do all this without any dependencies beyond a C compiler and some POSIX standard library.
That's ridiculous. DB is not even trying to become profitable, not is there any evidence that it's sole shareholder, aka the government, sets it as a target.
Well apparently they have been somewhat profitable from 2016 to 2019, and they have been paying a dividend to the state more often than not. I don't think their goal is actively loosing money?
My biggest gripe with DB is not that it's late, but that it quite often cancels the trains. If you decided to go by regional trains with 1-2 hops instead of direct (bc you can go much cheaper with Deutschlandticket), there's a high chance that at least one of your trains get cancelled and things will not go according the plan.
> Most of the whining I've heard about DB boils down to inconvenience in situations nobody could have predicted nor helped
Somehow doesn't happen in most other countries I lived. These things are easy to deal with with a bit of redundancy, which as I've heard is lacking in Germany these days.
I've had much better experience with trains in Russia despite much harsher weather conditions, much larger distances and much older cars. This problem is absolutely fixable, just let the trains go around problematic sections with redundant routes.
That's true, but at this point I would prefer slow but steady over being disembarked at random *dorf or standstill in a middle of nowhere with zero signal and no clue when we'll get back on track.
> Rather than getting stuck in front-end minutiae, the tutorial goes straight to generating working assembly code, from very early on.
I think this is important and for a more sophisticated compiler design I find Ghuloum approach very appealing [1]. I.e. build a very simple subset of the language from top to bottom and then grow the meat gradually.
The really great book following this approach I've discovered recently was [2]. Although I find both C and x86 not the best targets for your first compiler, still a very good book for writing your first compiler.
Yeah, I think this is one of the (few, rare) cases where the "official" academic way of teaching the subject is actually baggage and not really aligned with what's practically useful.
Compiler courses are structured like that because parsing really was the most important part, but I'd say in the "modern" world once you have a clear idea of how parsing actually works, it's more important to understand how compilers implement language features.
Even if you want to implement a compiler yourself, "Claude, please generate a recursive descent parser for this grammar" is close to working one-shot.
> Even if you want to implement a compiler yourself, "Claude, please generate a recursive descent parser for this grammar" is close to working one-shot.
How is this even close to implementing it yourself ??? If Claude gave you the code, by definition, you didn't implemented it yourself - you hired a third party to implement it for you.
This is something I've noticed on academic vs "practicing" coders. Academics tend to build in layers, though not always, and "practicing" coders tend to build in pipes give or take. The layers approach might give you buildable code, but is hard to exercise and run. Both approaches can work though, especially if you build in executable chunks, but you have to focus on the smallest chunk you can actually run.
I'd argue the opposite. Nora's approach demonstrates that simple ideas work great for getting half of the problem done, but can make it impossible to finish the second half.
But in case of layoffs you will be kicked out first and he would be kicked out the last and with a far better severance package.