引用维基百科对 Programming Language 的定义¹：

A programming language is a notation for writing programs, which are specifications of a computation or algorithm.

一个程序设计语言是我们描述程序的记述方式，是对一种计算模型或者算法的说明。

1. 以机器为目标

   程序语言的一个目标就是要在机器（特别是计算机）上运行，因此，程序语言的规格与它要运行的目标机器的规格息息相关。冯·诺伊曼架构的计算机模型就对现代程序语言产生了巨大的影响（比如 C 中的指针概念）。量子计算机、生物计算机等新时代计算机架构的出现也会引起程序语言的巨大变革，但本文不做深入探讨。

2. 抽象

   可以说每个程序语言都是为抽象而生的。机器语言是对硬件操作的抽象，汇编语言是对机器语言的抽象，C 语言是对汇编语言的抽象。

   而抽象也有好坏之分，好的抽象能让人非常容易地理解，而坏的抽象则是雪上加霜，给本就复杂的对象平添了一层复杂度。程序语言也是如此，好的程序语言可以让程序员轻松地将自己想要表达的功能与计算机底层的逻辑联系起来，而坏的程序语言则要让程序员付出更多的时间与精力去完成同样的任务。

   抽象也因此可以称作语言在程序员书写和阅读时展现出来的表现能力。

3. 表现力

   此处的表现力与「抽象」不同，指的是语言在算法层面的表现能力。

   计算理论²通过对语言的表现能力进行分类。现代常用的高级语言都是图灵完备（Turing-Complete）的。

   注意：除了图灵的理论外，还有很多其他的计算模型³。

• 语法

  语法是一个程序语言的最表面的表现形式。大部分的程序语言都是通过文字来表现的（一小部分语言是通过图形表示的，两者的区别在后续内容中讨论）。

  这些文字的语法通常通过正则表达式和巴克斯范式一起组合定义。其中，正则表达式负责词法分析的部分，巴克斯范式负责语法的部分。

  有的语言语法简洁明了，有的语言则像英语语法一样复杂。拥有一个简单、易懂、符合程序员直觉的语法是一个程序语言成功的必要因素。

• 类型系统

  类型系统定义了一个程序语言如何对值和表达式进行分类，操作变换，以及不同类型之间的交互。

  类型是程序语言中一个重要的抽象概念，如果没有类型，那我们熟悉的字符串、整型、浮点型等基本概念都无从谈起，更不用说面向对象编程这种重度依赖数据类型的编程范式了。

  也正因此，一个程序语言对类型定义、变换、交互的支持会很大程度影响程序员在编程时的方方面面。

• 标准库

  标准库也是程序语言在定义时的一个重要组成部分。标准库决定了程序员在只有这个程序语言支持的情况下完成自己任务的难易程度，因此标准库也对一个程序语言的好坏有着很大的影响。

  有的程序语言有着丰富的标准库（如 Go ），程序员甚至不用借助任何第三方库就能完成自己大部分的工作。

  有的程序语言则标准库不完善（如 JavaScript ），程序员需要大量借助第三方库的实现才能让自己的工作轻松一点，这样的语言是很难能被称得上是优秀的。

• 语义

  语义是语法的反面，是一个程序的想要表达的算法的意义。

  一个程序的语义与使用者的能力息息相关，资深的程序员可以使用抽象能力差的语言写出同样表现力的程序，蹩脚的程序员也可以用抽象能力强的语言写出晦涩难懂的程序，而两个程序在语义上是完全一致的。

  这个假设和本文中的其他讨论都是建立在两个语言都是图灵完备的前提下的。程序员对程序语言语义表达的影响超出了本文讨论的范畴，后文将要讨论的是程序语言的设计会如何影响最终程序的可读性。

  我们会发现，程序语言的语法、类型系统、编程范式、标准库，最终都会影响到程序的语义是否清晰可读，甚至影响到程序语言使用者的思维。

用我们所熟知的面向对象思想来看，在面向对象语言写就的程序中，一个对象（object），所代表的就是其封装的数据（data）和行为（behavior）¹⁴。对象通过互相发送消息（message）调用其他对象的行为。

而在结构化或者说过程式语言中，数据本身和行为是没有进行绑定的，每个子过程或者子函数必须通过某种方式知道参数的类型，才能决定下一步的行为。这在大型的项目中是无法满足开发维护的需求的，因为有很多对语言自带类型和自定义类型的使用，如果每次使用都要进行对类型的判断来决定程序的行为，程序本身将变得非常复杂，难以维护。

