王垠关于编程语言的一些帖子,

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010087886/article/details/48877123

王垠是编程语言方面的科学家,我很喜欢他对于程序设计语言的一些见解。

从很多角度都给与了我启发,当然它的博客里面的文章不只包括程序设计语言方面的。

本帖罗列一些我看到的他的关于程序语言的文章,摘抄一些我喜欢的话语,总结一些结论。

这里选取的文章并不是专门针对某一门语言的,而是介绍一类语言或者针对许多语言。

第5篇SQL,NoSQL以及数据库的实质,看似只是在说SQL实则不然。

谢谢王垠的分享。

王垠的博客地址:http://www.yinwang.org/

http://www.jianshu.com/users/b1dd2b2c87a8/latest_articles


阅读的文章:

1.如何掌握程序语言:http://www.douban.com/group/topic/32248067/

2.什么是语义学:http://www.yinwang.org/blog-cn/2012/07/25/semantics/

3.谈语法:http://www.yinwang.org/blog-cn/2013/03/08/on-syntax/

4.什么是脚本语言:http://www.yinwang.org/blog-cn/2013/03/29/scripting-language/

5.SQL,NoSQL以及数据库的实质:http://www.yinwang.org/blog-cn/2014/04/24/sql-nosql/


1.如何掌握程序语言

这篇文章对于我这个帖子来说可以说是提纲挈领的,对我来说最精彩的内容莫过于


(1)几种常见语言风格的介绍

①面向对象

②面向过程

③函数式语言

在《对函数式语言的误解》一文(http://www.yinwang.org/blog-cn/2013/03/31/purely-functional/)中,王垠给的函数式语言的定义为:能够在任意位置定义函数,并且能够把函数作为值传递,不管这函数是“纯”的还是“不纯”的。

④逻辑是语言

一个重要特点是:逻辑式语言写的程序,是能“反向运行”的。


(2)语言速度快取决于什么

两点:①编译器质量②算法


(3)推荐的书籍


2.什么是语义学

一个程序的“语义”通常是由另一个程序决定的,这另一个程序叫做“解释器”(interpreter)。程序只是一个数据结构,通常表示为语法树(abstract syntax tree)或者指令序列。这个数据结构本身其实没有意义,是解释器让它产生了意义。

所以“语义学”,基本上就是研究各种解释器。


3.谈语法

语法其实只是对语言的本质结构,“抽象语法树”(abstract syntax tree,AST),的一种编码。一个良好的编码,应该极度简单,不引起歧义,而且应该容易解码。在程序语言里,这个“解码”的过程叫做“语法分析”(parse)。

为什么我们却又需要语法呢?因为受到现有工具(操作系统,文本编辑器)的限制,到目前为止,几乎所有语言的程序都是用字符串的形式存放在文件里的。为了让字符串能够表示“树”这种结构,人们才给程序语言设计了“语法”这种东西。


对于2和3的总结

编程无非就是想要将人自己想做的事情交给机器去做,所以中间就有人描述自己想做的事情,以及机器做事儿的过程。

机器可以很好地做好被指定事情,但是永远不知道人可能会想要自己做什么。

人需要描述自己想要做的事情,而人类更习惯于用字符串来表述。

但是机器并不懂人在说什么,这个时候需要有人告诉机器a做什么b怎么做

a做什么便是parser的工作

b怎么做便是interpertor的工作

这样也就和语言速度快对应起来。

这里比较容易混淆的概念是,做什么对于程序员来说是一个算法问题,。


4.什么是脚本语言

谈到了脚本语言和解释性语言的区别。


5.SQL,NoSQL以及数据库的实质

谈到了逻辑式语言和关系语言的共同特点,并因为这个特点,“只告诉它 What,而不是告诉它 How”,可以将它们都称为:描述性语言。

逻辑式语言(以Prolog为例)的弊端:说白了,Prolog 采用的“计算”方式就是“穷举法”。为了得到用户“描述”的问题的答案,而不需要用户指定具体的数据结构和算法,Prolog 必须对非常大的图状解空间进行完全的遍历(Prolog 采用深度优先搜索)。而这种解空间的“状态”数量往往是与程序运行时路过的分支数目成指数关系,这就决定了 Prolog 虽然“最终”可能找到问题的答案,却很有可能在地球毁灭之前都没法完成它的搜索。


逻辑式语言 VS SQL关系语言

由于 SQL 比起逻辑式语言有更多的限制,表达力弱很多,再加上 SQL 对于基本的数据结构进行了“索引”,逻辑式语言的性能问题在 SQL 里面得到了局部的缓解。


其实关系模型比起逻辑式语言,基本就是个衍生产物,算不上什么发明。关系代数其实对应逻辑式语言里面的一个很小的部分——它的数据结构及其基本操作,只不过关系模型有更大的局限性而已。


关系式数据库的表达能力,绝对不会超过逻辑式语言。关系式代数里面的“=”,join 等构造都是没有方向的。然而与逻辑式语言不同,这些“可逆操作符”在关系代数里的用法受到非常大的限制。比如,这些可逆操作都不能跨过程,而且关系模型并不包含递归函数。所以你并不能真正利用这种“无方向的代码”来完成比“有方向代码”更加强大的功能,大部分时候它们本质上只是普通程序语言里面最普通的一些表达式,只不过换了一种更“炫”的写法而已。


我们再来探讨一下关系模型与数据结构的关系。

其实,关系模型的每一个“关系”或者“行”(row),表示的不过是一个普通语言里的“结构”(就像 C 的 struct)。一个表(table),其实不过是一个装着结构的数组。举个例子,以下 SQL 语句构造的数据库表:

CREATE TABLE Students ( sid CHAR(20),
                        name CHAR(20),
                        login CHAR(20),
                        age INTEGER,
                        gpa REAL )

其实相当于以下 C 代码构造的结构的数组:

struct student {
  char* sid;
  char* name;
  char* login;
  int age;
  double gpa;
}

每一个 join,本质上就是沿着行里的“指针”(foreign key)进行“寻址”,找到它所指向的东西。在实现上,join 跟指针引用有一定区别,因为 join 需要查软件哈希表,所以比指针引用要慢。指针引用本质上是在查硬件哈希表,所以快很多。当然,这些操作都是基于“集合”的,但其实普通语言也可以表示集合操作。

所谓的查询(query),其实就是普通的函数式语言里面的 filter, map 等抽象操作,只不过具体的数据结构有所不同。关系式代数更加笨拙一些,组合能力弱一些。



阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页