智能代码完成?有没有人工智能可以通过学习来编写代码?

这样的工具存在。他们是一个叫做 Genetic Programming . 如何评价他们的成功取决于他们的应用范围。

他们已经非常成功地(比人类效率高出几个数量级)设计了用于工业过程管理、自动化医疗诊断或集成电路设计的最佳程序。这些过程都受到很好的约束,有一个明确的、不变的成功衡量标准,以及大量的“宇宙知识”,这是一套关于什么是有效的、有效的、可工作的、可编程的以及什么不是有效的规则。

它们在构建需要用户交互的主流程序方面完全无用,因为学习需要的系统的主要项目是一个明确的” fitness function “,或对其提出的当前解决方案的质量进行评估。

在处理“程序学习”时可以看到的另一个领域是 Inductive Logic Programming 尽管它更用于提供自动演示或语言/分类学习。

免责声明: 我不是英语母语者,也不是该领域的专家,我是 amateur -在接下来的工作中会出现不精确和/或错误。所以,本着堆积如山的精神,不要害怕纠正和改进我的散文和/或内容。还要注意这是 不 全面调查 automatic programming 技术( code generation (CG)来自 Model-Driven Architectures (mdas)至少值得一提)。

我想再加一点什么 Varkhan 回答(基本正确)。

这个 Genetic Programming (gp)接近 Automatic Programming 将其与 fitness functions ,两个不同的问题(“自编译”在概念上是无需考虑的):

• 自我改进/适应-综合程序,如果需要,还包括合成器本身;以及
• program synthesis .

W.R.T. 自我改进/适应 参考J_¼Rgen Schmidhuber的 Goedel machines : 自我参照的普遍问题解决者做出可证明的最佳自我改进 . (旁注:他的工作很有趣 artificial curiosity 与本次讨论有关的还有 Autonomic Systems .

W.R.T. 程序综合 我认为可以将3个主要分支机构分类: stochastic (概率-如上所述,gp) 归纳法 和 演绎的 .

GP 本质上是 随机的 因为它产生了启发式的程序空间,如交叉、随机变异、基因重复、基因缺失等。(而不是用 fitness function 让适者生存和繁殖)。

归纳程序综合 通常被称为 Inductive Programming (IP),其中 Inductive Logic Programming (ILP)是一个子字段。也就是说,一般来说,技术不限于 logic program 用逻辑编程语言编写的合成或合成器(或两者都不限于“ ..自动演示或语言/分类学习 “”。

IP 往往是 确定性的 (但也有例外):从 不完全 规范(如示例输入/输出对),用于约束满足该规范的可能程序的搜索空间,然后对其进行测试。( 生成和测试方法 )或者直接合成一个程序来检测给定例子中的重复,然后将其推广( 数据驱动 或 解析 方法)。整个过程本质上是 statistical induction/inference -也就是说,在不完整的规范中考虑什么类似于随机抽样。

Generate-and-test and data-driven/analytical ¨方法可以很快,因此两者都很有希望(即使到目前为止只有很少的综合程序在公开场合演示),但是 生成和测试 (像GP)是 embarrassingly parallel 然后可以预期显著的改进(扩展到实际的程序大小)。但是请注意 Incremental Inductive Programming (IIP)§,本质上是连续的,证明了非增量方法更有效的数量级。

这些链接直接指向PDF文件:抱歉,我找不到摘要。

Programming by Demonstration (PBD)和 Programming by Example (PBE)是 end-user development 已知可利用的技术 归纳程序综合 实际上。

Deductive program synthesis 以(假定的)开头 完成 (形式)规范(逻辑条件)。其中一个技术杠杆 automated theorem provers :要合成一个程序,它构造一个符合规范的对象存在的证明;因此,通过 Curry-Howard-de Bruijn isomorphism (证明作为程序通信,公式作为类型通信),它从证明中提取程序。其他变体包括使用 constraint solving 和 deductive composition of subroutine libraries .

在我看来 归纳法 和 演绎的 合成 在实践中 用两个不同的角度来处理同一个问题,因为 完成 规范是有争议的(此外,今天的完整规范明天可能会变得不完整——世界不是静止的)。

当(如果)这些技术(自我改进/适应和程序合成)成熟时,它们承诺增加 declarative programming (应考虑这种设置) 程序设计 是 sometimes debated ):我们会更加专注于 Domain Engineering 和 Requirements Analysis and Engineering 比软件的手动设计和开发、手动调试、手动系统性能调优等(可能用较少的 accidental complexity 与现行手册相比,不是自我改进/适应技术)。这也将提升 agility 但仍有待于现有技术的证明。