wuuwoo

I wholeheartedly disagree. Compiler engineering is ultimately about taking data in one representation and converting to another, in practice much of the job is figuring out what data you need to have access to in order to perform a transformation and test that it is sound - the plumbing is usally uninteresting and straightforward.

Code generation and optimization are just the task you're trying to complete, the actual implementation of it is not so different from most SWE grunt work. But many of the abstractions you build when trying to do it are useful to understand and use in practice everywhere you right software.

If you've ever worked on an application that ingests data and spits out meaningful output, you've written a compiler. Failing to understand the shared abstractions is not good engineering.

Any analysis would be less than insightful unless it comes from someone who sat in the meetings and helped write the standard.

FWIW Bluetooth isn't "terrible." It's pretty remarkable we can get all sorts of devices to communicate with eachother wirelessly and at low powers with pretty decent bandwidth. And now you can buy a Bluetooth stack on a chip from a variety of vendors.

The bigger issue with Bluetooth is that failure conditions are mostly an afterthought by device manufacturers, and Bluetooth is becoming a sought after feature in environments less than tolerable to failure like automotive and medical devices.

Some stuff not to forget

- Calculate your trace widths (based on heat/current requirements and copper weight - there are online calculators that do fine).

- USB data lines require controlled impedances, check your fab for a trace width calculator.

- Don't forget via sizes, the default in your CAD tool is probably too small

- Check your fab for their design rules instead of using rules of thumb

- 4 layer boards are cheap enough for hobbyists today, don't be afraid of them