为什么 LLM 无法让代码变得更简洁
<p><em>这篇文章最初发表 .</em></p><blockquote> 长话短说,Peter Naur 博士的“编程作为理论构建”指出,真正的程序,他所说的理论,大写的 T,都在工程师的脑海中。 代码和文档只是下游(因此不完整)工件。 我对法学硕士的主要抱怨之一是代码非常冗长,而且复杂性无处不在。 我始终相信,我们可以使用 LoC 等指标或独立代码路径的数量来约束它们,从而改进这一点。 然而,读完 Naur 后,我意识到我们试图降低的复杂性是理论复杂性,而不是代码复杂性,并且没有相关措施,因为它非常主观。 </blockquote><p>我最近读了一篇很棒的论文 。它极大地改变了我对当前法学硕士能做什么或不能做什么、如何提示他们、当前代理系统的主要限制是什么或为什么结对编程如此有效的看法。</p><p>今天我将重点讨论它与代码复杂性的关系。</p><p>如果您还没有阅读过这篇论文,我强烈建议您阅读一下。 事实上,我写这篇文章的主要目的是让你们中的一些人阅读原始论文。 这是值得的。 这也是练习(或学习!)精读的绝佳机会 因为这样简单多了:你可以在全文中提出任何问题,深入任何你喜欢的深渊,或者直接让Solveit让你更清楚地理解语言。关于细读的更多信息请参见你可以快速开始.</p><p>考虑到这一点,如果你仍然决定不读,这里是论文的简要总结;总结:</p><blockquote>程序是由构建和维护它的人所持有的理论:理解程序如何与现实世界的问题相关,哪…</blockquote> 









