Hi, Simon (Jakobi)! When reading your remarks on the LLM policy, I was quite perplexed, because apparently there are certain views that seem self-evident to me but which you don’t seem to share. Let me comment on some things that you wrote:
> > In particular, you must not use AI-generated text in a direct > > conversation with a human reviewer. > > I think this is too restrictive. Isn’t it fundamental for a conversation that the conversation partners themselves speak or write and not send texts generated by a machine? > > You must understand, and be able to explain, every line of code, and > > every sentence of documentation. Every line! > > I think that’s a good goal, but even for MRs, maybe too strict a > requirement. Where do you draw the line? Is the contributor expected > to understand every (pre-existing) function they used? To what extent? > Strictness and performance characteristics too? If you contribute code, you should surely understand this code that you contribute. If your code uses some function, you should understand the consequences of using it, which implies that you should know about its strictness and performance characteristics. This is the ideal at least, which, I agree, is difficult to meet for people not deeply into GHC, me included. However, the solution is to make it easier to understand existing functions in the GHC codebase, for example by writing documentation, not to lower the standard for contributions. > > We strongly prefer human-written code > > I understand that it’s “good exercise” to write code by hand. I don’t see programming as a mere exercise. It’s a key part of developing software. > But I've always been pretty bad and extremely slow to write code. And > now that recent models have become so good at producing code, I was > relieved that I can now contribute without being so limited by my > code-writing skills. I definitely don’t want to be offensive, but is it a good idea to contribute code to a software that many are relying on if you’re “pretty bad” at writing code? > > Writing it yourself forces you to think about every line; and it > > imposes a cost on you if you write 1000 lines instead of 100. > > IMHO contributing to GHC is already quite onerous and “costly”, > especially for newcomers. Just think of the flaky CI system and recent > GitLab performance. Instead of trying to impose additional costs on > contributors, I think it would be better to try to reduce the cost of > reviewing and maintenance! I completely agree that contributing to GHC can be a frustrating experience, but the solution is to improve things like the CI system, isn’t it? What Simon (Peyton Jones) suggested was that the actual coding should have a significant cost to avoid generating lots of code, which can hardly be checked properly. > Overall, I feel that much of the recent discussion about LLMs in GHC and > Haskell has been driven by fear and anger. I can assure you that at least I are not driven by anger in this discussion. What I want is preventing harm. You may call this “motivation by fear”. I would rather call it “motivation by concern” and, not least, “motivation by ideals”. Also note that being motivated by fear is not necessarily a bad thing. Sometimes fear is adequate. All the best, Wolfgang _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
