編程語言的複雜性

Question

在語法和語義方面是否存在編程語言的複雜性的客觀度量，而不是語言使用的複雜程度？

我讀過很多主觀評論，但很少有嚴謹的分析。

Answer 1

看一看Denotational semantics和operational semantics：

指稱語義是通過建立數學對象（被稱爲denotations），它描述了從語言表達的含義正式的編程語言的含義的方法。

的操作語義用於編程語言描述瞭如何有效的程序被解釋爲計算步驟序列。這些序列就是程序的意義。在功能程序的上下文中，終止序列中的最後一步返回程序的值。 （一般情況下，單個程序可能有很多返回值，因爲程序可能是非確定性的，即使對於確定性程序，也可能有許多計算序列，因爲語義可能沒有明確指定哪個操作序列到達該值。）

Answer 2

語言使用有多複雜是完全主觀的。

另一方面，關於語言語義有多複雜的問題可以回答，但只有在與其他語言進行比較時。但是，這些不一定有用。例如，我會給Smalltalk 1的語義複雜度，而C++的複雜度爲9.但是，我敢打賭，您正在閱讀的瀏覽器的所有內容都是用C++編寫的，而不是Smalltalk。

Answer 3

如果存在這樣的客觀度量，那麼對於評估給定用途的給定語言的效用或成本可能幾乎是無用的。它可以幫助你排除空白或腦波，但是這樣做可以輕鬆完成，而不會在這樣的客觀度量上花費資源 - 通過主觀地觀察源代碼並意識到你永遠不想對它進行認真的工作。

大多數語言都會有很多積極和消極的東西，你需要衡量你試圖達到的目標和需要滿足的條件。

Answer 4

我見過的語言的最好的措施是隨機字符串將是一個有效的程序的概率。 Perl是一種在這個規模上排名很高的語言，Ada的排名很低。

這是什麼公制意味着完全是另一個問題。

Answer 5

對我而言，當應用於編程語言時，複雜性甚至是一個明確定義的術語，這一點我不清楚。

如果「目標」你的意思是「量化」，你可以問這樣的問題

• 有多大是一個明確的語法？

• 工作yacc語法有多大？

由於幾乎沒有語言具有正式的語義，因此很難做任何定量研究。但是你可以詢問

• 相對於使用相同元語言（寫入解釋器的語言）的其他語言的解釋器，語言最簡單的解釋器有多大？這一措施與Kolmogorov的複雜性有些相關。

除了好奇心，我不清楚這個問題值得問—很難想象有用的答案。

Answer 6

作爲一般規則，更活力和抽象語法或語義或實現的，更復雜的語言（不使用，你說）。

因此，Java是一種更復雜的語言比C，因爲：

1. C具有簡單的作用域規則和Java的比較複雜的規則
2. 類型較爲複雜，方法解析和重載
3. 之類的東西插入，參數枚舉和檢查，方法重載使得編譯過程變得更加複雜。

我要說的Python比Java簡單的在此基礎上，因爲它的對象模型，而複雜的，是在還原方面爲更簡單的形式簡單。從一個時間和計算的角度來看，一個給定的語法可以簡化爲翻譯成更簡單的形式也可能是一個角度。

語言，例如，從另一方面口齒不清，有人會說是複雜的使用，但非常簡單。 Haskell也是如此。

你可以衡量的下列方式之一的複雜性，但非齊全：

1. 關鍵字，一個簡單問題的代碼行和語義的複雜性（如標識分辨率）的數量。斐波那契計算可能是一個。比較常見算法的高效實現。
2. 什麼時候會發生？名稱在運行時是否延遲，還是在編譯時解決？
3. 當給定標識符，類型和外部代碼的所有事實時，是否可以通過多種方式理解給定的代碼片段？

還有噸的方式。您可以測量給定語法的編譯過程的計算複雜度。

並非所有這些例子都是正確的。一些對象模型非常複雜，但速度非常快，因爲它們使用了一個快速基礎。自我可能是一個例子。

Answer 7

語言的BNF是一個粗略的措施 - 只爲:-)

的幾個例子味道，

• C++
• Scheme
• Lua
• Ada
• Haskell

Answer 8

我愛項目歐拉評估這一點。 :)

Answer 9

最簡單的兩個完全客觀事物看將是languaged定義的符號和關鍵字/保留字的數量，並在其BNF生產量。

對於那些擁有它們的語言，您可以考慮的另一件事是標準文檔的相對大小。但有人會說，並非所有的標準文件都是在同一層次上編寫的。

Answer 10

我認爲，如果你看看正確性證明的區域，你會發現更多的語義複雜性分析。像CSP這樣的系統（在較小的程度上，Lambda Calculus）被設計爲通過分析來處理。語言越接近作爲基本形式系統的表達，其語義立場就越簡單。

反例就像C語言一樣。無法弄清楚C程序實際上做了什麼，而不知道它將運行在哪個操作系統和硬件上。

Answer 11

與其他用戶發佈的一樣，關鍵字是衡量編程語言複雜程度的客觀指標。語法/語法將描述代碼結構的複雜程度（允許的關鍵字組合）。有與軟件質量相關的代碼度量標準來衡量一段代碼的複雜程度。

語義複雜性似乎難以衡量。它與表現力相關（編程語言層次越高表達力越強）。我看不出試圖比較以不同語言實施的不同解決方案以衡量其表達能力（即使用歐拉項目問題實施=解決方案）。問題本身和每種編程語言範例可能會對比較產生偏差。如果使用高級編程語言，我假定（從抽象的觀點來看）一個特定問題的可能實現的數量是衡量語義複雜度的一個很好的度量。

對於低級別的編程語言，可能會有興趣看看規範語言如何生成代碼（找到一個實現=針對給定問題的解決方案）。無論如何，由於抽象的限制，這一措施似乎與軟件質量代碼度量密切相關。

正如您所看到的，抽象和語義複雜性很難自動化（根據規範生成實現=解決方案）。程序員的知識，智力和心理學就在哪裏（人工智能尚未達到這一點）。