Earlier quoted context omitted.
[flagged]
Stretch goal: hold three
A safe work contribution plan for the year: Hold 1+ (stretch 3) opposing thoughts at a time.
John Carmack on inlined code (2014)
131–140 of 402 posts
Re: John Carmack on inlined code (2014)
#132The clean code people are losing their collective minds reading that. lol
Re: John Carmack on inlined code (2014)
#133Earlier quoted context omitted.
Or rather, senior devs have learned to care more for having clear code rather than (over-)applying principles like DRY, separation of concerns etc., while juniors haven't (yet)...
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...
WET, write everything twice
Re: John Carmack on inlined code (2014)
#134Re: John Carmack on inlined code (2014)
#135Earlier quoted context omitted.
Teaching. I had this problem with an overzealous junior developer and the solution was showing some different perspectives. For example John Ousterhout's A Philosophy of Software Design.
I tried this but they just come back with retorts like "OK boomer" which tends to make the situation even worse. How do you respond to that?
This is a discriminatory statement and it should be taken seriously.
Re: John Carmack on inlined code (2014)
#136When 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/…
I suppose that depends on the language and the elegance of your programming paradigm. This is where primitive simplicity becomes important, because when your foundation is composed of very few things that are not dependent upon each other you can scale almost indefinitely in every direction.
Imagine you are limited to only a few ingredients in programming: statements, expressions, functions, objects, arrays, and operators that are not overloaded. That list does not contain classes, inheritance, declarative helpers, or a bunch of other things. With a list of ingredients so small no internal structure or paradigm is imposed on you, so you are free to create any design decisions that you want. Those creative decisions about the organization of things is how you dictate the scale of it all.
Most people, though, cannot operate like that. They claim to want the freedom of infinite scale, but they just need a little help. With more help supplied by the language, framework, whatever the less freedom you have to make your own decisions. Eventually there is so much help that all you do as a programmer is contend with that helpful goodness without any chance to scale things in any direction.
Re: John Carmack on inlined code (2014)
#137Earlier quoted context omitted.
Which is usually a positive. Testing tiny subunits usually just makes refactoring and adding new features hard while not improving test quality.
Not according to jon carmack. He stated he switched to pure functional programming in the intro which is basically stating all his logic is in the form of unit testable pure functions.
I found this [] article of Carmack. While reading, I understood there is a large set of gray shades to pureness of "pure functional" code. He calls being functional a useful abstraction, a function() is never purely functional.
[] https://web.archive.org/web/20120501221535/http://gamasutra....
Re: John Carmack on inlined code (2014)
#138His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…
I've never seen pure FP...
I might add Carmack's take on functional programming
https://web.archive.org/web/20120501221535/http://gamasutra....
Re: John Carmack on inlined code (2014)
#139His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…
I've never seen pure FP...
I would recommend you take a look at Haskell or Elm.
John Karmack did and talked about it https://m.youtube.com/watch?v=1PhArSujR_A
Re: John Carmack on inlined code (2014)
#140Earlier quoted context omitted.
You are probably reaching for Hegel’s concept of dialectical reconciliation
Not sure, didn't Hegel say that there should be a synthesis step at some point? My view is that there should never be a synthesis when using these principles as tools, as both conflicting principles need to always maintain opposites. So, more like Heraclitus's union of opposites maybe if you really want to label it?
the synthesis would be the outcome maybe? writing code that doesn't follow either rule strictly:
> Concretely related to the topic, I've often found myself inlining short pieces of one-time code that made functions more explicit, while at other times I'll spend days just breaking up thousand line functions into simpler blocks just to be able to follow what's going on. In both cases I was creating inconsistencies that younger developers nitpick -- I know I did.