国产自主程序开发语言TSL炼成记

前言

　　深圳市天软科技开发有限公司是国内比较罕见的自主基础软件的开发厂商，已经在这条道路上坚守了20年。其开发的自主技术有计算机语言、数据仓库及数据挖掘平台、网格计算、BI工具、桌面开发工具、协同报告生成系统等等，同时还在进行新型数据库的研发。天软的这些技术已经在金融机构得到了较大规模的应用，包括风险绩效模型、投资策略开发、交易方法研发、BI系统、信息披露系统、数据中心应用等等领域。

　　这里将天软的TSL语言的研发的经过做一个简单回顾，希望可以为致力于国产化自主软件的厂商提供一些帮助。

缘起

　　写下这段文字的时候，时光回溯到了20年前，当我和当时我最好的一个哥们说起要自己做一门语言的时候，得到的是坚决反对。大致意思是，C++不够好么，JAVA不够好么？

　　这个哥们是一个我蛮尊重的技术大牛，当初的质疑还历历在目。20年间我后来又接触到了形形色色的技术大牛，几乎也全是质疑的声音。

　　我为什么一定要做一门自己的语言，自然有自己的考量。我有如下两个论点：

　　首先，几乎任何一个伟大的IT公司都有自己的语言，如果连自己的语言都不做，注定无法成为一家伟大的IT公司，而一旦连成为一家伟大的IT公司的梦想都没有，也许就连成为一家IT公司的资格都没有。这一点也正是天软成为一家IT公司的初心。

　　其次，任何语言都不是完美的，这是一门门新的语言出现的原因。即便是自己已经有计算机语言的，也并非因循守旧而在不断创新中。因此必需遵循现有计算机语言的论点是站不住脚的，尤其有现有语言做参考，做一门新的语言也并非不可能的事情。

　　实际上，以上两个论点非常简单，相信每一个IT人也都能想到，但为什么几乎每一个技术大牛都会反对呢？后边的【不得不说的话】里我会提到。

起步

　　从2002年公司成立一开始，天软的定位就是在金融领域做一个数据挖掘软件。软件的名称叫天软金融分析.NET。那时候，分析还主要基于局域网，C/S架构还大行其道，受到当初刚刚兴起的允许协同开发的网络游戏MUD的影响，又认识到了海外数据挖掘软件的强大，于是萌发了做一款可以基于互联网在线挖掘分析的软件。这一年，比2006年谷歌第一次提出云计算还早四年。

　　而国外每一个数据挖掘软件都有自己独到的语言，这也就是我们投入TSL语言开发的初衷。正是因为定位在网络共享式数据挖掘工具，而不是一款桌面计算工具，所以从语言设计开始就规避了目前许多语言遇到的问题---由于大部分语言定位于桌面计算和配置脚本，包括R、PYTHON、PERL、PHP等许多开源软件，以及几乎全部商业数据挖掘计算软件都无法提供多线程并发运行。甚至于运行在前端的JavaScript引擎虽然工作在多线程之上，但由于桌面应用对可靠性要求不高还常常引发浏览器崩溃。

　　可以说，TSL语言是一款从刚开始在设计上就是具备高可靠性多并发的脚本语言，这也使得在后续发展中获得了更多的适用性场景，这是后话。

TSL语言的发展过程

　　刚开始，TSL语言仅仅只是一门类PASCAL的面向过程的语言，在其中也引入了一些C的一些语法特性，例如RETURN以及算符。作为脚本语言，从一开始就考虑到了字符串下标等特性，数据结构相比PASCAL而言相对灵活丰富。

　　在公司成立的前五年间，TSL语言方面的工作基本上就是完成一个稳定可靠的面向过程语言，在许多人的眼中，这就和重新发明了一个轮子一样可笑。但我们知道这是我们从事的事业的根基。

天软平台的TSL语言集成IDE

WEB开发与报告引擎

　　在TSL发展了两三年时间，客户还极少的。但一旦有了客户，客户的需求就是全方位的，例如需要网页版的系统，还希望自动化生成报告。

