<mark id="oztn4"></mark>
0
本文作者是高級系統(tǒng)開發(fā)工程師 Torbear Gannholm。Torbear 有著 30 多年的開發(fā)經(jīng)驗，對技術(shù)很深刻的理解。對于什么是好的編程語言，他發(fā)表了一篇文章分享了自己的觀點。以下是他的全文：
這篇文章改編自我在 Cygni 科技峰會上的一次演講。
我一直認(rèn)為編程行為是在一個抽象的領(lǐng)域中完成的，只是后來才被翻譯成編程語言。編程應(yīng)該比寫作需要更多的思考。
我基本上仍然堅持這一點，但我在谷歌擔(dān)任代碼可讀性審查員的多年經(jīng)驗讓我意識到，要想很好地使用一門語言需要時間和經(jīng)驗。許多 C++程序員在使用 Java 時編寫了功能完備且合理的面向?qū)ο蟠a，但是 C++的臃腫卻不能很好地滿足 Java 中的優(yōu)雅（即使 C++程序員可能認(rèn)為它除了 Java 的「缺陷」之外大多是優(yōu)雅的）。
那么程序語言的選擇有多重要呢？有沒有一種語言可以被認(rèn)為是完美的？
什么是好的語言？
在學(xué)術(shù)界，關(guān)于什么是一門好語言的話題似乎相當(dāng)平靜，但 Tony Hoare 在 1973 年發(fā)表了一個有趣的主題演講，名為「Hints on Programming Language design」。
如果你不知道 Tony Hoare 是誰，你可能會記得他是幾年前在公眾場合為發(fā)明了「NULL」而道歉的人。他本想避免這個，但實施起來太容易了，所以他無法抗拒。他還發(fā)明了很多好東西，比如 switch 語句和通信順序、進程的思想，它們經(jīng)常出現(xiàn)在 Go 和 Ada 的并發(fā)范例中。他的大部分工作都花在追求無錯誤編程上，但他斷定這是一種浪費，因為業(yè)界對此根本不感興趣。
關(guān)于 PL 設(shè)計的提示首先提出，一種好的語言應(yīng)該支持程序員需要完成的工作——主要是設(shè)計、文檔和調(diào)試。因此，編程語言的設(shè)計應(yīng)該引導(dǎo)程序員將程序分解成可管理的部分，幫助程序員使代碼大部分具有可讀性，當(dāng)代碼發(fā)生錯誤時，不應(yīng)該太難找到并修復(fù)它們。我認(rèn)為這聽起來是一個很好的方法，盡管我還想補充一點，編程在某種程度上也應(yīng)該很有趣。
隨后，Tony Hoare 提出了一些好的編程語言應(yīng)該具備的特性：
最重要的是簡單性。一種語言應(yīng)該足夠簡單，程序員應(yīng)該能夠知道關(guān)于它的一切。似乎有證據(jù)支持這一觀點。Smalltalk 非常簡單，可以在明信片上完整地描述，它可能是最有效的通用編程語言。我發(fā)現(xiàn)一個博客曾經(jīng)總結(jié)說，完美的編程語言是你已經(jīng)知道的語言。所以這就引出了一個問題，如果堅持使用你熟悉的「糟糕」的語言，而不是切換到「更好」的語言，會不會更好？好吧，首先，盡管語言在統(tǒng)計上有顯著的可測量的差異，但是轉(zhuǎn)換的代價似乎總是比我們想象的要花更長的時間來償還。不了解一門語言全部知識的代價也可能是非常昂貴的。但這些都是無聊的答案，在這篇文章中，我們尋求完美。
安全性很重要。生成的程序應(yīng)該以可預(yù)測的方式運行，最好是無錯誤的。當(dāng) bug 簡單地給出錯誤的答案時，它尤其糟糕，就像在匯編程序中對一個固定的點號執(zhí)行浮點操作一樣。將單位附加到數(shù)字上也是可取的，但據(jù)我所知，很少有語言允許這樣做。
快速編譯是迭代解決方案所必需的。任何經(jīng)歷過 sub-second 測試運行的緊湊 TDD 周期的人都知道，不能低估此屬性的重要性。Flutter 的熱重載或類似 REPL 的探索性編程確實將生產(chǎn)率提高到了新的水平。
代碼應(yīng)該運行得快速高效。不管處理能力增長有多快，我們?nèi)匀恍枰鉀Q更大的問題。Tony Hoare 提出，一門好的語言應(yīng)該反映計算機的實際工作方式，優(yōu)化步驟應(yīng)該產(chǎn)生新的源代碼。這可能不完全實用，但我認(rèn)為我們至少可以思考一下，應(yīng)該知道哪些代碼構(gòu)造的性能特征。
可讀性：能夠理解別人的代碼在做什么。顯然，尤其在你的代碼被讀的次數(shù)比寫的次數(shù)多得多的情況下，這一點尤為重要。
市場可以保持非理性的時間比你保持償付能力的時間長。
這是經(jīng)濟學(xué)家 John Maynard Keynes 的名言。它說明了這樣一個觀點：我們并不總是認(rèn)可最好的產(chǎn)品，有可能完美的語言已經(jīng)被創(chuàng)造出來，但我們并沒有使用它。
第一候選語言
task body Controller is
begin
loop
My_Runway.Wait_For_Clear; -- wait until runway is available (blocking call)
select -- wait for two types of requests (whichever is runnable first)
when Request_Approach'count = 0 => -- guard - no tasks queuing on Request_Approach
accept Request_Takeoff (ID: in Airplane_ID; Takeoff: out Runway_Access)
do -- start of synchronized part
My_Runway.Assign_Aircraft (ID); -- reserve runway (potentially blocking call if protected
Takeoff := My_Runway; -- assign "out" parameter value to tell which runway
end Request_Takeoff; -- end of the synchronised part
or
accept Request_Approach (ID: in Airplane_ID; Approach: out Runway_Access) do
My_Runway.Assign_Aircraft (ID);
Approach := My_Runway;
end Request_Approach;
or -- terminate if no tasks left who could call
terminate;
end select;
end loop;
end;
上世紀(jì) 80 年代，上述觀點被大肆宣傳，設(shè)計師 Jean Ichbiah 認(rèn)為，十年內(nèi)，世界上只會有兩種編程語言，一種是 Lisp，另一種是 Ada。這不是一個完全不合理的想法。Ada 是在非常堅實的需求集合和與大量團隊設(shè)計競爭下產(chǎn)生的，這是因為當(dāng)時計算機語言是一門大生意。Tony Hoare 和 Niklaus Wirth 實際上是另一支半決賽隊伍的顧問，獲勝的隊伍的語言更加復(fù)雜，他試圖簡化他們的意見。Ichbiah 沒有想到的是，第一個 Ada 非常復(fù)雜，甚至連編譯器都有性能問題，所以它有點延遲，然后，第二個編程語言——C 和 Unix 出現(xiàn)了。
但是，由于美國國防部希望創(chuàng)造一種語言來取代他們擁有的 160 種左右的語言，因此在 1991 年 Ada 成為北約系統(tǒng)的強制性語言（盡管例外情況經(jīng)常被允許）。事實證明，Ada 實際上是一種設(shè)計精良的語言，除了軍事系統(tǒng)外，它在太空任務(wù)、空中交通管制和法國高速列車上也得到了證明。在危急情況下，Ada 應(yīng)該是最佳選擇。對于 C 程序中的每 100 個錯誤，對應(yīng)的 Java 程序中大約有 50 個錯誤，而 Ada 版本中只有 4 個錯誤。Ada 還有一種方言 Spark，在這里你可以正式證明你的程序的正確性。在生產(chǎn)率方面，Ada 與 Java 差不多。所以，除了復(fù)雜性，Ada 似乎非常完美。由于 Ada 在設(shè)計上的一致性，所以即使你不知道構(gòu)造的具體細(xì)節(jié)，也可以很好地了解代碼所做的事情。并且，Ada 有優(yōu)秀的文檔，文檔中包含了為什么每個特征會存在。那些用 Ada 編寫代碼的人似乎也很喜歡這一點。
Ada 繼續(xù)發(fā)展，并在 2012 年獲得了合同。不幸的是，似乎不太可能出現(xiàn) Ada 的復(fù)興。
第二候選語言
-- Type annotation (optional, same for each implementation)
factorial :: (Integral a) => a -> a
-- Using recursion (with the "ifthenelse" expression)
factorial n = if n < 2
then 1
else n * factorial (n - 1)
-- Using recursion (with pattern matching)
factorial 0 = 1
factorial n = n * factorial (n - 1)
-- Using recursion (with guards)
factorial n
| n < 2 = 1
| otherwise = n * factorial (n - 1)
-- Using a list and the "product" function
factorial n = product [1..n]
-- Using fold (implements "product")
factorial n = foldl (*) 1 [1..n]
-- Point-free style
factorial = foldr (*) 1 . enumFromTo 1
似乎每年都有至少一個博主問：今年是否終于是世界恢復(fù)理智、Haskell 終于起飛的一年？Haskell 的搜索結(jié)果似乎一致稱贊這種語言。難道我們使用其它語言的程序員只是不理智嗎？
當(dāng)然，Haskell 是一種非常有趣的語言，但它非常抽象。你真的需要六種不同的方法來實現(xiàn)階乘嗎？我想說，也許 Haskell 的主要關(guān)注點在于抽象代數(shù)和對數(shù)學(xué)的興趣上。有些人確實在生產(chǎn)中使用 Haskell，所以我也看了他們的說法：
創(chuàng)建二進制兼容的 libs 是很困難的，這意味著你基本上希望從頭開始編譯所有內(nèi)容，這可能會在一個大項目上花費數(shù)小時。
很難預(yù)測性能，一個小的重構(gòu)會導(dǎo)致代碼運行速度減慢幾個數(shù)量級，甚至有經(jīng)驗的程序員也很難診斷它。
你需要監(jiān)控你的內(nèi)存使用情況，因為它會在一些輸入上突然爆炸。
盡管有人聲稱，當(dāng) Haskell 代碼編譯時，它往往是正確的，但這似乎不像支持者所希望的那樣正確。
默認(rèn)情況下，所有東西都是無副作用的，因此如果你確實需要改變內(nèi)部代碼，則必須重寫上面的所有層（例如，沒有調(diào)試打印語句）。
Haskell 遇到了一個「神秘元組問題」，因為盡管類型的定義非常嚴(yán)格，但是每個函數(shù)中的組件可以有不同的名稱。
那些使用 Haskell 的用戶聲稱對此非常滿意，但是一位生產(chǎn)用戶說，當(dāng)他們?yōu)榱俗约核饺擞猛揪帉懘a時，他們更喜歡使用 Python。
除了類型安全性，Haskell 似乎真的沒有踩雷，所以我們可能根本沒有錯過完美的語言。繼續(xù)向前！
在一門語言中我想要什么樣的特性？
為了回答這個問題，我看了一下我使用過的語言，并嘗試指定一些我喜歡的特性。如果我設(shè)計了一種語言，我會考慮使用以下這些特性。
Cobol
PERFORM LOOP VARYING MyCounter FROM 1 BY 1 UNTIL 10 ...
RECORD
01 namn PIC A(80).
02 personnr PIC 999999-9999.
Cobol 最初是美國國防部管理行政事務(wù)的權(quán)宜之計。與所有臨時解決方案一樣，60 年后，它仍在強勁發(fā)展，主要是用在銀行和政府部門。它穩(wěn)步發(fā)展，最新的版本是 2014 年的。從 for 循環(huán)可以看出 Cobol 非常冗長。它考慮的是讓非編程業(yè)務(wù)專家也能夠讀取代碼。雖然我很欣賞這個目標(biāo)，但我不會模仿這么冗長的內(nèi)容。另一方面，record 的定義也很棒！你只需指定自己擁有哪些字段以及它們是以何種模式寫入的，計算機就會為你處理所有的讀寫操作。這是一個聲明性語法的例子，我特別喜歡模式中的一些可視組件。
FORTRAN
integer, dimension(10, 10, 10)::a
integer, dimension(-5:5)::b
c = a(1, 3:7, 5) + b(3:-1:-1)
我們程序員可能會嘲笑 FORTRAN 是一種過時的語言，但是一旦你進入世界上任何一個物理機構(gòu)，F(xiàn)ORTRAN 很可能就占據(jù)了至高無上的地位。事實證明，F(xiàn)ORTRAN 與物理學(xué)家思考工作的方式非常吻合，而且它還傾向于生成最有效的可執(zhí)行文件。高效率的一個原因是缺少指針，這使得編譯器可以進行更積極的緩存優(yōu)化。FORTRAN 當(dāng)然也經(jīng)過多年的發(fā)展，最新的規(guī)范是從 2018 年開始的。
另一種在物理系大量使用的語言是 Python，不幸的是它的運行速度非常慢。為了改進這些問題，2009 年開始的一項工作提出了編程語言 Julia，它的目標(biāo)是像 Python 一樣簡單，像 FORTRAN 一樣快。總的來說，它在這方面很成功，而且它也是一種非常好用的語言。
我從 FORTRAN 中得到的是數(shù)組/向量功能。默認(rèn)情況下，索引開始于 1，但也可以自主定義為從任何地方開始。在上面的代碼中，我們看到索引從-5 到 5 的向量 b，向量 c 是一個 5 元素向量，其中元素是 a 和 b 向量切片中相應(yīng)元素的總和。
其他語言
我使用了很多其他語言，所以在這里快速瀏覽其中一些語言，也許有些語言有鼓舞人心的效果：
BASIC 在 Apple II 上可用，它是一個簡化的 FORTRAN，pre-vectors。
Pascal 是在那之后來的。結(jié)構(gòu)化編程的典范，使用起來相當(dāng)愉快。我記得 REPEAT..UNTIL 結(jié)構(gòu)通常更符合邏輯。其它有用的特性有記錄結(jié)構(gòu)和將數(shù)值限制在范圍內(nèi)的能力等。
Forth 玩起來很有趣，但沒什么用。我記得最清楚的是，幾乎沒有什么是預(yù)先定義的，你在某種程度上定義了你自己的語言。
PostScript 被用在 Irix 窗口系統(tǒng) NeWS 上，我用了相當(dāng)多的時間來嘗試和定制它，主要是為了好玩。我還是覺得很有趣。PostScript 堆棧在一些算法中非常有用，編寫代碼有點像做拼圖。它有 postfix 符號來操作堆棧的頂部元素，所以「253 add mul」將變成 16
Tcl 在某種程度上是對 csh 邏輯異常的一種反應(yīng)，因此它被設(shè)計成具有非常邏輯和統(tǒng)一的語法，這是一件好事。它可以用作 tclsh 的 shell，但我認(rèn)為在 wish 中與優(yōu)秀的窗口工具包 Tk 一起使用更為常見。我仍然隨身攜帶著一個輕量級但功能相當(dāng)不錯的編輯器，它是用 427 行寬敞的愿望代碼編寫的。1998 年，我使用瀏覽器的 tclplugin 創(chuàng)建了一個 SPA。
我學(xué)這個計劃是因為每個人都應(yīng)該在某個時候嘗試一下 Lisp。這很有趣，但我真的沒有任何理由用它來做任何實質(zhì)性的事情。括號太多了，我沒有任何頓悟。現(xiàn)在我在探索 Shen，它有一些非常好的語法特性，嵌入式 Prolog 和一個可選的基于順序邏輯的類型系統(tǒng)。
有一次，當(dāng)我正努力用 AWK 處理一些文本時，一位同事建議我試試 Perl，書中的第一個例子起到了這個作用，于是我開始了一段和 Perl 的短暫戀情。當(dāng)我試圖理解我以前編寫的一些程序時，它很快就不起作用了。在 Perl 中，如果你知道 magic 操作符，那么任何東西都是一行。因此，Perl 將提醒你不要為各種問題發(fā)明很多操作符。
C 語言—更壞也更好
如前所述，編程語言曾經(jīng)是一門大生意。有人會創(chuàng)建一臺計算機，為它設(shè)計一個操作系統(tǒng)，然后語言編譯器是可選的附加組件。但后來 Unix 出現(xiàn)了，在構(gòu)建計算機之后，你所要做的就是創(chuàng)建一個相當(dāng)簡單的 C 編譯器，并以復(fù)制成本獲得 Unix 源代碼。既然你有 C 編譯器，你也可以免費把它裝進去。因此 C 語言成為世界上最成功的計算機病毒。
人們會不遺余力地說服自己，這簡直是免費的午餐。但僅僅因為 Unix 是用 C 編寫的，并不意味著用 C 編寫應(yīng)用程序是件好事。與當(dāng)時可用的 FORTRAN、Pascal 和其他語言相比，C 語言可能是一個讓你想自殺的極好的工具。
從另一方面來說，C 語言是最接近我們可能得到的通用語言的東西，回顧過去，很難想象編程語言、操作系統(tǒng)和許多軟件在沒有 C 語言的情況下是免費的。
我已經(jīng)成功地避免了 C++，這是我非常慶幸的。它就像是豬身上的口紅，層層疊疊的有著不必要的復(fù)雜性。有趣的是，當(dāng) GO 被顯式地替換為 C++時，結(jié)果喜歡 C++的程序員發(fā)現(xiàn)，C++ 在復(fù)雜程度上很高，這使得他們感覺自己是宇宙的主宰，除了 Haskell 之外，他們永遠不會換用任何其他語言。
DSL-解析器/生成器
在 20 世紀(jì) 90 年代末，有一些小小的活動來創(chuàng)建特定于領(lǐng)域的語言，因此有一個解析器/生成器是非常有幫助的。我使用了 yacc/lex（和 GNU 等價物 bison/flex）以及 Javacc。我對以前版本的 ANTLR 并不太感興趣，但是最新的 ANTLR4 非常好，它只是處理你編寫規(guī)則的方式，其主要思想當(dāng)然是用描述性聲明的方式描述語法。
structureLiteral: LeftBrace (keyValue Comma?)* RightBrace;
keyValue: Key valueProduction;
在某種程度上，我希望它將開始逐漸衰敗，將所有內(nèi)容編碼為 XML、YAML 或 JSON，只是為了免費獲得解析，并且需要創(chuàng)建更具表現(xiàn)力的語法，所以我肯定認(rèn)為一種語言應(yīng)該包含各種類型的解析器/生成器。
SQL-必不可少的惡魔？
with areas as (
select c.name, count(*) size from closest c
left join infinites i on c.name = i.name
where i.name is null
group by c.name
) select max(size) from areas;
每當(dāng)我懷著恐懼的心情去寫一些 SQL 語句時，我總是拿著一份「SQL for Dummies」，尤其是在有 joins 之類的時髦東西的時候。但是你可以用 SQL 做一些非常強大的事情，只需考慮用一種「普通」的編程語言來做同樣的事情。我的靈感來自于 Cygni 的一位同事，他有時使用 SQL 作為應(yīng)用程序代碼，上面的代碼來自 aventofcode 2018，在那里我開始使用 SQL 來解決問題。過了一會兒我就放棄了，因為 SQL 不擅長迭代，特別是我使用的 mariadb 版本，但是我也很欣賞 SQL 的優(yōu)點。
有一些人喜歡批評 SQL，最顯著的是「第三個宣言」，其中描述了一系列優(yōu)秀的數(shù)據(jù)庫語言，稱為「D」，這些語言也擴展到了一般編程。「D」的一個版本是「Tutorial D」，它是為教學(xué)目的而開發(fā)的，目前正在 reldb 中使用。
我認(rèn)為在語言中有一些關(guān)系概念或數(shù)據(jù)結(jié)構(gòu)是一個好主意，即使在 C 語言中做一些類似 LINQ 的事情。但是，我首先要從 SQL 中獲得的是空值處理的性能。
JavaScript-是愛是恨？
let parse = {
s: function(s) { return [Number(s)]; },
x: function(s) {
return s.split("/").map(Number); },
p: function(s) { return s.split("/"); }
}
let args = parse[m.charAt(0)](m.substr(1));
JavaScript 是許多人討厭的語言，但也有很多人喜歡它。我喜歡從一個解決方案中以聲明的方式創(chuàng)建函數(shù)圖。但我討厭當(dāng)出了問題的時候，我不知道問題在哪里。
Java
class Car {
int topSpeed() { return 200; }
}
class SportsCar extends Car {
int topSpeed() { return 350; }
}
Car myCar = new SportsCar();
System.out.println(myCar.topSpeed());
我真的很喜歡 Java。它的效率比 C 高 30%-200%，錯誤率是 C 的一半。如果我們看一下我們在「PL 設(shè)計提示」一開始所設(shè)定的標(biāo)準(zhǔn)，我認(rèn)為它覆蓋了它們。
很難選擇特定的特性，因為我認(rèn)為是組合包實現(xiàn)了這一點——許多成功所必需的東西正是很多人喜歡抱怨的。我認(rèn)為這是偉大的，但對于其他一些語言來說卻不是這樣。另一個需要考慮的是包的結(jié)構(gòu)。
我認(rèn)為 Java 的一個錯誤是它沒有簡單數(shù)據(jù)對象的記錄或結(jié)構(gòu)類型。
當(dāng)我說完這番話，總有人問我為什么不提 C#，原因很簡單，因為我沒有充分使用 C# 語言，不理解它與 Java 的區(qū)別（除了它讓我惱火的所有方面）。撇開我的偏好不談，他們似乎有著非常相似的生產(chǎn)率配置文件，而且我不知道有什么足夠的客觀原因來選擇其中一個（除了平臺問題，因為反正沒有人使用.NET core）。另一方面，視覺語言的效率似乎提高了 30%。
XSLT
<xsl:template match="section[name=’top’]/rule">
<ul class='{@class}'>
<li style='list-style: none'>
<xsl:apply-templates />
</li>
</ul>
</xsl:template>
XSLT 是我一直以來最喜歡的語言，它讓我頭腦中的各種燈都亮了起來，是引發(fā)我對編程語言進行分析的原因。我想用類似 XSLT 的風(fēng)格來編程，不管這意味著什么。當(dāng)然，所有的數(shù)據(jù)在任何時候都應(yīng)該是 XML 格式的，但是這被整個 XMLSchema 的胡說八道以及用供應(yīng)商產(chǎn)品替代 freedom 的其他做法扼殺了。
回到 XSLT，看看這種語言的力量。實際上，這里沒有太多的代碼。match 語句簡潔地指出，每當(dāng)我們遇到「rule」元素，當(dāng)它是具有值為「top」屬性的「section」元素的子元素時，我們應(yīng)該從這個模板中得到一個結(jié)果。現(xiàn)在，你通常會編寫多少代碼來確定類似的內(nèi)容？XSLT 幾乎沒有代碼來產(chǎn)生結(jié)果，它只是直接寫在那里。
我使用 XSLT 的一個「亮點」是我的視角改變了。我不是用命令編寫程序，而是用機器運行輸入，所以輸入實際上是控制輸出的程序。
XSLT 的另一個特點是它非常明顯的同質(zhì)化，也就是說，程序本身只是另一個程序可能輸出的數(shù)據(jù)。這是一個有趣的特性，但是如果你真的用它來編寫程序，可能會變得很難維護。
Go
rCh := make(chan result)
for _, n := range numbers {
go decomp(n, rCh)
}
rs := []result{<-rch code="">
Go 可能與 Haskell 完全相反，因為它缺少語言理論上必須具備的幾乎所有特性。它是一種僵硬、枯燥和缺乏想象力的語言，對程序的高效開發(fā)非常有幫助。盡管缺乏特征，但對于實踐中存在的每一個問題，在 Go 中都有一個優(yōu)雅實用的解決方案。
Go 是為了更好地適應(yīng)谷歌開發(fā)的語言類型，主要對 C++的復(fù)雜度和編譯速度的反應(yīng)。它編譯速度非常快，具有垃圾回收功能，并利用 CSP 并發(fā)模型允許輕松、安全地使用并發(fā)。
在用 Go 編程的同事們表示，他們更喜歡使用 Go，并不再糾結(jié)于如何用不同的語言「優(yōu)雅地」完成任務(wù)。
我從 Go 中得到的啟發(fā)是，不去追求某種理論上的「特征完整性」是可以的。
Dart
void part1(List<Nanobot> bots) {
var largestRangeBot = bots.reduce((a,b) => a.range > b.range ? a : b);
bool inRange(Nanobot b) {
return manhattanDistance(largestRangeBot, b) <= largestRangeBot.range;
}
var numInRange = bots.where((b) => inRange(b)).length;
stdout.writeln(numInRange);
}
當(dāng)使用 V8 引擎的 javascript 開發(fā)人員開始考慮如何使程序運行得更快時，他們意識到必須從 javascript 中去掉一些難以加速的垃圾。Dart 看起來并沒有什么特別之處，它就好像 Java 和 Javascript 有了一個嬰兒，它最終成為一種大家都已經(jīng)知道的語言。
你為什么要用 Dart？好吧，事實證明，去掉 Javascript 中的垃圾，從 Java 中加入一些好的部分，最終得到了一種語言，這種語言比它的「雙親」工作起來愉快多了，而且效率更高。盡管 web 社區(qū)幾乎完全放棄了它，但你可以使用 Dart 并將其轉(zhuǎn)換為 Javascript，代碼的效率往往比任何人手工編寫的代碼都要高。它在谷歌內(nèi)部被大量使用，因此不會有陷入困境的風(fēng)險。還有一個殺手級的移動開發(fā)環(huán)境叫做 Flutter。
到目前為止，我的主要收獲是提供一個大型且功能強大的標(biāo)準(zhǔn)庫的「包括電池」政策。
使用哪種線程安全模型？
每一種現(xiàn)代編程語言都需要一種處理并發(fā)性的好方法，我們不能寄托于運氣了。那該選哪一種呢？
不可變；純函數(shù)，如 Haskell
一種理智的、可調(diào)節(jié)的內(nèi)存模型，如 Java
單線程隔離，如 Dart 和 Javascript
通信順序進程，如 Go 和 Ada
有安全檢查規(guī)則，如 Rust
事務(wù)內(nèi)存，類似于許多語言的附加組件，而 Culjure 內(nèi)置
我不知道我會選哪一個，它們都有各自的優(yōu)勢。目前我傾向于將不可變性和事務(wù)性內(nèi)存結(jié)合起來。
我卑微的嘗試，Tailspin
現(xiàn)在我已經(jīng)考慮這個問題 15 年了，我想是時候嘗試創(chuàng)造一種語言了，希望它足夠有趣。下面是一些代碼示例。
首先是 FizzBuzz 的實現(xiàn)：
templates fizz
$ mod 3 -> #
<0> 'Fizz' !
end fizz
templates buzz
$ mod 5 -> #
<0> 'Buzz' !
end buzz
[ 1..100 -> '$->fizz;$->buzz;' ] -> [i](<''> $i ! <> $ !)... -> '$;
' -> !OUT::write
我們首先定義真正的函數(shù)，但我決定改掉名字，以避免陷入先入為主的概念。因此，我們定義了一個名為「fizz」的模板部分，它簡單地獲取輸入模 3 并發(fā)送它進行匹配。如果它是零，它輸出字符串「Fizz」，否則什么也不會發(fā)生。我們對「buzz」也一樣。
在最后一行中，我們首先創(chuàng)建一個列表/數(shù)組，其內(nèi)容是通過將整數(shù)的流/范圍從 1 到 100 轉(zhuǎn)換為一個字符串來生成的，其中第一部分是 fizz 模板的輸出，第二部分是 buzz 模板的輸出。然后將整個數(shù)組發(fā)送到提供索引 i 的數(shù)組模板中，在這里我們匹配每個元素。如果是空字符串，則輸出索引，否則輸出字符串。然后，我們將所有數(shù)組元素流式輸出，并將它們轉(zhuǎn)換為一個字符串，在最后加上一個換行符，然后將其發(fā)送到 stdout。請注意，「$」在每個轉(zhuǎn)換步驟的含義都會更改為表示進入該步驟的當(dāng)前值。
接下來，我們有一個小程序?qū)卧~放在一行上，并按相反的順序打印出來：
composer words
[ <word>* ]
rule word: <~WS> <ws>?
end words
$IN::lines -> '$ -> words -> $(-1..1:-1)...;
' -> !OUT::write
這里我們有一個不同類型的函數(shù)，一個 composer，它接受一個 unicode 字符流并將它們解析到第一行的產(chǎn)品中，一個「word」產(chǎn)品數(shù)組。
「word」按規(guī)則生成一個連續(xù)的非空白字符元素，后跟一個可選的連續(xù)空白字符元素。如果我們想忽略/丟棄空白，我們可以將該產(chǎn)品放在括號中，比如「（<ws>？）」，但是反過來，我們還是希望單詞之間有空格，所以為什么不保留它呢？
在最后一行中，我們從 stdin 讀取一系列行，并為每個行創(chuàng)建一個以 new line 結(jié)尾的新字符串，其中的內(nèi)容是解析為數(shù)組的原始行，然后將其反轉(zhuǎn)并流式輸出。然后打印字符串。
最后一個例子是計算第 n 個斐波那契數(shù)的模板部分：
templates nthFibonacci
{ N: $, n0: 0, n1: 1 } -> #
<{ N: <0> }>
$.n0 !
<{ N: <1..>}>
{ N: $.N - 1, n0: $.n1, n1: $.n0 + $.n1} -> #
<{ N: <..-1>}>
{ N: $.N + 1, n0: $.n1 - $.n0, n1: $.n0} -> #
end nthFibonacci
8 -> nthFibonacci -> !OUT::write
在模板中，我們首先創(chuàng)建一個表示當(dāng)前狀態(tài)的對象，因此 N 是輸入，n0 和 n1 是斐波那契函數(shù)的種子。此對象被發(fā)送到匹配器。
如果 N 為零，我們的工作就完成了，n0 是我們正在尋找的值。
如果 N 是 1 或更大，我們創(chuàng)建一個新的狀態(tài)對象，其中 N 減少，斐波那契關(guān)系向前一步計算。然后這個新對象被發(fā)送回匹配器。
如果 N 是負(fù)的，我們增加 N 并反向執(zhí)行斐波那契步驟，然后發(fā)送給匹配器。
這是完美的語言嗎？我不知道，但它當(dāng)然不止如此，但到目前為止，我真的很高興使用它進行編碼和開發(fā)。如果您感興趣，可以查看它的 github。
via：https://cygni.se/the-perfect-programming-language/
雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)
