圖靈獎得主Barbara Liskov：為什么編程仍然很重要
本文轉自雷鋒網，如需轉載請至雷鋒網官網申請授權。 編者按：近日，英國科技網站The Register對麻省理工學院教授Barbara Liskov進行了采訪。Barbara于2009年因其對編程語言和系統設計的貢獻而獲得圖靈獎，在本次采訪中，Barbara總結回顧了其在70年代創建CLU編程語言早期工作，并發表了一些關于CLU編程語言的最新見解。
在即將開幕的CNCC2021（中國計算機大會）上，Barbara也將作為特邀嘉賓發表演講，為幫助參會者更好了解Barbara的最新研究及對編程理念的思考，AI科技評論特此對The Register的文章進行了編譯。
自從Barbara Liskov因其對編程語言和系統設計的貢獻而獲得圖靈獎已經有12年了，最近，她又發表了一些關于CLU編程語言的最新見解：為什么編程仍然很酷？
現年80多歲的Liskov, 正領導著麻省理工學院的編程方法論小組。最近，她一直在研究并行計算。
在90年代時她曾與一名學生一起開發了拜占庭容錯系統(Byzantine Fault Tolerance)，如今她表示，這對充滿區塊鏈的世界來說意義重大。
近年來，隨著CLU在GitHub上的出現，人們的注意力轉向了Liskov師徒在20世紀70年代初創造的這門語言時的早期工作。今天，我們詳細談談為什么直到今天，編程仍然很重要。
1. 傳統的編程并不溯源 error，也沒有泛型
當初CLU起步時，整個編程語言的狀態太差，許多東西需要創新。
例如，我們不得不正視泛型的問題。在抽象數據類型的概念出現之前，實際上已經需要泛型了。如果你寫一個排序例程，并不希望更替不同類型的數組時都要重寫。
然后是異常處理。Liskov回憶起關于恢復模型與替代方案的爭論：“問題是，在引發異常之后，控制權是否隨后恢復到引發異常的代碼，還是只是結束了該代碼？"
如果沒有一種方法從主流中分離單個異常情況，那么經常出現在遠離錯誤源的bug就越難追蹤。不幸的是，今天這種情況仍然會發生，還需要你一個一個debug。
數據抽象是一件大事，所有其他東西也都是隨之而來的。Liskov說到。“如果你回顧一下 90 年代 Java 發生的事情，他們想使用采用參數多態的方式，但他們沒有做，也從來想過優化異常處理”。
2. 發明新的計算機語言
然而，到了20世紀70年代末，科研道路出現了岔路口: 要么嘗試將這門語言商業化，要么堅持研究。Liskov選擇了研究，“在我的小組里，沒有一個學生想要創業。"
直到現在，Liskov 還一直贊揚她的學生 Russ Atkinson、Alan Snyder 和 Craig Schaffert 以及Stephen Zilles。后者也在麻省理工學院，并于 1973 年與她一起改進 CLU 基礎概念。Bob Scheifler, Eliot Moss和Toby Bloom也出現在1979年10月的CLU參考手冊上。
她指出，現在發生的事情別無二致。現如今把東西放到網上，并建立一個智囊社區是一個相對簡單的過程。但是在70年代，你必須掛靠一家公司，但即便如此，也很難獲得啟動資金。直到90年代初，情況才有好轉。
話說回來，CLU的本質是它沒有全盤接受多年來困擾其他語言的糟粕。Liskov說 ,“一門語言一旦運行，它就開始衍生遺留問題，致使你必須繼續支持所有已經編寫的代碼。這就產生了負擔。"
在過去的20年里，Liskov參與的大部分開發工作都與c++有關。她說，“程序開發不再是用機器語言完成的。這是一個很大的進步。只是提高了抽象的層次，模塊化的原則就已經被很好地理解了。"
然而，直到今天，Liskov一直希望改變的事情是：語言被強制執行封裝。但是當大家在構建一些低級平臺時，又必須違反封裝。Liskov認為封裝是編程方法的關鍵工作--模塊化，即將數據和處理數據的方法捆綁到單個單元中，并將對數據內部的訪問限制在這些方法中。這與讓編譯器強制執行是兩碼事。
不過，其他方面也有所改善。與 1970 年代可用的存儲能力相比，今天的巨大存儲能力意味著在設計模塊時，“緊湊性”可以讓“優雅”退居二線。我們總是希望它可用，但盡可能簡單。
3. 結語
Liskov現在仍對編程和技術充滿熱情，她說：“編程和軟件工程仍然是一個令人興奮的職業。我認為要牢記接口和實現之間的區別，讓行為與實現分開定義。
“如果你沒有使用強制封裝的語言(不幸的是，大多數語言都強制封裝)，那么你就必須自己強制封裝，這有助于維持區塊鏈系統完整性，廣義地說，超類的對象應該可以被子類的對象替換而不破壞應用程序。”