反观面向对象语言，由于数据与行为的绑定这一抽象，对数据类型的判断可以由程序语言在一定程度上用类型系统辅助解决，帮助简化了程序。

如上小节所述，数据与行为的绑定，是面向对象在抽象层次上更为高明的地方。在这个抽象背后，是对过程式语言控制流方向的反转，下面是一个简单的例子：

• 过程式编程

  World = Struct.new(:category)
  Duck = Struct.new(:name)
  
  def hello(object)
    case object
    when World
      puts "Hello World: #{object.category}!"
    when Duck
      puts "Hello Duck: #{object.name}!"
    else
      raise NoMethodError
    end
  end
  
  world = World.new('CS')
  hello(world) # => Hello World: CS!
  
  duck = Duck.new('Donald')
  hello(duck) # => Hello Duck: Donald!
  
  int = 0
  hello(int) # => NoMethodError
  

  在过程式编程中，控制流的方向是以子过程为重心的，就如这个例子中 object 被传入 hello ， hello 需要通过 case 表达式选择对待不同类型结构时自身的行为，这样的编程范式有几个缺点：

  不易扩展

  每次增加一个新的 hello 可以处理的类型时，都要修改 hello 自身，即违背了开闭原则¹⁵。而在大型程序中， 像 hello 一样要用到新类型的子过程可能非常多，而其中很大一部分的定义和新类型的定义很可能相隔遥远，要修改起来需要在整个项目中寻找每一个子过程的定义，非常繁琐。

  不利于抽象

  当要接受的类型变多，行为变复杂时， hello 中要处理的逻辑将混杂着多个不同类型的逻辑，这很容易导致抽象层级的混杂，不利于抽象，最终让这个函数难以理解。

  难以处理错误

  对类型的手动判断意味着对错误类型也要通过手动判断进行处理，这些额外的逻辑一方面增加了程序的复杂度，另一方面也增加了程序设计者的工作量，给程序员增加了更多负担。

• 进一步抽象后的过程式编程

  为了解决抽象层级复杂的问题，过程式编程发展到一定程度时会将 hello 中对不同类的逻辑单独抽到各自单独的子函数中，以方便管理和扩展。上例改进后的版本如下：

  World = Struct.new(:category)
  Duck = Struct.new(:name)
  
  def hello(object)
    case object
    when World
      world_hello(object)
    when Duck
      duck_hello(object)
    else
      raise NoMethodError
    end
  end
  
  def world_hello(world)
    puts "Hello World: #{world.category}!"
  end
  
  def duck_hello(duck)
    puts "Hello Duck: #{duck.name}!"
  end
  
  world = World.new('CS')
  hello(world) # => Hello World: CS!
  
  duck = Duck.new('Donald')
  hello(duck) # => Hello Duck: Donald!
  
  int = 0
  hello(int) # => NoMethodError
  

  虽然这个版本改进了抽象层级难以统一的问题，但仍然没有解决「难以扩展」和「难以处理错误」这两个问题。而面向对象语言的出现则解决了以上两个问题。

• 面向对象编程

  class World
    def initialize(category)
      @category = category
    end
  
    def hello
      puts "Hello World: #{@category}!"
    end
  end
  
  class Duck
    def initialize(name)
      @name = name
    end
  
    def hello
      puts "Hello Duck: #{@name}!"
    end
  end
  
  def hello(object)
    object.hello
  end
  
  world = World.new('CS')
  hello(world) # => Hello World: CS!
  
  duck = Duck.new('Donald')
  hello(duck) # => Hello Duck: Donald!
  
  int = 0
  hello(int) # => NoMethodError
  

  在这个例子中我们可以看到 hello 函数中不再有判断参数类型的 case 语句，判断类型和分配消息的任务则交给了程序语言本身来完成。这在程序代码上的表现虽然只是由 world_hello(object) 和 duck_hello(object) 变成 object.hello （ object 可以是 world 也可以是 duck ）的简单改变，但这个简单的转变代表的是将控制流的方向从「对象作为函数的参数传入」反转成了「函数作为消息，传入对象」，这是在抽象层级上的一大进步。

  程序语言负责了更多任务

  在面向对象语言中，判断类型和消息分配的任务可由程序语言本身完成（用多态来代替条件判断），这将程序设计者从繁琐的类型判断和错误处理中解放了出来，让人可以专心于设计程序内各种类型的逻辑。

  更优雅的代码组织方式

  由于类型相关的函数都被绑定到了类型本身的定义上，也就意味着在代码组织时，这些逻辑很自然地被归类到了一起，让设计者在设计时对这个类型的职责思考更加深入，让阅读者对类型的理解更加透彻。这也是对象作为数据和行为的结合这一抽象的高明之处。

