{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系統或股票交易系統那樣創建。守則將在路上負責數億人的生命，它必須工做。這不是小任務。

傑拉德·貝里在談話中說：「計算根本看不見。 「當你的輪胎平坦的時候，你看輪胎，平坦。當你的軟件壞了，你看看你的軟件，你什麼都看不到。「

「那是個大問題。」