DSL技术如何解决“最后一公里”传输瓶颈问题?
21ic 2024-07-18

所谓领域专用语言(domain specific language / DSL),其基本思想是“求专不求全”,不像通用目的语言那样目标范围涵盖一切软件问题,而是专门针对某一特定问题的计算机语言。DSL之于程序员正如伽南地之于以色列人,是最初也是最终的梦想。几乎自计算机发明伊始,人们就开始谈论DSL使用DSL了。而前几年随着被誉为“Web开发领域专用语言”的Ruby on Rails迅速走红,DSL又一次成为人们讨论的热点话题。很多人都认为,DSL将会是软件业的“next big thing”。然而随着DSL的日益流行,围绕着DSL出现了很多质疑和误解,比如下面这几个:


1. DSL的目标受众是非程序员,业务员或者最终用户在很多人的心中,DSL等同于“非程序员的编程语言”(programminglanguage for non-programmers),因此DSL的最终受众应该是非程序员,一切不直接被最终用户使用的DSL都不是真正的DSL,仅仅是另一种使代码看起来不像代码的无聊技巧。这是一个很有趣的观点,事实上在计算编程语言发展的历史上,的的确确出现过“非程序员的编程语言”,而且还非常有名,它们就是FORTRAN,COBOL这些第一代高级语言。在当时的那个时代,计算机的主要目的是科学计算,而程序员则是专指那些摆弄开关,继电器,纸带以及汇编语言的geek们。而计算机的主要受益者非程序员——也就是那些学者和研究员——不得不委托这些人帮助它们完成从数学公式到机器指令的转换。于是第一代高级语言的主要目的是缩短计算公式和可执行的代码之间的差距(比如Fortran),或者是简化信息管理员的日常工作(比如COBOL)。有趣的是,恰恰是这些当年的“非程序员”把软件开发发展成了一门正当且颇为体面的职业。其实当年的“非程序员的编程语言”与的DSL境况颇为相似,所不同的是,当代企业级信息系统更为复杂,所关注的焦点逐渐从计算转移到数据上,业务领域和计算机的物理过程也不再具有简单直接的对应关系了。

而且随着社会分工细化,就算是通过DSL,我们仍然不太可能把那些衣冠楚楚的HR们,销售们,部门经理们统统拉下水变成新新程序员。我仍然要承认,以最终用户为目标受众的DSL是一个很引人侧目很有意思的主意,但是在相当长的一段时间内都是不太现实的。或许我们需要新的方法(比如精益)来协调IT部门和业务部门,或许我们需要全新的软件工程理论,或者某些非常具有独创性的工作方式。

2.DSL = 整洁的代码这种观点与前面的观点正好相反,把DSL完全当作程序员的游戏,把一切能将代码写得整齐好看的技巧都归结为DSL。虽然从形式上看DSL和“整洁的代码”都具有简洁清晰的特征,但并不能因此将简单将两者草率地归为等同。从概念上说,程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来:由于计算机的程序模型较为单一(归根结底都是运算和存储),就算是在面向对象技术成为主流,通常情况下,计算机程序不太可能做到与业务领域中的概念一致,或者具有某些直觉的对应。也这正是因为这样,软件的修改和可维护性并没有想象中的容易。我们必须不断地将业务领域中的概念转换成相应的代码模型,然后再进行修改。这种间接性直接造成了软件的复杂度。而DSL的主要目的就是要消除这样的复杂度(或者说,以构造DSL的复杂度代替这种复杂度),DSL就要是要以贴近业务领域的方式来构造软件。因此,DSL的简洁性往往是一种思维上的简洁性,使我们不用费太多的气力就能看懂代码所对应的业务含义。

从这里我们可以看出DSL和“整洁的代码”的根本不同,“整洁的代码”只是泛泛的要求代码简洁易懂,而不太在意是否贴近业务领域。比如对于一个J2EE开发者来说,DAO,DTO,FormBean,Action已经足够清晰了,但是这却跟DSL沾不上一丝的关联。DSL更注重强调使用业务词汇,尽可能贴近业务模型来编写代码,使业务模型和程序模型之间具有简洁的对应关系。因此我们不能将DSL等同于“整洁的代码”,只能说DSL是一种“整洁的代码”而已。

声明: 本文转载自其它媒体或授权刊载,目的在于信息传递,并不代表本站赞同其观点和对其真实性负责,如有新闻稿件和图片作品的内容、版权以及其它问题的,请联系我们及时删除。(联系我们,邮箱:evan.li@aspencore.com )
0
评论
  • 相关技术文库
  • C语言
  • 编程
  • 软件开发
  • 程序
下载排行榜
更多
评测报告
更多
广告