Earlier quoted context omitted.
Yes! I work with many folks objectively way younger and smarter than me. The two bad habits I try to break them of are abstractions and what ifs. They spend so much time chasing perfection that it negatively affects their output. Multiple times a day I find myself saying 'is that a realistic problem for our use case?' I don't blame them, it's admirable. But I feel like we need to teach YAGNI. Anymore I feel like a sa…
I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.
John Carmack on inlined code (2014)
141–150 of 402 posts
Re: John Carmack on inlined code (2014)
#142(2014) Ten years ago - a long time in coding.
Re: John Carmack on inlined code (2014)
#143Earlier quoted context omitted.
[flagged]
Indoctrination is the exact opposite.
This can be bad on the assumption that whoever is exposed to the maxim is not a proponent of "virtue ethics" (I use this as a catch-all term for various religious ethics doctrines, the underlying idea is that moral truths are given to people by a divine authority rather than discovered by studying human behavior, needs and happiness). In this situation, the maxim is an invitation to embrace ideas that aren't contradictory to one's own, but that live "outside the system", to put them on equal footing.
To make this more concrete, let's suppose the subject of child brides. Some religions have no problem with marrying girls of any age to men of any age. Now, the maxim suggests that no matter what your moral framework looks like, you should accept that under some circumstances it's OK to have child marriages. But, this isn't a contradiction. There's no ethical theory that's not based on divine revelation that would accept such a thing. And that's why, by and large, the Western society came to treat child marriages as a crime.
Contradictions are only possible when two parties agree on the premises that led to contradicting conclusion, and, in principle, should be possible to be resolved by figuring out which party had a faulty process that derived a contradicting opinion. Resolving such contradictions is a productive way forward. But, the kind of "disagreement" between religious ethics and "derived" ethics is where the premises are different. So, there can be no way forward in an argument between the two, because the only way the two can agree is if one completely abandons their premises.
Essentially, you can think about it as if two teams wanted to compete in some sport. If both are playing soccer, then there's a meaning to winning / losing, keeping the score, being good or bad at the game. But, if one team plays soccer while another team is playing chess... it just doesn't make sense to pit them against each other.
Re: John Carmack on inlined code (2014)
#144When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…
> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used? I think the truth is that we just CAN'T scale that way with the current programming languages/models/…
In the physical world, when we build something complex like a car engine, a microprocessor, or bookcase, the laws of physics guide us and help prevent invalid states. Not all of them -- an upside down bookcase still works -- but a lot of them.
Of course, part of the problem is that when we build the software equivalent of an upside down bookcase, we 'patch' it by creating trim and shims to make it look better and more structurally sound instead of tossing it and making another one the right way.
But mostly, we write software in a way that allows for a ton of incorrect states. As a trivial example, expressing a person's age as an 'int', allowing for negative numbers. As a more complicated example, allowing for setting a coupon's redemption date when it has not yet been clipped.
Re: John Carmack on inlined code (2014)
#145When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…
> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used? I think the truth is that we just CAN'T scale that way with the current programming languages/models/…
We will never get rid of the need for QA. Automated tests are great, I believe in them (Note that I didn't say unit tests or integration tests). Formal proofs appear great (I have never figured out how to prove my code), but as Knuth said "Beware of bugs in the above code; I have only proved it correct, not tried it". There are many ways code can be meet the spec and yet wrong because in the real world you rarely understand the problem well enough to write a correct spec in the first place. QA should understand the problem well enough to say "this isn't what I expected to happen."
Re: John Carmack on inlined code (2014)
#146Re: John Carmack on inlined code (2014)
#147When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…
We already have a technology which scales infinitely with the human mind: abstraction and composition of those abstractions into other abstractions.
Until now, we’ve focused on getting AI to produce correct code. Now that this is beginning to be successful, I think a necessary next step for it to be useful is to ensure it produces well-abstracted and clean code (such that it scales infinitely)
Re: John Carmack on inlined code (2014)
#148Earlier quoted context omitted.
I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.
The important bit is figuring out if those times where "the right way" would have helped outweigh the time saved by defaulting to "good enough". There are always exceptions, but there's typically order of magnitude differences between globally doing "the right thing" vs "good enough" and going back to fix the few cases where "good enough" wasn't actually good enough.
If you are on a true green field project - your organization has never done this before good luck. Do the best you can but beware that you will regret a lot. Even if you have those long term employees you will do things you regret - just not as much.
Re: John Carmack on inlined code (2014)
#149Earlier quoted context omitted.
My 'principle' for DRY is : twice is fine, trice is worth an abstraction (if you think it has a small to moderate chance to happen again). I used to apply it no matter what, soi guess it's progress...
I really dislike how this principle ends up being used in practice. A good abstraction that makes actual sense is perfectly good even when it's used only once. On the other hand, the idea of deduplicating code by creating an indirection is often not worth it for long-term maintenance, and is precisely the kind of thing that will cause maintenance headaches and anti-patterns. For example: don't mix file system or low-…
https://loup-vaillant.fr/articles/source-of-readability#avoi...
Re: John Carmack on inlined code (2014)
#150> "it is often better to go ahead and do an operation, then choose to inhibit or ignore some or all of the results, than try to conditionally perform the operation."
I'm not the audience for this topic, I do javascript from a designer-dev perspective. But I get in the weeds sometimes, maxing out my abilities and bogged down by conditional logic. I like his quote it feels liberating... "just send it all for processing and cherry-pick the results". Lightbulb moment.