在程序语言中，不可变对象就是在创建后无法被更改内部状态的对象。不可变对象的使用，迫使程序设计者在修改一个对象时，都不能在原有的对象上做任何修改，而是返回一个重新创建的新对象。

内部状态的变化，是程序副作用（Side-Effect）的一部分，其他的副作用有对数据库的操作、输入输出等等。函数式程序语言倡导的一点就是写出「没有副作用」的函数体。若我们将函数看作一个个黑盒子，当副作用存在于一个函数中时，函数有三个职责：接收输入、产生副作用（如改变状态）和返回输出；当一个函数没有副作用时，函数只用接收输入和返回输出即可。当然，现代程序不可能完全没有副作用（比如数据库操作、磁盘读写等等），而函数式语言的使用者则会有意将具有副作用的函数和不具有副作用的函数明显分隔开，来尽量靠近理想的函数式程序模型。

这个约束给程序设计带来几个好处¹⁷：

1. 数据稳定性

   在面向对象程序语言中，由于内部状态可变性的存在，一个状态复杂的对象很容易在进行某些操作失败时陷入一个不确定的异常状态中，这些破碎的状态，让程序的除错和修复变得非常困难。

   而使用不可变对象，让我们用新对象的创建来替代原有对旧对象状态修改的操作，这将一个复杂的操作变为了一个具有原子性的操作。新对象创建成功即保证了状态更新成功，否则状态更新失败，而不会有任何难以处理的中间状态出现，这对程序的健壮性是一大保障。

2. 代码质量提高

   不可变对象的使用也鼓励程序设计者写出更小的子程序体。因为大部分没有副作用的函数都能表示为一个简单的变换函数，如下：

   new_data = transform(original_data)
   

   而将函数根据有无副作用分割开，也能写出职责更明确的函数，让代码质量提高：

   new_state = transform(current_state, message)
   execute_impure_tasks(new_state)
   store_state(new_state)
   

   如本例中， transform 是没有副作用的函数，而 execute_impure_tasks 和 store_state 是有副作用的，函数的职责更加明确、纯粹，易于阅读者理解。

   当一个函数没有副作用时，程序设计者能很容易地设计出一个输入对应唯一确定输出的函数，这样的函数如数学里的函数一般，能通过一定的表达式清楚表达出来，阅读者也能更加容易地理解这个函数的作用。

3. 并行计算更加容易

   没有副作用的函数可以很容易地被并行化，甚至不需要锁（Lock）等传统同步技术。因为不用担心副作用给程序中共享的数据带来改变，影响同时进行的其他计算。比如当需要改变一个共享对象中的状态时，两个线程不是直接改变其状态，而是使用写时复制（Copy-on-Write）等技术创建具有新状态的对象，不再共享原有对象。

由于不可变对象的特性，循环语句在 Elixir（或者其他函数式语言）中需要用递归来实现。下面是 C 和 Elixir 循环输出一条消息的代码对比：

• C

  int print_multiple_times(string message, int n) {
    for(int i = 0; i < n; i++) {
      printf("%s\n", message);
    }
  }
  

• Elixir

  defmodule Recursion do
    def print_multiple_times(msg, n) do
      if n >= 1 do
        IO.puts msg
        print_multiple_times(msg, n - 1)
      end
    end
  end
  
  Recursion.print_multiple_times("Hello!", 3)
  

  Hello!
  Hello!
  Hello!
  
  

由于没有 i 这个内部状态，Elixir 版本的循环更加易于理解，甚至于我们在此处都可以抛弃循环的概念，只用理解递归函数的概念就可以了。这也正是一种抽象：将程序语言里蕴含的概念进行缩减，让只保存了和「表达循环算法」这一目的有关的内容。这让程序设计者能更加方便地使用程序语言这一工具。

