其实我很乐意讨论架构方面的问题。但这个策略和代码分开，应该不涉及架构问题，顶多算是语言解析层面。不用编译就可以运行的语言，vb脚本就是。 一个可执行的程序形成过程： 1．语言（如c语言）->编译A（优化）-〉可执行的机器码 ２．解释性语言（ｖｂ脚本等）-> 语言解析器->语言（如c语言）->编译A（优化）-〉可执行的机器码 3．策略语言（如easylanguage）-〉策略平台的编译B（如mc，功能是解析策略语言变成类c语言）->语言（如c语言）->编译A（优化）-〉可执行的机器码 第二种和第三种本质是一样的. 而espresso兄提到的伪码策略，执行和上面后二种没有本质区别，仅仅是多了个伪码的解析器，编译的工作放在了幕后。 所以，策略和代码分开，仅仅是多个伪码解析器，不涉及软件架构问题。
做脚本引擎也不是特别困难，用yacc和lex就可以方便构建，如果嫌这个不够，可以用可变目标c编译器来改。策略架构变化后从新更改引擎结构，从4缸升级v6、v8，或者加turbo都不困难，但是目前小弟的水平觉得perl python这些脚本语言已经很够用拉。
早就投产运行了, v3.8 in full Production mode. 除了界面有点简陋，功能是灰常强大滴。 除了1分钟以下的“高频”策略，其他策略都没有问题。 konit兄关于计算性能方面的担心，这个部分外包给matlab, R, excel完成。 有了上面这三，你还有什么不能计算的？ 讨论一下挺好，这不大家都想到脚本，伪码，DSL了吗， 是还有更简单和高效的方法。 但是"代码和策略分开“这个经验，的确不是瞎掰的， 用对了，长期来看会节省很多时间和精力。 我对这个帖子的贡献也就仅此一点， 因为知识产权和其他一些原因，抱歉，就不说更多细节了。
这个结果和预想的一样： 1。用户层次意义上的简单，决定了所能写得策略的层次。就像初学者喜欢文华，用了一段时间，发现连个for循环都没有，就学mc或者金字塔，再用一段发现有些策略也写不了，比如mc，连撤单指令都不提供。所以，没有编码的平台不可能实现复杂的功能。这样的平台高频的不行，复杂的算法交易也不能用。 2。“konit兄关于计算性能方面的担心，这个部分外包给matlab, R, excel完成”，其实这样的平台，性能是劣势，不要指望性能，能到1分钟级别就不错了。一般编程层次的性能，一般matlab，excel等都排不上队。 代码和策略一般不可分（分开的平台，一般是鸡肋的东西，功能和市面的软件差不多，性能可能都不如人家），交易系统的设计，把策略编写、回测、实盘等分开就可以了。
randomain兄并没有见到我说的“策略和代码分开”是怎么实现的，也没有见到这个系统， 怎么就“结果和预想一样”了？那只是你预想的吧。 不过也不怪你，因为我也没有说得太详细，原因之前说过。 如果randomain兄弟对复杂的系统，复杂的策略，计算性能有一些接触的话， 我想请教几个问题， #1 你所指的复杂策略是做市场横向扫描，还是对单个品种做特定的分析，或者都有， 你的策略从读取数据，到完成分析，并给出交易指令一般花多少时间， 我看你上面说的那些，应该是能说说平均到几秒的吧？ #2 你的策略运行在什么环境？系统到达峰值的时候CPU用多少？内存用多少？ #3 你的那些比matlab/r/excel快的模块是自己开发，还是第三方开发的模块？ #4 你有多个并行的交易订单通道，还是单个通道？ 如果是单个的话，你知道这个通道最快能走多少交易指令（比如每分钟）？ 这里就是纯粹地讨论一下系统的性能，也不涉及任何商业机密。 相信大家对交流一下这些东西还是很有兴趣的。
看了一下这两个，功能都很强大啊。 现在的编程语言是越来越多了。 konit兄有看过这个指数吗？前5名是: java, c, objective-c, c++, c# objective-c最近几年势头很猛.... c/c++是永远的王者。 TIOBE Programming Community Index for February 2013 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
我所提到的“结果和预想一样”，是指的系统的性能。 下面按照你的问题，探讨下： 1。我的策略在计算过程，一般小于 1ms，如果运行结果要报单，从成都收到tick-报单-收到报单回报，小于50ms，应该说，大部分时间是网络传输时间。 2。系统是windowsserver。系统的峰值没有基准，这个和策略加载的多少以及策略本身的复杂程度有关，cpu和内存占用没有可比性，就不说了。 3。模块都是自己开发的。我说比matlab快，是因为我做过测试，测试结果快10-100倍，这个结果和测试内容有关，每个人可以自己做测试。另外，语言层次的测试我也做过，从结果看c、c++、c#在一个层面上，只有10w次以上的计算，这些语言之间才会显示出差异，从交易系统上讲，单独的一次下单，这些语言都是一样快，因此，你可以选择自己熟悉的语言开发系统。 4。多个策略是并行发单的，通道的限制仅受限于ctp本身的限制，系统本身没有限制。 以上就是我的平台的一些情况，也请espresso介绍下自己的情况。
两位挺好的信息分享。 c/c++就不用说了，必要时只能用它。其实偶比较感兴趣的是python和函数式haskell、ocamel。后者貌似hk有个量化公司有在用。考虑函数式是出于建模方便，还有多核开发，并行计算的原因。 这只是设想，偶不想过度设计，最终还是要视实际需要而定。
Matlab/Excel比C/C++慢是肯定的（虽然也有提速的方法，但毕竟是慢）， 关键在于提高了速度能带来多少好处。 可能也是因为我对所谓高频从来兴趣不大的原因。 我觉得好的系统（和策略）不能对系统速度，对网络，对信号太过于敏感， 必须很健壮，有一定容错性和灵活性。 我现在的系统的运行过程有点类似批量处理， 生成市场信号（1-2秒）， 策略运行（＜5秒 per symbol，这里要看大家怎么定义"策略"？？） 交易指令发送到确认（＜1秒）， 基本上我现在每2分钟运行一次整套策略，但实际上信号是5分钟生成一次。 所以我根本不在乎要1秒，10秒，甚至100秒完成所有计算。 另外，我觉得大家说到策略，可能是专指某个算法生成一些信号。 我对"策略"的定义则不仅包括交易指令的生成， 还包括对订单的监控（出错，STP/MKT触发,取消，修改等） 也包括当前交易计划根据目前订单，头寸所做的动态调整，等等等等。 很多情况的处理其实不单是计算性能的问题。 "代码与策略分开"，可能更准确的说法是"代码和交易计划/决策分开"？ 嗯，就不纠结这些说法和定义了。 这么说吧，我的系统里真正能获利的核心， 不是市场信号，也不是交易指令，不是订单速度， 应该是一堆交易计划（或者说是决策过程）， 这个似乎已经不是本帖的主题了... 生成市场信号（1-2秒）， 决策和调整交易计划（＜5秒 per symbol）， 交易指令发送到确认（＜1秒），
做一个能策略，回测，执行分开的系统也是小弟的一个梦想。 当前认为要写一个类似解析器的东西难度有点大了。 所以目前做的一个回测系统把策略部分放在单独文件中。 策略主要负责生成买卖的原子信号，或者生成嵌套信号。 信号的回测执行部分分两部分， 原子信号是真正执行部分。 另一部分即嵌套信号的执行，实际是对信号进行解析，然后释放出多个原子原子信号交付给前一部分执行。 另外数据采集也要包括数据的校验部分。获取的数据常有时间断点，需要处理。 总体来说还是比较复杂。 执行部分最近才开始做。由于太沉迷交易，一边慢慢腾腾做着交易系统，一边还在不断手动做单，给MM送钱。。。 现在觉得总体而言开发从交易辅助工具往自动交易渐进是个比较好的思路。因为要忍住不交易单纯开发系统确实很难忍。。。
伪码和DSL还是有区别的。 一来伪码不能被计算机执行，二来伪码未必与特定问题域（Domain）有关系。典型的例子是用伪码写个排序算法，既不能被执行，也和Domain没有关系。 相反，DSL则必须能被计算机执行，必须与特定Domain有关系。在交易领域，典型的例子是股软里的公式编辑器。像EasyLanguage这样的语言算不算DSL存在争议，它倒是满足这两个条件，只不过有人认为达到一定的通用程度（支持条件、循环，能定义变量、函数等）就不Specific了。 有点吹毛求疵了，见谅见谅 魔鬼全在细节中。譬如说：策略与OMS之间的接口应该如何界定？举例：追踪止损属于策略还是OMS？如果要求追踪止损的参数除了支持固定点数，还要能支持百分比或者要与波动性相联系呢？下单和成交回报分别由哪个模块处理？策略模块要不要管底层的通讯故障？....... 很多细节的处理方式不是黑白分明的，更多地与策略本身有关，反过来说，针对某些策略合理的“分开”方式很可能并不适用于其它策略。当然，在成功搞定所有细节之后，好处确实很多。 个人感觉对于编程不太熟练的程序化交易者来说，如果追求这种架构设计的目的是既能找别人编程又不会泄露自己策略，怕是方向未必对头。还不如老老实实下点功夫去学一下编程，然后自己面条般地去实现一个个单独的策略来得靠谱一些。 白云兄是自己做过脚本引擎吗？ 函数式的好处还是学术圈里捧得比较多，真正应用起来困难不少的，不知道是哪个hk公司在用haskell、ocamel做量化？