{done}GTD190019:【翻译】The Coming Software Apocalypse
https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/?single_page=true
A small group of programmers wants to change how we code—before catastrophe strikes.
here were six hours during the night of April 10, 2014, when the entire population of Washington State had no 911 service. People who called for help got a busy signal. One Seattle woman dialed 911 at least 37 times while a stranger was trying to break into her house. When he finally crawled into her living room through a window, she picked up a kitchen knife. The man fled.
The 911 outage, at the time the largest ever reported, was traced to software running on a server in Englewood, Colorado. Operated by a systems provider named Intrado, the server kept a running counter of how many calls it had routed to 911 dispatchers around the country. Intrado programmers had set a threshold for how high the counter could go. They picked a number in the millions.
Shortly before midnight on April 10, the counter exceeded that number, resulting in chaos. Because the counter was used to generating a unique identifier for each call, new calls were rejected. And because the programmers hadn’t anticipated the problem, they hadn’t created alarms to call attention to it. Nobody knew what was happening. Dispatch centers in Washington, California, Florida, the Carolinas, and Minnesota, serving 11 million Americans, struggled to make sense of reports that callers were getting busy signals. It took until morning to realize that Intrado’s software in Englewood was responsible, and that the fix was to change a single number.
Not long ago, emergency calls were handled locally. Outages were small and easily diagnosed and fixed. The rise of cellphones and the promise of new capabilities—what if you could text 911? or send videos to the dispatcher?—drove the development of a more complex system that relied on the internet. For the first time, there could be such a thing as a national 911 outage. There have now been four in as many years.
It’s been said that software is “eating the world.” More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of The Wall Street Journal’s website crashed; and Seattle’s 911 system went down again, this time because a different router failed. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence.
“When we had electromechanical systems, we used to be able to test them exhaustively,” says Nancy Leveson, a professor of aeronautics and astronautics at the Massachusetts Institute of Technology who has been studying software safety for 35 years. She became known for her report on the Therac-25, a radiation-therapy machine that killed six patients because of a software error. “We used to be able to think through all the things it could do, all the states it could get into.” The electromechanical interlockings that controlled train movements at railroad crossings, for instance, only had so many configurations; a few sheets of paper could describe the whole system, and you could run physical trains against each configuration to see how it would behave. Once you’d built and tested it, you knew exactly what you were dealing with.
Software is different. Just by editing the text in a file somewhere, the same hunk of silicon can become an autopilot or an inventory-control system. This flexibility is software’s miracle, and its curse. Because it can be changed cheaply, software is constantly changed; and because it’s unmoored from anything physical—a program that is a thousand times more complex than another takes up the same actual space—it tends to grow without bound. “The problem,” Leveson wrote in a book, “is that we are attempting to build systems that are beyond our ability to intellectually manage.”
这里是2014年4月10日夜间六个小时，当时华盛顿州全体人民没有911服务。呼吁帮忙的人有一个忙碌的信号。当一名陌生人正在打破她的房子时，一名西雅图女子至少打了37次911。当男子终于通过窗户爬进客厅时，女人拿起一把厨刀。这个人逃跑了。
当时有史以来报道最多的911中断被追溯到科罗拉多州恩格尔伍德（Englewood）的服务器上运行的软件。该服务器由名为Intrado的系统提供商运营，该服务器保留了一个运行中的计数器，该计数器已经将其路由到全国各地911个调度员的呼叫数量。 Intrado程序员已经设定了计数器可以走多高的门槛。他们选择了数百万的数字。
4月10日午夜之前，柜台超过了这个数字，造成混乱。由于计数器用于为每个呼叫生成唯一的标识符，所以新的呼叫被拒绝。而且因为程序员没有预料到这个问题，所以没有发出警报来提醒他们注意。没有人知道发生了什么。在华盛顿，加利福尼亚州，佛罗里达州，卡罗莱纳州和明尼苏达州的调度中心，为1100万美国人提供服务，努力了解呼叫者正在忙碌的信号。直到早上才意识到Intrado在Englewood的软件是负责任的，修复是改变一个数字。
不久前紧急电话在本地处理。停电时间小，易诊断和固定。手机的兴起和新功能的承诺 - 如果你可以文字911？或将视频发送到调度员？开发一个依赖于互联网的更为复杂的系统。第一次可能会有一个这样的事情，如国家911中断。现在已经有四年了。
据说软件正在“吃饭世界”。越来越多的机械或人员控制的关键系统将依赖于代码。这可能并不比2015年夏天更清晰，因为联合航空公司在一天内，由于其离港管理系统的问题，使其舰队落地;升级后，纽约证券交易所暂停交易; “华尔街日报”网站的首页坠毁;而西雅图的911系统再次下降，这次是因为不同的路由器失败。首先在协调的网络攻击中，许多软件系统同时发生故障。几乎更可怕的是实现，一天晚上，这只是巧合。
马萨诸塞理工学院航空航天学教授Nancy Leveson说：“当我们有机电系统的时候，我们曾经能够对其进行全面的测试。”他一直在研究软件安全35年。她因Therac-25的报告而闻名，Therac-25是一种放射治疗机，因为软件错误导致6名患者死亡。 “我们曾经能够思考所有可能做的事情，所有这些国家都可以进入。”例如，在铁路交叉口控制列车运动的机电联锁只有很多配置;几张纸可以描述整个系统，您可以针对每个配置运行物理列车，以了解其行为。一旦你建立并测试了它，你就知道你正在处理什么。
软件是不同的只要通过编辑某个文件中的文本，同一块硅就可以成为自动驾驶仪或库存控制系统。这种灵活性是软件的奇迹，它的诅咒。因为它可以便宜地改变，软件不断变化;并且因为它没有任何物理 - 一个比另一个更复杂的程序占用相同的实际空间 - 它往往无限制地增长。 Leveson在一本书中写道：“问题在于，我们正在尝试构建超出我们智力管理能力的系统。”
1.The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.
Our standard framework for thinking about engineering failures—reflected, for instance, in regulations for medical devices—was developed shortly after World War II, before the advent of software, for electromechanical systems. The idea was that you make something reliable by making its parts reliable (say, you build your engine to withstand 40,000 takeoff-and-landing cycles) and by planning for the breakdown of those parts (you have two engines). But software doesn’t break. Intrado’s faulty threshold is not like the faulty rivet that leads to the crash of an airliner. The software did exactly what it was told to do. In fact it did it perfectly. The reason it failed is that it was told to do the wrong thing. Software failures are failures of understanding, and of imagination. Intrado actually had a backup router, which, had it been switched to automatically, would have restored 911 service almost immediately. But, as described in a report to the FCC, “the situation occurred at a point in the application logic that was not designed to perform any automated corrective actions.”
This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”
he attempts now underway to change how we make software all seem to start with the same premise: Code is too hard to think about. Before trying to understand the attempts themselves, then, it’s worth understanding why this might be: what it is about code that makes it so foreign to the mind, and so unlike anything that came before it.
Technological progress used to change the way the world looked—you could watch the roads getting paved; you could see the skylines rise. Today you can hardly tell when something is remade, because so often it is remade by code. When you press your foot down on your car’s accelerator, for instance, you’re no longer controlling anything directly; there’s no mechanical link from the pedal to the throttle. Instead, you’re issuing a command to a piece of software that decides how much air to give the engine. The car is a computer you can sit inside of. The steering wheel and pedals might as well be keyboard keys.
Like everything else, the car has been computerized to enable new features. When a program is in charge of the throttle and brakes, it can slow you down when you’re too close to another car, or precisely control the fuel injection to help you save on gas. When it controls the steering, it can keep you in your lane as you start to drift, or guide you into a parking space. You couldn’t build these features without code. If you tried, a car might weigh 40,000 pounds, an immovable mass of clockwork.
Software has enabled us to make the most intricate machines that have ever existed. And yet we have hardly noticed, because all of that complexity is packed into tiny silicon chips as millions and millions of lines of code. But just because we can’t see the complexity doesn’t mean that it has gone away.
The programmer, the renowned Dutch computer scientist Edsger Dijkstra wrote in 1988, “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.” Dijkstra meant this as a warning. As programmers eagerly poured software into critical systems, they became, more and more, the linchpins of the built world—and Dijkstra thought they had perhaps overestimated themselves.
1.软件完全符合要求做的事情。失败的原因是被告知要做错事。
关于工程故障的标准框架，例如反映在医疗设备的规定中 - 在二次大战之后，在软件出现之前，机电系统出现。这个想法是，通过使其部件可靠（例如，您构建发动机以承受40,000起飞和着陆周期），并通过规划这些部件的故障（您有两个引擎），您可以使某些可靠。但软件不会中断。 Intrado的错误门槛不像导致飞机坠毁的有缺陷的铆钉。该软件完全符合要求做的事情。其实它做得很好。失败的原因是被告知要做错事。软件故障是理解和想象的失败。 Intrado实际上有一个备份路由器，如果被自动切换，几乎会立即恢复911服务。但是，正如FCC向FCC提交的报告所述，“这种情况发生在应用程序逻辑中，其目的不在于执行任何自动纠正措施。”
这是使代码丢失的问题，而不是物理的东西。 Leveson说，“复杂性”是看不见的。“
他现在正在努力改变我们如何使软件似乎从同样的前提开始：代码太难想了。在尝试了解自己的尝试之前，那么值得了解为什么这可能是什么：它是什么关于代码，使它如此外在的心灵，所以不像之前的任何东西。
用来改变世界观的技术进步 - 你可以看路铺路;你可以看到天际线上升。今天你几乎无法知道什么东西被重塑，因为经常被代码重塑。例如，当您将脚压在汽车的加速器上时，您不再直接控制任何东西;没有从踏板到油门的机械连接。相反，您正在向一个软件发出命令，决定给引擎带来多少空气。这辆车是一台可以坐在里面的电脑。方向盘和踏板也可能是键盘键。
像其他一切一样，这款车已经通过电脑化来实现新功能。当一个程序负责节气门和制动器时，当您太靠近另一辆车时，它可能会减慢，或者精确控制燃油喷射以帮助您节省气体。当它控制转向时，当您开始漂移或引导您进入停车位时，它可以让您保持在车道中。您无法使用代码构建这些功能。如果你试过，一辆汽车可能会重4万磅，这是不可移动的发条。
软件使我们能够制造出最复杂的机器。然而，我们几乎没有注意到，因为所有这些复杂性都被包装成微小的硅芯片，数以百万计的代码行。但只是因为我们看不到复杂性并不意味着它已经消失了。
荷兰知名计算机科学家Edsger Dijkstra的程序员在1988年写道：“必须能够从概念层次上思考，比以前需要面对的单一思想深刻一些。”Dijkstra认为这是一个警告。随着程序员热切地将软件投入关键系统，他们越来越成为建造世界的主角，而Dijkstra认为他们可能高估了自己。
2.“Software engineers don’t understand the problem they’re trying to solve, and don’t care to.”
What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer’s shoulder as they pored over line after line like “100001010011” and “000010011110” would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as “integrated development environments,” or IDEs, that help correct simple mistakes (like Microsoft Word’s grammar checker but for code), obscured, though did little to actually change, this basic alienation—the fact that the programmer didn’t work on a problem directly, but rather spent their days writing out instructions for a machine.
“The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” When you’re writing code that controls a car’s throttle, for instance, what’s important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. “There’s 100 million lines of code in cars now,” Leveson says. “You just cannot anticipate all these things.”
In September 2007, Jean Bookout was driving on the highway with her best friend in a Toyota Camry when the accelerator seemed to get stuck. When she took her foot off the pedal, the car didn’t slow down. She tried the brakes but they seemed to have lost their power. As she swerved toward an off-ramp going 50 miles per hour, she pulled the emergency brake. The car left a skid mark 150 feet long before running into an embankment by the side of the road. The passenger was killed. Bookout woke up in a hospital a month later.
The incident was one of many in a nearly decade-long investigation into claims of so-called unintended acceleration in Toyota cars. Toyota blamed the incidents on poorly designed floor mats, “sticky” pedals, and driver error, but outsiders suspected that faulty software might be responsible. The National Highway Traffic Safety Administration enlisted software experts from NASA to perform an intensive review of Toyota’s code. After nearly 10 months, the NASA team hadn’t found evidence that software was the cause—but said they couldn’t prove it wasn’t.
It was during litigation of the Bookout accident that someone finally found a convincing connection. Michael Barr, an expert witness for the plaintiff, had a team of software experts spend 18 months with the Toyota code, picking up where NASA left off. Barr described what they found as “spaghetti code,” programmer lingo for software that has become a tangled mess. Code turns to spaghetti when it accretes over many years, with feature after feature piling on top of, and being woven around, what’s already there; eventually the code becomes impossible to follow, let alone to test exhaustively for flaws.
2.“软件工程师不明白他们想要解决的问题，而不在乎”。
什么使编程变得困难，它需要你像电脑一样思考。当代码采用文字和零的形式时，它的奇怪性在某种程度上在计算的早期更加生动。任何看过程序员肩膀的人，像“100001010011”和“000010011110”一样，都会看到程序员与他们试图解决的实际问题有多么疏远;不可能知道他们是否试图计算火炮的轨迹或模拟一场Tic-tac-toe的游戏。引入了类似于英文的Fortran和C等编程语言，被称为“集成开发环境”（IDE）的工具，可帮助纠正简单错误（如Microsoft Word的语法检查程序，但是对于代码）来说却模糊不清，实际上改变了这个基本的异化 - 程序员直接对问题没有作用的事实，而是花了他们的时间为机器写出指令。
麻省理工学院软件安全专家Leveson说：“问题是软件工程师不了解他们正在解决的问题，而不在乎。”原因是他们太累了，让他们的代码工作。 “软件工程师喜欢为编码错误提供各种工具和东西，”她指的是IDE。 “软件发生的严重问题与要求有关，而不是编码错误。”例如，当您编写控制汽车油门的代码时，重要的是关于何时，如何以及多少打开的规则它。但是这些系统变得如此复杂，几乎没有人能够保持直线。 Leveson说：“目前汽车上有1亿行代码。 “你根本无法预料这些事情。”
2007年9月，Jean Bookout正在高速公路上与丰田凯美瑞的最好的朋友一起开车，当时加速器似乎被卡住了。当她脚踏下脚踏车时，车子没有减速。她试过刹车，但似乎失去了力量。当她朝向每小时50英里的斜坡转弯时，她拉紧急刹车。汽车在路边一路走进路堤前，留下了150英尺长的防滑标记。乘客死亡一个月后，医院在医院醒来。
事件是对丰田汽车所谓无意加速的索赔近十年的调查中的许多事件之一。丰田将这些事件归咎于设计不善的地板垫，“粘性”踏板和司机错误，但外部人士怀疑有问题的软件可能是负责任的。国家公路交通安全管理局招募了美国宇航局的软件专家，对丰田的代码进行了深入的审查。经过近10个月的时间，美国航空航天局的一个小组没有发现软件是事实的证据，但他们说不能证明是不是的。
3.“If the software malfunctions and the same program that crashed is supposed to save the day, it can’t.”
Using the same model as the Camry involved in the accident, Barr’s team demonstrated that there were actually more than 10 million ways for the onboard computer to cause unintended acceleration. They showed that as little as a single bit flip—a one in the computer’s memory becoming a zero or vice versa—could make a car run out of control. The fail-safe code that Toyota had put in place wasn’t enough to stop it. “You have software watching the software,” Barr testified. “If the software malfunctions and the same program or same app that is crashed is supposed to save the day, it can’t save the day because it is not working.”
Barr’s testimony made the case for the plaintiff, resulting in $3 million in damages for Bookout and her friend’s family. According to The New York Times, it was the first of many similar cases against Toyota to bring to trial problems with the electronic throttle-control system, and the first time Toyota was found responsible by a jury for an accident involving unintended acceleration. The parties decided to settle the case before punitive damages could be awarded. In all, Toyota recalled more than 9 million cars, and paid nearly $3 billion in settlements and fines related to unintended acceleration.
There will be more bad days for software. It's important that we get better at making it, because if we don't, and as software becomes more sophisticated and connected—as it takes control of more critical functions—those days could get worse.
The problem is that programmers are having a hard time keeping up with their own creations. Since the 1980s, the way programmers work and the tools they use have changed remarkably little. There is a small but growing chorus that worries the status quo is unsustainable. “Even very good programmers are struggling to make sense of the systems that they are working with,” says Chris Granger, a software developer who worked as a lead at Microsoft on Visual Studio, an IDE that costs $1,199 a year and is used by nearly a third of all professional programmers. He told me that while he was at Microsoft, he arranged an end-to-end study of Visual Studio, the only one that had ever been done. For a month and a half, he watched behind a one-way mirror as people wrote code. “How do they use tools? How do they think?” he said. “How do they sit at the computer, do they touch the mouse, do they not touch the mouse? All these things that we have dogma around that we haven’t actually tested empirically.”
The findings surprised him. “Visual Studio is one of the single largest pieces of software in the world,” he said. “It’s over 55 million lines of code. And one of the things that I found out in this study is more than 98 percent of it is completely irrelevant. All this work had been put into this thing, but it missed the fundamental problems that people faced. And the biggest one that I took away from it was that basically people are playing computer inside their head.” Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself.
3.“如果软件发生故障并且相同的程序崩溃了应该保存一天，那就不行了。”
巴尔的团队使用与事故相关的凯美瑞模式相同的模型，证明车载电脑实际上有超过1000万种方式导致意外的加速。他们表明，只要一个单一的位翻转，计算机内存中的一个变成零，反之亦然 - 可能导致汽车失去控制。丰田已经实施的故障安全代码还不足以阻止。 “你有软件看软件，”巴尔作证。 “如果软件发生故障，同一程序或相同的应用程序被坠毁，应该保存一天，因为它不工作，所以无法保存一天。”
Barr的证词为原告提供了这一案件，导致Bookout及其朋友的家人损失了300万美元。据“纽约时报”报道，这是丰田的许多类似案件中首例引入电子油门控制系统的试点问题，而丰田公司首次发现由陪审团负责意外加油。双方当事人决定解决案件，然后才能给予惩罚性赔偿。总而言之，丰田回顾了900多万辆汽车，并支付了近30亿美元的定居点和与意外加速有关的罚款。
软件会有更糟糕的日子。重要的是，我们做得更好，因为如果我们没有，随着软件变得更加复杂和连接 - 因为它控制着更重要的功能 - 那些日子可能会变得更糟。
问题是程序员很难跟上自己的创作。自20世纪80年代以来，程序员的工作方式和使用的工具变化不大。有一个小而不断增长的合唱，担心现状是不可持续的。 “即使是非常好的程序员也在努力地理解他们正在使用的系统，”一位软件开发人员Chris Granger说，微软在Visual Studio上担任首席执行官，该公司每年花费1,199美元，每年花费1,199美元。是所有专业程序员的三分之一。他告诉我，当他在微软的时候，他安排了一个端到端的Visual Studio研究，这是唯一一个曾经做过的研究。一个半月的时间里，当人们写了代码的时候，他看着一个单向的镜子。 “他们如何使用工具？他们怎么想？“他说。 “他们如何坐在电脑上，他们是否触摸鼠标，他们没有触摸鼠标？所有这些我们有教条的东西，我们实际上并没有经过实证检验。“
结果让他感到惊讶。 “Visual Studio是世界上最大的软件之一，”他说。 “这是超过5500万行代码。我在这项研究中发现的一件事就是98％以上是完全不相干的。所有这些工作都被放在了这件事上，但却错过了人们面临的根本问题。而我最大的一个，就是基本上人们都在玩电脑，“程序员就像象棋玩家一样试图用眼罩玩，他们的精神力量很大程度上只是用来画图片那么几乎没有任何的余地去思考游戏本身。
4.Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?
John Resig had been noticing the same thing among his students. Resig is a celebrated programmer of JavaScript—software he wrote powers over half of all websites—and a tech lead at the online-education site Khan Academy. In early 2012, he had been struggling with the site’s computer-science curriculum. Why was it so hard to learn to program? The essential problem seemed to be that code was so abstract. Writing software was not like making a bridge out of popsicle sticks, where you could see the sticks and touch the glue. To “make” a program, you typed words. When you wanted to change the behavior of the program, be it a game, or a website, or a simulation of physics, what you actually changed was text. So the students who did well—in fact the only ones who survived at all—were those who could step through that text one instruction at a time in their head, thinking the way a computer would, trying to keep track of every intermediate calculation. Resig, like Granger, started to wonder if it had to be that way. Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?
The fact that the two of them were thinking about the same problem in the same terms, at the same time, was not a coincidence. They had both just seen the same remarkable talk, given to a group of software-engineering students in a Montreal hotel by a computer researcher named Bret Victor. The talk, which went viral when it was posted online in February 2012, seemed to be making two bold claims. The first was that the way we make software is fundamentally broken. The second was that Victor knew how to fix it.
Bret victor does not like to write code. “It sounds weird,” he says. “When I want to make a thing, especially when I want to create something in software, there’s this initial layer of disgust that I have to push through, where I’m not manipulating the thing that I want to make, I’m writing a bunch of text into a text editor.”
“There’s a pretty strong conviction that that’s the wrong way of doing things.”
Victor has the mien of David Foster Wallace, with a lightning intelligence that lingers beneath a patina of aw-shucks shyness. He is 40 years old, with traces of gray and a thin, undeliberate beard. His voice is gentle, mournful almost, but he wants to share what’s in his head, and when he gets on a roll he’ll seem to skip syllables, as though outrunning his own vocal machinery.
Though he runs a lab that studies the future of computing, he seems less interested in technology per se than in the minds of the people who use it. Like any good toolmaker, he has a way of looking at the world that is equal parts technical and humane. He graduated top of his class at the California Institute of Technology for electrical engineering, and then went on, after grad school at the University of California, Berkeley, to work at a company that develops music synthesizers. It was a problem perfectly matched to his dual personality: He could spend as much time thinking about the way a performer makes music with a keyboard—the way it becomes an extension of their hands—as he could thinking about the mathematics of digital signal processing.
By the time he gave the talk that made his name, the one that Resig and Granger saw in early 2012, Victor had finally landed upon the principle that seemed to thread through all of his work. (He actually called the talk “Inventing on Principle.”) The principle was this: “Creators need an immediate connection to what they’re creating.” The problem with programming was that it violated the principle. That’s why software systems were so hard to think about, and so rife with bugs: The programmer, staring at a page of text, was abstracted from whatever it was they were actually making.
“Our current conception of what a computer program is,” he said, is “derived straight from Fortran and ALGOL in the late ’50s. Those languages were designed for punch cards.” That code now takes the form of letters on a screen in a language like C or Java (derivatives of Fortran and ALGOL), instead of a stack of cards with holes in it, doesn’t make it any less dead, any less indirect.
4.过去40年来，电脑每18个月就翻了一番。为什么没有编程改变？
John Resig在他的学生中也注意到了同样的事情。 Resig是一个着名的JavaScript软件程序员，他写了所有网站的一半以上的权力 - 在网络教育网站汗学院的技术主管。在2012年初，他一直在努力研究该网站的计算机科学课程。为什么要学习编程呢？基本问题似乎是代码如此抽象。写作软件不像从冰棍棒上摆出一座桥，在那里你可以看到棍棒和触摸胶水。为了“制作”一个程序，你输入了一个字。当你想改变程序的行为，无论是游戏，还是网站，或物理模拟，你实际上改变的是文本。所以，实际上是唯一幸存下来的人的学生，就是那些可以一步一步地在文本中一步一步的思考，思考计算机的方式，试图跟踪每一个中间计算。 Resig像格兰杰一样，开始怀疑是否必须这样。过去40年来，电脑每18个月增加一倍。为什么没有编程改变？
事实上，他们两个同样的思考同样的问题，同时也不是巧合。他们刚刚在蒙特利尔酒店的一组计算机研究员名叫布雷维克（Bret Victor）的同时，也看到了一批软件工程学生。这个在2012年2月发布在网上的病毒的演讲似乎正在引起两个大胆的声明。第一个原因是我们制作软件的方式根本就被打破了。第二个是维克多知道如何解决它。
Bret胜者不喜欢写代码。 “听起来很奇怪，”他说。 “当我想要做一件事情时，特别是当我想用软件创建一些东西的时候，我有一个令人厌恶的这一层令人厌恶的事情，我不得不强调，我不是在操纵我想要做的事情，而是在写一堆文本成文本编辑器。“
“有一个非常坚定的信念，这是错误的做事方式。”
维克多拥有大卫·福斯特·华莱士（David Foster Wallace）的女士，闪电般的智慧使人难以置信。他年满40岁，身上有灰色和薄薄的胡须。他的声音几乎是温柔的，悲哀的，但他想分享他头脑里的东西，当他上了卷，他似乎跳过音节，好像超越了自己的声乐机器。
虽然他经营一个研究计算机未来的实验室，但他对技术本身的兴趣似乎比使用它的人的心灵。像任何好的制造商一样，他有一种看待世界的技术和人性化的方法。他毕业于加州理工学院电气工程系，并在加利福尼亚大学伯克利分校毕业后继续在一家开发音乐合成器的公司工作。这是一个与他的双重个性完美匹配的问题：他可以花费多少时间思考一个表演者使用键盘制作音乐的方式 - 它成为他们手中的延伸 - 他可以考虑数字信号处理的数学。
当他发表了他的名字的时候，Resig和Granger在2012年初看到的那样，维克多终于落实了似乎贯穿于他所有工作的原则。 （他实际上称之为“发明于原则”）原则是这样的：“创作者需要立即与创造的关系”。编程的问题在于它违反了原则。这就是软件系统如此难以思考的原因，并且充满了错误：程序员盯着一页文本，被从他们实际制作的任何东西中抽象出来。
他说：“我们目前对计算机程序的看法是”在五十年代后期从Fortran和ALGOL得出的。这些代码现在以C或Java（Fortran和ALGOL的衍生物）的形式在屏幕上以字母的形式，而不是一堆带有孔的卡片，不会形成它更少死亡，更不间接。
5.To Victor, the idea that people were trying to understand cancer by staring at a text editor was appalling.
There is an analogy to word processing. It used to be that all you could see in a program for writing documents was the text itself, and to change the layout or font or margins, you had to write special “control codes,” or commands that would tell the computer that, for instance, “this part of the text should be in italics.” The trouble was that you couldn’t see the effect of those codes until you printed the document. It was hard to predict what you were going to get. You had to imagine how the codes were going to be interpreted by the computer—that is, you had to play computer in your head.
Then WYSIWYG (pronounced “wizzywig”) came along. It stood for “What You See Is What You Get.” When you marked a passage as being in italics, the letters tilted right there on the screen. If you wanted to change the margin, you could drag a ruler at the top of the screen—and see the effect of that change. The document thereby came to feel like something real, something you could poke and prod at. Just by looking you could tell if you’d done something wrong. Control of a sophisticated system—the document’s layout and formatting engine—was made accessible to anyone who could click around on a page.
Victor’s point was that programming itself should be like that. For him, the idea that people were doing important work, like designing adaptive cruise-control systems or trying to understand cancer, by staring at a text editor, was appalling. And it was the proper job of programmers to ensure that someday they wouldn’t have to.
There was precedent enough to suggest that this wasn’t a crazy idea. Photoshop, for instance, puts powerful image-processing algorithms in the hands of people who might not even know what an algorithm is. It’s a complicated piece of software, but complicated in the way a good synth is complicated, with knobs and buttons and sliders that the user learns to play like an instrument. Squarespace, a company that is perhaps best known for advertising aggressively on podcasts, makes a tool that lets users build websites by pointing and clicking, instead of by writing code in HTML and CSS. It is powerful enough to do work that once would have been done by a professional web designer.
But those were just a handful of examples. The overwhelming reality was that when someone wanted to do something interesting with a computer, they had to write code. Victor, who is something of an idealist, saw this not so much as an opportunity but as a moral failing of programmers at large. His talk was a call to arms.
At the heart of it was a series of demos that tried to show just how primitive the available tools were for various problems—circuit design, computer animation, debugging algorithms—and what better ones might look like. His demos were virtuosic. The one that captured everyone’s imagination was, ironically enough, the one that on its face was the most trivial. It showed a split screen with a game that looked like Mario on one side and the code that controlled it on the other. As Victor changed the code, things in the game world changed: He decreased one number, the strength of gravity, and the Mario character floated; he increased another, the player’s speed, and Mario raced across the screen.
Suppose you wanted to design a level where Mario, jumping and bouncing off of a turtle, would just make it into a small passageway. Game programmers were used to solving this kind of problem in two stages: First, you stared at your code—the code controlling how high Mario jumped, how fast he ran, how bouncy the turtle’s back was—and made some changes to it in your text editor, using your imagination to predict what effect they’d have. Then, you’d replay the game to see what actually happened.
Victor wanted something more immediate. “If you have a process in time,” he said, referring to Mario’s path through the level, “and you want to see changes immediately, you have to map time to space.” He hit a button that showed not just where Mario was right now, but where he would be at every moment in the future: a curve of shadow Marios stretching off into the far distance. What’s more, this projected path was reactive: When Victor changed the game’s parameters, now controlled by a quick drag of the mouse, the path’s shape changed. It was like having a god’s-eye view of the game. The whole problem had been reduced to playing with different parameters, as if adjusting levels on a stereo receiver, until you got Mario to thread the needle. With the right interface, it was almost as if you weren’t working with code at all; you were manipulating the game’s behavior directly.
When the audience first saw this in action, they literally gasped. They knew they weren’t looking at a kid’s game, but rather the future of their industry. Mostsoftware involved behavior that unfolded, in complex ways, over time, and Victor had shown that if you were imaginative enough, you could develop ways to see that behavior and change it, as if playing with it in your hands. One programmer who saw the talk wrote later: “Suddenly all of my tools feel obsolete.”
When john resig saw the “Inventing on Principle” talk, he scrapped his plans for the Khan Academy programming curriculum. He wanted the site’s programming exercises to work just like Victor’s demos. On the left-hand side you’d have the code, and on the right, the running program: a picture or game or simulation. If you changed the code, it’d instantly change the picture. “In an environment that is truly responsive,” Resig wrote about the approach, “you can completely change the model of how a student learns ... [They] can now immediately see the result and intuit how underlying systems inherently work without ever following an explicit explanation.” Khan Academy has become perhaps the largest computer-programming class in the world, with a million students, on average, actively using the program each month.
Chris Granger, who had worked at Microsoft on Visual Studio, was likewise inspired. Within days of seeing a video of Victor’s talk, in January of 2012, he built a prototype of a new programming environment. Its key capability was that it would give you instant feedback on your program’s behavior. You’d see what your system was doing right next to the code that controlled it. It was like taking off a blindfold. Granger called the project “Light Table.”
In April of 2012, he sought funding for Light Table on Kickstarter. In programming circles, it was a sensation. Within a month, the project raised more than $200,000. The ideas spread. The notion of liveness, of being able to see data flowing through your program instantly, made its way into flagship programming tools offered by Google and Apple. The default language for making new iPhone and Mac apps, called Swift, was developed by Apple from the ground up to support an environment, called Playgrounds, that was directly inspired by Light Table.
But seeing the impact that his talk ended up having, Bret Victor was disillusioned. “A lot of those things seemed like misinterpretations of what I was saying,” he said later. He knew something was wrong when people began to invite him to conferences to talk about programming tools. “Everyone thought I was interested in programming environments,” he said. Really he was interested in how people see and understand systems—as he puts it, in the “visual representation of dynamic behavior.” Although code had increasingly become the tool of choice for creating dynamic behavior, it remained one of the worst tools for understanding it. The point of “Inventing on Principle” was to show that you could mitigate that problem by making the connection between a system’s behavior and its code immediate.
5.对维克多来说，人们通过盯着文本编辑器试图了解癌症的想法令人震惊。
有一个类比的文字处理。以前，在程序中可以看到的所有文档都是文本本身，并且要更改布局或字体或边距，您必须编写特殊的“控制代码”或命令，告诉计算机，例如，“这部分文本应该是斜体”。麻烦的是，在打印文档之前，你看不到这些代码的效果。很难预测你会得到什么。你不得不想像计算机将如何解释这些代码 - 也就是说，你必须在头上玩电脑。
然后所见即所得（发音为“wizzywig”）。它代表“你看到的是什么”。当你将一个段落标记为斜体时，字母在屏幕上倾斜。如果要更改边距，可以拖动屏幕顶部的标尺，并查看该更改的效果。因此，这个文件就像一个真正的东西，你可以捅和刺激的东西。只要看着你可以告诉你是否做错了事情。控制一个复杂的系统 - 文档的布局和格式化引擎 - 可以让任何可以在页面上点击的人访问。
维克多的观点是编程本身应该是这样的。对他来说，盯着文本编辑器，人们正在做重要工作的想法，如设计自适应巡航控制系统或试图了解癌症，这是令人震惊的。程序员正确的工作是确保有一天他们不必。
有一个先例足以表明这不是一个疯狂的想法。例如，Photoshop将强大的图像处理算法放在可能甚至不知道算法的人手中。这是一个复杂的软件，但复杂的一个好的合成器是复杂的，旋钮和按钮和滑块，用户学习玩像一个乐器。 Squarespace是一个可能以播客广泛宣传的公司，它通过指向和点击而不是通过在HTML和CSS中编写代码来构建网站。做一个专业网页设计师曾经做过的工作就够强大了。
但这些只是几个例子。压倒性的现实是，当有人想用电脑做有趣的事情时，他们不得不编写代码。维克多谁是一个理想主义者，看到这不是一个机会，而是作为整个程序员的道德失败。他的谈话是对武器的呼吁。
它的核心是一系列的演示，试图显示可用的工具是多么原始的各种问题 - 电路设计，电脑动画，调试算法 - 以及更好的可能的样子。他的演员是演奏家。夺取大家想象力的是讽刺的是，表面上最为微不足道的。它显示了一个分割屏幕，一个游戏看起来像马里奥一边，代码控制在另一边。随着维克斯改变了代码，游戏世界中的事情发生了变化：他减少了一个数字，重力的力量，马里奥的角色浮动;他增加了另一个，球员的速度，马里奥在屏幕上跑。
假设你想设计一个水平，马里奥，跳跃和跳出乌龟，只会使它成一个小通道。游戏程序员被用来分两个阶段来解决这个问题：首先，你盯着你的代码 - 控制马里奥跳高的代码，跑得多快，乌龟的背部弹跳，在你的文本编辑器，使用您的想象来预测他们会有什么影响。然后，你会重播游戏，看看实际发生了什么。
维克多想要更直接的东西。 “如果你有时间的过程，”他说，指的是马里奥的水平线，“你想立即看到变化，你必须映射时间到空间。”他打了一个按钮，显示不只是马里奥在哪里现在，但他将来会在什么时候在一起：阴影马里奥斯的曲线延伸到远处。此外，这个预测的路径是被动的：当维克多改变游戏的参数时，现在通过鼠标的快速拖动来控制，路径的形状发生变化。就像拥有游戏的神眼。整个问题已经减少到使用不同的参数，就像调整立体声接收机的电平一样，直到你马里奥穿线。使用正确的界面，就好像你没有使用代码一样;你直接操纵游戏的行为。
6.“I’m not sure that programming has to exist at all.”
In a pair of later talks, “Stop Drawing Dead Fish” and “Drawing Dynamic Visualizations,” Victor went one further. He demoed two programs he’d built—the first for animators, the second for scientists trying to visualize their data—each of which took a process that used to involve writing lots of custom code and reduced it to playing around in a WYSIWYG interface. Victor suggested that the same trick could be pulled for nearly every problem where code was being written today. “I’m not sure that programming has to exist at all,” he told me. “Or at least software developers.” In his mind, a software developer’s proper role was to create tools that removed the need for software developers. Only then would people with the most urgent computational problems be able to grasp those problems directly, without the intermediate muck of code.
Of course, to do that, you’d have to get programmers themselves on board. In a recent essay, Victor implored professional software developers to stop pouring their talent into tools for building apps like Snapchat and Uber. “The inconveniences of daily life are not the significant problems,” he wrote. Instead, they should focus on scientists and engineers—as he put it to me, “these people that are doing work that actually matters, and critically matters, and using really, really bad tools.” Exciting work of this sort, in particular a class of tools for “model-based design,” was already underway, he wrote, and had been for years, but most programmers knew nothing about it.
“If you really look hard at all the industrial goods that you’ve got out there, that you’re using, that companies are using, the only non-industrial stuff that you have inside this is the code.” Eric Bantégnie is the founder of Esterel Technologies (now owned by ANSYS), a French company that makes tools for building safety-critical software. Like Victor, Bantégnie doesn’t think engineers should develop large systems by typing millions of lines of code into an IDE. “Nobody would build a car by hand,” he says. “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.”
Bantégnie’s company is one of the pioneers in the industrial use of model-based design, in which you no longer write code directly. Instead, you create a kind of flowchart that describes the rules your program should follow (the “model”), and the computer generates code for you based on those rules. If you were making the control system for an elevator, for instance, one rule might be that when the door is open, and someone presses the button for the lobby, you should close the door and start moving the car. In a model-based design tool, you’d represent this rule with a small diagram, as though drawing the logic out on a whiteboard, made of boxes that represent different states—like “door open,” “moving,” and “door closed”—and lines that define how you can get from one state to the other. The diagrams make the system’s rules obvious: Just by looking, you can see that the only way to get the elevator moving is to close the door, or that the only way to get the door open is to stop.
6.“我根本不知道编程是不存在的。”
维克多进一步谈到“停止绘制死鱼”和“绘制动态可视化”。他演示了他创建的两个程序 - 第一个是动画师，第二个是为了使他们的数据可视化的科学家，其中每个程序都采用了一个过程，用于编写大量的自定义代码，并将其减少到所见即所得界面。维克多提出，几乎每个今天写代码的问题都可以提到同样的伎俩。他说：“我不确定编程是否存在，”他告诉我。 “或至少是软件开发人员”。在他看来，软件开发人员的正确角色是创建可以消除软件开发人员需求的工具。只有这样，最迫切的计算问题的人才能够直接掌握这些问题，而没有中间的代码。
当然，要做到这一点，你必须让程序员自己上船。在最近的一篇文章中，Victor恳请专业软件开发人员停止将其人才投入到用于构建Snapchat和Uber等应用程序的工具中。他写道：“日常生活的不便并不是重大问题。相反，他们应该专注于科学家和工程师，就像他把它放在我身上，“那些正在做的工作真正重要，重要的，使用真正非常糟糕的工具的人”。这种令人兴奋的工作，特别是他写道，“基于模型的设计”的工具类型已经在进行中，多年来，但大多数程序员一无所知。
“如果你真的看到你所在的所有工业产品，你正在使用的公司正在使用的是唯一的非工业产品，那里面就是代码。”EricBantégnie是Esterel Technologies（现由ANSYS所有）的创始人，该公司是制造安全关键软件工具的法国公司。像Victor一样，Bantégnie不认为工程师应该通过在IDE中打入数百万行代码来开发大型系统。 “没有人会手工制造汽车，”他说。 “代码还在，在很多地方，工艺品。当你手工制作10,000行代码时，没关系。但是，拥有3000万行代码的系统，例如空中客车，还有1亿行的代码，如特斯拉或高端车型，变得非常复杂。“
Bantégnie公司是基于模型的设计工业使用的先驱之一，您不再直接编写代码。相反，您创建一种描述程序应遵循的规则（“模型”）的流程图，计算机将根据这些规则为您生成代码。例如，如果您正在制作电梯的控制系统，那么一个规则可能是当门打开时，有人按下大厅的按钮，您应该关上门并开始移动汽车。在基于模型的设计工具中，您可以使用一个小图来代表这个规则，就好像在白板上绘制逻辑，由代表不同状态的框组成，如“门打开”，“移动”和“门关闭“，以及定义如何从一个状态到另一个状态的行。图表使系统的规则显而易见：只要看看，你可以看到，让电梯移动的唯一方法是关上门，或者打开门的唯一方法是停止。
7.“The people know how to code. The problem is what to code.”
It’s not quite Photoshop. The beauty of Photoshop, of course, is that the picture you’re manipulating on the screen is the final product. In model-based design, by contrast, the picture on your screen is more like a blueprint. Still, making software this way is qualitatively different than traditional programming. In traditional programming, your task is to take complex rules and translate them into code; most of your energy is spent doing the translating, rather than thinking about the rules themselves. In the model-based approach, all you have is the rules. So that’s what you spend your time thinking about. It’s a way of focusing less on the machine and more on the problem you’re trying to get it to solve.
“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”
On this view, software becomes unruly because the media for describing what software should do—conversations, prose descriptions, drawings on a sheet of paper—are too different from the media describing what software does do, namely, code itself. Too much is lost going from one to the other. The idea behind model-based design is to close the gap. The very same model is used both by system designers to express what they want and by the computer to automatically generate code.
Of course, for this approach to succeed, much of the work has to be done well before the project even begins. Someone first has to build a tool for developing models that are natural for people—that feel just like the notes and drawings they’d make on their own—while still being unambiguous enough for a computer to understand. They have to make a program that turns these models into real code. And finally they have to prove that the generated code will always do what it’s supposed to. “We have benefited from fortunately 20 years of initial background work,” Bantégnie says.
Esterel Technologies, which was acquired by ANSYS in 2012, grew out of research begun in the 1980s by the French nuclear and aerospace industries, who worried that as safety-critical code ballooned in complexity, it was getting harder and harder to keep it free of bugs. “I started in 1988,” says Emmanuel Ledinot, the Head of Scientific Studies for Dassault Aviation, a French manufacturer of fighter jets and business aircraft. “At the time, I was working on military avionics systems. And the people in charge of integrating the systems, and debugging them, had noticed that the number of bugs was increasing.” The 80s had seen a surge in the number of onboard computers on planes. Instead of a single flight computer, there were now dozens, each responsible for highly specialized tasks related to control, navigation, and communications. Coordinating these systems to fly the plane as data poured in from sensors and as pilots entered commands required a symphony of perfectly timed reactions. “The handling of these hundreds of and even thousands of possible events in the right order, at the right time,” Ledinot says, “was diagnosed as the main cause of the bug inflation.”
Ledinot decided that writing such convoluted code by hand was no longer sustainable. It was too hard to understand what it was doing, and almost impossible to verify that it would work correctly. He went looking for something new. “You must understand that to change tools is extremely expensive in a process like this,” he said in a talk. “You don’t take this type of decision unless your back is against the wall.”
7.“人们知道如何编写代码。问题是什么代码。“
这不是Photoshop。 Photoshop的美丽当然是你在屏幕上操作的图片是最终的产品。相比之下，在基于模型的设计中，屏幕上的图片更像是蓝图。尽管如此，以这种方式制作软件在质量上与传统编程不同。在传统的编程中，您的任务是采取复杂的规则并将其转换为代码;你的大部分精力都用于翻译，而不是考虑规则本身。在基于模型的方法中，你所有的都是规则。这就是你花时间考虑的事情。这是一种减少对机器的关注，更多地关注您想要解决的问题。
“通常是软件编码的主要问题 - 我自己编写了一个编码器，”班特尼说，“编码器不是技能。人们知道如何编码。问题是什么代码。因为大多数要求是自然语言，含糊不清，而且要求从来不是非常精确，所以应该编码的人通常会有不同的理解。“
在这种观点下，软件变得不守规矩，因为用于描述什么软件应该做的介质 - 对话，散文描述，一张纸上的图纸 - 与描述软件所做的媒体，即代码本身的媒体有太大的区别。从一个到另一个失去了太多。基于模型设计的理念是缩小差距。系统设计人员使用相同的模型来表达自己想要的内容，并由计算机自动生成代码。
当然，为了取得成功，这项工作在项目开始前必须做好很多工作。有人首先必须建立一个开发适合人们自然的模型的工具，就像他们自己制作的笔记和图纸一样，而对于计算机来说，它们仍然是明确的。他们必须制定一个程序，将这些模型变成真正的代码。最后，他们必须证明生成的代码将永远做到应该做的事情。 Bantégnie说：“幸运的是，我们受益于20年的初步背景工作。”
由ANSYS于2012年收购的Esterel Technologies成长于20世纪80年代由法国核能和航空航天工业开始的研究，他们担心安全关键代码的复杂性越来越高，越来越难以保持错误。法国制造战斗机和商业飞机的达索航空科学研究主管伊曼纽尔·莱迪诺特（Emmanuel Ledinot）说：“我从1988年开始。 “当时我正在从事军用航空电子系统。负责整合系统的人员和调试系统的人们已经注意到，这些错误的数量在增加。“80年代飞机上的机载计算机数量激增。而不是单一的飞行计算机，现在有几十个，每个负责与控制，导航和通信相关的高度专业化的任务。协调这些系统作为从传感器输入的数据飞行飞机，并且当飞行员进入命令时需要完美定时反应的交响乐。 “在正确的时间处理这些数百甚至数千个可能的事件，在正确的时间，”Ledinot说，“被诊断为通货膨胀的主要原因。
莱迪诺特决定用手写这样复杂的代码已经不再可持续了。很难理解它在做什么，几乎不可能验证它是否正常工作。他去寻找新的东西。 “你必须明白，在这样一个过程中，改变工具是非常昂贵的，”他在一次演讲中说。 “你不要采取这种类型的决定，除非你的背靠在墙上。”
8.Most programmers like code. At least they understand it.
He began collaborating with Gerard Berry, a computer scientist at INRIA, the French computing-research center, on a tool called Esterel—a portmanteau of the French for “real-time.” The idea behind Esterel was that while traditional programming languages might be good for describing simple procedures that happened in a predetermined order—like a recipe—if you tried to use them in systems where lots of events could happen at nearly any time, in nearly any order—like in the cockpit of a plane—you inevitably got a mess. And a mess in control software was dangerous. In a paper, Berry went as far as to predict that “low-level programming techniques will not remain acceptable for large safety-critical programs, since they make behavior understanding and analysis almost impracticable.”
Esterel was designed to make the computer handle this complexity for you. That was the promise of the model-based approach: Instead of writing normal programming code, you created a model of the system’s behavior—in this case, a model focused on how individual events should be handled, how to prioritize events, which events depended on which others, and so on. The model becomes the detailed blueprint that the computer would use to do the actual programming.
Ledinot and Berry worked for nearly 10 years to get Esterel to the point where it could be used in production. “It was in 2002 that we had the first operational software-modeling environment with automatic code generation,” Ledinot told me, “and the first embedded module in Rafale, the combat aircraft.” Today, the ANSYS SCADE product family (for “safety-critical application development environment”) is used to generate code by companies in the aerospace and defense industries, in nuclear power plants, transit systems, heavy industry, and medical devices. “My initial dream was to have SCADE-generated code in every plane in the world,” Bantégnie, the founder of Esterel Technologies, says, “and we’re not very far off from that objective.” Nearly all safety-critical code on the Airbus A380, including the system controlling the plane’s flight surfaces, was generated with ANSYS SCADE products.
Part of the draw for customers, especially in aviation, is that while it is possible to build highly reliable software by hand, it can be a Herculean effort. Ravi Shivappa, the VP of group software engineering at Meggitt PLC, an ANSYS customer which builds components for airplanes, like pneumatic fire detectors for engines, explains that traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisfied. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process.
The cost is compounded by exacting regulatory standards. The FAA is fanatical about software safety. The agency mandates that every requirement for a piece of safety-critical software be traceable to the lines of code that implement it, and vice versa. So every time a line of code changes, it must be retraced to the corresponding requirement in the design document, and you must be able to demonstrate that the code actually satisfies the requirement. The idea is that if something goes wrong, you’re able to figure out why; the practice brings order and accountability to large codebases. But, Shivappa says, “it’s a very labor-intensive process.” He estimates that before they used model-based design, on a two-year-long project only two to three months was spent writing code—the rest was spent working on the documentation.
8.大多数程序员喜欢代码。至少他们明白了。
他开始与法国计算研究中心INRIA的计算机科学家Gerard Berry合作，在法国的一个名为Esterel-portmanteau的工具“实时”。Esterel背后的想法是，传统的编程语言可能是很好的描述以预定的顺序发生的简单程序，就像一个食谱 - 如果你试图在几乎任何时间发生大量事件的系统中使用它们，就像在飞机的驾驶舱中几乎任何顺序 - 你不可避免地弄乱了控制软件的混乱是危险的。在一篇论文中，Berry甚至预测“低级编程技术对大型安全关键程序而言将不会被接受，因为它们使行为理解和分析几乎不切实际。”
Esterel旨在使您的计算机处理这种复杂性。这是基于模型的方法的承诺：您不是编写正常的编程代码，而是创建了系统行为的模型 - 在这种情况下，一个模型侧重于如何处理单个事件，如何优先考虑事件，哪些事件依赖于其他的，等等。该模型成为计算机将用于进行实际编程的详细蓝图。
Ledinot和Berry工作了将近10年，使Esterel能够在生产中被使用。 “在2002年，我们拥有第一个具有自动代码生成的操作软件建模环境，”Ledinot告诉我，“作战飞机Rafale的第一个嵌入式模块。”今天，ANSYS SCADE产品系列 - 关键应用开发环境“）用于生成航空航天和国防工业，核电厂，交通系统，重工业和医疗设备的公司的代码。 Esterel Technologies创始人之一Bantégnie说：“我最初的梦想是在世界各地的每一架飞机上都生成了SCADE生成的代码，而且我们距离这个目标并不遥远。”几乎所有安全关键的代码空中客车A380，包括控制飞机飞行面的系统，由ANSYS SCADE产品生成。
客户特别是航空业客户的一部分，是可以用手工建立高可靠性的软件，这可能是一个艰巨的任务。 Meggitt PLC集团软件工程副总裁Ravi Shivappa，一个建立飞机零部件（如发动机气动火灾探测器）的ANSYS客户解释说，传统项目以英文开发，规定了软件应该做的一切。 （要求可能类似于“当本节的压力超过阈值时，打开安全阀，除非手动开关被打开。”）以这种方式描述要求的问题是当您实现他们在代码中，你必须仔细检查每个人是否满意。当客户改变需求时，代码也必须改变，并进行广泛的测试，以确保在此过程中没有任何其他内容被破坏。
成本由严格的监管标准而变化。 FAA对软件安全感到狂热。该机构要求对一件安全关键软件的每个要求都可追溯到实施它的代码行，反之亦然。所以每一次代码行都会改变，它必须回溯到设计文档的相应要求，你必须能够证明代码实际上满足要求。这个想法是，如果出现问题，你可以弄清楚为什么;这种做法为大型代码库带来了秩序和责任感。但是，Shivappa说：“这是一个非常劳动密集型的过程。”他估计，在使用基于模型的设计之前，在一个为期两年的项目中，只花了两到三个月的时间编写代码 - 其余的工作在文件。
9.We already know how to make complex software reliable, but in so many places, we’re choosing not to.
As Bantégnie explains, the beauty of having a computer turn your requirements into code, rather than a human, is that you can be sure—in fact you can mathematically prove—that the generated code actually satisfies those requirements. Much of the benefit of the model-based approach comes from being able to add requirements on the fly while still ensuring that existing ones are met; with every change, the computer can verify that your program still works. You’re free to tweak your blueprint without fear of introducing new bugs. Your code is, in FAA parlance, “correct by construction.”
Still, most software, even in the safety-obsessed world of aviation, is made the old-fashioned way, with engineers writing their requirements in prose and programmers coding them up in a programming language like C. As Bret Victor made clear in his essay, model-based design is relatively unusual. “A lot of people in the FAA think code generation is magic, and hence call for greater scrutiny,” Shivappa told me.
Most programmers feel the same way. They like code. At least they understand it. Tools that write your code for you and verify its correctness using the mathematics of “finite-state machines” and “recurrent systems” sound esoteric and hard to use, if not just too good to be true.
It is a pattern that has played itself out before. Whenever programming has taken a step away from the writing of literal ones and zeros, the loudest objections have come from programmers. Margaret Hamilton, a celebrated software engineer on the Apollo missions—in fact the coiner of the phrase “software engineering”—told me that during her first year at the Draper lab at MIT, in 1964, she remembers a meeting where one faction was fighting the other about transitioning away from “some very low machine language,” as close to ones and zeros as you could get, to “assembly language.” “The people at the lowest level were fighting to keep it. And the arguments were so similar: ‘Well how do we know assembly language is going to do it right?’”
“Guys on one side, their faces got red, and they started screaming,” she said. She said she was “amazed how emotional they got.”
9.我们已经知道如何使复杂的软件可靠，但在很多地方，我们选择不是。
正如Bantégnie解释的那样，计算机将你的需求变成代码而不是人类的美好之处在于，你可以确定，实际上你可以数学证明生成的代码实际上满足了这些要求。基于模型的方法的许多优点来自于能够在飞行中增加需求，同时仍然确保满足现有方法;随着每一个变化，计算机都可以验证你的程序是否仍然有效。您可以自由调整蓝图，而不用担心引入新的错误。你的代码是用FAA的说法，“通过建设来纠正”。
尽管如此，大多数软件，即使在安全迷茫的航空世界中，也是以老式的方式，工程师在散文和程序员中编写他们的要求，用C编程语言编写它们。因为Bret Victor在他的文章中明确了，基于模型的设计比较不寻常。 “很多人在FAA认为代码生成是魔术，因此要求更多的审查，”Shivappa告诉我。
大多数程序员都是一样的。他们喜欢代码至少他们明白了。为您编写代码的工具，并使用“有限状态机”和“循环系统”的数学验证其正确性，如果不是太好，不能真正使用，这是非常深奥和难以使用的。
这是以前发生过的一种模式。每当编程从文字和零的写作中脱颖而出，最大的反对意见来自程序员。阿波罗任务中着名的软件工程师玛格丽特·汉密尔顿（Margaret Hamilton），实际上是“软件工程”一词，在1964年在麻省理工学院Draper实验室的第一年，她记得一个派别在战斗中的一次会议另一个关于从“一些非常低的机器语言”转变为接近于零和零的“汇编语言”。“最低级别的人们正在努力保持它。而且这些论据是如此的相似：“我们怎么知道汇编语言会做的对吗？”
“一方面，他们的脸红了，他们开始尖叫，”她说。她说她很惊讶他们有多么感性。
10.You could do all the testing you wanted and you’d never find all the bugs.
Emmanuel Ledinot, of Dassault Aviation, pointed out that when assembly language was itself phased out in favor of the programming languages still popular today, like C, it was the assembly programmers who were skeptical this time. No wonder, he said, that “people are not so easily transitioning to model-based software development: They perceive it as another opportunity to lose control, even more than they have already.”
The bias against model-based design, sometimes known as model-driven engineering, or MDE, is in fact so ingrained that according to a recent paper, “Some even argue that there is a stronger need to investigate people’s perception of MDE than to research new MDE technologies.”
Which sounds almost like a joke, but for proponents of the model-based approach, it’s an important point: We already know how to make complex software reliable, but in so many places, we’re choosing not to. Why?
In 2011, chris Newcombe had been working at Amazon for almost seven years, and had risen to be a principal engineer. He had worked on some of the company’s most critical systems, including the retail-product catalog and the infrastructure that managed every Kindle device in the world. He was a leader on the highly prized Amazon Web Services team, which maintains cloud servers for some of the web’s biggest properties, like Netflix, Pinterest, and Reddit. Before Amazon, he’d helped build the backbone of Steam, the world’s largest online-gaming service. He is one of those engineers whose work quietly keeps the internet running. The products he’d worked on were considered massive successes. But all he could think about was that buried deep in the designs of those systems were disasters waiting to happen.
“Human intuition is poor at estimating the true probability of supposedly ‘extremely rare’ combinations of events in systems operating at a scale of millions of requests per second,” he wrote in a paper. “That human fallibility means that some of the more subtle, dangerous bugs turn out to be errors in design; the code faithfully implements the intended design, but the design fails to correctly handle a particular ‘rare’ scenario.”
Newcombe was convinced that the algorithms behind truly critical systems—systems storing a significant portion of the web’s data, for instance—ought to be not just good, but perfect. A single subtle bug could be catastrophic. But he knew how hard bugs were to find, especially as an algorithm grew more complex. You could do all the testing you wanted and you’d never find them all.
10.你可以做所有你想要的测试，你永远都不会发现所有的错误。
达索航空公司的伊曼纽尔·莱迪诺特（Emmanuel Ledinot）指出，当汇编语言本身已经逐渐淘汰出来，现在仍然像C那样流行的编程语言，这是汇编程序员这次持怀疑态度的。难怪他说：“人们不会轻易过渡到基于模型的软件开发：他们认为这是另一个失去控制的机会，甚至超过了他们已经。
基于模型的设计（有时被称为模型驱动型工程）或MDE的偏见实际上已经根深蒂固，根据最近的一篇文章，“有人甚至认为有必要调查人们对MDE的看法，而不是研究新的MDE技术“。
这听起来就像一个笑话，但对于基于模型的方法的支持者来说，这是一个重要的一点：我们已经知道如何使复杂的软件可靠，但是在很多地方，我们选择不是。为什么？
2011年，克里斯·纽科姆在亚马逊工作了将近七年，并已升至首席工程师。他曾在该公司的一些最关键的系统工作，包括零售产品目录和管理世界各个Kindle设备的基础设施。他是亚马逊网络服务团队的领导者，该团队为Netflix，Pinterest和Reddit等网络最大的一些属性维护云服务器。在亚马逊之前，他帮助建立了全球最大的在线游戏服务Steam的骨干。他是工作安静地保持互联网运行的工程师之一。他所从事的产品被认为是巨大的成功。但他所能想到的只有那些埋在这些系统的设计中的是灾难等待发生。
他在一篇文章中写道：“人类的直觉在估计在每秒数百万个请求数量级别的系统中发生事件的真正概率很差。 “人的谬误意味着一些更微妙的，危险的bug变成设计错误;代码忠实地实现了预期的设计，但是设计无法正确处理特定的“罕见”场景。
Newcombe相信，真正关键系统背后的算法 - 存储网络数据的很大一部分的系统 - 应该不仅仅是好，而且是完美的。一个微妙的错误可能是灾难性的。但是，他知道如何找到难点，尤其是随着算法的复杂化。你可以做所有你想要的测试，你永远都不会找到它们。
11.“Few programmers write even a rough sketch of what their programs will do before they start coding.”
This is why he was so intrigued when, in the appendix of a paper he’d been reading, he came across a strange mixture of math and code—or what looked like code—that described an algorithm in something called “TLA+.” The surprising part was that this description was said to be mathematically precise: An algorithm written in TLA+ could in principle be proven correct. In practice, it allowed you to create a realistic model of your problem and test it not just thoroughly, but exhaustively. This was exactly what he’d been looking for: a language for writing perfect algorithms.
TLA+, which stands for “Temporal Logic of Actions,” is similar in spirit to model-based design: It’s a language for writing down the requirements—TLA+ calls them “specifications”—of computer programs. These specifications can then be completely verified by a computer. That is, before you write any code, you write a concise outline of your program’s logic, along with the constraints you need it to satisfy (say, if you were programming an ATM, a constraint might be that you can never withdraw the same money twice from your checking account). TLA+ then exhaustively checks that your logic does, in fact, satisfy those constraints. If not, it will show you exactly how they could be violated.
The language was invented by Leslie Lamport, a Turing Award–winning computer scientist. With a big white beard and scruffy white hair, and kind eyes behind large glasses, Lamport looks like he might be one of the friendlier professors at the American Hogwarts. Now at Microsoft Research, he is known as one of the pioneers of the theory of “distributed systems,” which describes any computer system made of multiple parts that communicate with each other. Lamport’s work laid the foundation for many of the systems that power the modern web.
For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” Programmers are drawn to the nitty-gritty of coding because code is what makes programs go; spending time on anything else can seem like a distraction. And there is a patient joy, a meditative kind of satisfaction, to be had from puzzling out the micro-mechanics of code. But code, Lamport argues, was never meant to be a medium for thought. “It really does constrain your ability to think when you’re thinking in terms of a programming language,” he says. Code makes you miss the forest for the trees: It draws your attention to the working of individual pieces, rather than to the bigger picture of how your program fits together, or what it’s supposed to do—and whether it actually does what you think. This is why Lamport created TLA+. As with model-based design, TLA+ draws your focus to the high-level structure of a system, its essential logic, rather than to the code that implements it.
Newcombe and his colleagues at Amazon would go on to use TLA+ to find subtle, critical bugs in major systems, including bugs in the core algorithms behind S3, regarded as perhaps the most reliable storage engine in the world. It is now used widely at the company. In the tiny universe of people who had ever used TLA+, their success was not so unusual. An intern at Microsoft used TLA+ to catch a bug that could have caused every Xbox in the world to crash after four hours of use. Engineers at the European Space Agency used it to rewrite, with 10 times less code, the operating system of a probe that was the first to ever land softly on a comet. Intel uses it regularly to verify its chips.
But TLA+ occupies just a small, far corner of the mainstream, if it can be said to take up any space there at all. Even to a seasoned engineer like Newcombe, the language read at first as bizarre and esoteric—a zoo of symbols. For Lamport, this is a failure of education. Though programming was born in mathematics, it has since largely been divorced from it. Most programmers aren’t very fluent in the kind of math—logic and set theory, mostly—that you need to work with TLA+. “Very few programmers—and including very few teachers of programming—understand the very basic concepts and how they’re applied in practice. And they seem to think that all they need is code,” Lamport says. “The idea that there’s some higher level than the code in which you need to be able to think precisely, and that mathematics actually allows you to think precisely about it, is just completely foreign. Because they never learned it.”
11.“几个程序员甚至在开始编码之前就会写出他们的程序将要做的事情。”
这就是为什么当他在阅读的一篇论文的附录中，他遇到了一个奇怪的数学和代码 - 或者看起来像代码 - 在一个叫做“TLA +”的代码中描述了一种算法的原因。令人惊讶的部分是，这种描述据说在数学上是精确的：用TLA +编写的算法原则上可以证明是正确的。在实践中，它允许您创建一个现实的问题模型，并不仅仅是彻底测试它，而且是彻底的。这正是他一直在寻找的：一种用于编写完美算法的语言。
代表“时间逻辑逻辑”的TLA +在精神上类似于基于模型的设计：它是一种用于写下要求的语言--TLA +称之为计算机程序的“规范”。然后可以通过计算机完全验证这些规格。也就是说，在编写任何代码之前，请先写出程序逻辑的简明大纲，以及您需要满足的限制（比如说，如果你正在编程一个ATM，一个约束可能就是你永远不会提取相同的钱两次从您的支票帐户）。然后，TLA +彻底检查您的逻辑确实满足了这些限制。如果没有，它会显示出他们如何被违反。
该语言是由图林·拉姆波特（Leslie Lamport）发明的，这是图灵获奖的计算机科学家。有一个大白胡子和褴褛的白发，以及大眼镜背后的善良的眼睛，拉姆波特看起来像他可能是美国霍格沃茨的更友好的教授之一。现在在微软研究院，他被誉为“分布式系统”理论的先驱之一，它描述了由彼此通信的多个部分组成的任何计算机系统。 Lamport的工作为许多为现代网络供电的系统奠定了基础。
对于Lamport来说，今天的软件是一个主要的原因，就是编程人员直接编写代码。他在一篇文章中写道：“建筑师在布置砖块之前画出详细的计划，或钉子被锤击。” “但是，很少程序员甚至在开始编码之前就编写了他们的程序将要做的粗略的草图。”程序员被吸引到编码的严重性，因为代码是程序的执行;花时间在别的地方看起来像是分心。而令人难以置信的微观力学代码就有一种令人满意的感觉。但是，Lamport认为，代码从来不是一个思考的媒介。他说：“这确实限制了您在编程语言方面思考的能力。”代码让你想念树林的森林：它吸引你注意个人作品的工作，而不是你的程序如何组合在一起的更大的图景，或者它应该做什么，以及它是否真的做了你的想法。这就是Lamport创建TLA +的原因。与基于模型的设计一样，TLA +将您的重点放在了系统的高级结构（它的基本逻辑）上，而不是实现它的代码。
Newcombe及其在亚马逊的同事将继续使用TLA +在主要系统中发现微妙的关键错误，包括S3后面的核心算法中的错误，被认为是世界上最可靠的存储引擎。它现在在公司广泛使用。在曾经使用TLA +的微小宇宙中，他们的成功并不是那么的不寻常。 Microsoft的实习生使用TLA +来捕获可能导致世界上每个Xbox在使用四小时后崩溃的错误。欧洲航天局的工程师使用它的代码重写了10倍，这是首次在彗星上轻轻落地的探测器的操作系统。英特尔定期使用它来验证其芯片。
但TLA +只占据了主流的一个小角落，如果可以说占据了所有的空间。即使是像纽康姆这样一个经验丰富的工程师，语言首先被看作奇异而深奥的符号动物园。对于Lamport来说，这是一个教育失败。虽然编程是在数学中诞生的，但它已经在很大程度上脱离了数学。大多数程序员不太流利的数学逻辑和集合理论，主要是你需要使用TLA +。 “很少有程序员 - 包括非常少的编程教师 - 了解基本的概念，以及它们在实践中的应用。他们似乎认为他们所需要的就是代码，“Lamport说。 “这个想法比您需要准确思考的代码高一些，数学实际上允许您仔细思考，这完全是外来的。因为他们从来没有学过。
12.“I hope people won’t be allowed to write programs if they don’t understand these simple things.”
Lamport sees this failure to think mathematically about what they’re doing as the problem of modern software development in a nutshell: The stakes keep rising, but programmers aren’t stepping up—they haven’t developed the chops required to handle increasingly complex problems. “In the 15th century,” he said, “people used to build cathedrals without knowing calculus, and nowadays I don’t think you’d allow anyone to build a cathedral without knowing calculus. And I would hope that after some suitably long period of time, people won’t be allowed to write programs if they don’t understand these simple things.”
Newcombe isn’t so sure that it’s the programmer who is to blame. “I’ve heard from Leslie that he thinks programmers are afraid of math. I’ve found that programmers aren’t aware—or don’t believe—that math can help them handle complexity. Complexity is the biggest challenge for programmers.” The real problem in getting people to use TLA+, he said, was convincing them it wouldn’t be a waste of their time. Programmers, as a species, are relentlessly pragmatic. Tools like TLA+ reek of the ivory tower. When programmers encounter “formal methods” (so called because they involve mathematical, “formally” precise descriptions of programs), their deep-seated instinct is to recoil.
Most programmers who took computer science in college have briefly encountered formal methods. Usually they’re demonstrated on something trivial, like a program that counts up from zero; the student’s job is to mathematically prove that the program does, in fact, count up from zero.
“I needed to change people’s perceptions on what formal methods were,” Newcombe told me. Even Lamport himself didn’t seem to fully grasp this point: Formal methods had an image problem. And the way to fix it wasn’t to implore programmers to change—it was to change yourself. Newcombe realized that to bring tools like TLA+ to the programming mainstream, you had to start speaking their language.
For one thing, he said that when he was introducing colleagues at Amazon to TLA+ he would avoid telling them what it stood for, because he was afraid the name made it seem unnecessarily forbidding: “Temporal Logic of Actions” has exactly the kind of highfalutin ring to it that plays well in academia, but puts off most practicing programmers. He tried also not to use the terms “formal,” “verification,” or “proof,” which reminded programmers of tedious classroom exercises. Instead, he presented TLA+ as a new kind of “pseudocode,” a stepping-stone to real code that allowed you to exhaustively test your algorithms—and that got you thinking precisely early on in the design process. “Engineers think in terms of debugging rather than ‘verification,’” he wrote, so he titled his internal talk on the subject to fellow Amazon engineers “Debugging Designs.” Rather than bemoan the fact that programmers see the world in code, Newcombe embraced it. He knew he’d lose them otherwise. “I’ve had a bunch of people say, ‘Now I get it,’” Newcombe says.
12.“我希望如果不明白这些简单的事情，就不会允许人们写程序。”
拉姆波特认为这个失败在数学上就他们正在做的事情就像现代软件开发的问题一样思考：赌注不断上升，但程序员们并没有加紧，他们没有开发出处理越来越复杂的问题所需的诀窍。 “在15世纪，”他说，“人们习惯于建立大教堂而不知道微积分，而现在我不认为你会允许任何人在不知道演算的情况下建造大教堂。而且，我希望在一段适当的很长一段时间后，如果不明白这些简单的事情，人们就不会被允许写程序。“
Newcombe不太确定这是程序员是谁的责任。 “从Leslie听说，他认为程序员害怕数学。我发现程序员不知道 - 或者不相信 - 数学可以帮助他们处理复杂性。复杂性是程序员面临的最大挑战。“他说，让人们使用TLA +的真正问题是说服他们，这不会浪费时间。程序员作为一个物种，是无情的务实的。工具像TLA + reek的象牙塔。当程序员遇到“正式方法”（因为涉及数学，“正式”程序的精确描述）时，他们的深层次本能就是反冲。
大多数计算机科学的程序员简单地遇到了正式的方法。通常情况下，这些东西被显示在一些微不足道的地方，就像一个从零开始计数的程序;学生的工作是在数学上证明程序确实从零开始计数。
“我需要改变人们对正式方法的看法，”Newcombe告诉我。即使Lamport本人似乎也没有完全把握这一点：正式的方法有一个形象问题。而解决这个问题的方法并不是要求程序员改变，而是改变自己。 Newcombe意识到，要将TLA +等工具用于编程主流，您必须开始使用他们的语言。
一方面，他表示，当他在亚马逊的同事们向TLA +介绍时，他会避免告诉他们是什么意思，因为他害怕这个名字似乎不必要地禁止：“时间行为逻辑”恰恰是这种高频在学术界打得很好，但推迟了大多数练习程序员。他也试图不使用“正式”，“验证”或“证明”这一术语，提醒程序员繁琐的课堂练习。相反，他提出了TLA +作为一种新的“伪代码”，这是真实代码的一个踏脚石，让您彻底测试您的算法，而且您可以在设计过程的早期思考。他写道：“工程师们从调试的角度来看，而不是”验证“，所以他就亚马逊的工程师”调试设计“这个题目进行了内部的谈话，而不是嘲笑程序员在代码中看到这个世界的事实，Newcombe拥抱它。他知道他会失去他们。 “我有一大堆人说，”现在我得到了，“Newcombe说。
13.This code has created a level of complexity that is entirely new. And it has made possible a new kind of failure.
He has since left Amazon for Oracle, where he’s been able to convince his new colleagues to give TLA+ a try. For him, using these tools is now a matter of responsibility. “We need to get better at this,” he said.
“I’m self-taught, been coding since I was nine, so my instincts were to start coding. That was my only—that was my way of thinking: You’d sketch something, try something, you’d organically evolve it.” In his view, this is what many programmers today still do. “They google, and they look on Stack Overflow” (a popular website where programmers answer each other’s technical questions) “and they get snippets of code to solve their tactical concern in this little function, and they glue it together, and iterate.”
“And that’s completely fine until you run smack into a real problem.”
In the summer of 2015, a pair of American security researchers, Charlie Miller and Chris Valasek, convinced that car manufacturers weren’t taking software flaws seriously enough, demonstrated that a 2014 Jeep Cherokee could be remotely controlled by hackers. They took advantage of the fact that the car’s entertainment system, which has a cellular connection (so that, for instance, you can start your car with your iPhone), was connected to more central systems, like the one that controls the windshield wipers, steering, acceleration, and brakes (so that, for instance, you can see guidelines on the rearview screen that respond as you turn the wheel). As proof of their attack, which they developed on nights and weekends, they hacked into Miller’s car while a journalist was driving it on the highway, and made it go haywire; the journalist, who knew what was coming, panicked when they cut the engines, forcing him to a slow crawl on a stretch of road with no shoulder to escape to.
Although they didn’t actually create one, they showed that it was possible to write a clever piece of software, a “vehicle worm,” that would use the onboard computer of a hacked Jeep Cherokee to scan for and hack others; had they wanted to, they could have had simultaneous access to a nationwide fleet of vulnerable cars and SUVs. (There were at least five Fiat Chrysler models affected, including the Jeep Cherokee.) One day they could have told them all to, say, suddenly veer left or cut the engines at high speed.
“We need to think about software differently,” Valasek told me. Car companies have long assembled their final product from parts made by hundreds of different suppliers. But where those parts were once purely mechanical, they now, as often as not, come with millions of lines of code. And while some of this code—for adaptive cruise control, for auto braking and lane assist—has indeed made cars safer (“The safety features on my Jeep have already saved me countless times,” says Miller), it has also created a level of complexity that is entirely new. And it has made possible a new kind of failure.
13.这个代码创造了一个全新的复杂度。而且它已经成为一种新的失败。
他已经离开了亚马逊的Oracle，在那里他能够说服他的新同事给TLA +一个尝试。对他来说，使用这些工具现在是一个责任的问题。 “我们需要在这方面做得更好，”他说。
“我自学，自从九岁以来一直在编码，所以我的本能就是开始编码。那是我唯一的 - 那就是我的思维方式：你会画一些东西，尝试一下，你会有机地发展它。“在他看来，这是许多程序员今天仍在做的。 “他们google，他们看堆栈溢出”（一个受欢迎的网站，程序员回答对方的技术问题）“，他们获得代码片段来解决他们在这个小功能中的战术关注，并将它们粘合在一起，并重复。
“这是完全正确的，直到你跑到一个真正的问题。
在2015年夏天，一对美国安全研究人员查理·米勒（Charlie Miller）和克里斯·瓦拉斯克（Chris Valasek）确信汽车制造商没有认真对待软件缺陷，表明2014年吉普切诺基可以被黑客远程控制。他们利用了汽车的娱乐系统，即具有蜂窝连接（例如，您可以用iPhone启动汽车）的娱乐系统连接到更多的中央系统，如控制挡风玻璃雨刷的系统，转向，加速和制动（例如，您可以看到后视屏幕上的指导，当您转动轮）响应。作为他们在夜晚和周末发展的攻击的证明，当一名记者在高速公路上开车时，他们被黑客入侵了米勒的车，并将其溜冰;谁知道即将来临的记者，当他们切断发动机时，惊慌失措，迫使他缓缓爬上一条没有肩膀的道路逃跑。
虽然他们并没有创造一个，但他们表示可以写出一个聪明的软件，一个“车辆蠕虫”，它将使用被砍死的吉普切诺基的车载计算机来扫描和窃取他人;如果他们想要，他们可能会同时进入一个全国范围的弱势车和SUV车队。 （至少有五辆菲亚特克莱斯勒车型受到影响，其中包括吉普车手。）有一天，他们可能会告诉他们所有人，突然间离开，或者高速切割发动机。
“我们需要考虑软件的不同，”瓦拉塞克告诉我。汽车公司长期以来由数百家不同供应商制造的零件组装最终产品。但是，这些零件曾经是纯机械的，现在，它们通常不会有数百万行代码。而对于自动刹车和车道辅助而言，适用于巡航控制的一些代码确实使汽车更安全（“我的吉普车上的安全功能已经节省了我无数次”，Miller也表示：的复杂性是全新的。而且它已经成为一种新的失败。
14.In the world of the self-driving car, software can’t be an afterthought.
“There are lots of bugs in cars,” Gerard Berry, the French researcher behind Esterel, said in a talk. “It’s not like avionics—in avionics it’s taken very seriously. And it’s admitted that software is different from mechanics.” The automotive industry is perhaps among those that haven’t yet realized they are actually in the software business.
“We don’t in the automaker industry have a regulator for software safety that knows what it’s doing,” says Michael Barr, the software expert who testified in the Toyota case. NHTSA, he says, “has only limited software expertise. They’ve come at this from a mechanical history.” The same regulatory pressures that have made model-based design and code generation attractive to the aviation industry have been slower to come to car manufacturing. Emmanuel Ledinot, of Dassault Aviation, speculates that there might be economic reasons for the difference, too. Automakers simply can’t afford to increase the price of a component by even a few cents, since it is multiplied so many millionfold; the computers embedded in cars therefore have to be slimmed down to the bare minimum, with little room to run code that hasn’t been hand-tuned to be as lean as possible. “Introducing model-based software development was, I think, for the last decade, too costly for them.”
One suspects the incentives are changing. “I think the autonomous car might push them,” Ledinot told me—“ISO 26262 and the autonomous car might slowly push them to adopt this kind of approach on critical parts.” (ISO 26262 is a safety standard for cars published in 2011.) Barr said much the same thing: In the world of the self-driving car, software can’t be an afterthought. It can’t be built like today’s airline-reservation systems or 911 systems or stock-trading systems. Code will be put in charge of hundreds of millions of lives on the road and it has to work. That is no small task.
“Computing is fundamentally invisible,” Gerard Berry said in his talk. “When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.”
“So that’s a big problem.”
14.在自驾车的世界里，软件不能是事后的想法。
Esterel的法国研究员Gerard Berry在一次演讲中说：“车里有很多错误。 “它不像航空电子设备那样在航空电子设备中非常重视。并且承认软件与机械技术不同。“汽车行业也许还没有意识到他们实际上处于软件业务。
在丰田案中作证的软件专家迈克尔·巴尔（Michael Barr）说：“我们在汽车制造业没有一个软件安全监管机构知道它在做什么。他说，NHTSA“只有有限的软件专业知识。他们从机械历史来看这个问题。“制造基于模型的设计和代码生成对航空业有吸引力的监管压力一直比较慢。达索航空公司的伊曼纽尔·莱迪诺特（Emmanuel Ledinot）推测，也可能有经济原因。汽车制造商根本不能增加零部件的价格甚至几美分，因为倍增了百万倍;因此，嵌入汽车的电脑必须减至最低限度，没有足够的空间运行尚未被手动调整的代码尽可能精简。我认为介绍基于模式的软件开发在过去十年中对他们来说太贵了。“
有人怀疑激励正在改变。 “我认为自主的汽车可能会推动他们，”莱迪诺特告诉我：“ISO 26262和自主的汽车可能会慢慢推动他们采取这种关键部件的方法。”（ISO 26262是2011年发布的汽车的安全标准。 ）巴尔说得很一样：在自驾车的世界里，软件不能是事后的想法。它不能像今天的航空公司预订系统或911系统或股票交易系统那样建立。守则将在路上负责数亿人的生命，它必须工作。这不是小任务。
杰拉德·贝里在谈话中说：“计算根本看不见。 “当你的轮胎平坦的时候，你看轮胎，平坦。当你的软件坏了，你看看你的软件，你什么都看不到。“
“那是个大问题。”