　　开发网页的后端语言，其实选择很多，那时的主流是PHP、ASP等。但由于当初我们的人员很少，采用相同技术栈显然可以大大降低实施难度，做IT的人往往都有大一统的梦想。如果没有当初坚持统一技术栈，也许就没有后来天软介入到金融机构内部系统开发的框架体系里，仅仅只能充当一个计算软件。

　　当初做出这个决定还是蛮艰难的，客户没有看好的，内部也有很强的不同意见，这等同于再一次造轮子。从理解HTTP协议开始，到了解CGI的规范，事实上将一门语言完成WEB开发支持并没有想象中那么困难。就这样在2004年， TSL语言支持了WEB后端开发。这也成为了十年后天软许许多多WEB版系统的基础。

　　同样在2004年，为了完成自动化报告功能，虽然有许多报表引擎，但开发难度太大，我们巧妙地想到了利用WORD软件自身强大的排版功能，在WORD里内嵌TSL语言来完成报告的生成。这个功能非常高效，在数年后，一家大型基金管理公司将一百余份积累的JAVA开发的自动化报告迁移到TSL报表引擎仅仅只花了一周时间，而十余年后，这又成为信息披露系统的基础，大型基金管理公司每年有数万份报告在其上生成。

文档元素化数据化的协同报告生成系统标题

TS-SQL

　　在2006年的时候，由于金融模型需要做大量数据处理，看了无数的循环语句的我萌发了一个新的念头，是否可以将SQL内嵌进TSL语言。

　　SQL语言被广泛使用在数据库系统中，但在高级语言里内置SQL史无前例，尤其是我们的定位是仅对SQL做少量改造完成和TSL语法的兼容，使之成为TSL语言的子集。这项充满挑战的工作，要构思如何巧妙地完成SQL语法地改造使之可以兼容高级语言的语法，又要完成SELECT、UPDATE、DELETE、INSERT等功能。SQL语法融入TSL语言是在2006年，这比2007年底微软在C#.NET 3.5里推出的类SQL语法LINQ还要提前了一年。而且LINQ的使用需要学习的成本高，并不像TS-SQL的语法几乎只要做小的学习就可以从SQL中无缝迁移。后续一两年时间又将GROUP BY,JOIN等特性进行了完整的支持，使之几乎支持了全部SQL特性。完成了SQL以后，我们又扩展了SQL对时间序列的支持特性，使得TS-SQL语法可以很方便地进行移动时间序列分析，目前这已经是许多TSL语言用户最喜欢的特性，也是目前各式语言中独一无二的特性。

TS-SQL支持序列处理

面向对象

　　由于刚开始TSL语言定位于数据挖掘，大多数应用场景仅仅在于建模，由于建模大部分都是面向过程的，所以几乎所有数据挖掘语言并不具备面向对象特性。

　　到了2008年，由于天软开始介入了客户的内部系统开发，开始处理用户管理、权限、流程等方方面面，TSL语言的面向过程的开发方式的弊端就显现出来了。

　　OBJECT TSL的基础面向对象特性就是在这一年开发而成。

　　到如今，TSL语言支持多重继承、支持算符重载、支持getter,setter等几乎一切面向对象语言的特性，后来不仅WEB后端开发，许多金融方法的框架也都是采用面向对象开发而成。

　　也是在这一年，由于全球金融危机，海外回流了大量金融人才，他们回国一看，国内竟然有一个这么样的软件，惊奇不已，甚至于认为天软一定是从海外带回来的代码。因为这样的系统往往是海外的大行花费巨额经费自研的，而且几乎每一个大的机构内部都有一种自己的语言。这些海归其中许多人都成为了天软TSL语言的用户。

.WEB

　　在2009年，由于WEB开发的需求越来越多，我基本确定了WEB是未来主要的应用场景。作为一个IT人，降低重复性的开发工作是本身的责任。于是我们抽象了一个不需要前后端网页开发的WEB开发框架，称之为.WEB。