Elixir 中引入了另一个强大的特性，甚至于让程序设计者能够写出完全没有 if, cond, case 等条件判断语句的程序，这就是模式匹配（Pattern Matching）¹⁸。简单地说，模式匹配可以让 Elixir 根据一个函数的参数不同，来选择不同的函数实现，功能上有点类似 C++ 中的函数重载，但更加强大（函数重载是基于类型判断，而模式匹配可以精确到值）。

• Fibonacci 数

  defmodule Fib do
    def fib(0), do: 0
    def fib(1), do: 1
    def fib(n), do: fib(n-1) + fib(n-2)
  end
  
  Fib.fib(10) # => 55
  

  这是 Elixir 中求 Fibonacci 数的函数实现，简单到几乎和数学中的 Fibonacci 数定义一致：

  \[fib(n) = \begin{cases} 0 & n = 0 \\ 1 & n = 1 \\ fib(n-1) + fib(n-2) & n > 1 \end{cases}\]

  对比下面 Ruby 中的实现，没有了模式匹配，只能通过 case 等条件判断语句来决定函数的行为，而这个条件判断将函数体分为了三部分，程序阅读者在阅读这一个函数时需要理解 Elixir 版本中三个函数的信息量，自然在复杂度上比较高：

  class Fib
    def fib(n)
      case n
      when 0
        0
      when 1
        1
      else
        fib(n - 1) + fib(n - 2)
      end
    end
  end
  

• Map

  下面是 Elixir 中实现 Map 函数的例子：

  defmodule MyList do
    def map([], _func), do: []
  
    def map([head | tail], func), do: [func.(head) | map(tail, func)]
  end
  
  defmodule Math do
    def square(x), do: x * x
  end
  
  MyList.map([1, 2, 3, 4, 5], fn(x) -> x * x end)
  

  [1, 4, 9, 16, 25]
  
  

  在本例中，Elixir 利用模式匹配和递归实现了一个简单的 map 实现，同样，模式匹配避免了我们去使用 if array.empty? 这类判断语句来增加复杂度，而让我们将一个函数切分成更小的子函数，更加易于理解。

• 游程编码（RLE，run-length encoding）

  游程编码¹⁹，即将字符串中重复出现的字符用该字符和其重复出现的次数来代替，以实现数据的压缩。下面是 Elixir 实现的版本：

  defmodule RLE do
    def encode(list), do: _encode(list, [])
  
    defp _encode([], result), do: Enum.reverse(result)
  
    defp _encode([ a, a | tail ], result) do
      _encode( [ {a, 2} | tail ], result )
    end
  
    defp _encode([ {a, n}, a | tail ], result) do
      _encode( [ {a, n+1} | tail ], result )
    end
  
    defp _encode([ a | tail ], result) do
      _encode(tail, [ a | result ])
    end
  end
  
  RLE.encode([1, 2, 2, 2, 3, 4, 4, 4, 4, 4])
  

  [1, {2, 3}, 3, {4, 5}]
  
  

  下面是 Ruby 实现的版本：

  class RLE
    def encode(list)
      @result = []
  
      last = nil
      count = 0
      list.each do |num|
        if last != num && !last.nil?
          update_result(last, count)
          count = 0
        end
        count += 1
        last = num
      end
      update_result(last, count)
      @result
    end
  
    private
  
    def update_result(last, count)
      return if last.nil? || count == 0
      if count == 1
        @result << last
      else
        @result << [last, count]
      end
    end
  end
  
  p RLE.new.encode([1, 2, 2, 2, 3, 4, 4, 4, 4, 4])
  

  [1, [2, 3], 3, [4, 5]]
  
  

  这个版本明显比 Elixir 的版本复杂了很多，原因有以下几点：

  1. Ruby 没有模式匹配机制，无法像 Elixir 一样做出复杂的函数自动分配机制，即使手动维护也十分麻烦，需要很多条件语句，因此难以用递归来解决这个问题，这是 Ruby 版本不如 Elixir 版本优雅的最重要的一个原因。
  2. 即使不用递归，用循环语句处理，依然需要用条件语句处理一些边界条件，这些边界条件让程序不够清晰易懂。
  3. Ruby 版本中用了可变的对象（ @result ），维护这个对象让程序变得复杂，更容易出错。

通过上面几个例子，我们可以发现，通过模式匹配，将程序中的条件语句取代掉之后，函数体变成了职责更加明确的子函数，甚至能够简单到像数学函数的定义一般优雅。而且，模式匹配能够让程序设计者更容易地使用递归这一工具，避免很多复杂的条件判断。

