If you constantly pawn a task or cognitive load onto someone else (AI or not), you'll eventually get worse and worse at that particular type of thinking. Your overall mind doesn't necessarily get weaker, but you definitely start to get worse at anything you don't regularly practice.
I am a bit confused and very curious what purpose this site is trying to serve. They seem to have many articles all talking about the same concept which I think could be summarized as: "code is fungible". That is to say, the tests, specifications, and other supporting documentation are the truly important pieces of a system. The code part is easily replaceable. Every article on the site is about that concept in some way.
Human language is imprecise and it seems to be a common thought on HN that it is impossible to clearly and completely define the requirements of a sufficiently complex system of software without, well... writing the software. I just don't see a scenario where The Phoenix Architecture would actually make sense.
> The deletion test is not a recommendation. It’s a diagnostic.
> That’s not robustness. It’s entanglement.
> This isn’t a tooling fad. It’s an economic shift.
I have a strong feeling this article would survive regeneration well.
AI says many true things. That doesn’t mean I want to read someone else’s AI generated output. I want something in the article to show that the author spent more time writing than I will spend reading, and by a wide margin, or else I know they feel that my time is not valuable.
In 2020 Netflix claimed they would start to automatically cancel inactive accounts [1], but the post has since disappeared. I also remember Microsoft saying the same thing about Xbox Game Pass but have not searched for their statement.
As someone with no real-world petrochemistry experience, but much gaming experience, I was very surprised how familiar the crude oil processing diagram looks. Factorio and GregTech are two prime examples of fairly realistic oil processing lines (probably as accurate as any game would reasonably try to be).
I was thinking the same thing! Having played through Factorio and a fair amount of GregTech really reframed my viewpoint on energy production that a huge part of the benefit of fossil fuels is the byproducts, not just raw energy output.
I'm trying to understand what you mean by this. Are you saying they're "bad" in terms of resolution, or artistic value, or something else? They seem good enough (far from "bad") by any definition I can think of.
`9↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑9` seems like a reasonable guess (barring encoding cheats/trickery like @masfuerte commented!)
Edit: I've misread the above comment and my number is is 64 bytes (significantly more than 64 bits. The largest 64 bit number through my approach would be `9↑↑↑↑↑↑9`, which is significantly smaller.
I can do you one better and specify that the normal base-2 integer represented by the bits is the number of up-arrows. But as /u/tromp has already pointed out, that is not very interesting.
In terms of the Fast Growing Hierarchy, it's about f_62(9) or what the article would denote as [62] 9. It's way smaller than Graham's Number, which involves 64 iterations of mapping n to 3 ↑↑↑... {n uparrows) 3, whereas this expression has between 1 and 2 iterations.
If every atom in the universe had a universe inside each proton, there still wouldn’t be enough atoms within all the universes in the protons. In fact you might not make it to four arrows with the above lol
Fun to see you here - I discovered this game through your videos! I think despite the lack of raw "content", I got a LOT of playtime out of this game by trying to push higher on the leaderboards.
I've considered trying to do some hyper optimisation, taking into account the number of cycles each instruction takes - it seems that a lot of people are interested in that.
That's not my natural style though. I've had plenty of criticism for not being performance sensitive, but that's not really how I unwind (although I do plenty of optimisation at work!).