　　这项工作的开展在内外部几乎都无人支持，这不是在造轮子，这完全是在创新。但这项工作最终成为天软大部分内部WEB版应用系统的基础。有了.WEB系统，以往需要数周乃至数月的工作，就可以当日或者数日内完成。更为重要的事情是，这打通了业务和IT之间的壁垒，业务人员不再仅仅被局限在模型开发，还可以配置出美观的可交互的WEB系统。

　　在十年后，这项技术在技术领域中有了一个专有名词：被称之为少代码或者无代码开发。

.WEB工具-无代码开发工具,由TSL语言开发而成

数学方法库和矩阵计算

　　美国回国的海归们大大推动了数学在金融领域的应用，为了适应用户的需要，我们和矩阵计算软件做了接口，使得我们可以很方便地调用这个矩阵计算软件（这个软件在十年后宣布了对中国一些特定的领域禁售）。

　　有了这个接口，客户都非常满意，因为这解决了他们的应用需求。但这并没有让我们满意，我认为如果一旦一些复杂计算都依赖使用第三方软件尤其是海外的软件，我们的软件就不是完整的。

　　做出自主研发数学方法包的决定和.WEB是在同一年，都是2009年。当我兴冲冲地将这个主意告诉我的一位我很尊敬的客户的时候，被狠狠泼了一盆冷水：“这不是你们可以做的，即便你们做了，我们也不会用”。当时，我们团队几乎清一色的IT男，我们系统里的数值计算方法库还仅仅停留在当初从fortran里移植来的代码，做出这个决定非常艰难，这是第一次尝试做真的不擅长的事情。而以前所有的决定都是我们团队所擅长的，唯一的决策依据是是否值得做，这一次对于我们而言是一个未知领域。

　　而到了十年后，再也不会有人质疑当初的决定，投资策略、风险绩效计算、衍生品的计算中大量使用到数学方法，这些都是完全在我们的平台上用TSL研发而成的，完全不需要调用其他矩阵计算软件。

　　当然，数学方法库开发是非常艰难的，对于一个面向对象的高级语言，要开发那么多的数学公式，相比简洁的矩阵计算语言而言难于上青天。我们一方面坚持数学方法库的开发，另一方面在第二年，也就是2010年，我们决定了将TSL语言改造为矩阵计算语言。

　　改造TSL成为矩阵计算语言，这几乎牵涉到了原有语言的方方面面，所有的算符，所有的数据结构，一大堆的基础函数都需要改造。

　　但一切的困难并没有想象中那么难，2010年，语言的改造就基本完成了。TSL语言终于具备了矩阵的算符，矩阵的查找，子矩阵的操作等等几乎一切矩阵计算的特性。而到2013年，历经艰辛终于完成了所有基础函数的矩阵支持改造，使TSL终于成为了另一个支持纯矩阵计算的语言，也就是说除了矩阵算符以外，基础算符、基础函数也通通支持矩阵。

　　有了矩阵计算，许多天软客户也正是从这一刻开始将复杂计算从海外的矩阵计算软件转到天软平台之上。

　　而也正因为如此，才有天软后来在具备高度门槛的风险绩效等领域里的扎根和发芽。

　　目前，我们可以说在纯计算领域，我们的TSL语言几乎可以对海外矩阵计算软件形成完全替代，并在数据处理方面具备自己独到的优势。而在未来，还可以为有着广阔空间的工业软件等需要计算的应用场景提供支撑。

TSL语言的部分数学方法库,其中矩阵计算起到了关键作用题

调试器与优化器

　　TSL语言的发展到了第十个年头，也就2011年，天软的TSL语言依旧没有断点调试器，我们给客户的说辞无非是优秀的程序员用打印就够了。可毕竟这不是实事求是，谎言说了一百遍也无法解决客户的实际问题，这也成为了一个我们不太喜欢回首的过往。