本章通过几个简单的例子展现了 Elixir 的进步之处，在用不可变对象给编程加上一定限制之后，编程的实质变得更加明显了，即每个函数都被抽象成了一个个运算，这层抽象让大部分的操作都在形式上统一起来，如数学函数一般的程序让人更加易于理解。

最后在用递归替代了循环语句，用模式匹配替代了条件语句之后，我们之前在结构化语言中讨论的结构化程序理论中只留下了顺序执行，而循环和选择都变成了函数的一种形式，这鼓励了程序设计者在写程序时写出更加短小的函数，由此让程序变得更加简洁、易懂。

SQL 通过几个简单的关键词将数据库领域最常用的增删改查（CRUD）操作抽象了出来：

• 插入数据 INSERT

  INSERT INTO Example
  (field1, field2, field3)
  VALUES
  ('test', 'N', NULL);
  

• 读取数据 SELECT

  SELECT *
  FROM Example
  WHERE field2 = 'Y'
  ORDER BY title;
  

• 更新数据 UPDATE

  UPDATE Example
  SET field1 = 'updated value'
  WHERE field2 = 'N';
  

• 删除数据 DELETE

  DELETE FROM Example
  WHERE field2 = 'N';
  

从这些简单的例子，我们可以看出 SQL 这类领域特定语言的几个特点：

1. 所用词汇、语法与对应领域十分接近

   如 SQL 在数据库领域所做的，INSERT, SELECT, UPDATE, DELETE 都是数据库管理员在操作数据库时需要时常用到的词汇，而 INSERT INTO, DELETE FROM, ORDER BY 等词汇的组合则和英文环境下的数据库操作统一起来，这让数据库管理员在编写良好的 SQL 语句时就如书写英文句子一样。

   这些词汇和语法上的相似之处让领域从业人员能更容易地掌握这门语言，也减少了沟通上的成本（相比 C，Java 等通用语言程序，SQL 语句能更自然地读出来，直接交流）。

2. 不需担心底层实现

   在使用 SQL 语句查询数据库时，数据库管理员不需要知道这条 SQL 语句被转换成了什么样的底层实现，他不需要知道这条 SQL 要使用多少个 for 循环，多少个 if 判断，多少个磁盘读写，他只需要知道 SQL 的语法就能完成自己的工作。这个特性甚至在一定程度上促进了工程师和数据库管理员的进一步分工。

   而 SQL 与底层实现分离的另一个好处是：在保证 SQL 语法不变的情况下，对应的底层实现可以替换。SQL 现在覆盖的领域不单单是如 MySQL 和 PostgreSQL 这样的传统关系型数据库，还有 Amazon Redshift²¹，Vertica²² 这样的列式数据库，甚至有 SparkSQL²³，Amazon Athena²⁴，Apache Hive²⁵ 这样的分布式大数据系统。

   能够覆盖不同类型、不同规模的数据库，SQL 的能力是令人惊叹的。而这跟 SQL 对数据操作领域精准的抽象是功不可没的。

3. 语句灵活，可以组合实现领域内的各种功能

   不单单每个 SQL 词汇都对该领域的一项特定操作做出了准确的抽象，他们之间互相组合也能实现更加复杂的功能。可以说，SQL 的函数都最大程度上实现了正交性，因此才能通过比较小的函数集合，满足该领域的所有需求。

当然，本文想要讨论的依然是通用编程语言，而不是 SQL 这类领域特定语言。但笔者认为，通用编程语言依然可以从 SQL 这类成功的领域特定语言中学到很多东西。毕竟，如果我们换一个角度来看，通用编程语言也是一种「领域特定语言」，而这个领域正是编程（或者说程序设计）这一领域。如何设计出一个在程序设计领域让领域从业者（程序设计者）能够使用自如的特定语言，也正是本文想要探讨的问题。

程序语言的精练程度，即能否用尽可能少的语句表达出更多的意思。这在很大程度上也是程序语言生产效率的一部分，一个语言越精练，设计者也就能更容易地用更小的工作量来完成相同的任务。

程序语言的精练程度，与它的抽象程度是密不可分的。正如前文所述，一个语言越抽象，相同行数的代码所蕴含的信息量也就越大，即这个语言越精练。抽象层次最高的语言——领域特定语言，就能通过最精练的语句，完成该领域内的一个特定任务。也正是因此，程序语言的发展是一个不断抽象的过程，当抽象层级更高的语言出现时，往往是这个语言兴起之时，也正是旧的抽象层级更低的语言衰落之时。

