自动编码和编程的未来

Editor’s Note: Automation has been a game-changing phenomenon in many fields. As the VP of Content Strategy at O’Reilly Media, Mike Loukides has an intimate knowledge of how automation has transformed certain industries in drastic and unexpected ways. In this article, Mike takes a look at what automation might mean for the future of programming and its effect on professional software development. We’d love to hear from you about what you think about this piece.

编者注： 在许多领域，自动化已成为改变游戏规则的现象。 作为O'Reilly Media内容策略副总裁，Mike Loukides对自动化如何以戏剧性和出乎意料的方式改变某些行业有着深刻的了解。 在本文中，Mike研究了自动化对编程的未来可能意味着什么及其对专业软件开发的影响。 我们很乐意听到您对您对此作品的看法。

At Microsoft’s Build conference, Microsoft CTO Kevin Scott talked about an experimental project in which an AI, trained on code in GitHub, actually creates programs: it generates function bodies based on a descriptive comment and a message signature. (Skip to 29:00 of the video.) Along similar lines, an unrelated research paper reports on unsupervised translation of programs from one language to another–indeed, probably an easier task than natural language translation.

在微软的Build大会上，微软首席技术官凯文·斯科特(Kevin Scott)谈到了一个实验项目，其中一个在GitHub上受过代码训练的AI实际上创建了程序：它基于描述性注释和消息签名生成功能主体。 (跳至视频的 29:00。)与此类似，一份无关的研究论文报告说， 无监督的程序从一种语言到另一种语言的翻译 ，实际上比自然语言翻译更容易。

Microsoft’s demo is, well, a demo, and the research paper is a research paper. Microsoft’s AI was able to provide method bodies for some relatively simple functions; it was obviously rather limited. It begs the question of exactly how you write the comment that tells the AI what to do; are we just replacing a description in a precise programming language with a description in an ambiguous, imprecise human language? I’m sure that training the model costs more than hiring a developer to write a few short functions. And while it’s easy for me to believe that software can translate some simple code from COBOL to Rust, I can only imagine that it would be horribly confused by the multitude of tricks programmers used in the 1960s and 1970s to deal with computers that had, by modern standards, miniscule memories. Programming jobs are not going to disappear tomorrow.

微软的演示很好，就是演示，研究论文是研究论文。 微软的AI能够为一些相对简单的功能提供方法主体。 这显然是相当有限的。 这就引出了一个问题，即您究竟如何编写注释来告诉AI该怎么做； 我们是否只是将一种精确的编程语言中的描述替换为一种模棱两可，不精确的人类语言中的描述？ 我敢肯定，训练模型的成本要比雇用开发人员编写一些简短函数的成本高。 虽然我很容易相信软件可以将一些简单的代码从COBOL转换为Rust，但是我只能想象，对于1960年代和1970年代程序员用来处理具有现代标准，微不足道的回忆。 编程工作明天不会消失。

Nevertheless, it’s important for us to think about what automation might mean for the future of programming. Is this a glimpse of the future, and if so, what is it telling us? What can we learn from it? Programming will increasingly be automated; and, as someone who got started writing assembler on a PDP-8, I can tell you that programming is already highly automated, and that a good optimizing compiler is already an advanced AI system that takes your hints and turns them into working code.

尽管如此，对我们而言，重要的是要考虑自动化对于编程的未来可能意味着什么。 这是对未来的一瞥，如果是的话，它告诉我们什么？ 我们可以从中学到什么？ 编程将越来越自动化。 而且，作为开始在PDP-8上编写汇编程序的人，我可以告诉您编程已经高度自动化，并且一个好的优化编译器已经是一个先进的AI系统，可以将您的提示转化为工作代码。

Programming is not going to “go away” or “become obsolete.” However, its meaning will change. I’ve previously written about blue- and white-collar programmers: programmers who connect things, and programmers who design the things that are connected, and build the tools to connect them. These are different (though highly overlapping) skillsets. And while Microsoft’s demo may show that programmers may eventually be liberated from the task of coding up simple functions, the code-generating engine was certainly built by a team of programmers, and possibly a large one. The programmers who write the higher-level tools, like Microsoft’s coding engine itself, can breathe a sigh of relief. As can programmers who design APIs, since you still have to provide the function/method signatures.

