对 Quant 而言 Python 的需求高吗，除 C++ 外还有哪些流行的编程语言？
按投票排序
Python是非常适合做quant类工作的语言，本身就是科学计算方面的统治级语言，现在加入了IPython，pandas等重量级神器，为Quant类工作量身定做，而且仍在飞速发展中，以后会越来越重要。关于其他语言，首先介绍一下我自己最喜欢的一个比较小众的组合，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的使用方式，在其他语言或系统里也都或多或少包含了不同的特点，可以在学习过程里慢慢体会。
谢邀。很抱歉这个问题我三天前有看到，当时欲答又止，因为我发现我可以两行答完这个问题：1、高2、还有：Python, Java, Matlab, R, Q和某些公司内部自有语言（如高盛的自有语言）但是我不希望敷衍了事，如果回答就展开了说，说说我心中最重要的五类语言。这不仅仅是对于一个Quant必须的，而是一个丰满的程序员所必备的。在艺术中，艺永远比术重要；在Quant相关知识中，intuition永远比纯technique更加重要。两年前在Princeton，我和一位研究计算机语言的PhD两人吃饭聊天。他的主要研究方向就是新的计算机语言，及相关的逻辑学。大神如他一顿饭下来80%的时间处于放空状态，基本没在关注我，但我得到了我自以为深刻的理念：一种计算机语言是一种对应哲学的体现。因此，在我看来，有五类语言构建了一个丰满的编程能力强的Quant的一切，它们分别是：效率类语言（C、C++、Java等）、胶水类语言（Python、Ruby等）、科学类语言（Matlab、R、S等）、Alpha演算类语言（Lisp、Clojure等）、查询类语言（SQL、Q等）。这是基于我理解浅薄的分类，完全与计算机科学的规范化分类（如面对对象语言、函数类语言）不相容。持不同意见者大可付之一笑。1、效率类语言（C、C++、Java等）：老派的Quant很多都是C++高手，特别是80年代涌入华尔街的那帮MIT的高能物理博士们。在那个年代，可以选择的语言不多。要么就Fortan，要么就C/C++了。所以在当时基本上这些语言同时充当着基础架构（infrastructure）和数值计算（比如Monte Carlo）的双重目的。但是现在各种胶水类语言、科学类语言多了起来，而且由于单机性能越发强悍，效率再也不是唯一的诉求了，因此目前C++、Java大量应用于金融系统级的开发，和对于效率要求极高的实时定价等领域。从一个Quant的角度来看，这类语言最大的特点是快，编程复杂度高，维护难，同时原生语言普遍不支持向量运算。2、胶水类语言（Python、Ruby等）：我必须承认，这些语言是新世代Quant的福音。在国内工作的时候我目睹并参与了一个将原有的C++框架全部用Python重写的项目，而现在JP Morgan这边利率类产品的定价软件也在从Java像Python转移。实现同样的代码，Python、Ruby的实现速度比效率类语言快很多，而且在机器速度越来越快的今天，差距已经不是不可接受。这些语言最大的特点是比较快，编程复杂度高，维护相对简单，同时大量的包（比如Numpy+Scipy）可以轻松实现向量运算。3、科学类语言（Matlab、R、S等）：一般而言，科学类语言最大的特点是支持向量运算，同时各种附加数学、统计包极其丰富，但运算速度无法与前两类相比。在一个具体的投资/交易策略、模型投入实际使用前，你需要快速的去实现（Implement）和验证（Back-testing）你的想法。这个时候，科学类语言就有绝对的优势。验证思路有效后，再用效率类语言或胶水类语言开发成系统级组件。你可以理解为科学类语言是用来造概念车的，而前两类语言是用来量产的。而在具体的职业角度，造概念车的这帮人一般是Pure Quant，而实现量产的很多是Quant Developer。当然也有两者合一的集大成者。4、Alpha演算类语言（Lisp、Clojure等）：我第一次对这类语言感兴趣，是12年冬天接触硅谷一家科技公司时（Prismatic，人工智能新闻App），发现他们在用Clojure，也极力向我推荐Clojure。Clojure是基于Java封装的语言，可以用Java虚拟机执行。但归根结底，Clojure是Lisp这类语言。之前我长期沉迷于过程编程与面对对象等概念之中，第一次接触Lisp很不习惯，但后面开始感叹于这类语言之美。我个人感觉目前Quant界用这种语言偏少，但是不排除以后流行的可能。5、查询类语言（SQL、Q等）：SQL就不必说了，金融公司很多时候都是使用Oracle等关系型数据库，SQL是基础。而我之前几次面试也遇到了SQL的问题。Q是Morgan Stanley为了应对金融中的海量数据而采用的一种非关系型查询语言，特点是极快，有SQL的基础可以很快掌握。全面的说：如果你是做Pure Quant，整天与交易策略和模型睡觉，那么2、3是必须的；如果你是开发为主，或者是Quant Developer，那么1、2、5是必须的；如果你立志让编程不成为你做Quant的障碍，那么1-5全都是必须掌握或至少了解其思想的。不管是作为Quant还是Coder，都不可拘泥于语言。语言只是其背后设计哲学的体现。这就等同一个数量金融从业者不可拘泥于产品一样。数量金融的根基永远是供给需求、金钱时间价值这些基本的经济学理论以及现金流的相关概率这些基本的统计学思想。如果拘泥于术而非艺，那路就会越走越窄。
熟悉金融工程的人都知道，金融工程需要学习许多软件和编程语言，一般的选择是matlab，C++，再加上一种统计或计量软件，如SAS、Eviews、SPSS、stata等，但是金融工程同时还要学习许多艰深的数学知识，需要学习的数学除了一般的高等数学外还包括测度论、随机过程、鞅过程、偏微分方程等等，更不用说还要学习经济和金融方面的大量知识。如此多需要学习的东西吓跑了一大堆人，也不符合现代科学越来越细化、专业化的要求，学的太多，学习时间不够，导致很难深入金融工程内部，更别谈创新了。
有鉴于此，我们有必要研究怎么把宝贵的时间用在数学基础知识和经济金融领域知识上面，至于工具软件和编程语言，能简化尽量简化，毕竟我们又不做程序员，没必要学的太深。其中统计或计量软件中最强大的无疑是SAS，那么，能不能用一种工具代替或者近似代替matlab、C++和SAS三者呢？完全地代替显然是不现实的，只能尽可能地从最大程度上代替它们，我的选择是python。
python是一种动态编程语言，语法很简洁，某种程度上类似于matlab和SAS，结合python的几种强大的科学计算类库：NumPy（主要是数学基础方面的）、SciPy（数值计算上很强大，包含NumPy）、SymPy（符号运算库）、matplotlib（绘图库）、Traits（程序界面库）等，可以近似地替代matlab、C++和SAS三者。原因在于：
第一，python首先是一种完整的动态编程语言，虽然执行效率比不上C++，但是开发效率远远高于C++，学习成本较小，对于金融工程这种专业来讲比C++更加合适，毕竟我们自己做模型的时候更在乎的是如何快速实现模型，而不是模型运行快几秒钟，当然对于金融方面的大规模产品，还是用C++更加合适，这就是程序员的事情了，我们一般不会去编写几万行代码的程序。从这个方面来讲，python可以代替C++。
第二，python利用NumPy、Pandas、SciPy、SymPy、matplotlib等类库，可以完成matlab 90%以上的功能，欠缺的只是极特殊的函数。而且这些都是免费的，中国现在虽然盗版很严重，但是明显正在向正版化的方向发展，以后谁保证能得到免费的matlab？这些类库也在一直发展中，超过matlab只是时间问题。不仅如此，python利用它的界面库做程序界面是非常方便的，用的VB的都还记得可视化编程的爽快，python也可以实现，而且可以实现的更好，这是matlab远远不足的地方。利用这个功能，我们可以用python做好程序后发布给其他人使用，就像使用word这种程序一样，这种方便程度是目前matlab远远不及的。再比如我们要抓取网上的一些数据，利用matlab就比较麻烦，而利用python就极为简单。python可以大大加快我们研究的自动化程度和简单程度，需要的只是好好学习一段时间python而已。
第三，python代替SAS。这个方面其实python没有明显的优势，在统计功能上比不过SAS，但是利用python的好处在于：我们不需要再次学习SAS语言，特别是对于金融工程专业来讲，没有那么多时间和必要性去学习SAS，我们又不是搞专业数据统计的。SAS的大部分功能python都可以实现，不过实现起来比SAS困难一些，对于金融工程专业的人来说，选择SAS还不如选择python+Eviews的组合，Eviews是非常简单，几乎不需要学习。python的学习比较简单，也非常值得。
选择python的最大好处在于可以节省学习的时间，而且弹性较强，可以适应未来多变的需求。剩下的时间不如去好好研究下怎么在金融工程理论与应用方面创新，就不需要浪费时间在学习工具上了。
国外的话 比较流行的应该是R+Python，R用来快速实现和验证你的策略。Python的好处在于速度比较快，移植到C++之类的也比较方便。国内的情况就比较复杂了。首先是用Matlab的比R多多了，国外有版权问题，国内几乎没有这个问题，学校里面又以教Matlab的巨多，所以导致了毕业以后用Matlab的人比较多。从金融工程的使用者来说这个比例应该在4:1到5:1之间。其次Python也有一些用户，但是在行业内比想象的少，更不用说C++和JAVA之类的。SAS是一个比较特别的异类，行业内有不少人用。当然比不过Matlab，数量应该和R类似，这点上我没有精确的数字。用SAS的原因主要是因为和SQL之间的交互效率很高，但是SAS的编程方式比较奇怪。SQL还是很有必要懂一点的，虽然未来的趋势可能是大家更多的使用API的方式提取数据，但是如果要追求稳定性和速度，落地数据库的方式还是逃不了的。所以做金融工程的最好还是要会SQL，当然只需要select和复杂的join就可以了。SQL方面，大家主要用SQL server和Oracle。目测MySQL非常少。最后还有一个大家没有提到的，但是非常重要的就是VBA，因为Excel的关系，其实VBA是一个很好地实现工具。也很多人用，国外的金融行业里面VBA的应用也是非常多的，作为快速实现和展示的工具，VBA是非常好的东西。
13年的问题至今，不知道还有没有人关注，楼主是否已经总结出自己的经验？我是做产品的，坦率讲谈到编程我也是在学习、探索、理解中，就和大家分享下我的理解吧：1、关于语言，我就从国内普遍应用角度说，策略研究类：R\matlab，策略开发类：python，c++、c#；其他还有很多，这里不赘述。从我接触国内的情况来看，越来越多的趋向于python和c++的组合，因为用python开发效率更高，而c++执行效率更高。虽说差别‘感觉’不大，但是高频一些的策略，还是有差别。用python的大多都是自己研发的平台，支持python语言的量化交易产品并不多，有掘金、wind、可能还有，不缺定了。其他都是基于一种工具进行深度定制的。2、对艺和术的理解，感觉像先有鸡还是先有蛋的问题。我认为语言是敲门砖，举个例子：这和开发工程师一样，必须总要学习新的东西，了解国外的前沿技术，以前国内的老工程师，都买国外的工程书看，虽然英文看着费劲，但是必须与时俱进。我认为quant更是如此。为什么？无论从哪个角度讲，量化交易，一定是技术驱动的业务创新的。3、和大家分享一些我的总结：Pycharm，IDE对比，学习链接：Python：R:最后分享一个：当然还有一些，python的Ta-lib的东西，就不在这里写了。感兴趣的可以交流互相学习。有不足的大家请批评指正。
语言只是工具。重要的是你掌握一种新语言要多少时间，而不是你已经会了多少。谈得上基础的只有C（虽然纯quant researcher未必会用它写一句code)，其他都是酌情使用，会用一两种即可。quant常用语言标准有以下几点：1、package丰富程度，2、community活跃度（方便上stackoverflow问题），3、API支持情况，包括maketdata和execution两类，4、代码效率，5、多线程和端口通讯能力。五项全能的没有，python除了4差点其他还可以，适合作主力语言形成系统骨架。R的话只有1-2还成，这几年有下坡路趋势。c++/java之类更适合risk和IT做成熟产品，做研究环境太差。functional语言主要还是做risk和pricing的Q quant用的多。python的效率问题这几年有numba和pypy提供JIT以后改善很多。
补充一下吧，C++在HFT里目前应该还是不可替代，分钟级的Algo很多已经是Java了，C++的问题是好程序员少且贵，不容易维护。Q不是MS专属的，它是KDB自带的解决方案，理论上也可以用别的API去解决Accessing KDB的问题。
严格的说，quant需要掌握各种语言，不过perl,python,matlab,r,sql的语法相对简单。一般python之类的都是做研究用的，真正写大程序问题很多。写production code的话还是编译以后的比较好，C++至今还是主流，当然一般GUI都用C#写。关键不是语言，而是一个人对整个架构的理解，包括算法，甚至底层知识（内存操作，硬件等）。
做这行的要么会越做越快，要么会越做越难大，然后越做越复杂。但是：如果要快，就C++；能做复杂问题的，就Matlab。我的观点，一个完整高效的交易平台和策略交易系统中，C++ + Matlab是必备最佳的。这是上面提到的五种编程语言里的核心的最佳搭配，其余的比如数据库语言，胶水语言，等等的可以人任意发挥。有一点是肯定的，像Python这样的胶水语言显然是代替不了的C++的核心作用。
每个Quant组里因为人员发展原因都会有他们偏爱的程序。出现很多开发语言，不是流行的问题，那是换编程语言，时间成本太高的问题。
做交易员出生的人一般不会C++，花个把星期学一下python比较现实。程序员出生的 C++可以很牛叉，但不了解市场。像Matlab这样的工具虽然国内用的人很多，也是限于工具运算的多，Matlab的核心是C写的，但是国内研究过Matlab与C++接口的又有多少人能做到把Matlab当C++用，实现高频级别的复杂的统计套利策略？
所有无法解决的技术问题时的中间状态都会归结于编程能力与时间成本的平衡问题。
所以，如果你有时间又想一辈子做好这行，那么老老实实学习C++吧。呵呵 Good Luck~
没人注意到Julia吗？虽然Julia的库目前还不成熟，但考虑到其开发容易程度和执行速度，将来会有一定的占有率的。
已有帐号？
无法登录？
社交帐号登录各主流编程语言对比_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
各主流编程语言对比
上传于||文档简介
&&编​程​语​言​简​介
阅读已结束，如果下载本文需要使用2下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩19页未读，继续阅读
你可能喜欢&p&题主目前在国内一家对冲基金的负责期权交易部门。前期在调研了国内现有的期权做市商和高频交易平台后：RTS（太弱）、Horizon（太复杂）、Orc（得自己开发整套系统接口）、风软（功能过得去，但太封闭） 等等，没有找到满意的解决方案，遂决定自主开发。&/p&&br&&p&整个平台核心完全基于python开发，交易接口的封装使用了C++的boost.python库，参与了之前的中金所期权测试和郑商所期权做市商比赛，上几张截图：&/p&&img src=&/741dcfa9faefeb234c81e6be_b.jpg& data-rawwidth=&1928& data-rawheight=&1080& class=&origin_image zh-lightbox-thumb& width=&1928& data-original=&/741dcfa9faefeb234c81e6be_r.jpg&&&p& 波动率管理&/p&&br&&p&&img src=&/ec73b0d4fa674fa34aa6_b.jpg& data-rawwidth=&1928& data-rawheight=&1080& class=&origin_image zh-lightbox-thumb& width=&1928& data-original=&/ec73b0d4fa674fa34aa6_r.jpg&&风控和希腊值管理&/p&&br&&p&&img src=&/07ffe4d44bf9c58dff5fb6_b.jpg& data-rawwidth=&1928& data-rawheight=&1080& class=&origin_image zh-lightbox-thumb& width=&1928& data-original=&/07ffe4d44bf9c58dff5fb6_r.jpg&&做市报价&/p&&br&&br&&br&&p&春节长假期间突然萌发了启动一个开源量化交易平台项目的想法，原因包括：&/p&&p&1.
国内很多的机构和个人量化投资者，在受够了一些商业软件的束缚后（TB、金字塔等）想基于柜台API进行直接开发，然后在C++的.h头文件、网上一些不成体系的开发指南、不知道如何构建程序核心架构等等问题中赚的一头雾水后放弃，知乎上就有不少相关的提问。&/p&&p&2.
国外有相当多类似的项目，比如AlgoTrader、Tradelink、Marketcetera等等开源交易平台有着大量的用户和活跃的社区。目前国内据我所知只有海风的AT平台项目（基于C#），QuantBox项目目前更多只是一个柜台API的统一化封装（当然封装的非常漂亮，有兴趣的建议直接看源代码）。&/p&&p&3.
在题主的整个求学经历中，发现最佳的学习方式之一就是自己当老师，当你试着把某种知识教给别人时，你对这种知识的掌握会更加深入。&/p&&p&4.
抛砖引玉，题主只是交易员出身，编程算是半路出家，不专业的地方很多，通过这个项目和业内人士多多交流。&/p&&p&5.
国内目前最大量化交易社区应该是C#（交易）和Matlab（研发），TB之类的就算了。而能兼顾交易和研发的python社区居然十分弱小，实在是不能忍。&/p&&br&&br&&p&整个平台主要使用了以下几种技术：&/p&&p&C++
boost.python封装API&/p&&p&python实现核心功能&/p&&p&PyQt事件循环和GUI&/p&&br&&p&开源项目中不会包括策略之类的算法逻辑以及上面截图中的业务逻辑（商业机密啊）。&/p&&br&&br&&p&想请教对于这么一个开源项目的建议，比如：&/p&&p&开源协议（GPL、LGPL等等？）&/p&&p&发布平台（GitHub、开源中国？）&/p&&p&社区建设（QQ群、知乎、豆瓣？）&/p&&p&项目维护&/p&&p&等等&/p&&br&&p&总之题主应该属于尽管会编程，但仍然是程序员圈子的圈外人这么个状态，所以任何建议都欢迎。&/p&&br&&p&最后求一个知乎专栏的邀请。&/p&&br&&p&&b&更新&/b&&/p&&p&突然发现可以编辑问题，更新下目前的项目状态：&/p&&p&已经放出了LTS API的python封装以及事件驱动引擎，项目地址是&a href=&///?target=http%3A///vnpy/vnpy& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/vnpy/vnpy&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& &/p&&p&项目的主页发布在&a href=&///?target=http%3A//vnpy.github.io/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&vn.py&i class=&icon-external&&&/i&&/a&，回头教程会放在这个上面&/p&&br&&br&&p&&b&更新&/b&&/p&&p&再次更新目前的项目状态：&/p&&p&1. 完成了CTP的Python封装，发布在github上vn.py下的vn.ctp中&/p&&p&2. 完成了基于vn.lts和vn.ctp的DEMO交易程序开发，发布在vn.demo中，可以通过nuitka编译为独立的exe程序脱离Python环境运行&/p&&p&3. 在&a href=&///?target=http%3A//vnpy.org& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&vnpy.org&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&发布了5篇系列教程，包括API的封装设计、事件驱动引擎、DEMO程序的交易接口对接，接下来还会发布中层主引擎设计以及GUI开发等内容弄&/p&&p&4. 创建了交流QQ群，在QQ里直接搜索“vn.py框架交流群”&/p&&br&&p&&u&&b&最后，招实习生！！！&/b&&/u&&/p&&p&硬性要求有两条：&/p&&p&1. Python编程经验（没有的能看完learnpythonhardway之类的能运行起程序也行，反正如果真招了我会手把手教你）。&/p&&p&2. 流利的英文读写能力（很多资料都是英文的，没办法）&/p&&br&&p&软性要求如下：&/p&&p&1. 极为强烈的学习欲望和成功欲望，想成为成功的交易员必备条件&/p&&p&2. 耐心，学编程和交易的路还是挺曲折的&/p&&br&&p&公司：上海一家量化私募&/p&&p&岗位：量化交易实习生&/p&&p&工作地点：上海浦东&/p&&p&工资：无（主要缺点）&/p&&p&实习期：三个月到半年&/p&&p&工作内容：跟着我开发量化交易程序和策略（Python为主，可能用到C++），通过一定考验有机会操盘（当然是根据交易计划，量化并不等于全自动）&/p&&br&&p&实习结束后能通过测试有机会转正。&/p&&br&&p&感兴趣的话请把简历发送到vn.&/p&&br&&p&谢谢！&/p&
题主目前在国内一家对冲基金的负责期权交易部门。前期在调研了国内现有的期权做市商和高频交易平台后：RTS（太弱）、Horizon（太复杂）、Orc（得自己开发整套系统接口）、风软（功能过得去，但太封闭） 等等，没有找到满意的解决方案，遂决定自主开发。整个平台核心完全基于python开发，交易接口的封装使用了C++的boost.python库，参与了之前的中金所期权测试和郑商所期权做市商比赛，上几张截图： 波动率管理…
主要看你的定位在哪里。简单说，作为一个业余时间的练手就是很赞的作品，但要定位成专业交易平台则问题很多：Python的问题不仅仅在于延迟性能，更致命的是这个弱类型语言很难做编译期静态检测，系统复杂以后很容易写出 bug。这对于交易系统这种对系统稳定性有苛刻要求的系统来说是很难接受的。你的架构看起来是图形界面和策略代码都跑在一个进程里，如果这是真的那就意味着任何一个 UI 上的问题都有可能导致交易策略崩溃。看你的截图，开发这么复杂的图形界面要想不出问题，很难。截图上还可以看出这个系统运行起来会同时跑很多个 Order。Order 多了以后首先是上面说的稳定性隐患很致命，你的系统一旦崩溃，那些还在运行的 Order 估计多半要手动清理了，手慢了可能会有直接损失。另外系统需要实时收发行情数据来更新界面，如果架构上没有解藕的话，很可能意味着界面更新慢会阻塞网络数据的收发（俗称 backpressure）。事件驱动引擎要做好并不容易。比如有名的
就是相当复杂的系统（而且用户体验还很差）。用 Python 写，我觉得难度更加大。基本上，从计算机系统的角度考虑，我觉得最好还是不要定位成一个大而全的一体化交易系统为好。你作为一个交易员，如果能把自己熟悉的业务部分的若干模块提炼出来做精就很有价值了。开源协议 GPL 系是大忌，慎入。GPL 的意思是用了你的代码以后，自己的二次开发也要强制开源，这意味着所有的交易策略都要开源，那就没人敢用你的东西了。如果有兴趣在系统开发上向前走，几点建议是：核心策略相关的代码用强类型语言编写，做足检查和测试至少在进程粒度上把图形界面和交易策略分开现在的图形界面是 Web 的天下了，试着学学 HTML/CSS/Javascript。看到题主的回答中这一段非常有感触：但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！1. 由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭2. 为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。3. 交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。4. 某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。这可以说是纯 IT 背景的人入行会遭遇的最大的挑战，一个 Pure IT Role 其实是很难适应交易这个行业的。干这行是非常需要复合型人才的，IT 如果只满足于在自己一亩三分地恪守软件开发的职责，后果就是 Trader 们被逼自己写代码，这实在是一出悲剧。
&p&多谢大家的回答，一些问题的交流就发在我的这个回答里了。&/p&&br&&p&特别感谢何波、董可人、Mr Mistake、LIKE&/p&&br&&p&&b&首先，为什么用python&/b&&b&？&/b&&/p&&p&目前本人所在的公司一共有三款平台，分别基于C++， C#和python。其中C#和python平台都是由交易员开发；C++平台则是由专职IT团队作为一个通用平台开发，内部组件进行了封装（交易员不可见），对外提供行情、交易的API用于策略开发（除了C++ 外也包括C#和python可用的API）。&/p&&br&&p&理论上这款C++平台应该是最为稳定和强大的，由专业人士设计，同时采用封装核心，暴露API，支持组件模块开发，linux服务器运行的形式。&/p&&br&&p&但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！&/p&&p&1.
由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭&br&&/p&&p&2.
为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。&/p&&p&3.
交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。&/p&&p&4.
某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。&/p&&br&&p&用web开发来做比较的话，C++实现的量化交易平台像是java在网络开发领域的地位，强大（几乎无所不能）、稳定（无数大公司的支持），但是也很臃肿（你一两个人开发试试）。&/p&&br&&p&以上的原因促成了我坚持使用python开发一个交易平台，这款平台的定位好比于node.js为前端工程师（用户体验的直接缔造者）提供了一个简洁又不失强大的后端平台，主要的目标用户群是中小型量化团队（根据我的经验，绝大部分的券商自营、期货资管和基金量化部门都不大）、专业的交易员团队（可以雇得起少量专职IT）以及一部分打算从互联网领域转行来的程序猿们（python在互联网公司用的不少）。&/p&&br&&p&总结下python在量化平台开发方面的优缺点（欢迎补充）。&/p&&p&优点：&/p&&p&1.
动态语言的快速开发特性，封接口有boost.python，写GUI有PyQt，时间序列有numpy，等等，几乎你想干的事都有现成的库可以用，这里吐槽下公司大牛自己写C++里的简单移动平均（SMA）算法，确实比常规实现快不少，但似乎对pnl没什么直接帮助。&/p&&p&2.
学习成本低，这点算是个共识了吧？&/p&&p&3.
真需要低延迟的时候，胶水语言很容易通过其他语言拓展：cython, ctypes, boost.python等等。&/p&&p&4.
运行速度足够快，也许和C++比起来确实慢了不少，但是就我的经验来看，这点速度延迟对90%的策略pnl毫无影响。&/p&&br&&p&缺点：&/p&&p&1.
GIL，该死的全局锁导致python无法有效利用多核CPU的性能，尽管可以通过拓展绕过去，但还是没有其他语言原生多线程利用多核的方案来的简便。&/p&&p&2.
没有静态类型检查，重构的时候确实有点痛苦，不过一个良好的编程范式可以有效解决这个问题。&/p&&p&3.
不适合用来搞超高频策略（追求微秒级延迟的差异），得承认这点python确实搞不过C++。常规基于TICK级数据的策略没问题。&/p&&br&&br&&p&&b&协议方面&/b&&/p&&p&打算设计的尽可能宽松一些，代码可以随便修改、使用、分发、做成商业产品拿出去卖，都免费。&/p&&p&交易亏钱了别来找我。&/p&&br&&br&&p&&b&开源平台的内容&/b&&/p&&p&目前计划包括：&/p&&p&1.
一个C++ API的封装框架，国内绝大部分交易API都是C++的，手动写python封装非常繁琐（不难），github上有个pyctp项目尽管已经存在了很久，但人气不高，个人认为和代码复杂度有关（目前据说是使用cython自动生成，没有详细的使用说明）。初期将会封装一个华宝证券LTS的API，一来ETF期权上市我目前也在做，二来和CTP的API几乎通用，金仕达、恒生也都提供通用接口。&/p&&p&2.
一个事件驱动引擎，这东西不复杂，但是没见过的人第一次确实不好理解，身边大量朋友的经验。&/p&&p&3.
基于封装API，事件驱动引擎，PyQt的一个桌面交易程序，将会实现LTS柜台上的绝大部分功能。&/p&&p&4.
一个策略运行接口和策略模板，用于降低从金字塔、TB等软件上转移过来的用户的入门难度。&/p&&br&&br&&p&&b&发布平台&/b&&/p&&p&打算用GitHub，不过今天刚看到海风的AT平台发布在了开源中国上，不知道有什么深意不？&/p&&br&&br&&p&&b&关于Quantopian&/b&&/p&&p&这个确实是欧美在python量化交易领域的先行者，zipline库闻名已久，自己没用过。不过和我这个项目的方向略有不同，一来它接的是IB的API，二来它主要还是为自己的这个web应用服务（在服务器运行）。我的项目将会服务于中国用户，同时希望用户在自己的本地跑，不要受到第三方任何服务器的约束（谁都不想被偷策略）。&/p&&br&&p&另外目前在quantopian上并没有看到过特别好的策略，也许好东西不会免费放出来，but who knows.&/p&&br&&br&&br&&br&&p&&b&&/b&&b&更新&/b&&/p&&p&董可人的一些评论：&/p&&br&&p&1.
这个平台的定位处于TB、MC之类的低端量化软件和大型量化团队自己开发的复杂量化平台（Java、C++）之间，目标就是快速上手、开放源代码可以随便改、真要性能不足了容易上拓展（cython等等）。&/p&&br&&p&2.
Python缺乏静态检测确实是个不小的问题，比较容易出bug，解决方案是：&/p&&p&a)
平台采取非常简单的核心架构，用户容易掌握所有源代码细节&/p&&p&b)
测试，其实静态语言写出来的东西也还是得测试，python写测试还快些&/p&&br&&p&3.
框架本身不包含图形界面，我写上去的一个界面属于简化示例。从python角度上，可以将底层逻辑和GUI分到两个进程中，然后跨进程通讯，但这个方案对于快速开发的需求来说麻烦了点，可以作为业务需求稳定后改进的方向（其实就是我偷懒想交给开源社区来开发，不过确实我自己目前没这块需求）.&/p&&br&&p&4.
国内的交易API通常是C++的，网络数据收发在C++环境中完成。在API封装中我做了个队列作为缓冲区向python中推数据，防止由于C++ API的回调函数被阻塞导致程序崩溃（这个坑没自己遇到过很难想到会有）。GUI端的更新我在期权做市过程中大概是每秒更新上千个表格中的单元格同时同步刷新大概40多条波动率曲线，耗时也就是几十毫秒而已，要知道国内的数据量和欧美不在一个数量级，所以并不是特别大问题，当然也调整了算法和GUI在事件驱动中的运行顺序后保证算法的优先响应，。&/p&&br&&p&5.
Esper那玩意太复杂了。我这个事件引擎就是实现不同组件向引擎注册对某个事件的监听，然后事件来了分发通知，懂编程的大神必然觉得是个小case，但对于大部分交易员而言这是个神奇的东西。&/p&&br&&p&6.
Trader被逼写代码这种事在国内已经成为一个必然趋势了，光是期权做市和套利平台，目前上海这里大量的欧美海龟期权交易员在寻找解决方案，希望这个框架能降低一些进入门槛吧。&/p&&br&&br&&p&Mr Mistake的一些评论:&/p&&br&&p&1.
目前我的整个平台（框架+业务模块）加起来已经上万行代码，设计方面使用了不少OO，确实偶尔我也希望python能报编译错误。。。&/p&&br&&p&2.
用python的目标就是容易，真要性能我也直接去在公司那个C++平台上写得了。&/p&&br&&p&3.
Python的GIL就是个大坑，希望目前dropbox那个pyston项目能成功。&/p&&br&&p&4.
这种快速开发的工作通常是交易员自己负责的，策略不见得是那种长期运行的非常稳定的全自动策略，可能是某种需要程序辅助的半自动交易策略，比如同时监控市场上3000只股票的某些技术特征，然后盘中监控提示，辅助快速下单，用C++当然能写，但等写好估计交易员的需求已经变了。&/p&&br&&p&5.
国内交易所只提供标准的通信协议，然后由各家柜台公司接入后，对外提供柜台交易接口，通常是C++，期望能试着推动改变这个情况（每个接口都要封也太累了）。&/p&&br&&br&&p&&b& 更新&/b&&/p&&p&项目在Github的地址
&a href=&///?target=https%3A///vnpy/vnpy& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&vnpy/vnpy · GitHub&i class=&icon-external&&&/i&&/a&&/p&&br&&p&开发环境说明：&/p&&p&windows 7 专业版&/p&&p&visual studio 2013 express&/p&&p&boost 1.57.0&/p&&p&python环境Anaconda 1.9.2（32位）&/p&&br&&p&刚完成了LTS API的封装和行情API的测试脚本，先上传了，接下来的工作顺序是：&/p&&p&1. 交易API测试脚本&/p&&p&2. 事件驱动引擎&/p&&p&3. API的封装方面的教程&/p&&p&4. 事件驱动引擎使用方面的教程&/p&&p&5. 基于API和引擎开发的LTS交易客户平台（因为华宝没有提供官方的LTS交易软件）&/p&&p&6. 策略引擎接口&/p&&br&&p&&b& 更新&/b&&/p&&p&完成了API的封装，上传了交易API的测试脚本。&/p&&br&&p&目前玩过boost.python的大神可以通过vnltsmd和vnltstd目录下的C++源代码编译出API，每个目录下的test文件夹里包含了编译好的API，使用方法参见测试脚本。&/p&&br&&p&争取明天放出事件驱动引擎后开始制作教程。&/p&&br&&p&&b& 二次更新&/b&&br&&/p&&p&工作效率不错，已经放出了事件驱动引擎，有兴趣的可以看下了。&/p&&p&项目的主页发布在&a href=&///?target=http%3A//vnpy.github.io& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&vnpy.github.io&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&，回头教程会放在这个上面。&/p&
多谢大家的回答，一些问题的交流就发在我的这个回答里了。特别感谢何波、董可人、Mr Mistake、LIKE首先，为什么用python？目前本人所在的公司一共有三款平台，分别基于C++， C#和python。其中C#和python平台都是由交易员开发；C++平台则是由专职IT团队作为…
前ORC员工，挺支持题主的想法的，python去做量化交易的模型也是比较容易实现的。&br&&br&Python如果进行快速prototype或者只进行编写最上层的策略本身而不进行order management，trade synchronization, 以及与您提到的与交易所或者broker进行的connectivity，那么还是非常不错的，有numpy, pandas等优秀的library。&br&&br&不过对于一个专业的交易系统，尤其是量化平台难度很大，仅仅python也很难满足需求，需要多种技术的结合，没有一个专业的团队合作是很难完成的。主要的问题在于python这种动态语言，写时一时爽，重构哭天喊地了要。&br&&br&大致说一下这么一套系统的难点：&br&&ol&&li&交易系统本身的架构：&/li&&ol&&li&大量运算、order的执行与管理、对外的连接都需要服务器端的程序处理&/li&&ol&&li&CPU intensive的处理，放在服务器端会有非常明显的优势&/li&&li&服务器端会非常稳定，试想你的电脑出现windows更新等等&/li&&li&网络方面的代码需要服务器端至少交易时段和交易所亦或是券商连接，需要处理大吞吐、低延迟的网络编程。&/li&&/ol&&li&交易、图形、报告界面需要GUI - 一般会运行在Windows或mac上（ORC最早的时候只有Mac版本的ORC Trader, 如果trader想要交易必须配置mac机器，想想也是醉了。。。），亦或是只用浏览器来控制交易，那么势必对后端的代码要求更加高。&/li&&/ol&&/ol&
由此可见你很难仅仅是一个“程序”就把一套交易系统给运作起来，这里就需要自己去设计一套基础的内部协议框架能让各个trading system的component去运作起来。给一个建议就是可以参考FIX，但这个协议也仅仅是偏向于order execution与基础的market data，比如risk方面的: Alpha, Beta, Sharpe就不要指望这种协议会帮你定义了。&br&
做好了协议之后，那么问题又来了，这些component之间哪些需要低延迟哪些需要高吞吐，哪些需要TCP哪些用UDP就可以解决了。。&br&&br&所以一般你会发现你需要做一个这样的交易系统：&br&&br&GUI Client &---------&
&---------&
HK Exchange / Broker&br&Strategy Execution Engine
&-------& Gateway 2
&---------&
Tokyo Exchange / Broker
&br&&br&Gateway会帮你做一部分order management和处理每个市场的微观不同，比如每个市场的order type也会有相当大的不同，但是如何让一个trading desk能有a view of whole portfolio(不同市场的orders， trades, portfolio returns, risks)，this is a hard problem. &br&兴许你就需要一套非常好的SOA - service oriented architecture来做分布式系统。&br&PS: 仅仅是一个gateway的编写就需要一个程序员对金融交易市场有很细致深入的了解，他的头脑里面就要有how the orders matched in this market. 这也就是你文中提到的基于“柜台API”的开发，要知道国外（包括HK，台湾）很多市场不会有“API” 给你的，只会有一个网络协议。&br&&br&再后来，你会发现有更多的需求，比如满足风控，想有各种options pricing的计算，那么系统继续拓展：&br&&br&Strategy Execution Engine &-----& Pre Risk &----& Gateway &------& Post Trade Risk &----& Exchange.&br&&br&OMG！我如何track我的order flow呢？我的order到底到哪里挂掉了？是bug还是我的order不符合交易所的要求被reject了呢？到底在这个分布式系统中一个order的延迟多少？如果延迟过高的话我的策略会受到什么样的影响呢？&br&&br&2. 功能&br&如果只是做click stock trading，兴许第一个架构就足够了。但是在金融领域会有很多细分的功能，如果是market making你会需要理解how quoting works, 但是click trading中只有order的concept兴许就够了。&br&如果是券商的系统，他们兴许还需要知道每个用户的order、position的情况来处理突发情况或者风控等。&br&如果是algo trading，兴许你还要提供科学计算的可能性。&br&题主提到希望直接使用柜台API来进行操作，那么还涉及到这样的交易是DMA(Direct Market Acccess)，券商未必会放开让你直接做DMA的在国内。那么又需要考虑连接哪家券商的API的问题。&br&&br&所以综上，兴许从一个部分出发做开源会更好，focus在一个方向做好。&br&&br&关于license，我们以前是从来绝对不会用GPL的，it's like a virus... 只能把代码自己写也不用GPL的。&br&&br&现在我和另外一位前同事以及前投行交易组的朋友、BAT小伙伴做了&a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& 。 也是想把量化交易更加开放地带给大家，我们拿着低延迟系统在做这么一个开放、免费的平台，也希望大家喜欢。&br&&br&&img src=&/e56a352b39eac7a12c83cf72cfcef430_b.jpg& data-rawwidth=&160& data-rawheight=&53& class=&content_image& width=&160&&&br&Happy Coding & Happy Trading.
前ORC员工，挺支持题主的想法的，python去做量化交易的模型也是比较容易实现的。Python如果进行快速prototype或者只进行编写最上层的策略本身而不进行order management，trade synchronization, 以及与您提到的与交易所或者broker进行的connectivity，那么…
已有帐号？
无法登录？
社交帐号登录
自选集《我是高频交易工程师》已上市}