当然，抽象程度高的语言也有可能不精练，但精练的语言一定要抽象。程序语言的精练程度不仅仅与其抽象程度唯一相关，也与其语法结构、类型系统有关。为了设计一个精练的语言，必须要保证其语法结构的清晰、简单；在保证可读性的同时，尽量减少保留关键词的数量。

而关于类型系统，业界也有着许许多多的争论，为了语言的精练，很明显动态类型的语言因为不需要声明表达式的类型，在精练程度上是占优势的，但它们相比静态类型语言有着性能上的先天劣势，导致了两者各有各的簇拥，双方相持不下。笔者认为，一种介于两者之间的类型系统^{27, 28}是一个比较好的解决方案：在性能可以满足需求时使用动态类型，用最精练的语句完成任务，减少程序员的思考负担，避免过早优化；当碰到性能瓶颈时通过分析，加入类型声明等手段提高性能。

但是，很多在抽象程度上很高，语法简单，也有着优秀的类型系统的精练语言也没有流行起来（如 Lisp）。这说明，语言的精练程度并不是决定语言是否流行（高效）的唯一因素，一个语言的流行程度还取决于很多语言设计以外的因素。

随着计算机软件的不断发展，现在大部分的软件已经不是能凭一己之力完成的小玩具了，代码的重用显得愈发的重要。而开源运动（Open Source）的不断发展，也让代码重用变得更加简单。即使一个语言设计的相当精练，没有完善的库支持，也比不上一个不够精练，但有丰富的库支持的语言。毕竟，最高效的开发模式莫过于直接复用别人已经完成的代码，这是再精练的设计也无法弥补的。因此，代码重用的难易程度，或者说一个程序语言对应的库（Library）的数量成为了影响开发效率的一大因素。

而库的数量又包含两个方面：

• 标准库（Standard Library）

  在高级语言发展的初期，各种语言的标准库的功能都非常有限，只有一些基本操作的封装，如 IO，数学运算，字符串操作，内存管理等等。随着计算机功能的逐渐增多，语言的标准库也不断丰富完善。在多线程出现之后，标准库中加入了对多线程的支持。再到如今，各式各样的需求层出不穷，程序语言的标准库也愈发强大，甚至可以直接利用标准库完成一个 Web 应用²⁹，其中用到的标准库功能包括 net/http （网络传输）, html/template （HTML 模板处理）, regexp （正则表达式）等等。

  可以说，一个语言的标准库对于其生产效率起着越来越重要的作用，原因主要有二：

  1. 标准库是一个语言中重用门槛最低的代码。标准库的功能越全，质量越高，则开发效率也就越高。
  2. 标准库起到了标杆作用。在人们学习一门语言时，标准库往往代表着这个语言的核心思想，作为范例供人们参考。标准库的质量越高，人们上手这个语言也就越快，完成的项目质量也更高。

  当然，标准库功能越丰富，另一方面也增加了这个语言的学习成本，设计者要在标准库的功能上做出取舍，找到适当的平衡点，将多余的功能交给第三方库来完成。

• 第三方库、框架等

  开源库和开源框架，作为标准库的补充，可以看作是一个个领域特定语言（如 Ruby on Rails 是 Web 领域的特定语言），它们的数量基本决定了一门语言的在面对某一领域通用功能时的开发效率。它们的数量越多，质量越好，代表着开发者在面对这一领域时的选择就越多，反之，开发者只能从头开始对这一领域实现自己的解决方案，这无疑降低了他的开发效率。

  因此开源软件在现代的软件开发中扮演的角色越来越重要，开源库和开源框架的影响力甚至能够超过语言本身，反过来提高相应语言的影响力。

  最能说明这一点的例子是 Ruby on Rails Web 框架对 Ruby 语言的影响：当 Ruby on Rails 在 2015 年发布时，Web 界的流行框架都非常繁琐，不够好用，Ruby on Rails 凭借 Ruby 的灵活特性和其自身的优秀设计迅速地在 Web 界获得了大量簇拥。为了能够使用 Ruby on Rails 快速构建 Web 应用，大量的 Web 开发者学习了 Ruby on Rails，与此同时学习了 Ruby 语言。可以说，是 Ruby on Rails 的出现使得 Ruby 成为了 Web 领域最有竞争力的一门流行语言。

