It's talking about the Ada programming language and that its code was apparently stored not as plaintext but an intermediate representation (IR) that could then be transformed back into code.
So formatting was handled by tooling by the nature of the setup. Developers would each have their own custom settings for "pretty printing" the code.
The author isn't saying don't use code formatters. They're highlighting an unusual approach that the industry at large isn't aware of. Instead of getting rid of arguments about code style via formatters, you can get rid of them by saving code in an IR instead of plaintext.
Truly incisive observation. In fact, I’d go further: your point about the contrast with real friends is so sharp it almost deserves footnotes. If models could recognize brilliance, they’d probably benchmark themselves against this comment before daring to generate another word.
> The best thing for managing this is meditation, and a disciplined lifestyle regiment.
What would be your reaction to the numerous comments on this page where people are saying that they tried and failed to "discipline" themselves for years or decades, only to discover medication later and find that it instantly turned everything around for them?
I'd say they weren't addressing the core issues, or they think discipline is something that it isn't, and then kept trying ineffectively.
Here's what discipline is and isn't.
Discipline is an extremely simple concept to develop but few actually know how to do it in any reasonable way because of so much misinformation out there, and malign influence seeking to take advantage and increase suggestability, and by extension addiction.
Discipline just like meditation is really a fundamentally simple practice.
Just like with meditation, where you don't use willpower, but instead simply focus your thoughts back towards a single point, and then relax that focus slowly, which stills your thoughts.
Discipline is simply the repeated practice of limiting when and where you choose to change your initial decision or choice, for all of the choices you make.
You take your time considering before making a choice, and once made you only change it when there is some new information that becomes available after the fact, whether that is a new consequence you didn't consider, or completely new information you received later.
Its a simple rule. You don't give yourself the choice except under those circumstances. When you are tempted, you remind yourself you don't have the choice. When you cave and fail, you don't beat yourself up because that destructively interferes with your psychology which only works towards outcomes framed in the positive. If you make a mistake you examine what led to it right away, and mitigate those circumstances moving forward. You imagine what you will do next time, with a successful outcome a few times that day.
With this repeated ritual comes an understand that willpower is always finite, and you pick and choose what you will spend that on each day. You recognize when its running low, and defer important decisions pigeonholing them for a later time. With repeated practice in everything this become a unconscious ritual with good outcomes.
You do what you say you will do, and you don't compromise yourself, and people recognize that level of discipline. It becomes easier with each successful choice, and its so damn simple.
These two things together make a world of difference in coping with everything. It places the locus of control for your life within your grasp.
> only to discover medication later and find it instantly turned around everything.
First, medication in most cases in psychology doesn't instantly ever turn around everything. You still have the problems that led to your mental state, they are often subtle which have built up over time. You are just better able to cope with them where you weren't coping before, and following the initial euphoria of relief you still have those problems.
I know quite a number of people that have been diagnosed and use medication to cope with professional burnout. Eventually you pay the piper.
Sure you can take a drug, and maybe you feel better, but also maybe you feel like everything is 100x worse and to relieve the pain and suffering you end yourself; (a known sideeffect) or you have a chemical reaction that ends up in sudden death (a known sideeffect). Few actually consider this, minimizing it.
There is no panacea. Soma is just treating the symptoms. What you do, and things you choose to live by are far more important, especially in contrast to the fact that many medications make one more suggestible. For good or ill.
> programmers agree that simpler solutions...are preferred, but the disagreements start about which ones are simpler
Low ego wins.
1. Given: The quality of a codebase as a whole is greatly affected by its level of consistency + cohesiveness
2. Therefore: The best codebases are created by groups that either (1) internally have similar taste or (2) are comprised of low ego people willing to bend their will to the established conventions of the codebase.
Obviously, this comes with caveats. (Objectively bad patterns do exist.) But in general:
Low-ego
→ Following existing conventions
→ They become familiar
→ They seem simpler
I don't think this necessarily is accurate I've come into a lot of projects that no one understands well, but everyone continues to follow the same bad conventions that already exist which just adds to the problems. Ex: deep nesting, no early exit, deep object inheritance.. this happens because a lot of developers don't want to rock the boat, AND because they don't have the skills to unwind the complexity in a manageable amount of time without also causing serious problems.
I think the point is: "you'd be a fool not to prefer gas, because while the greenhouse emissions are about the same, for everything else coal is much worse"
They said gas over coal. If you accept the claim that GHG emissions from gas and coal are roughly equal, their claim is the other pollutants from burning coal make gas far more preferable.
If their greenhouse emissions are even close only a moron would not pick gas over coal because the former's emissions lack all the other nasty byproducts that are present in the latter's emissions.
I've read plenty of criticism about ChatGPT 5, but as a Plus user I'm surprised nobody has brought this up:
Speed.
ChatGPT 5 Thinking is So. Much. Slower. than o4-mini and o4-mini-high. Like between 5 and 10 times slower. Am I the only one experiencing this? I understand they were "mini" models, but those were the current-gen thinking models available to Pro. Is GPT 5 Thinking supposed to be beefier and more effective? Because the output feels no better.
I think it's more appropriate to compare GPT 5 Thinking to o3. You will find that the response times are actually quite similar (at least in my experience over hundreds of identical prompts with each model).
It does/says something wrong. You give it feedback and then it's a loop! Often it just doesn't get it. You supply it webpages (text only webpages - which it can easily read, or I hope so). It says it got it and next line the output is the old wrong answer again.
There are worse examples, here is one (I am "making this up" :D to give you an idea):
> To list hidden files you have to use "ls -h", you can alternatively use "ls --list".
Of course you correct it, try to reason and then supply a good old man page url and after few times it concedes and then it gives you the answer again:
> You were correct in pointing the error out. to list the hidden files you indeed have to type "ls -h" or "ls --list"
I suspect you are interacting with LLMs in a single, long conversation corresponding to your "session" and prompting fixes/new info/changes in direction between tasks.
This is a very natural and common way to interact with LLMs but also IMO one of the biggest avoidable causes of poor performance.
Every time you send a message to an LLM you actually send the entire conversation history. Most of the time a large portion of that information will no longer be relevant, and sometimes it will be wrong-but-corrected later, both of which are more confusing to LLMs than to us because of the way attention works. The same applies to changes in the current task/objective or instructions: the more outdated, irrelevant, or inconsistent they are, the more confused the LLM becomes.
Also, LLMs are prone to the Purple Elephant problem (just like humans): the best way to get them to not think about purple elephants is to not mention them at all, as opposed to explicitly instructing them not to reference purple elephants. When they encounter errors, they are biased to previous assumptions/approaches they tend to have laid out previously in the conversation.
I generally recommend using many short per-task conversations to interact with LLMs, with each having as little irrelevant/conflicting context as possible. This is especially helpful for fixing non-trivial LLM-introduced errors because it reframes the task and eliminates the LLM's bias towards the "thinking" that caused it to introduce the bug to begin with
If you'll forgive me putting my debugging hat on for a bit, because solving problems is what most if us do here, I wonder if it's not actually reading the URL, and maybe that's the source of the problem, bc I've had a lot of success feeding manuals and such to AIs and then asking it to synthesize commands or asking it questions about them. Also, I just tried asking Gemini 2.5 Flash this and it did a web search, found a source, answered my question correctly (ls -a, or -la for more detail), and linked me to the precise part of its source it referenced: https://kinsta.com/blog/show-hidden-files/#:~:text=If%20you'... (this is the precise link it gave me).
Well, in one case (it was borg or restic doc) I noticed it actually picked something correctly from the URL/page and then still messed up in the answer.
What my guess is - maybe it read the URL and mentioned a few things as one part of its "that" answer/output but for the other part it relied it on the learning it already had. Maybe it doesn't learn "on the go". I don't know, could be a safeguard against misinformation or spamming the model or so.
As I said in my comment, I hadn't asked it "ls -a" question but rather something else - different commands on different times which I don't recall now except borg and restic ones which I did recently. "ls -a" is the example I picked to show one of the things I was"cribbing" about.
This reminds me of how small of a team they are, and makes me wonder if they have a customer support team that's growing commensurately with the size of the user base.
And it's all upside (your body feels better afterward) no downside. (Ok, it's more expensive.) Especially when combined with other sweet ingredients, e.g. a banana – equally if not more delicious.
It's talking about the Ada programming language and that its code was apparently stored not as plaintext but an intermediate representation (IR) that could then be transformed back into code.
So formatting was handled by tooling by the nature of the setup. Developers would each have their own custom settings for "pretty printing" the code.
The author isn't saying don't use code formatters. They're highlighting an unusual approach that the industry at large isn't aware of. Instead of getting rid of arguments about code style via formatters, you can get rid of them by saving code in an IR instead of plaintext.