　　有一次，客户在我们的开发者大会上演示了他们的代码，客户已经有单个代码行数超过5000行的模型，而单个客户积累的代码行数已经数以万计，这远远超出了我对用户的想象，同时这也促使我们下定了决心去完成断点调试这个基础必备功能。

　　在调试器的开发上，我们结合了传统高级软件的断点调试以及矩阵软件和其他脚本软件的交互式调试的优势，对两种特性我们均进行了支持。这件工作并不简单，将一个提交任务拿回结果的简单协议到允许断点调试就是一个飞跃，这不仅仅牵涉到改造语言，还要定义新的协议，更为繁杂的是还要改造集成开发环境的客户端代码。

　　通过这一整年的努力，我们终于啃下这块骨头，TSL语言终于具有了调试器。而且，顺带地，我们也开发了TSL的优化器。

　　这一年的工作，不仅为TSL大规模开发奠定了基石，积累的技术成果也成为了其他后续特性开发的基础。到现在为止，保守估计天软的客户已经用TSL语言开发了上百万个模型，累计代码数量达到数千万上亿行，如果没有当年这个调试器的工作，是无法想象的。

交互式计算

　　天软的平台体系可以认为是传统的T/S架构，也就是运行于服务器端，客户端仅仅只是一个浏览和操作工具。但随着客户机的资源越来越多，有的客户自己在客户机安装了数据库软件，还有的客户具有调用本地计算工具的需求，甚至于有的客户需要调用本地的交易接口进行交易。这个时候，一个难题产生，T/S架构相比桌面软件的劣势就在于无法利用本地计算资源。于是我们有了一个大胆的设想，如果允许TSL语言代码运行在本地，并在设计安全管理机制的条件下允许服务机代码调用本地代码执行，是否就可以一劳永逸地解决这个问题呢？

　　在2011年，这是又一个史无前例地尝试，使得TSL语言具备了混合云端和本地数据以及计算的能力。包括计算结果的输出以及用户数据的输入，也可以不用界面来导入导出这么复杂，而直接可以使用程序来完成。这已经成为了天软客户最受喜爱的特性之一。

网格计算

　　虽然天软的平台架构从一开始就是分布式计算架构，但支持并行计算应用一直在脑海里挥之不去，这是天软作为IT人的梦想。这同时也是计算工程皇冠上的一颗明珠。

　　多年的思考中，发现改造语言增加算符并改造语言的数据结构是一条可行的道路。但这个想法虽然非常另人兴奋，但其难度不易于重新开发一套架构。毕竟这不仅仅牵涉到语言的改造，还牵涉到调度网络通讯协议等诸多技术点。

　　在和一个客户兼好友的聊天中，大致谈了谈我们的构思，很巧他正好有这方面的积累，首先断定了思想的创新性，其次至少认为这是一件非常有趣的事情。

　　这件事情的投入开发是我们最棘手的一次，第一个版本的开发耗费了数月的时间，结果发现不仅仅无法正常工作，而且会诱发系统崩溃。当IT系统的复杂度到了一定的时候，是如此地难以捉摸。这也成为了有史以来第一个被废弃的开发工程，由于改造代码涉及过多，为了不影响后续的开发升级，我们做出了艰难的决定，将这几个月难以计数的工作成果，完全从代码里移除。TSL语言以及平台复原到了开发这项功能之前。

　　调试器和交互式计算的开发成功，给了开发网格计算的第二次尝试的冲动。在2012年我们重新起步，做足了功课，做了充足的条件编译，防止上一次失败推倒重来的产生。一是有了第一次失败的经历，二也有了调试器协议的经验，这一次的研发出奇地顺利。

　　终于，在2012年，TSL语言初次具备网格计算能力，随着后续不断在网格计算研发的深入，这也成为了天软的自主专利的网格计算方法。

　　目前，无论是天软的云平台，还是客户自己的内部服务器群，天软的网格计算在并行计算中都发挥了巨大的作用。目前天河二号超算中心上也部署有天软平台可以提供网格并行计算。

桌面开发