语言的精练程度和库的数量、质量代表的是一个语言能够完成的产品质量，与完成它需要的时间。而另一个能影响生产效率的则是语言对应的工具链的成熟程度。它决定的是开发者在使用这个语言时的开发体验，体验越好，开发者的效率自然也就越高。

因此，我们也就不难理解，为什么在移动开发领域，Apple 和 Google 两大公司都在不断地完善 iOS 和 Android 这两大移动操作系统应用的工具链（分别对应的是 iOS 的 Xcode 和 Android 的 Android Studio）。

另外，2011 年出现的 Elixir，也将其交互式环境（iEx）、构建工具（Mix）和测试框架（ExUnit）同语言本身一起打包，提供给开发者。这些工具链与语言本身的组合在之前的语言中是很少见到的，但笔者认为，工具链的完善是程序语言发展的一个重要方向。

语言的工具链在开发过程中对生产效率的影响主要在以下几个方面：

1. 自动化测试、构建、部署

   在一个语言的工具链中最重要的部分就是其自动化工具的完善程度，只有让测试、构建、部署，这些在开发流程中重复而又繁琐的过程自动化，该程序语言的开发流程才能得到最大的简化，效率也能得到最大的提高。

   在上面的例子中，Xcode 和 Android Studio 都集成了自动测试、构建、部署的工具， Elixir 则用自带的 Mix 和 ExUnit 满足了这些需求。

2. 提供快速试验的场所

   如 Swift 以 Xcode 中的 Playground 作为交互式环境，Elixir 以 iEx 作为交互式的脚本试验场，他们都为开发者提供了一个快速试验想法的工具，以此加快开发者实现想法的速度。

   这类交互式的环境避免了传统的编译运行流程，能够让开发者快速试验一段代码是否可行，也能让开发者在调试、差错时更加容易，因此它们在如今的开发流程中显得越来越重要。

3. 引导开发者入门

   一个语言的工具链还包括了帮助开发者入门该语言的部分。

   如 Apple 在 2016 年发布的 Swift Playgrounds³⁰ 这个 iPad App，作为一个可交互的编程环境，结合说明文字、动画等等辅助内容，甚至能够让没有编程经验的小学生快速学习 Swift 语言。这对语言的传播和普及来说是影响深远的。

   当然，一般的程序语言并没有 Apple 这样实力雄厚的公司作为后盾，但我们仍能看到如 Python 社区的 Jupyter Notebook³¹ 这样的开源项目，实现类似的功能，笔者也相信这样的工具将会传播到更多的社区，降低语言的学习成本。

语言的品种是多一点比较好，还是少一点比较好？这是一个非常难以回答的问题。就目前来说，他们都各有利弊：

• 语言品种多

  • 文化多元

    当语言品种够多时，不同语言都拥有自己的独特文化，而正是这些文化让程序语言的世界变得丰富多彩。也正是因为这些文化的存在，增加了程序语言的生命力，不同文化的语言互相交融碰撞产生新的语言为程序语言注入新的活力。

  • 选择困难

    但若语言品种过多，则会造成使用者的困惑和选择困难的情况。可以用很多不同的语言解决相同的问题说明了这些语言之间功能的重复，而对比不同语言才能最终做出决定则违背了设计程序语言提高效率的初衷。

• 语言品种少

  • 学习、沟通成本低

    当语言品种少时，程序设计者需要学习的语言也就相对较少，可以集中精力掌握主流的语言，满足自己的大部分需求。而且，语言品种少也降低了行业内的沟通成本，因为大家都能用相同的语言进行沟通，而不需要进行思维上的切换，使得知识的交流和分享门槛大大降低。

  • 单一语言有其局限性

    但语言种类少也有其缺陷，即单一语言的局限性。虽然现今的高级语言都属于「通用编程语言」，但是受限于语言设计者的能力和文化偏好，还有使用者的广泛程度、文化背景的不同，几乎每一门高级语言都有其擅长与不擅长的领域，即其局限性。而这种局限性在目前看来，只能通过语言的多样性来解决。

但笔者认为，语言的分裂只是暂时的，可能这种情况会持续几十年，或者几百年，但最终程序语言应该会在扩张之后收敛到几个主流语言，最终收敛为一个主要语言。