编程不会“消失”或“变得过时”。 但是，其含义将改变。 我以前写过有关蓝领和白领程序员的文章： 连接事物的程序员，以及设计所连接事物的程序员 ，并构建用于连接它们的工具。 这些是不同的(虽然高度重叠)技能组。 尽管Microsoft的演示可能表明程序员最终可能会从编写简单功能的任务中解放出来，但是代码生成引擎肯定是由一组程序员(可能是一大批)构建的。 编写高级工具(例如Microsoft的编码引擎本身)的程序员可以松一口气。 设计API的程序员也一样，因为您仍然必须提供函数/方法签名。

And the blue-collar programmers who connect things? While this demo could spit out functions, I saw few signs that it could build larger systems out of the functions that it wrote. Although it had the ability to call functions that it had written, it could not put together a large program from a written specification. It might be able to spit out a simple bill, but it certainly couldn’t spit out a complete billing system. A project for future research? No doubt, but that’s probably dozens of years out. Programmers who connect things — the plumbers of the digital world — are also safe.

和连接事物的蓝领程序员？ 尽管此演示可以吐出功能，但我几乎看不到任何迹象表明它可以从其编写的功能中构建更大的系统。 尽管它具有调用已编写函数的能力，但是它无法将已编写规范中的大型程序组合在一起。 它可能可以吐出一个简单的账单，但是肯定不能吐出一个完整的账单系统。 一个未来的研究项目？ 毫无疑问，但这可能要花费数十年的时间。 连接事物的程序员(数字世界的管道工)也很安全。

But this feat still begs the question about what we mean by programming. In the video, Kevin Scott talks about reducing the time programmers spend on dull, repetitive tasks. Yes, that’s what we all say about AI: it will reduce the time spent on dull, repetitive tasks and free more time for creative work. Let’s break that down, though. Most of programming is specifying, in excruciating detail, how to execute some process. That can be dull, it is often repetitive, and it is certainly error-prone. And we really need to think more about what programming ought to be. To use Scott’s word, what are the “creative” aspects of programming?

但是，这一壮举仍然引出了关于编程的意义的问题。 在视频中，凯文·斯科特(Kevin Scott)谈到了减少程序员在乏味，重复性任务上花费的时间。 是的，这就是我们所有人所说的AI：它将减少花在乏味，重复性任务上的时间，并腾出更多时间进行创造性工作。 不过，让我们分解一下。 大部分编程都在详细说明如何执行某些过程。 这可能很乏味，通常是重复的，并且肯定容易出错。 我们确实需要更多地考虑编程应该是什么。 用斯科特的话来说，编程的“创造性”方面是什么？

I’m not sure that “creative” is the right word. Back in the 1960s and 1970s, more programmers were called “analysts.” That job title is still in use, but it’s not all that common: Glassdoor shows about 10,000 jobs for “programmer analyst,” 44,000 for “programmer,” and 100,000 for “software engineer.” Monster shows about 20,000 for “programmer analyst,” 300,000 for “programmer,” and 170,000 for “software engineer.”

我不确定“创意”是否正确。 早在1960年代和1970年代，更多的程序员被称为“分析师”。 该职位名称仍在使用中，但并不太常见： Glassdoor的“程序员分析师”职位约有10,000个，“程序员”职位约有44,000个，“软件工程师”职位约有100,000个。 Monster为“程序员分析师”显示20,000，为“程序员”显示300,000，为“软件工程师”显示170,000。

While the job may have differed little from what it is now, let’s think about what “analyst” means. Analysts analyze a problem; they think about what the problem is, and how to solve it effectively. They think about breaking it up into parts. They may even think about whether it should be solved; they might think about how it should be solved, what ethical issues it raises and how those issues should be handled. Can the software be abused? If so, how? What steps can be taken to prevent abuse? And analysts need to think about how people will use the software: what’s the user interface, what’s the user experience, can it be used by people with disabilities?

尽管这项工作可能与现在的工作几乎没有什么不同，但让我们考虑一下“分析师”的含义。 分析师分析问题； 他们考虑问题是什么，以及如何有效解决问题。 他们考虑将其分解为多个部分。 他们甚至可能在考虑是否应该解决它。 他们可能会考虑应如何解决，引发什么道德问题以及应如何处理这些问题。 可以滥用软件吗？ 如果是这样，怎么办？ 可以采取哪些步骤来防止滥用？ 分析人员需要考虑人们将如何使用该软件：什么是用户界面，什么是用户体验，残疾人可以使用它吗？

In O’Reilly’s Software Architecture Fundamentals Superstream, Thoughtworks’ Rebecca Parsons said that “analysts” were essentially doing software architecture: making big picture decisions about what the software should do, and how it should be built. Analysts and architects need to understand the business case. They need to present decisions about software systems to management in business terms. She used the need to test a backup strategy as an example: rather than telling the CEO about the technical details, just say “This test will show us how long it will take to get back online if the system crashes on the busiest retail day of the year.” That’s what an analyst does.

