Sure, but in combinatorics the number of atoms in the universe (say 1e80) is not a large number. For example, the factorial of 59 is larger. If you own 30 pairs of shoes, there are factorial(60) ways to arrange the individual shoes in a sequence.
To be fair, that's atoms in the observable universe.
The total size of the universe is unknown, and could (and likely does) have way more atoms than that.
Actually, that's a fun thought: assuming homogenuity of matter between the observable and unobservable universe, how much bigger would the unobservable universe need to be to render some of these claims no longer true?
Because you're right to point out that factorials grow absurdly quickly. It's entirely possible my caveat straight up doesn't matter.
Edit: Ok, I'm seeing Wikipedia has a (disputed) estimate for the diameter of the total universe as 10^10^10^128 megaparsecs. Then, radius cubed should be 1/2(10^10^10^128^3)=1/210^10^10^131, as opposed to the radius of the observable universe being a nice, clean 14 billion parsecs = 1410^3 megaparsecs, making the radius cubed 1410^4 megaparsecs.
I don't think I have a big enough calculator for this, but for fun, let's say 128^3 is roughly 2,000,000. Then we can rewrite T, the relative volume of the total universe, as 1/210^10^10^2*(10^
6). I guess if we call 14 close enough to 10, then our density is 10^80/10^6=10^74 atoms for every pi megaparsecs cubed.
Going off the heuristic that n!<n^n, and the total universe can trivially produce (10^10)^(10^10), we would need to rearrange >10^10 objects just to even start to think about the number of (megaparsecs cubed)/pi it might have, let alone the 10^74 those each have.
We might not have enough decks of cards for this one.
(Feel free to criticize/tear down my math or logic anywhere in this one, it's very much off the cuff and I'm sure I made at least as many egregious errors in computing exponents as I did computations. No math class I've taken yet really prepares you to handle exponents raised four deep.)
> The one big problem: gopls. We need the first line of the script to be without spaces...
Specifically the problem here is automated reformatting. Gopls typically does this on save as you are editing, but it is good practice for your CI system to enforce the invariant that all merged *.go files are canonically formatted. This ensures that the user who makes a change formats it (and is blamed for that line), instead of the hapless next person to touch some other spot in that file. It also reduces merge conflicts.
But there's a second big (bigger) problem with this approach: you can't use a go.mod file in a one-off script, and that means you can't specify versions of your dependencies, which undermines the appeal to compatibility that motivated your post:
> The primary benefit of go-scripting is [...] and compatibility guarantees. While most languages aims to be backwards compatible, go has this a core feature. The "go-scripts" you write will not stop working as long as you use go version 1.*, which is perfect for a corporate environment.
> In addition to this, the compatibility guarantees makes it much easier to share "scripts". As long as the receiving end has the latest version of go, the script will run on any OS for tens of years in the future.
That is 100% the issue. This is really low quality heat. Making it better would require even more energy input (e.g. a heat pump) because we can’t safely run electronics hot enough to generate high quality process heat.
> England “gave up” scientific and technological leadership during the 20th century. (That’s a tongue-in-cheek take on it, don’t read too much into it.)
Was forced to give up, due to the economic devastation of WWII, might be more accurate (though of course there were other factors too).
“A lone coder, trained in the direct manipulation of symbols—an elegant weapon from a more civilized age—-is now all that stands between humanity and darkness.” etc
reply