函數式編程是命令式編程的一個子集嗎？

Question

函數式編程的主要特征之一是使用無副作用的函數。 但是，這也可以在命令式語言中完成。 遞歸和 lambda 函數（例如 C++0x）也是如此。 因此，我想知道命令式編程語言是否是函數式編程語言的超集。

Answer 1

我不能說它們是否是彼此的子集。 然而，我能說的是（除了真正深奧的語言）他們都是圖靈完全的 ，這意味着最終他們都是同樣強大的，但不一定具有同樣的表現力。

Answer 2

一般來說，沒有; 函數式編程是聲明式編程的一個子集（包括邏輯編程語言，如Prolog）。 許多命令式語言從函數式編程語言中借用元素，但簡單地使用lambdas或referentially-transparent函數並不能使命令式語言起作用; 函數式編程不僅僅是這些元素。

Answer 3

可以用不支持編程范例的語言實現某種編程范例。 例如，它可以在C中編寫面向對象的代碼，而不是為此目的而設計的。

函數式編程是一個完善的編程范例，最好通過Haskell，LISP等語言學習。在學好它們之后，即使你不經常使用這些語言，你也可以開始使用這些原理。您定期使用的日常語言。

有些人可能喜歡Google 在C中進行面向對象編程

Answer 4

范式是一種做事方式，有兩種主要的編程范式：命令式和聲明式。 某些語言允許混合兩種范式的事實並不意味着一種語言包含在另一種語言中，而是語言是多范式的 。

為了更清楚地說明一點，讓我繼續你的類比：如果Lisp和OCaml（例如）被認為是函數式語言，並且它們都允許命令式......那么命令式應該被視為功能的一個子集嗎？

Answer 5

大多數命令式語言沒有作為一階類型的函數，而大多數函數式函數都沒有。 （與C ++一樣，通過boost :: function。）

通過一階類型，這個meas值/變量可以是任何類型，int，bool，來自int-> bool的函數。 它通常還包括閉包或綁定值，您可以使用相同的函數，但是已經填充了一些參數。

這兩個是函數式編程主要是關於恕我直言。

Answer 6

我認為區分范式和語言可能會有所幫助。

對我來說， 范式代表“思維方式” （概念和抽象，如函數，對象，遞歸），而語言則提供“做法” （語法，變量，評估）。

所有真正的編程語言都是等同的 ，因為它們是圖靈完備的，並且理論上能夠計算任何圖靈可計算函數以及通用圖靈機模擬或模擬。

有趣的是，在某些語言或范例中完成某些任務是多么困難，這個工具對任務的適當程度。 即使康威的生命游戲也是圖靈完成的，但這並不能讓我想用它編程。

許多語言支持許多范例。 C ++被設計為C的面向對象的擴展，但是可以在其中編寫純粹的過程代碼。

有些語言隨着時間的推移借用/獲取其他語言或范例的功能（只看Java的演變）。

一些語言，如Common Lisp，是令人印象深刻的多范式語言。 可以在Lisp中編寫功能，面向對象或過程的代碼。 可以說，面向方面已經是常見的lisp對象系統的一部分，因此“沒什么特別的”。 在Lisp中，很容易擴展語言本身來做你需要做的事情，因此它有時被稱為“可編程編程語言”。 （我將在這里指出Lisp描述的是一系列語言，其中Common Lisp只有一種方言）。

我認為哪個術語，聲明性，命令性，功能性或程序性是其中的一個子集並不重要。 更重要的是了解您正在使用的工具語言，以及它們與其他工具的不同之處。 更重要的是理解范式所代表的不同思維方式，因為這些是你的思維工具。 與生活中的大多數其他事物一樣，您理解的越多，您變得越有效。

Answer 7

一種看待它的方式（不是說它是正確的方式'因為我不是一個lang設計師或任何方式的理論家）是如果語言基本上轉換成其他東西那么'別的'必須是超集的來源。 所以字節碼必然是Java的超集。 .NET IL是C＃和F＃的超集。 因此，C＃中的功能構建體（即LINQ）是IL的命令性構建體的子集。

由於機器語言是必不可少的，因此您可以采取這樣的立場：因此，所有語言都是必不可少的，因為它們只是對人類有用的抽象，然后被編譯器煮沸為程序性的，命令式的機器代碼。

Answer 8

模式映射就好

f:: [int] -> int
f [] = 0
f (x:xs) = 1 + f(xs)

例如，在命令式語言中沒有的東西是一件事。 還有類似curried函數的構造：

add2 :: int -> int
add2 = (2 +)

在大多數命令式語言中不可用

Answer 9

是的，函數式編程是命令式編程的一個子集，但是......

是的，因為沒有函數式編程，你不能在命令式編程做（盡管語法差異）。 您可以使用命令式語言“進行”函數式編程。

但是......你不能做的事情是函數式編程的關鍵特性。 通過限制你可以做的事情，

1. 你犯了一些不可能的錯誤，
2. 您啟用功能（例如程序分析、更簡單的並發、更簡單的測試等）。

函數式編程的其他好處更加主觀。 你經常聽到這些論點。

3. 狀態允許副作用。 副作用是不好的。 函數式編程沒有狀態。 沒有狀態就不可能有副作用。

這是一個可疑的好處。 首先，只有意想不到的副作用是不好的。 適當的編程實踐，例如限制對特權代碼的狀態修改，可以緩解副作用問題。 其次，函數式編程沒有內部狀態。 如果程序有 IO（訪問文件、網絡、硬件），則您有外部狀態，因此可能會產生副作用。

4. 函數式程序更容易調試。

在某些方面是的，比如知道異常的顯式路徑。 但是有狀態檢查是函數式編程沒有的調試好處。

5. 函數式程序更容易理解。

只有當您精通函數式編程而不精通命令式編程時，這才是正確的。 一方面，我對命令式編程更加流利，認為這個論點是錯誤的。