在O'Reilly的Software Architecture Fundamentals Superstream中， Thoughtworks的Rebecca Parsons说“分析师”实际上是在进行软件体系结构：就软件应该做什么以及应该如何构建做出大的决定。 分析师和架构师需要了解业务案例。 他们需要从业务角度向管理人员提出有关软件系统的决策。 她以测试备用策略的需求为例：没有向技术执行官介绍技术细节，而只是说：“该测试将向我们显示，如果系统在2008年最繁忙的零售日崩溃，恢复联机将花费多长时间。那一年。” 那就是分析师所做的。

Our emphasis on writing code, and on measuring productivity by “lines of code,” is myopic. Just look at all the wonderful (and absolutely necessary) tools we have for building, testing, archiving, and deploying code. But those tools, essential and revolutionary as they are, don’t address the real issue: are we solving the right problems? There are thousands of applications out there that pass every unit test, every integration test, and every acceptance test, but are still awful to use. And we are learning that there are new dimensions to software that we’ve rarely thought about: are there groups who need to use our software and can’t? Does your software support accessibility? Can it be used by people who don’t have reliable access to computers and to networks? The work of an organization like Code for America isn’t technically profound or deep. What’s radical about a product like GetCalFresh was the act of re-engineering the system to make it usable by the people who need to use it. And we need a lot more analysis like that.

我们对编写代码和通过“代码行”衡量生产力的重视是近视的。 只需看一下我们用于构建，测试，归档和部署代码的所有出色(绝对必要)的工具。 但是，那些本质上和革命性的工具并不能解决真正的问题：我们正在解决正确的问题吗？ 有成千上万的应用程序通过了每个单元测试，每个集成测试和每个验收测试，但是仍然很难使用。 而且我们正在学习，我们很少想到软件的新方面：是否有需要使用我们软件的小组？ 您的软件是否支持辅助功能？ 不能可靠访问计算机和网络的人可以使用它吗？ 像Code for America这样的组织的工作在技术上并不深刻。 像GetCalFresh这样的产品的根本之处在于，对系统进行了重新设计，以使需要使用它的人员可以使用它。 我们还需要更多这样的分析。

There’s a lot more to programming than just slinging code and writing functions. The most important parts of the job have nothing to do with writing quicksort on the whiteboard in an interview. There’s a lot to think about; and currently, programmers spend too much time rushing code out the door to meet a release date than they spend thinking about the bigger picture. That’s almost always someone else’s job. But whether or not it gets into production, Microsoft’s research gives us an opportunity to think about what programming really means. What’s the real job? What are we really trying to accomplish?

编程不仅有仅仅编写代码和编写函数的功能，还有很多。 这项工作中最重要的部分与在面试中在白板上书写快速排序无关。 有很多事情要考虑； 当前，程序员花太多时间把代码赶出去才能满足发布日期，而不是花在思考更大的事情上。 那几乎总是别人的工作。 但是，无论是否投入生产，微软的研究都为我们提供了一个思考编程真正含义的机会。 真正的工作是什么？ 我们到底想完成什么？

学得更快。 深入挖掘。 看得更远。 (Learn faster. Dig deeper. See farther.)

Join the O’Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

加入O'Reilly在线学习平台。 立即获得免费试用版，即时找到答案，或者掌握一些新的有用的知识。

Learn more

学到更多

Mike Loukides is Vice President of Content Strategy for O’Reilly Media, Inc. He’s edited many highly regarded books on technical subjects that don’t involve Windows programming. He’s particularly interested in programming languages, Unix and what passes for Unix these days, and system and network administration. Mike is the author of System Performance Tuning and a coauthor of Unix Power Tools. Most recently, he’s been writing about data and artificial intelligence, ethics, the future of programming, and whatever else seems interesting. He’s also a pianist, a ham radio operator, and a lover of birds.

Mike Loukides是O'Reilly Media，Inc.内容策略副总裁。他编辑了许多备受推崇的书籍，涉及与Windows编程无关的技术主题。 他对编程语言，Unix以及当今Unix的发展以及系统和网络管理特别感兴趣。 Mike是《系统性能调整》的作者，也是Unix Power Tools的合著者。 最近，他一直在撰写有关数据和人工智能，伦理学，编程的未来以及任何其他有趣的文章。 他还是钢琴家，业余无线电广播员和鸟类爱好者。

翻译自: https://medium.com/oreillymedia/automated-coding-and-the-future-of-programming-a8150dc41c11