I mean how should I know? The point is that I suspect there could be another option, which is that the pressure hull could have failed without imploding.
So, yes it seems insane, and having seen pictures which look both like that is a liner and ones where it looks like its not, I don't know. There is very clearly an outer shell offset from the pressure hull. Whats on the inside isn't as clear, but I'm not sure why they would be running cables out of the floor when they could just be running them out closer to the arm/etc if there is space behind.
Although from a human comfort perspective, I'm not sure why there isn't a little foot well/bench either. There is obviously stuff under the floor, but it also looks fairly hollow too.
No. I know what DI is. The debate is similar to imperative vs. OOP. But this is not exactly what I am referring to. Literally look at the second example, it's DI over and over and over again.
I am referring to DI 100%. Function composition works better and is a replacement for DI. You're the one that isn't getting it.
Either way, imperative programming and OOP are orthogonal concepts. There never really was an argument about imperative vs. OOP.
Additionally function composition is an FP concept. I'm not promoting FP over OOP here... far from it, I am simply saying that specifically for DI, you can borrow a pattern from FP and use it in place of DI because function composition is a much better pattern.
Not sure why the author decides to single out DI frameworks as a problem. In most cases DI is just an implementation detail for how the framework serves up its abstraction layer over the underlying mechanisms. For example, Spring is built around injecting beans so it can wrap them in proxies which provide transaction managements, security, etc. Sounds like he's really just criticizing frameworks in general.
On the topic of DI, it's such a simple and common-sense design "pattern" that it shouldn't even have a buzzword label. All it means is that, given service A which uses service B, it's not service A's job to instantiate B and provide B with its required sub-dependencies (DataSource, config params, etc). A should only consume B without concerning itself as to how B was created in the first place. This is usually handled by some "container" service whose job is to build-up every other service and make them accessible to one another so they may be strict consumers without transitive dependencies.
There's a hundred ways to mask your selling identity, this law won't change anything except, as usual, placing more bureaucratic baggage on honest sellers.
It really is stupefying how Amazon has turned into a dumping ground for cheap chinese junk. Surely they realize the long term damage they're causing to their own brand?
At the same time, they're constantly tightening KYC and other regulations which only hurts honest small-time merchants.
