web开发之动态语言与静态语言

写服务器端程序(业务)的同学或多或少都接触不止一门编程语言，大体上分为编译型和解释型，直观感受上来讲，解释型往往注重语言本身的表达力，一方面减少代码量，另一方面提高代码的可读性。举个例子，ruby 有个著名的用于测试的库叫 rspec，示例代码：

class HelloWorld

   def say_hello 
      'Hello World!'
   end
   
end

describe HelloWorld do 
   context 'When testing the HelloWorld class' do 
      
      it "should say 'Hello World' when we call the say_hello method" do 
         hw = HelloWorld.new 
         message = hw.say_hello 
         expect(message).to eq "Hello World!"
      end
      
   end
end

我们可以看到 describe, context, it, expect, to, eq 作为方法名，在语言层面的支持(ruby支持方法调用不加括号)下，将代码的可读性大大提高，单看这句 expect(message).to eq "Hello World!"，就是不懂程序的人，也能猜到它想要表达是：期望 message 是 "Hello World!"。再来看看Go语言版本的测试库，示例如下：

var _ = Describe("Book", func() {
    var (
        longBook  Book
        shortBook Book
    )

    BeforeEach(func() {
        longBook = Book{
            Title:  "Les Miserables",
            Author: "Victor Hugo",
            Pages:  1488,
        }

        shortBook = Book{
            Title:  "Fox In Socks",
            Author: "Dr. Seuss",
            Pages:  24,
        }
    })

    Describe("Categorizing book length", func() {
        Context("With more than 300 pages", func() {
            It("should be a novel", func() {
                Expect(longBook.CategoryByLength()).To(Equal("NOVEL"))
            })
        })

        Context("With fewer than 300 pages", func() {
            It("should be a short story", func() {
                Expect(shortBook.CategoryByLength()).To(Equal("SHORT STORY"))
            })
        })
    })
})

对比明显，由于Go语言本身的表现力不足(当然也叫极简)，比 rspec 的版本多了很多括号和 func 关键字，虽然仔细看其实差不都，但可读性真是不在一个数量级上。

说完表现力，我们再来谈谈性能。解释型语言绝大部分情况下在性能方面要落后编译型语言很多，当然这么比本身太过钻牛角尖，解释性语言由于设计之初就是要方便程序员表达大脑中的逻辑，同时提供语言运行时的便捷API，有得必有失，必然要舍弃一部分性能。而编译型语言由于对编译速度和硬件掌控度有更高的要求，所以需要舍弃很多语法糖，甚至还要提供更靠近硬件的接口以方便程序做针对性性能优化。

看来，“世界上本来就没有完美的事情” 这道理也适用在这里。那么我们该如何选择呢？这就是一个平衡的问题(假设对不同语言的熟悉程度相同)：

1. 需要快速迭代的新项目可以选择解释性语言，一方面代码量少，另一方面相关的框架(PHP/Laravel Ruby/Rails Python/Django)在项目前期可以帮我们省很多时间。

2. 对于已经梳理清晰业务的新项目，在时间比较宽裕条件下，那我们完全可以用编译型语言，虽然写起来更繁琐一些，但是项目复杂到一定程度，你会发现代码的可读性与代码的魔法程度成反比，换句话说多少代码是要猜的。

3. 如果业务有比较多的计算，无疑用编译型语言做针对性优化更为合适。

4. 如果业务变化非常频繁或者业务逻辑本身就是不断变化的，那么用编译型语言就会显得比较笨拙，而且你会发现你的时间都用在编译上了。时间充裕的话完全可以做一个简单的DSL，rspec 就是个很好的例子。