關於其他語言，首先介紹壹下我自己最喜歡的壹個比較小眾的組合，Mathematica+Java/Scala。 Mathematica的優點在於：本身提供函數式的編程語言，表達能力非常強大，比如Map/Reduce是標配，很多時候不需要去做煩人的for循環或下標控制，排版經常可以直接照數學公式原樣輸入，即直觀又不容易寫錯；代碼和輸出混排的排版方式使得建模時的演算和推理過程非常流暢，甚至還可以直接生成動畫，對於找直觀理解非常有幫助（這幾點分別被IPython和R偷師了壹部分）。Mathematica的缺點在於對金融類的時間序列數據沒有很好的內建支持，使得存儲和計算都會比較低效，因此需要用內嵌Java的方式來補足，對於數據格式或性能敏感的操作都可以用Java/Scala實現。這個組合在我心目中無出其右，不論是快速建模，還是建模轉生產，都遠遠領先於其他選擇。但Mathematica的商用授權很貴，如果公司本身不認可的話很難得到支持，這是最致命的缺陷。另外隨著Python系的逐漸成熟，領先優勢在逐漸縮小，長遠看Python的勢頭更好壹些。
其他答案裏也列舉了不少其他語言，我自己既做Quant的工作，也做軟件開發的工作，這裏想從壹個軟件工程師的角度，說說我的理解。平時工作中會和壹些偏Quant背景的人合作，很容易發現建模能力好的人往往在計算機方面基礎比較薄弱（因為以前的訓練重點不在這裏）。他們也可以快速學習掌握壹種像C++，Java這樣的語言，實現很多必要的功能。但是壹方面這些語言陡峭的學習曲線和繁瑣的開發步驟會給他們真正要做的工作增加不必要的負擔，另壹方面壹旦涉及到性能敏感的情景，他們對計算機體系結構缺乏理解的缺點就容易暴露，比如說很可能他們沒有計算復雜度，內存碎片，cache miss，甚至多線程等概念，導致寫出的程序存在相當大的隱患。
即使是計算機功底紮實，如果每天的工作需要在C++，Python，R/Matlab，甚至壹眾腳本語言之前來回切換，思維負擔也會非常重，人的精力是有限的，很難同時兼顧數學建模和底層代碼調試這種差距巨大的工作。長期發展下去最可能的結果就是要麽遠離建模，專心做生產環境開發，要麽遠離生產環境，專心建模。這種局面顯然不論對個人還是團隊都是有很大弊端的。
如果深入思考這個問題，相信不難得出結論，對於Quant來說，C++這種相當面向機器的語言肯定不是最佳選擇。的確在歷史上，它比更面向機器的C已經友好了很多，但是在計算機技術飛速發展的今天，如果還需要Quant大量使用C++做建模類的工作顯然是很遺憾的事情。設想壹下妳拿到壹份股票數據，不論妳是想分析價格走勢，成交量分布，還是波動性，第壹件要做的事壹定是畫出圖來看看，有壹個直觀認識。如果妳的工具是C++，肯定有很多時間花在編譯，調試，再編譯的過程上，好容易能解析文件了，接下來怎麽算移動平均？怎麽算波動性？全都要自己寫代碼。再然後怎麽畫圖？這整個工作流簡直慘不忍睹，這些問題浪費掉妳大部分精力，而他們全部和妳真正感興趣的工作毫無關系。所以如果妳是壹個數理金融等背景的新人打算開始Quant生涯，在決定是否要投資到這項重量級技術上時需要慎重，即便它目前的市場定價可能仍在峰值。相比之下我認為Python會是更理想的選擇，即能很好的完成建模工作，也可以訓練壹定的編程技巧，使妳在必要時也能勝任壹些簡單的C++工作。
最後同意 @袁浩瀚，不要拘泥於語言，不論學習那壹種，對其他的語言還是要抱有開放的心態。另外世界變化很快，妳會發現單壹的語言分類方式其實是沒有意義的，每壹門語言在發展過程中都會逐漸吸收其他語言的特性，比如Python本身就既有C/C++/Java那樣命令式的特點，也有函數式的特點，像pandas甚至還提供類似SQL的使用方式，在其他語言或系統裏也都或多或少包含了不同的特點，可以在學習過程裏慢慢體會。