Actually this is true whichever interpretation you take, give or take some knowledge around black holes.
I think hawking actually proved that this is true regardless of how black holes work due to hawking radiation.
Mr. G! I was just looking back at Robby the Robot stuff from my time at skyline! You should email me so we can catch up! Pick nearly anything at my lastname dot com to reach out!
It is the case that particles always try to settle into the lowest energy, and the more options they have the faster. We may be able to engineer places where they're stable, like in the example from my grandparent of a neutron. They are unstable since their mass is greater than the mass of a proton and an electron combined, but they're stable in all common elements we're used to. So much so that we think of radioactive elements as the exception, but (mostly) all that's happening there (in beta decay) is a neutron decaying.
I'm not an expert, but I'd imagine making a stable situation for a heavier particle much harder than just making an atom, and the fine grained control is even hard still.
I also recently(~1 month) purchased one of these, (DIY edition + windows). So far my only complaint is the screen size. I was really wanting a 17" touch screen and a keyboard with a num pad. My first thought when I was opening + working with this was that the whole experience felt like a labor of love.
I actually work in a table oriented language, harbour, a child of clipper/xBase mentioned in the article. There are a few issues I've found with a table oriented architecture:
1. Managing state is a bit of a nightmare. Harbour is based off of DBF databases, which are essentially flat files of a 2d array, and keeps your record number within any given db. You can then query a field with the arrow operator (table->field) but you have no guarantee that any subfunction is not changing state.
2. DBMS lock in. Because you're operating is totally different paradigm moving dbs is actually rather challenging. Harbour has a really nice system of replaceable database drivers(rdd), but when your code is all written assuming movement in a flat file, switching to a SQL based system is challenging. I'm currently in the process of writing a rdd to switch us to postgres, but translating the logic of holding state to the paradigm of gathering data then operating on it in an established code base is quite a challenge.
I am mind-blind in every sense, yet I got a 9/10 on that. It's still only checked by qualitative things, how a person self reports about it. I know it's not just a language thing though. My go to example is that if you knew morgan freedman wrote this you could read it in his voice in your head. I can't, I'd recognize his voice, but I can't use it in my head.
A (not)compiler can be made to look for issues in your codebase that already exists. It would need all the tools of a compiler, just that the target is the same as the source language.