A lot of it is anorexia by another name. There is a subspecies that involves compulsive exercise. Doing lots of athletics without proper nourishment is a good recipe for low performance and injury.
Literally my first thought after reading this training log excerpt:
> 10/4/2012: I’m really trying to be conscious right now about losing some worthless snack weight… Need to be more diligent, take action, get fucking after it, and restore the body and the mind!
"worthless snack weight" sounds very similar to epithets that anorexic people often use.
This sort of thing seems to have really fallen off after the Grand Theft Auto "Hot Coffee" scandal. Having hidden stuff in a game went from being a fun thing to a potential liability.
1. I think it's more about microtransactions than Hot Coffee. Why put cheats for free if you can monetize them.
2. Cheats don't make sense in the age of abundance of games. Previously you'd have 3 games on your PC and you'd try to extract as much fun out of them as possible, so you'd just dick around and do silly stuff, and cheats were helpful in that. Now most gamers literally have a backlog of games, there's no time for that style of gameplay. You're done with the campaign, next game.
3. "Fun" has always been a liability, it's just that previously companies saw that as cost of doing business while nowadays all risks need to be avoided. Doing borderline illegal marketing campaigns was actually normal for many companies. When Burnout 2 was being released in 2002, Acclaim wanted to reimburse speeding tickets in the UK. Think about it for a second.
4. Children playing a literal gang member simulator with all types of violent crimes built in? Business as usual. Penis into vagina? That's a step too far you monster! I never really understood this moral panic about sex. In Europe GTA games are labeled 18+ so Hot Coffee scandal was contained to last pages of video game magazines.
I think the other big thing that killed in game cheats and debug screens was Xbox and Steam Achievements/PlayStation Trophies. Some of the "value" in such tokens of game completion are the "skill checks" it takes to complete them. If a game provides cheats inside of it, it either needs to disable those Achievement systems, or it loses the ability to unlock them, and that's platform enforced by Xbox/Steam/PlayStation. So it's easier for most games to just not include cheats so they don't have to worry about accidentally violating platform terms on Xbox/Steam/PlayStation should players discover and "abuse" the cheat systems.
Similarly PC games with mod support often have to disable Achievement systems as soon as any mod is installed just in case the mod happens to offer cheats. Which also seems to have impacted mod culture to some extent with entire classes of gamers not installing mods ever to make sure that they still win Achievements.
It's an interesting social dynamic and I think one of the clearest lines in the sand for when cheat codes disappeared, especially in genres like the FPS where "God Mode" and "noclip" codes were genre staples until Achievements. (Because DOOM offered them, every FPS offered them. Until they stopped.)
PC games don't have to do this. Steam doesn't have a policy that achievements must prevent cheating. This is entirely a developer choice.
The main reason cheats have disappeared from mainstream games is because many of them prefer to sell them to you as micro-transactions, item pack DLCs, etc.
Steam has the weakest enforced terms of all the three that I mentioned, but it does have terms in its contract with developers for how Achievements are supposed to unlock.
But most "triple A" games don't just release under Steam's weaker terms, they also want Xbox and PlayStation certification, which have been strongly enforced.
I don't know how common it is, but Control (PS4 era) has an extensive cheat system accessible from the options menu, and Saros (PS5 era) has a wide variety of settings to make the game more or less difficult.
Yeah, I think overall it is trending better again, with the strictest terms being the Xbox 360/PS3 era. (Especially under the banner of Accessibility.)
Celeste (a difficult 2D platformer) has accessibility options that include invincibility, no fall deaths, etc. At least on Xbox using them does not turn off achievements, so I thought the choice to do so was left to the developers.
Yeah, it is starting to become more acceptable again, which is great. I think the "accessibility options" phrasing has been a key to why Xbox relaxed a lot of their earlier, harher standards on it. Which is a great thing, I appreciate Xbox's commitment to accessibility in the last several years as it has done some neat things.
Yeah I remember when Hot Coffee happened I was working at a studio owned by THQ and a message came down from the executive level basically warning us not to put in anything hidden like that. All secrets had to be disclosed and known by the executive team. Something like that anyway.
My theory is that it's more boring. Debugging tools got better where those were the ways to work around and get to testing stuff in old console era.
But now game development has much better tooling and SDK kits for a while in consoles. So I suspect there wasn't a need to spend extra development cycle implementing custom debug menus and stuff.
My theory is that cheat codes disappeared when developers discovered that they could have their effects as microtransactions instead, and then they just never came back because, as you say, SDKs are pretty good about not needing them.
While I understand why they would want to avoid that scandal happening, it's really ludicrous that it was ever a scandal. Murdering tons of innocent people and committing all sorts of crimes is totally fine to depict, but god forbid you show sex.
Over the last 20 years, much of the major game industry has become yet another 'project management' pipeline rather than a creative art, to where at most an 'easter egg' for a non indie title is most likely the result of some story on the board to include a 'throwback to other title' type nod.
Indie games still often have their own easter eggs or hidden scenes, even the more polished ones (Selaco comes to mind) so that's where I base my thoughts.
"Hot Coffee" wasn't even an easter egg, it was something you got to through the normal in-game dialog in the dating minigame. You're treated to watching two polygonal adults dry-humping each other fully clothed, and for this one publicity-seeking soon-to-be-disbarred lawyer got the country clutching its collective pearls for a moment.
I'm pretty sure the industry and the general public are long over it. It's just that AAA game production has become such an assembly-line industrial corporate process that no one involved has the independence or remaining soul to write such things anymore.
Anecdata, but an acquaintance of mine struggled with lifelong anorexia. Severe enough that he was hospitalized a few times. With great effort he could cling to the bottom of the "normal BMI" range, but his life was generally ruled by the eating disorder - he couldn't have meals with people, he had to do various exercise rituals.
He was an early participant in one of these psychedelic studies a few years ago. After the first treatment, he said he couldn't really tell if it had any effect. But six months later, he was totally changed - able to function almost normally.
We should exercise our usual amount of skepticism about miracle treatments, but my hope is that his experience can be replicated.
Science generally works on IF Then statements when it comes to treatment, IF you take this drug your blood pressure will increase, IF you exercise more your life expectancy will increase, with mental health issues there very few IF then treatments, there are only if maybe treatments, this is for a slew of reasons such as how we don't really understand it, symptoms can be caused by many different underlying issues, and legal risk of prescribing something that isn't proven effective. That being said, the IF maybe treatments are the only way to treat mental health, Psilocybin falls in this category.
Just about all common psychological medication (by which I mean antidepressants, antipsychotics, ADHD meds, etc) have a pretty weakly measurable effect and effectiveness. If you take them, your symptoms might improve. In some casesthey'll get a lot worse. In many cases it will have no effect on your symptoms. There are lots of side effects.
Debt-to-GDP ratio is useful for comparing the debt loads of two countries, but not terribly useful in assessing the serviceability of debt for a single country.
That is, suppose two countries both have $100B in debt. One of them is a small island nation; the other is a global superpower. Obviously the global superpower will be better able to handle that - dividing by GDP helps make that clear.
However, this simple division doesn't tell you some important things. How much of the debt comes due very soon? It's worse if the answer is "most of it." How was it incurred? "Winning a war" is much better than "losing a war."
The United States has lots of debt, and personally I'm worried about the long term serviceability of it. But the ratio to GDP isn't why!
(1) is equivalent to "typedef long* $(void*, ...)". '$' is the name of the defined function type.
it's obfuscated as follows:
- typedef is a specifier and can go on either side of the type, same as int const/const int
- [[ ]] is an empty list of attributes
- "void*($)" is an argument named '$' of type void*, but parameter names are ignored in declarations.
- you can put parens in declarations since sometimes you need to group prefixes and postfixes in a different order
- dollar signs in names are allowed in many c compilers (and some other c-like languages)
- "..." are variadic arguments. puts doesn't have those, but the first argument uses the same register either way so it happens to work out in this case
(4) declares a function named '$' of type '$', shadowing the type, and links it to the assembly label "puts". calling $ calls puts.
normally it looks like `int call_foo(void) asm("foo");`
(5) is parsed as: "label $: address-of-label $ and function $ called on str. the address of a label is truthy, so the function also gets called.
unary && looks for the argument in the label namespace, but other operators don't, so the two dollars refer to different things.
that's about it. if you're familiar with the c standard and some common gnu extentions, you can deconstruct the examples into their basic elements easily enough
What do you mean? It's just simple beginner's examples in C. Should be easy enough to understand, C is famously very simple ('portable assembler' as they say!).
> In our experience, C has proven to be a pleasant, expressive and versatile language for a wide variety of programs. It is easy to learn, and it wears well as one's experience with it grows.
I've reported a few very serious issues to vendors of widely used tools in recent weeks, and it's been even more difficult than usual to get them to be acknowledged - the teams that respond are reportedly swamped.
The developer of this tech demo also worked on porting Resident Evil 2 to Nintendo 64. This was quite the challenge - two discs worth of content had to be made to fit onto a single cart.
LLMs are very good at understanding decompiled code. I don't think people have updated on the fact that almost everything is effectively open source now!
Being able to read some iteration of potential source code doesn’t make it open source. Licensing, copyright, build chains, rights to modify and redistribute, etc are all factors.
I'm sympathetic to this view, but I also wonder if this is the same thing that assembly language programmers said about compilers. What do you mean that you never look at the machine code? What if the compiler does something inefficient?
Compilers are deterministic. People who write them test that they will produce correct results. You can expect the same code to compile to the same assembly.
With LLMs two people giving the exact same prompts can get wildly different results. That is not a tool you can use to blindly ship production code. Imagine if your compiler randomly threw in a syscall to delete your hard drive, or decide to pass credentials in plain text. LLMs can and will do those things.
Even ignoring determinism, with traditional source code you have a durable, human-readable blueprint of what the software is meant to do that other humans can understand and tweak. There's no analogy in the case of "don't read the code" LLM usage. No artifacts exist that humans can read or verify to understand what the software is supposed to be doing.
yeah there is. it's called "documentation" and "requirements". And it's not like you can't go read the code if you want to understand how it works, it's just not necessary to do so while in the process of getting to working software. I truly do not understand why so many people are hung up on this "I need to understand every single line of code in my program" bs I keep reading here, do you also disassemble every library you use and understand it? no, you just use it because it's faster that way.
What I mean is an artifact that is the starting point for generating the software. Compiled binaries can be completely thrown away whenever because you know you have a blueprint (the source code) that can reliably reproduce it.
Documentation & requirements _could_ work this way if they served as input to the LLMs that would then go and create the source code from scratch. I don't think many people are using LLMs this way, but I think this is an interesting idea. Maybe soon we'll have a new generation of "LLM-facing programming languages" that are even higher level software blueprints that will be fed to LLMs to generate code.
TDD is also a potential answer here? You can imagine a world where humans just write test suites and LLMs fill out the code to get it to pass. I'm curious if people are using LLMs this way, but from what I can tell a lot of people use them for writing their tests as well.
> And it's not like you can't go read the code if you want to understand how it works
In-theory sure, but this is true of assembly in-theory as well. But the assembly of most modern software is de-facto unreadable, and LLM-generated source code will start going that way too the more people become okay with not reading it. (But again, the difference is that we're not necessarily replacing it with some higher-level blueprint that humans manage, we're just relying on the LLMs to be able to manage it completely)
> I truly do not understand why so many people are hung up on this "I need to understand every single line of code in my program" bs I keep reading here, do you also disassemble every library you use and understand it? no, you just use it because it's faster that way.
I think at the end of the day this is just an empirical question: are LLMs good enough to manage complex software "on their own", without a human necessarily being able to inspect, validate, or help debug it? If the answer is yes, maybe this is fine, but based on my experiences with LLMs so far I am not convinced that this is going to be true any time soon.
Not only that but compiler optimizations are generally based on rigorous mathematical proofs, so that even without testing them you can be pretty sure it will generate equivalent assembly. From the little I know of LLM's, I'm pretty sure no one has figured out what mathematical principles LLM's are generating code from so you cant be sure its going to right aside from testing it.
I write JS, and I have never directly observed the IRs or assembly code that my code becomes. Yet I certainly assume that the compiler author has looked at the compiled output in the process of writing a compiler!
For me the difference is prognosis. Gas Town has no ratchet of quality: its fate was written on the wall since the day Steve decided he didn't want to know what the code says: it will grow to a moderate but unimpressive size before it collapses under its own weight. Even if someone tried to prop it up with stable infra, Steve would surely vibe the stable infra out of existence since he does not care about that
or he will find a way to get the AI to create harnesses so it becomes stable. The lack of imagination and willingness to experiment in the HN crowd is AMAZING me and worrying me at the same time. Never thought a group of engineers would be the most conservative and close minded people I could discuss with.
It's a paradox, huh. If the AI harness became so stable it wrote good code he wouldn't be afraid to look at the code he would be eager to look at it, right? But then if it mattered if AI wrote good code or not he couldn't defend his position that the way to create value with code is quantity over quality. He needs to sell the idea of something only AI can do, which means he needs the system to be made up of a lot of bad or low quality code which no person would ever want to be forced to look at.
Wait till you meet engineers other than sw engineers. Not even sure most sw people should be called engineers since there are no real accredited standards.
I specifically trained as EE in physical electronics because other disciplines at the time seemed really rigid.
There's a saying that you don't want optimists building bridges.
The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. It also doesn't involve any "creativity": a compiler is mostly translating a high-level concept into its predefined lower-level components. I don't know exactly what my code compiles to, but I can be pretty certain what the general idea of the assembly is going to be.
With LLMs all bets are off. Is your code going to import leftpad, call leftpad-as-a-service, write its own leftpad implementation, decide that padding isn't needed after all, use a close-enough rightpad instead? Who knows! It's just rolling dice, so have fun finding out!
> The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice.
That's barely true now. Nix comes close, but builds are only bit-for-bit identical if you set a bunch of extra flags that aren't set by default. The most obvious instability is CPU dispatch order (aka modern single computer systems are themselves distributed, racy systems) changes the generated code ever so slightly.
We don't actually care, because if one compiled version of the code uses r8 for a variable but a different compilation uses r9 for that variable, it doesn't matter because we just assume the resulting binary works the same either way. R8 vs r9 are implementation details that don't matter to humans. See where I'm going with this? If the LLM non-deterministically calls the variable fileName one day, and file_name the next time it's given the same prompt, yeah language syntax purists are going to suffer an aneurysm because one of those is clearly "wrong" for the language in use, but it's really more of an implementation detail at this point. Obviously you can't mix them, the generated code has to be consistent in which one it's using, but if compilers get to chose r8 one day and r9 the next, and we're fine with it, why is having the exact variable name that important, as long as it's being used correctly?
I’ve done builds for aerospace products where the only binary difference between two builds of the same source code is the embedded timestamp. And per FAA review guidelines, this deterministic attribute is required, or else something is wrong in the source code or build process.
I certainly don’t use all compilers everywhere, but I don’t think determinism in compilation is especially rare.
No, some compilers aren't deterministic by design, e.g. because they compile stuff in parallel and don't take extra steps to enforce consistent ordering of things (because it doesn't matter).
We can tell you weren't around for the advent of compilers. To be fair, neither was I since the UNIX c compiler came out in '68 and was by far not the first compiler. Modern comilers you can make that claim about, but early compilers weren't.
I've been programming since 6502/6510 assembly language and all compilers I've used were deterministic (which isn't the same thing as being bug free or producing the correct output for a given input).
All compilers have bugs. Any loss of semantics during compilation would be considered a bug. In order to do that, the source and target language need to be structured and specified. I wasn't around in the 60s either, but I think that hasn't changed.
This analogy has always been bad any time someone has used it. Compilers directly transform via known algorithms.
Vibecoding is literally just random probabilistic mapping between unknown inputs and outputs on an unknown domain.
Feels like saying because I don't know how my engine works that my car could've just been vibe-engineered. People have put 1000s of hours into making certain tools work up to a give standard and spec reviewed by many many people.
"I don't know how something works" != "This wasn't thoughtfully designed"
No, it is not what assembly programmers said about compilers, because you can still look at the compiled assembly, and if the compiler makes a mistake, you can observe it and work around it with inline assembly or, if the source is available, improve the compiler. That is not the same as saying "never look at the code".
>but I also wonder if this is the same thing that assembly language programmers said about compilers
But as a programmer writing C code, you're still building out the software by hand. You're having to read and write a slightly higher level encoding of the software.
With vibe coding, you don't even deal with encodings. You just prompt and move on.
I've wondered if people who write detailed specs, are overly detailed, are in a regulated industry, or even work with offshore teams have success more quickly simply they start with that behavior. Maybe they have a tendency to dwell before moving on which may be slightly more iterative than someone who vibecodes straight through.
