| ▲ | senderista 5 hours ago |
| Linus's claim that use of LLM tools is uncorrelated with understanding or competence is ludicrous. |
|
| ▲ | munchbunny 5 hours ago | parent | next [-] |
| What he actually said was: > The kind of expectations I have is that people do their best and I expect people to understand what they are doing. > But that understanding has very little to do with what tools they use. > And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools. He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking. |
| |
| ▲ | senderista 5 hours ago | parent [-] | | To be clear: I believe that it's entirely possible to use LLMs to amplify understanding and competence, but that in practice LLM usage is anticorrelated with understanding and competence. This is about empirical reality, not logical entailment. | | |
| ▲ | skydhash 4 hours ago | parent [-] | | Very much this. Experimentation and careful usage is ok, but we’ve all seen that is pretty much dwarfed by blind slop generation. |
|
|
|
| ▲ | vlovich123 5 hours ago | parent | prev | next [-] |
| As an example, I’m in the process of putting up a patch series to optimize some specific filesystem operations. The amount of boilerplate that has to know to get done is completely unapproachable to an outsider both from the amount of time needed to learn that boilerplate and form it in such a way that maintainers will be happy. Even though I know exactly how the code is working, it bridges that understanding gap but I don’t see how it correlates with incompetence. I may be an outlier but I suspect there’s a huge amount of people who are extremely capable and competent and it’s just that the Linux kernel has so many processes that it’s difficult to onboard into the community without LLM assistance. |
| |
| ▲ | MobiusHorizons 5 hours ago | parent [-] | | The Linux kernel project is not hurting for contributors nor was it prior to LLMs. The processes you describe as roadblocks don’t seem to have been preventing the Linux kernel from getting code contributions. Maybe they don’t need or want more easy onboarding or broader audience? |
|
|
| ▲ | cwillu 5 hours ago | parent | prev | next [-] |
| Presumably the person who's full-time job is staying on top of proposed changes to the linux source tree knows something about this; what are your credentials on the topic? |
|
| ▲ | rfgplk 4 hours ago | parent | prev | next [-] |
| Linus himself is actually comically incompetent. He only became famous after the Linux kernel took off... decades ago? Since Git, he has made ZERO code contributions whatsoever (not even to the Linux kernel). He doesn't even review code and has his team of capos do it for him. All in all he's no different than the CEO of some tech company, his thoughts on LLMs are no longer relevant (for more lack of credibility, see his stance on Rust, C++, Go) |
| |
| ▲ | nullpoint420 3 hours ago | parent [-] | | Why does he need to write code to be "competent." He's a structural and architectural genius. Projects like the Linux kernel do not pop up out of thin air. They need a leader. |
|
|
| ▲ | mathisfun123 5 hours ago | parent | prev [-] |
| how do you feel about his analogy > Here's a new rule just for you: don't use compilers for any of your
kernel submissions. > Because if you can't show that you really understand what the machine
is actually doing by writing your code in assembler, then I don't want
to see your code contribution. You clearly aren't competent if you
can't write it that way. |
| |
| ▲ | Matl 5 hours ago | parent [-] | | I feel like you can't compare deterministic tools to non-deterministic ones so not a great analogy. | | |
| ▲ | bitwize 5 hours ago | parent | next [-] | | It doesn't really matter. The point is, new technology arrived that allowed developers to do much more. Existing programmers hemmed and hawed about it because it threatened their egos, making easy what they once found very difficult. But the sensible engineers adopted the technology. AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility. | | |
| ▲ | bigstrat2003 4 hours ago | parent | next [-] | | Nice rhetorical sleight of hand, trying to paint your opponents as ego-driven and senseless. But LLMs are not compilers. They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce. The situation is different, therefore the reactions are different. > AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. That is not remotely true. | |
| ▲ | skydhash 4 hours ago | parent | prev | next [-] | | > AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility. How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code. | |
| ▲ | teiferer 4 hours ago | parent | prev [-] | | I believe we are at a crossroads here. The key question is: Do we want (desire or require) humans to understand the implementation? If the answer is no, then AI agents producing code faster and "more correct" (in some arguably questionable sense but let's fly with the assumption for a moment) should be embraced fully. Take the humans out of the loop, why review code, if there is a problem later then just ask the next AI agent to fix it. Similar to not looking at generated code by a compiler. Iterate fast, don't look back. Some code bases and some entire companies have adopted this view. If the answer is yes then we need to keep the human in the loop, ensure they have enough understanding to maintain the thing, review all the code etc. AI is just another tool to produce the code which ultimately the human still owns. Many code bases follow this philosophy. It seems to me that the discussion always ultimately falls on one of these two sides. They are incompatible but you need to pick one. Depending on which you pick, it is easy to predict how you argue in such discussions. | | |
| ▲ | skydhash 3 hours ago | parent [-] | | > The key question is: Do we want (desire or require) humans to understand the implementation? Understanding the implementation is not the root cause here. The actual issue is that all software are built for a particular needs which is human related. In most software, the cost mostly decays to a constant value unless that need has changed or an external event has occurred. Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users. The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints. | | |
| ▲ | teiferer an hour ago | parent [-] | | > Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users. You can pin down existing expected behavior pretty well with automated test cases and even bringing formal verification into the mix. Using LLMs to create those, it's not even a major cost factor. Then you are safe from such regressions. Just like when humans make changes. So, I don't see how this is introducing a difference. > The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints. Indeed. Though I don't see the connection to my point. | | |
| ▲ | skydhash 2 minutes ago | parent [-] | | > You can pin down existing expected behavior pretty well with automated test Test cases are sample based, they do not take care of the whole range of value. Type checking in the other hand are set based and sometimes the types are too coarse. In both instances, you need to carefully choose your axiomatic foundation, and if you can do that, that means you’re already aware of both programs and solution. As defining the problem is a major step in problem solving. > Indeed. Though I don't see the connection to my point. A lot of AI proponents are touting the tools as better hammers while purposely not saying anything about the house. You need to show how it can help with building a new house and not gush that it’s a new shape, different from all the other hammers in history. So the focus on line of codes, number of PRs, all the harness talks,… is worth nothing if better software can’t be built. |
|
|
|
| |
| ▲ | mathisfun123 5 hours ago | parent | prev [-] | | the question is about whether you understand in the slightest the output of the tool. does the determinism of the compiler somehow imbue you with a better understanding of the assembly it generates? | | |
| ▲ | sedan_baklazhan 4 hours ago | parent [-] | | Yes. If you understand C code well, you have a very good understanding of what will actually happen when the binary is executed. | | |
| ▲ | mathisfun123 4 hours ago | parent | next [-] | | This is a myth https://queue.acm.org/doi/10.1145/3212477.3212479 | | |
| ▲ | sedan_baklazhan 4 hours ago | parent [-] | | I did not say that C is a low level language.
You must have a very weak understanding on this topic. | | |
| ▲ | mathisfun123 4 hours ago | parent [-] | | > You must have a very weak understanding on this topic i work on the codegen for a C compiler i'm pretty sure my understanding is better than yours <shrug> EDIT: and also you've clearly never read that article > One of the key attributes of a low-level language is that programmers can easily understand how the language’s abstract machine maps to the underlying physical machine so you did exactly imply "C is a low level language" |
|
| |
| ▲ | bitwize 4 hours ago | parent | prev [-] | | lol nobody "understands C code well" The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed. C is riddled with complexities and footguns, especially but not exclusively around undefined behavior. | | |
| ▲ | sedan_baklazhan 4 hours ago | parent | next [-] | | Undefined behavior is something that you will avoid - of course, only if you know the language pretty well. | | |
| ▲ | senderista 3 hours ago | parent [-] | | UB is basically impossible to avoid in practice--that is why the Linux kernel forced GCC to add a bunch of flags to "do what I mean", making UB defined in those cases. |
| |
| ▲ | skydhash 4 hours ago | parent | prev [-] | | > The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed You don’t need to understand the language completely. You only need to understand the general semantics and refer to the standard and docs to get the semantics down. That’s what they’re here for. |
|
|
|
|
|