　　TSL语言已经覆盖建模，WEB开发，报表引擎，配置脚本等应用场景。但随着WEB开发越来越广，桌面开发领域越来越小，但在专业应用领域里，桌面开发依旧具有无可替代的作用。

　　专业桌面开发工具的门槛过高，而其他脚本软件由于基本都是采用第三方库作为桌面开发的基础，底层功能无法或者极难扩展，使得用作真正的桌面开发有其天然的劣势。为了填补这项空白，我们在四年前投入了桌面开发工具的开发中。2021年，世界上第一个纯脚本（TSL）开发而成的桌面开发工具就要正式面世了。这个桌面开发工具具备传统桌面开发工具的几乎全部特性，同时又兼备脚本语言的优势，TSL语言又进入到又一个全新的领域。

桌面开发工具-其本身包括的IDE环境以及编辑器、界面设计器均由TSL语言开发而成

从IT走向纯IT

　　一直以来，虽然天软是一家以IT著称的公司，但天软的TSL语言一直应用在投资以及分析的金融数据挖掘领域，并不具备纯IT系统所具备的良好的开放性。随着用户自主IT系统的开发需求，用户对系统的接口要求越来越迫切，利用天软TSL语言作为计算中间件，然后将计算结果回馈给其他系统。

　　从2014年开始，我们陆续为C、PYTHON、R、JAVA等开发工具提供了标准API，并开发了TSODBC和TSJDBC，使得用户可以将天软平台当成数据库，而TSL则是这个数据库的SQL。这样，几乎所有支持数据库的开发软件和工具（几乎没有哪个不支持）都可以接入天软平台和使用TSL语言。

　　原有天软的平台以及TSL语言仅只支持运行在WINDOWS之上，而目前已经同时支持WINDOWS和LINUX这两大主流操作系统。除此以外，天软平台已经通过鲲鹏认证，TSL语言已经可以运行在ARM的CPU和华为操作系统之上，而且由于天软的自主开发，未来必定可以运行到更多的国产化硬件架构下。

　　同时，随着桌面开发工具的推出以及数据库系统开发的推进，TSL语言在纯IT的道路上必定越走越远。

不得不说的话

　　如今的TSL语言以及天软的自主架构还在继续前进，这二十年间，有些话却不得不说。

　　在这个过程中，我们遇到了各式的质疑，刚开始是为什么不用C语言而要自己做一门语言，到为什么不使用JAVA，再到如今PYTHON喧嚣尘上又有说为什么不选用PYTHON。唯一就没有人认为需要一门自主的计算机语言，而对这种语言有着的诸多优势也视而不见。事实上，海外软件以及开源软件并没有想象中那么好，PYTHON仍然在多线程支持上挣扎。

　　反对做自己的语言当然有其中一点原因，就是人力资源问题，高等教育学的东西一贯是舶来品，我们缺乏反抗精神。在高校职称以维论文论的时候，我们的计算软件甚至于会以计算结果不是国际公认的为理由被教授们否定。高校的人力资源实际供给的是海外软件的使用者，这导致自主IT的基础出现严重的问题。而许多用户单位也会以此为前提，认为存在学习成本，这尤其是IT的主官人员更是如此。有些人即便你证明了这个学习成本低到极低也不愿意接受，说除非你全部兼容某种语言云云。扪心自问，难道有一门语言全兼C，又全兼JAVA，再全兼PHP、PYTHON么？这不是癔症么？难道那些语言自己不发展么？除非完全抛弃自主全部使用第三方内核是无法做到这一点的。这一点几乎就是完全拒绝接受自主化。

　　事实上，人力资源并不是问题，选用我们的用户内部培训就可以很快让学各种语言的人进入到我们的开发角色中来。退一万步来讲，真有学习成本，我们的IT界为什么厌恶学习成本，但又对新东西的喜好孜孜不倦。一个国外新出的东西，即便是一个非常小众的工具，也会引来各种追捧和学习，哪怕这些形形色色的东西绝大多数最终只是昙花一现。有时候，真让人以为学会最新的国外框架是我们这些IT人的追求。