毕竟，单一语言的局限性仅仅是说明语言的抽象层级还不够高，当语言的抽象层级足够高时，自然能够覆盖所有可能的应用场景，也能通过其定制的库和框架实现文化上的多元。

关于这一点，可能要参考科学语言和自然语言的发展历史。

回顾程序语言发展的历史，其实才短短的几十年时间，而科学语言（数学、物理、化学等）和自然语言（英语、中文等等）均已有了上千年的历史了。从后两者的发展历史中我们也能学习到程序语言发展的方向。

• 科学语言

  对比数学、物理、化学等历史比较久的科学，我们能发现，在这些学科中，所用的语言是比较统一的：数学有其完善的数学符号系统，化学有其一致的化学式系统。

  而程序语言则呈现出百花齐放的态势，原因主要有二：

  1. 自然科学发展比较早

     在人类历史早期时，自然科学就已经萌芽并发展。而交流仅限于文化近似的区域，语言上比较容易统一，之后传播开来时，语言已经比较成熟，传播之后也不会有很大的变化。

     而程序语言的发展则伴随着互联网、开源运动的兴起，不同文化、不同背景的人能很容易的在网上、开源社区交流对语言的要求和想法。这一方面促进了其发展，另一方面也造成了其分裂的状态。

  2. 自然科学历史比较悠久

     自然科学的发展时间比程序语言悠久得多。这一点是我们必须正视的。上千年悠久的时间，足够这些自然科学语言沉淀融合，最终达到一个比较统一的状态。

     这也是我认为程序语言最终会走向统一的原因，毕竟其目的就是为了更好的交流思想，表达算法，统一的语言带来的好处是显而易见的。

• 自然语言

  从现状看，程序语言则更加类似于自然语言。

  自然语言也因为各个地区文化的不同，有着各种不同的分支，但如今占统治地位的则明显是英语这一种语言。

  但自然语言与程序语言有一点很重要的不同就是：程序语言是人工设定的，而自然语言是自然发展而来的。因此，程序语言相比自然语言更加规范。

  而且，程序语言比自然语言更加注重实用性，其存在就是为了解决实际的问题。而自然语言还有小说、诗歌等文化上的需求，也有交流达意等任务，相比程序语言不那么纯粹。

  也正因此，我认为程序语言相比自然语言更有可能收敛到几个主要语言上。

当一个理想的语言出现时，理应是这个语言一统江湖之时。不过如果我们回首程序语言发展的历史，我们会发现优秀的语言并不是没有出现过，但为什么工业界至今没有一个统一的语言标准呢？为何唯独计算机领域无法找到一个统一的解决方案？笔者认为原因有以下几点：

1. 计算机领域发展得太快

   过去几十年里，计算机硬件的飞速发展使得这一领域的知识交替得太快。当一个语言还没有来得及获得大多数人的认同时，新的需求出现，使得这一语言迅速落后，被别的语言淘汰了。

2. 语言间迁移成本太高

   由于不同语言之间的迁移无法自动化完成，又由于各语言都是图灵完备的，最终能完成的任务没有区别，除非在运行效率上有显著的提升，一般没有公司会主动进行项目语言的迁移。这导致了很多旧语言写就的程序（如 Cobol 在银行领域³³）依然在运行，即使有更优秀的语言出现，也难以改变多种语言共存的现状。

3. 信息大爆炸

   伴随计算机出现的是信息的大爆炸，程序语言领域也是一样，单单程序语言领域内的知识已经超过了个人能够掌握的极限，因此没有人能够集各家之长，设计出一个「完美」的语言，每一个语言都有其特殊性和偏向性。

但笔者认为，这些障碍都是暂时的。毕竟，对比数学等有上千年历史的学科，计算机科学这一仅有几十年历史的学科最多只能算得上还在蹒跚学步的阶段，给足一定时间，上述问题终究能够解决：即使因为不断有新需求的出现造成语言的更替，我们依然能看到编程范式的不断发展；即使语言间的迁移成本高，随着新旧软件的交替，旧语言的占比会不断降低；即使随着信息大爆炸造成语言设计难度的提高，但有开源社区的支持，一个语言的发展也会愈发迅速。

笔者认为我们最终能达到一个理想的语言：它在抽象层级上足够高，有着丰富的库、框架，又有着强大的拓展能力，能够基于自身写出满足任意领域的特定语言，以此满足各个特定领域的独特需求，并且有着良好的开发体验，这些条件组合使得程序设计者能够高效地完成程序设计任务。