量化程式的未來語言？
我即將開始我的程式方面的教育，成為一名 Quant。我知道目前正在使用哪些語言以及它們有多受歡迎。但是，我有幾個獲得電腦科學和相關工程學位碩士學位的好朋友告訴我，對於 Quants 所做的事情，C++ 和類似語言肯定已經過時了。
現在，儘管這項工作建立在自身之上，因此目前需要 C++ 和類似語言，但您是否看到未來 10 年使用的語言發生變化？如果是這樣，您預計將使用哪些預期語言？
Ps 我知道這比 Stackexchange 通常處理的要多一些討論。但是，我正在從多個站點進行投票，希望能夠就這個主題撰寫文章，以便為未來的人們提供幫助（因為網路上幾乎沒有關於這個主題的內容）。此外，由於活躍的量化網站數量有限，為了獲得足夠大的數據集以供使用，Stackexchange 是一個很好的資源。- 任何不便敬請諒解。
人們把這個問題弄錯了，因為他們總是最終討論這些語言的理論優勢，而不是這些語言的實際用途。
從理論上講：
- Haskell很優雅，具有許多理論優勢（語言簡潔性、正交性、參數多態性、ADT、高階函式、智能編譯器），已經存在 25 年，但在金融領域仍然不是主流。
- Python是一門醜陋的語言。語法因其表現力而備受推崇，但GIL、動態類型、物件導向範式等設計決策本質上是反並行的，而且幾十年後，當我們在每個處理器上擁有數百個核心時，我們的孩子將會嘲笑這種語言的晦澀和過時（以及其他諸如磁片之類的東西）。
然而今天幾乎每個人都會鼓勵你學習 Python。為什麼？
一種語言（或任何技術）的未來取決於它的社區、它的庫和開發工具的豐富性以及該語言中遺留程式碼的自我延續性，而不是它的理論優勢。我們可以寫關於我們如何討厭Java的文章；ROOT和Boost庫；XML的冗長，但這些東西仍然存在，因為它們已經獲得了大量願意圍繞它們建構生產強度工具或庫的使用者。**F#**等數十種函式式語言會來來去去，但 C++ 幾乎肯定會繼續存在，因為 C++ 中有大量遺留程式碼。此外，C++ ‘11 在理清其發展道路上的理論失誤方面是一個巨大的里程碑。
我會謹慎對待一些選擇：
- 圍繞並發和函式範式建構的語言：Scala、F#。我想說要謹慎使用它，因為它已在 Dropbox、Lime、Tower Research、Credit Suisse 等公司用於生產，但考慮到目前趨勢，這些語言需要更長的時間才能成為主流使用在處理器架構中。我很難告訴你現在在這些語言上投入時間是否會在 5 年後得到回報，但我們似乎都同意這些語言最終會。
- 特定領域的語言：Julia。不幸的是，Julia 用“C 速度數值內循環”來推銷自己。它吸引了與這些 Julia 使用者爭論這無關緊要的 Python 人群的同一子集，因為他們總是可以放棄 Cython。兩種人群都支持注定失敗的範式並吸引低質量的開發人員。（我說不幸的是，因為 Julia 有很多人們沒有意識到的東西：類型參數多方法、對稱協程、與外語的干淨介面、Lisp 影響和元程式支持等）
有了這個，我鼓勵一些選擇：
- 大哥支持的語言：Go、Swift、C#。除了Google的支持，圍棋在中國已經非常流行；微軟通過開源 C# 向前邁出了一大步；並且總是圍繞 Apple 的核心語言產生大量高質量的 UI 開發工具。
- 旨在取代 C/C++ 作為系統級程式語言的語言：D、Nimrod。D 已經得到 Facebook 的支持，Nimrod 保留了 Python 語法的表現力，同時實現了令人印象深刻的基準測試並被用於某些系統級程式項目。但請注意，兩者仍然依賴 GC 方法進行記憶體管理。
上述任何一項是否已經達到了優秀開發人員的臨界質量？我不這麼認為。真正的解決方案是程式語言真的不難學！更重要的是你學會瞭如何設計程序而不是特定的語言。花時間學習 6 種主要的語言範式：
- 命令式程式 (C) 和類抽象（C++、C#、Java）
- 功能抽象（Lisp、ML、F#）
- 聲明式規範（C++ 模板、Haskell、Prolog）
- 句法抽象（Lisp）
- 並行性（Cilk、SISAL、Clojure、Erlang）
- 協程（C#、F#、Haskell、Scheme、Icon）
量化交易經常呼叫這三個核心領域的概念：
- 算法、設計模式和資料結構：B 樹、跳過列表、記憶化、DP 等。
- 系統程式：記憶體定址、彙編、連結、堆/棧、記憶體等。
- 數據庫：規範化、兩階段送出、複製、鏡像、模式設計等。
如果您更接近頻譜的量化開發人員：
- 分佈式系統
- 作業系統
- 網路
對於這類問題，你會得到相當廣泛的答案，但我會投入兩分錢。我不會回答你關於程式語言中“下一件大事”的問題，因為那隻是一個民意調查。相反，我將向您描述一些流行的（並且成熟且得到良好支持/記錄的）語言的特徵，以便您可以根據需要選擇一種。所有這些語言都至少存在了 10 年，這表明它們經受住了時間的考驗。讓我們將 Quant 的程式需求分解為不同的部分：研究和生產。
在進行研究（例如，對策略進行回測）時，許多人（包括我自己）更喜歡使用高級解釋語言，以減少想法和測試結果之間的程式碼行數。這是因為，儘管這些語言通常比編譯的語言慢得多，但在遊戲的這個階段，程序員的時間比執行時間更有價值。然而，值得牢記的是，大量研究正在使這些語言變得更快，因為它們非常易於使用！與 C/C++/Java 等語言相比，這些語言允許您以更少的程式碼行數進行微小的更改、修復錯誤和視覺化結果。它們幾乎總是被各種擴展語言功能的領域特定庫支持（並捆綁）。
一些最流行的研究語言是 Matlab、Python（帶有 numpy）和 R。一生中從未程式過的人可以在不到一天的時間內掌握這些語言的基礎知識並編寫一些簡單的程式碼。如果您不想購買商業軟體包，可以免費替代 Matlab 的 Octave。但是，如果您選擇 Octave，您應該知道它幾乎是可用的最慢的科學計算語言。未來需要關注的一種語言是一種叫做Julia的語言. 這是一種解釋型（ish）語言，其設計方式是為了在各種數值計算任務上實現類似 C 的性能。（如果您對它們是如何做到的感到好奇，那裡有很多好論文。）這是一種非常年輕的語言，正在迅速變化（並破壞向後兼容性），因此最好等待它成熟在投入時間/資源學習之前多一點。
對於生產程式碼，您可以根據應用程序的需求選擇一種語言。如果您嘗試進行 HFT 並從解釋語言執行它，那麼您將度過一段糟糕的時光。解釋語言根本不夠快（還沒有！）與編譯語言競爭。如果您正在尋找純粹的性能，那麼您不會擊敗 C 或 C++（Fortran 被排除在此討論之外，因為我真的不是粉絲，並且永遠不會鼓勵任何人使用它）。這些語言為程序員提供了對程序執行各個方面的非常細粒度的控制，但如果您不想要控制，無論如何您都必須處理它。如果您不編寫彙編，那麼 C 將盡可能“接近金屬”。
從 C/C++ 家族倒退的第一步將帶您進入 Java 和 C#。您會在這裡註意到的最大功能是“垃圾收集”。如果您不知道這是什麼，請不要擔心細節，但它使您不必手動管理程序的記憶體消耗。由於本網站的讀者應該熟悉無免費午餐的想法，您可能會猜測這會產生性能成本，如果您依賴實時系統，這可能會嚴重影響您的工作。垃圾收集器在原本平穩的執行過程中感覺有點像打嗝。在大多數應用程序中，您不會注意到它。戰鬥機航空電子設備不是用 Java 編寫的，這是有原因的。如果您覺得您的系統需要與飛機相同級別的實時控制，請不要
從這裡開始，您開始遠離人們目前似乎用於定量程式的語言。如果不是模型執行，我會為最後一個非常重要的案例做一個案例。Bash/shell 腳本。如果您在 *nix 系統上，您絕對需要熟悉這些以自動執行系統維護任務。