　　当然，也存在很多卓有远见的机构。他们选用我们的平台和语言是以事实为准绳，他们具备真正评判能力。这些客户既有大银行，大保险，大基金，大券商，也有小型的基金，私募机构等等，当然也有卓有眼界的高校和研究机构。正是他们的公正和无私，用我们的软件替换了国外的BI工具，替换了海外的开发框架，更换了采用海外软件开发的系统。而正是他们的支持，才使得这个天软背负这个最最艰难的使命坚持到了今天，在这里，天软要感谢他们。

　　此外，自主做计算机语言得不到许多用户以及IT人的认可，我认为无非有以下几点原因：

　　首先是骨子里的崇洋，这媚外是从我们的计算机教育里一点点潜移默化而来，我们几乎所有的计算机的基础技术都来源于美国，除了我们用的计算机里的各式组件，还包括其上运行的软件小到一个编辑器大到开发用的软件以及专业工具软件。因此，无论是学习和考试，甚至于认证，都是围绕这些国外的软硬件厂商设立的。骨子里的崇洋，首先就无法相信自己在基础软件上有可能比洋人做得更好。

　　其次是对自己的信心。我记得当初还有另一个论点，那么多顶尖的高校都没做好，那些清华北大科大的人，哪一个不比我们厉害呢？我觉得这个论点也是IT人的悲哀。我觉得我们经常陷入一个误区，就是看到国人做成了某件事情，自己一看，对方学识或者企业规模还不如自己，就将其成功归结于运气，自己也急吼吼冲进去进行竞争。这种无端的自信是极度缺乏信心的另一种表现。曾经有许多家公司号称过要开发一个和我们一样的系统，我个人非常欢欣鼓舞，只可惜最后他们都仅仅支持了一两年项目就折戟沉沙，因为他们没有一个想到要做天软的事情首先就要做一个和国外的顶尖公司竞争的软件，他们仅仅只是认为天软可以做到他们就必然可以做到。

　　再次是吃苦的能力。其实做事情无非是个坚持而已，许多事情，开了头，坚持下去，就有成功的可能。然而基础软件开发一看下去，要做的事情几乎是无穷无尽的，大多人就退缩了，畏难不愿意吃苦。我们很多人愿意牺牲身体996赚来快钱，却不愿意持久在一件事情上做下去，究其根本依旧是不愿意吃苦，因为短时间的苦和长时间的磨炼是无法比拟的。

更为艰难的话

　　目前，我国在政策上对自主软件的扶持力度非常之大，然而事实上，只有市场化才是商业软件得以壮大和发展的根本。政府的资源的搭配往往难以是最优的，一旦扶持的目标正好是劣币，就会形成对良币的驱除效应，使之得到相反的结果。此外尤其不应对大企业进行扶持，每一个对大公司的扶持的背后既会让人力资源过于集中过分浪费，同时也丧失了小公司的成长空间。而每一个硅谷的大佬，无不是从小公司成长起来的，可以说小公司才是创新的真正源泉，小公司灵活上进，具备有大公司不具备的高效和冲力，只要提供公平的市场和没有颜色的眼镜，小公司总会不断从中成长出一家家的大公司。

　　而在教育等产业，应该改革评价标准，从重学术逐步走到重产出上来。国外许多的创新本身就是由高校产出的，而在国内相对而言差了许多。另外尤其应该鼓励学界使用国产软件，甚至鼓励学校建立长效项目机制组织学生持续投入开发出所缺乏的所需软件的原型来。

　　此外，关于自主，目前主要关注点都在国产可替代，实际上这里边也存在一个隐式的陷阱。IT的发展本身就是由IT公司引领的，过分讲可替代，就依旧还在海外的软件厂商的框架内，而且也难以形成突破反而使软件公司丧失创新的能力。完全复制一个IT产品既困难，又丢掉了发展方向，我们必需跳出跟随的陷进，走真正自主创新的道路。