`
raymond2006k
  • 浏览: 290581 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

InfoQ刚发表一篇论文《半静态语言–原理和价值分析》

D语言velocityJSPIDE敏捷开发 
阅读更多
半静态语言 – 背景、原理和价值
（Semi-Static Language  - Background,Mechanism and Value）

【摘要】动态类型语言在企业开发和互联网开发中应用广泛，而其弱类型的内在特点使其在这些业务复杂的应用开发中存在很多缺点：无法静态验证，程序不健壮，测试成本高；缺乏静态语言如Java的实时验证、代码提示、代码重构等敏捷开发功能。为此，本文提出半静态语言，它的基本原理是两阶段模型，开发时运用变量类型声明进行类型检查，运行时采用解释执行的方式。半静态语言它结合了动态语言和静态语言的优点，同时满足灵活性、健壮性与敏捷开发的需求。

【关键词】半静态语言,动态类型语言, 静态类型语言, Velocity, Freemarker, Java

原文首发在 InfoQ China:
半静态语言 – 背景、原理和价值


PS: 第一次在InfoQ发论文，感谢凯丰热情的服务，感谢张逸、王瑜珩对论文的评审，专业认真的意见对二稿完善很有帮助。
分享到：
Xml 的两类应用场景
评论
16 楼 sunnyfun 2010-12-14  
强类型和弱类型，动态和静态没有直接的关系吧，强类型可以是动态的，弱类型也可以是静态的，只要你有精力去实现就是了。
知道basic不？最早是弱类型的，在vb里加个声明就可以变成强类型了，basic既有解释执行的，又有编译执行的
所以楼主无非是需要一个解释器和一个编译器罢了
15 楼 ustcfrank 2010-12-14  
如果这样的话，那就无法解决 VelocityContext 和 Template 中变量名称不匹配的问题。
也就是说，变量名不能重构。


raymond2006k 写道
ustcfrank 写道
又看了一遍楼主的文章，总结一下楼主引入“半静态语言”的好处：
1、可以重构
2、提高开发效率：比如在IDE中能“.”出属性。


这里我说说重构，拿这段段代码来讲： 
##$ com.abc.crm.Customer customer   
<HTML>   
Hello $customer.name   
</HTML>


按照楼主的思路，如果 
Hello $customer.name

错写（name->nome）成了 
Hello $customer.nome


那么编译阶段是能检查出来的。

这个就是 半静态语言在 IDE 内最直接的优势了，实时的可视化的编译错误显示，就像 Java 一样。

引用

但是如果整体错写（customer->custamer）成了： 
##$ com.abc.crm.Customer custamer   
<HTML>   
Hello $custamer.name   
</HTML>

这样的话，编译也能检查出来吗？？

这段代码是正确的哦，因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。

引用

如果能的话，那么我觉得： 
##$ com.abc.crm.Customer custamer

这个声明就是多余的。

原因：说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查，
既然已经去来源地去做检查的，其实就可以获得它的真正类型了，所以声明是多余的。

基本验证规则是按 class 进行验证，这个是不多余。
如果是分析对应 Java 源文件， 这个声明可以去掉，但这是一种隐式声明， 文章中有提到的。
比如：不分析Java源码，编译器还可以内置固定变量 
<html>
<body>
Hello, $request.getParameter("username") ! <p/>
Your logged in at $session.getAttribute("loginTime") last time.
</body>
</html>


14 楼 sleepinglord 2010-12-14  
1.静态语言也可以解释执行。你用过单步调试？那就是在解释执行你的语句，甚至是传说中最静态的语言fortran，都是可以解释执行的！
2.动态语言也可以编译执行。你用过python，ruby？这些不能编译成exe么？甚至是传说中最动态的语言lisp，都是可以编译成exe的！

所以在解释与编译，动态与静态之间完全没有既定的规则，说谁一定要解释谁一定要编译。

类型检查，嗯……其实呢，我一直觉得，类型检查是好东东，动态也是好东东，ducking type在使用的时候也是好东东。为啥一定要矛盾呢？

我期望的语言是，你愿意写明类型，我就检查，写得越多检查越多，你不写，我就推断，推断不出来拉倒。

举例而言：我期望中的语言的函数，大概是这样的（语法可以再设计，这里只说明思路）
func(in a as const A, in b, inout c like IC, out d as D)

这里in，inout，out，as，like是关键字。
a,d写了类型const A，于是我就检查，你的参数是不是A类型的，在函数里有没有写操作？
b什么都没写，于是就不检查，运行时再报错。
like是我自己编的关键字，专门针对ducking type的情况，即，你编写一个interface，只要c长得和这个interface一样，即满足其公共方法（注意只关心公共方法），就ok！没必要从那个interface继承（有时候强制继承很没必要）。如果愿意的话，这种interface甚至只是用来做检查，不会真正参与编译。

这语言甚至可以考虑在语法上支持更多的约束的表示，以方便愿意使用的人们在编译时进行检查。

所以我觉得很多事情其实没用本质冲突的来着。
13 楼 raymond2006k 2010-12-14  
ustcfrank 写道
又看了一遍楼主的文章，总结一下楼主引入“半静态语言”的好处：
1、可以重构
2、提高开发效率：比如在IDE中能“.”出属性。


这里我说说重构，拿这段段代码来讲： 
##$ com.abc.crm.Customer customer   
<HTML>   
Hello $customer.name   
</HTML>


按照楼主的思路，如果 
Hello $customer.name

错写（name->nome）成了 
Hello $customer.nome


那么编译阶段是能检查出来的。

这个就是 半静态语言在 IDE 内最直接的优势了，实时的可视化的编译错误显示，就像 Java 一样。

引用

但是如果整体错写（customer->custamer）成了： 
##$ com.abc.crm.Customer custamer   
<HTML>   
Hello $custamer.name   
</HTML>

这样的话，编译也能检查出来吗？？

这段代码是正确的哦，因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。

引用

如果能的话，那么我觉得： 
##$ com.abc.crm.Customer custamer

这个声明就是多余的。

原因：说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查，
既然已经去来源地去做检查的，其实就可以获得它的真正类型了，所以声明是多余的。

基本验证规则是按 class 进行验证，这个是不多余。
如果是分析对应 Java 源文件， 这个声明可以去掉，但这是一种隐式声明， 文章中有提到的。
比如：不分析Java源码，编译器还可以内置固定变量 
<html>
<body>
Hello, $request.getParameter("username") ! <p/>
Your logged in at $session.getAttribute("loginTime") last time.
</body>
</html>

12 楼 raymond2006k 2010-12-14  
yimlin 写道
不错的文章。

在动态类型语言中这么搞有助于提高效率。

但是我的问题是这样：
freemarker和velocity这样的弱类型，包括EL提供的能力，可是使得我们的程序可以超越类型（Type），比如： 
actionLet.submit();


我可以不去理会actionLet具体是何种类型，只要他有这个方法就可以了。
但是如果加上一个类型申明，则意味着程序必须有类型定义，如果我们在java下开发，那么比较好的方式是定义一个接口，比如： 
com.xxx.web.ActionLet


这样就会导致，一些依靠约定可以完成的工作，现在不得不额外增加接口了。方案在这个方面是怎么取舍的？




这是个典型的  ducking type 问题————无继承的行为多态。 ducking type是很难做到行为的强类型检查的，因此，在语义上，semi-static language 是禁止 ducking type的。
11 楼 deepthink 2010-12-13  

个人觉得，用什么样的语言，不管是静态强类型，或者半静态，还是动态语言，并不存在拿出来比较的价值，除非是为了做很底层的开发，或者研究用；
至于说哪个更好一点，就要根据具体的情况而定，对于模板语言而言，我个人觉得是越简单，越灵活越好，因为这意味着开发成本的降低

之前楼层的同学曾经提出过一个velocity的重构的问题，这里我也发表一下自己的看法，个人觉得，velocity其实不存在重构的问题，能够重用的东西往往都是带有极的一致性，而在网页的开发中，重用虽然能够有效的降低开发周期，但是往往是存在代价的，而且在不同项目之间的移植性往往差的要命；
另外一个关键的问题是，现有的模板引擎大部分已经是很弱的类型，甚至比脚本语言更甚；所以，我认为，如果你不是打算像google那样想要完整的搞一套控件出来，还是不要试图去对模板进行重构了，要做的只是使用已有的模板引擎把逻辑敲出来就好了...

一家之言，欢迎拍砖...
10 楼 hatedance 2010-12-13  
静态类型语言也可以被解释执行，动态类型语言也可以编译执行。
所以，jsp就可以满足lz的要求，在eclipse里支持类型检查和代码提示，修改完了tomcat直接后台编译运行，无须用户干预。
至于velocity，我觉得关键也是要做一个eclipse插件支持类型检查等功能。
9 楼 allbin1983 2010-12-13  
在展示层原生态HTML也是一个思路，比如： http://simpleframework.net/simple/main/doc/d2/d.jsp?a=2.1.3 的想法也不错。

比如开发一个树，对应的demo.jsp 如下,只需要通过id="demoDbTree"就可以完成数据的绑定，不需要学更多的语法：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<div style="padding: 10px;">
<div>这棵树直接和后台数据库的表绑定</div>
<div id="demoDbTree" style="padding: 8px; border: 5px solid #ddd;"></div>
</div>

对应的 demo.xml 描述文件：

<?xml version="1.0" encoding="UTF-8"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="/xsd/default/simple.xsd">
<components>
<dbTree name="demoDbTree" containerId="demoDbTree" tableName="simple_department"
parentIdName="parentId" idName="id" textName="text" width="300">
</dbTree>
</components>
</page>

实现原理：

Web应用中，无论服务器端采用（Java EE或.Net），客户端的请求（Request）经Web或应用服务器解析后，最终返回客户端的响应（Response）内容主体都是HTML（含Javascript脚本、CSS等）。由此，就提供了解决问题的契机，那就是在响应内容返回客户端（/浏览器）之前，“拦截”响应，解析响应HTML，并进行“再处理”，由此，可以保留HTML和HTTP的原生态。

8 楼 ustcfrank 2010-12-13  
又看了一遍楼主的文章，总结一下楼主引入“半静态语言”的好处：
1、可以重构
2、提高开发效率：比如在IDE中能“.”出属性。


这里我说说重构，拿这段段代码来讲： 
##$ com.abc.crm.Customer customer   
<HTML>   
Hello $customer.name   
</HTML>


按照楼主的思路，如果 
Hello $customer.name

错写（name->nome）成了 
Hello $customer.nome


那么编译阶段是能检查出来的。

但是如果整体错写（customer->custamer）成了： 
##$ com.abc.crm.Customer custamer   
<HTML>   
Hello $custamer.name   
</HTML>



这样的话，编译也能检查出来吗？？

如果能的话，那么我觉得： 
##$ com.abc.crm.Customer custamer

这个声明就是多余的。


原因：说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查，
既然已经去来源地去做检查的，其实就可以获得它的真正类型了，所以声明是多余的。

7 楼 yimlin 2010-12-13  
不错的文章。

在动态类型语言中这么搞有助于提高效率。

但是我的问题是这样：
freemarker和velocity这样的弱类型，包括EL提供的能力，可是使得我们的程序可以超越类型（Type），比如： 
actionLet.submit();


我可以不去理会actionLet具体是何种类型，只要他有这个方法就可以了。
但是如果加上一个类型申明，则意味着程序必须有类型定义，如果我们在java下开发，那么比较好的方式是定义一个接口，比如： 
com.xxx.web.ActionLet


这样就会导致，一些依靠约定可以完成的工作，现在不得不额外增加接口了。方案在这个方面是怎么取舍的？

6 楼 agapple 2010-12-13  
顶中堂，velocity的维护和重构的确是一个很头疼的问题

这么多年下来，有见过重构biz层代码的，但很少有敢重构view层展示逻辑，大量充斥着不知名的变量定义，唯一能做的的无非就是完全重写一遍
5 楼 ustcfrank 2010-12-13  
好吧，希望大家早点做完，然后开源出来，再写几个例子，给javaeyer们一个交待吧:)
4 楼 ZHH2009 2010-12-12  
<div class="quote_title">raymond2006k 写道</div>
<div class="quote_div">
<br>其实“半静态语言”乍看上去和“JSP+EL”的思路很相似，不过还是有区本质别的。对于EL，拿 JSP2.1-EL规范的例子来说：&lt;c:out value="${customer.name}"/&gt;， 获取model仍然是一种动态类型推断，在JSP执行前，你无法知道 name 是不是 customer 的合法属性.<br>
</div>
<p><br><br>这个没错，EL和velocity的核心实现都是一样的，<br>都是先用JavaCC把文法文件转换成Parser和TokenManager，<br>然后Parser和TokenManager在运行时把模板解析为一棵抽象语法树(AST)，<br>最后再从上往下遍历这棵树，树结点有很多类型(比如Reference、Method、MathNode等等)，<br>对这些树结点"求值"，最后把结果放入一个Writer中。<br><br>为什么说“半静态语言”乍看上去和“JSP+EL”的思路很相似呢？<br>比如举个例子:</p>
<pre name="code" class="java">1)
class Customer {
String name;
}

2) jsp声明
&lt;%! Customer customer %&gt;

3) el使用
${customer.name}
</pre>
<p><br><br>如果把2)和3)放到一个foo.jsp文件中，是不是就很像下面这段代码呢:</p>
<pre name="code" class="java">##$ com.abc.crm.Customer customer
&lt;HTML&gt;
Hello $customer.name
&lt;/HTML&gt;
</pre>
<p><br><br>只不过这里对customer这个变量的赋值不在当前模板(或jsp)中进行，而是放在控制器层或其他地方赋值，<br>这会给人一种不一致的感觉(比如大家养成的习惯是变量在使用前不能为null)，<br>这里的变量声明仅仅是个"类型暗示"，不是一般程序语言中的变量声明。<br><br>当然，上面给出的“JSP+EL”的代码是不能工作的，<br>jsp之所以做不到像velocity那样能解释执行，主要是因为jsp中有可能包含java源代码(更规范的说法叫: "scriptlet")，<br>如果把这个限制去掉，就很容易做到像velocity那样解释执行了。</p>
<div class="quote_title">raymond2006k 写道</div>
<div class="quote_div">
<br>不知你的强类型方案是怎样的，如果是类似 Mvel 模板的编译方式，它只是将 AST 进行了二进制化，还是一个dynamic typing system.  jjw 同学谢了篇mvel 性能对比的文章，http://jjw.iteye.com/blog/706034。这种字节码方式，还是有提升空间的。 <br>具体我们再聊聊。 <br>你说的IDE优点指的就是我在文章中所说的 代码提示，实时验证等功能么？ <br>
</div>
<p><br><br>我所说的"强类型的模板引擎"，就是把jsp中的"scriptlet"去掉，<br>如果应用想要使用for\while这样的功能，可以从velocity、freemarker借鉴一下，都是有现成的解决方案的。<br><br>如果有了类型声明，IDE可以做很多事了，比如输入一个点号就能提示你有哪些字段和方法可用，按下F3就会跳到声明的地方。<br><br>静态编译(包括现在做的velocity编译)也像jsp的传统做法，先将模板转成java源代码，最后再用编译器编译成字节码，<br>当然也可以直接用ASM不经过编译器直接把模板转成字节码，这种方式缺点是难度大，不方便开发调试。<br><br>关于性能提升这块，因为velocity本身的渲染性能就很高，所以编译后的字节码就目前来看要做到两倍提升会有点难度，<br>主要还是cpu这块要好很多，具体的测试报告还是内部邮件的方式，不方便发出来。<br><br>PS1. 上面提到的mvel 性能对比的文章还是没做到极致，<br>请参见这里:<br><a href="http://rdc.taobao.com/team/jm/archives/552">大方法的执行性能与调优过程小记</a><br><br><br>我们现在的做法是尽量避免反射调用，做到类似jit的功能，考虑到数据一旦放到Context中就很少变动了，<br>此时可以根据数据类型来生成代码:<br><br>比如先把数据放到Context:</p>
<pre name="code" class="java">context.put("customer", new Customer());

$customer.name

当在编译时生成这样的代码：
if(context.get("customer") instanceof Customer) {
Customer customer = (Customer)context.get("customer");
customer.getName();
} else {
  //反射逻辑
}
</pre>
<p> </p>
<p> </p>
<p> </p>
3 楼 androidleader 2010-12-12  
raymond2006k 写道
看来大家的思路和想法志同道合啊，多多交流。


ZHH2009 写道
呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是JSP+EL，
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行，
而EL又不能静态编译成源代码。



其实“半静态语言”乍看上去和“JSP+EL”的思路很相似，不过还是有区本质别的。对于EL，拿 JSP2.1-EL规范的例子来说：<c:out value="${customer.name}"/>， 获取model仍然是一种动态类型推断，在JSP执行前，你无法知道 name 是不是 customer 的合法属性.

ZHH2009 写道

我从去年就开始尝试做一个强类型的模板引擎，
在开发阶段能像velocity那样解释执行，也能利用ide的很多优点，
也可以静态编译成java源代码然后直接部署到生产环境，这样性能会很高。

已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成），
可以带来性能提升(特别是cpu load会下降)，
也可以做到零成本迁移，唯一缺点就是在开发阶段无法利用ide的优点。

不知你的强类型方案是怎样的，如果是类似 Mvel 模板的编译方式，它只是将 AST 进行了二进制化，还是一个dynamic typing system.  jjw 同学谢了篇mvel 性能对比的文章，http://jjw.iteye.com/blog/706034。这种字节码方式，还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示，实时验证等功能么？

ZHH2009 写道

楼主这个方案的起因是为了尽量兼容现有的velocity应用，
不过还是无法做到零成本迁移的。

虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity，但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术，尽量接近 零迁移成本。因为，根据我们的分析，完全零成本是很有难度的。可以适当安排进行Code Refactor，辅以少量显式声明，毕竟，实现半静态化Velocity后，开发质量和开发效率上，好处是多多的。^_^


本版目前唯一的好帖。


说白了，要灵活，并且高效，这两个找个平衡点。

如何能让嵌入的半静态内容，有fp一样灵活的特性。
2 楼 raymond2006k 2010-12-12  
看来大家的思路和想法志同道合啊，多多交流。


ZHH2009 写道
呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是JSP+EL，
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行，
而EL又不能静态编译成源代码。



其实“半静态语言”乍看上去和“JSP+EL”的思路很相似，不过还是有区本质别的。对于EL，拿 JSP2.1-EL规范的例子来说：<c:out value="${customer.name}"/>， 获取model仍然是一种动态类型推断，在JSP执行前，你无法知道 name 是不是 customer 的合法属性.

ZHH2009 写道

我从去年就开始尝试做一个强类型的模板引擎，
在开发阶段能像velocity那样解释执行，也能利用ide的很多优点，
也可以静态编译成java源代码然后直接部署到生产环境，这样性能会很高。

已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成），
可以带来性能提升(特别是cpu load会下降)，
也可以做到零成本迁移，唯一缺点就是在开发阶段无法利用ide的优点。

不知你的强类型方案是怎样的，如果是类似 Mvel 模板的编译方式，它只是将 AST 进行了二进制化，还是一个dynamic typing system.  jjw 同学谢了篇mvel 性能对比的文章，http://jjw.iteye.com/blog/706034。这种字节码方式，还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示，实时验证等功能么？

ZHH2009 写道

楼主这个方案的起因是为了尽量兼容现有的velocity应用，
不过还是无法做到零成本迁移的。

虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity，但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术，尽量接近 零迁移成本。因为，根据我们的分析，完全零成本是很有难度的。可以适当安排进行Code Refactor，辅以少量显式声明，毕竟，实现半静态化Velocity后，开发质量和开发效率上，好处是多多的。^_^

1 楼 ZHH2009 2010-12-11  
呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是JSP+EL，
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行，
而EL又不能静态编译成源代码。

我从去年就开始尝试做一个强类型的模板引擎，
在开发阶段能像velocity那样解释执行，也能利用ide的很多优点，
也可以静态编译成java源代码然后直接部署到生产环境，这样性能会很高。

楼主这个方案的起因是为了尽量兼容现有的velocity应用，
不过还是无法做到零成本迁移的。

已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成），
可以带来性能提升(特别是cpu load会下降)，
也可以做到零成本迁移，唯一缺点就是在开发阶段无法利用ide的优点。
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Magicbox
Global site tag (gtag.js) - Google Analytics