代码的未来读后感10篇
《代码的未来》是一本由[日] 松本行弘著作，人民邮电出版社出版的平装图书，本书定价：79.00元，页数：356，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《代码的未来》读后感(一)：攻城狮的未来
之后介绍了各式各样的语言的特点（注意，不是教你怎么用，而是为什么会诞生这样的语言）
此书提到的未来的方向是 多核，并行
不得不说激动不已，thread thread try catch的烦都烦死了
但如果说 线程、分布式计算 都可以像openfile一样操作的话，未来的射击狮就可吞掉不少攻城狮而升级为射击攻城狮，而反向兼并就比较困难
这篇博客可以很好的说明这个问题：[右脑革命：别学编程了，学艺术吧](http://www.36kr.com/p/201646.html)
gt;在未来 50 年内，擅长创意的人群，如宏观思想家、艺术家、发明家、设计师等将会崛起。实际上，劳动力市场变迁的历史也证明了这种典范转移：工具的出现让体力无足轻重，装配线的出现替代了家庭手工作坊。而在未来变得无足轻重的，不是那些不懂读写代码的人，而是那些无法将一个个点与对星座的想象联系在一起的人。
鉴于那个不确定何时爆发的**奇点**（PS：何为奇点，参照《时间简史》，乃是宇宙和时空的开端），对之前的预测是毫无疑义的！以至于都无法用概率来站队
if 奇点 爆发了:
学艺术了 ？ 射击狮 : 失业
else :
学艺术了 ？ 射击狮 : 攻城狮
这样来看，学艺术是有赚无赔的。
此书也提到了类似观点：编程可能会消失，属于一种对于程序员来说比较悲观的未来
《数学之美》中提到自然语言相互之间的翻译都可能会引起信息的丢失，何况自然语言翻译成机器语言
此书还有一点受启发是，之前看python/ruby的代码，只是感觉简洁了许多，具体为什么说不清楚
仔细想想确实如此
比如描述一个二分，C 的话要 int 还要 main，编译时这少个标点，那少个括号，光改这些边边角角的东西去了；java就更恐怖了，eclipse打开半天，还得先弄个包名，定义个类，写核心代码的时候咖啡都变冰了
《代码的未来》读后感(二)：ruby之父的技术剖析（科普）
这本书其实是ruby之父Matz的一些期刊文章的集合，可能是发表在比较大众化的杂志《日经linux》上的科普文章，居然意外地浅显易懂我，只花了三天就读完了。 因为作者是日本人，其思维方式和国人较为相似，读起来十分流畅，另外书中的卖萌之处也不少。书中关于Ruby的东西非常多，基本上每章都有，以下是一些笔记和总结：
#1 关于编程
* 编程不是和计算机打交道，而是和人打交道，编程应该人性化（有人味），其乐趣在于创造
* 算法是基本保持不变的，大部分算法都是在20世纪60年代提出，有些甚至源于2000多年前的古希腊
#2 关于摩尔定律
* 集成电路中的晶体管数量大概每18个月翻一倍，制程减半意味着成本降低，且速度提升2倍，耗电量降低到1/4
* 20年后的PC也许相当于现在的超级计算机
#3 编程语言
* 编程语言进化的方向是更高的抽象化、并行和多核
* 设计API相当于设计DSL
* 库设计就是语言设计（源于AT&T贝尔实验室）
* OOP语言如Java、C++其实或多或少都具备一些元编程能力
* 根本没有什么元编程，只有编程而已 --《Ruby 元编程》
* C语言中，错误处理主要是通过返回特殊值（如：fopen失败返回Null）
* 闭包，即在函数对象中，将局部变量这一环境封闭起来的结构（与封闭它的函数对象的生命周期相等）
* 静态语言的优点是，易查错（类型确定容易发现bug），高性能（编译时可以更好的优化）
#4 Go语言
* Go语言的目的是取代C/C++，是一种编译型的，并发性的，带GC（垃圾回收）的系统语言（所谓系统语言，大概是指能编写操作系统）
* Go是静态类型，但类型声明有时候可以省略
* Go通过goroutine源生支持并发编程
* Go是下一代语言中，作者最看好的一个
* 无继承式面向对象、多重赋值、可以返回多个值
#5 Dart和Coffeeｓｃｒｉｐｔ
* 目的是取代Javaｓｃｒｉｐｔ
* Dart是静态类型，很像Java和Groovy
* Dart提供基于类的对象系统（javaｓｃｒｉｐｔ是基于函数和prototype的）
* Coffeeｓｃｒｉｐｔ很像Python/Ruby，语法优美，采用强制缩进
#6 Lua
* 是唯一一个来自南美洲的编程语言（Ruby则是唯一一个来自亚洲的编程语言）
* Lua的优势在于其高速虚拟机（LLVM），有时甚至比宿主语言还快
* 核心数据结构是列表（table），数组和列表合为一体（与PHP一样）
* 与Javaｓｃｒｉｐｔ十分相似，函数是first-class Object 面向对象是通过函数来实现的
* 因为轻量、简洁、快速，被嵌入到各种应用程序中，如魔兽世界、仙境传说、Adobe Photoshop LightRoom等
#7 云计算
* 大数据处理中，要用哈希表、布隆过滤器等技术减小计算量
* google采用分布式文件系统GFS，并用MapReduce实现分布式任务处理，其中，Map负责数据映射，Reduce负责数据化简
* GFS和MapReduce都是不开源的，但其原理已通过论文公开，Hadoop和HFS是其开源实现（google在对外的分布式环境讲座中也用Hadoop）
#8 Unix
* Unix进程ID是16位的，也就是说无法超过32767个，Linux则被限制为48353个
* select系统调用能监视的文件描述符（fd）是有上限的（一般为1024），为了解决这个问题，可以使用epoll、kqueue、libev、Ruby的EventMachine框架等
* Unix管道对于多核的运用是非常有效的，类似CPU的流水线优化，多个管道串联的情况也可以进行叠加
* 多核编译和distcc可以通过分布式提升编译速度
#9 Ruby和Rails
* rack是http服务器（如nginx、apache）和Web应用框架(如rails、sinatra)的中间层(类似Python的wsgi)
* rack的工作原理是将请求环境(env)作为参数来调用call方法，和wsgi类似
* 由于GIL锁的限制，Ruby线程无法利用多核
#10 进程间通信
* 管道（pipe），仅本地
* 消息（message），仅本地
* 共享内存，仅本地
* TCP套接字，可用于不同主机通信，可靠，需建立连接（开销大）
* UDP套接字，可用于不同主机通信，无连接，不可靠，实时性好
* Unix套接字，通过本地文件实现，仅本地，可靠
* ZeroMQ可以统一管理各种底层通信（TCP、进程间、进程内线程、UDP多播等）
#11 存储技术
* NoSQL 并不是不再需要SQL，而是 "Not Only SQL"
* 关系型数据库由于要保持ACID，在分布式中，并发访问存在很多问题
* 将关系型数据库分割到多台服务器上，可以采用水平分割（分割行）和垂直分割（分割列）
* NoSQL数据库包括键-值型、文档型和对象型，键-值型有memcached、redis等，文档型有MongoDB
* MongoDB的数据格式是Json，没有表结构定义（schema），并使用javaｓｃｒｉｐｔ作为命令行语言
* 关系型数据库不会消亡，VoltDB是一个高性能关系型数据库（据说比传统RDBMS高出数十倍）；VoltDB只能用存储过程，无法直接使用SQL，它的数据存在内存中，并支持分布式
* memcached可用作高速缓存数据库，但由于限制较多，逐渐被redis取代
* SSD、MRAM、FERAM等存储技术的革新，可能会颠覆数据库技术，下一代内存技术成熟后，像Smalltalk、Lisp这样将内存空间直接保存下来的模型也许会东山再起
#12 Node.js
* Javaｓｃｒｉｐｔ是目前动态语言中，性能最高的一种
* 单线程和事件循环方式内存占用小，性能高，但是无法利用多核，而且如果回调函数产生了阻塞，事件循环就整体停滞了
* Node.js的http连接采用keep-alive方式，并且通过实践驱动模型，减少了每个连接消耗的资源，非常适用于同一客户端对同一服务器进行频繁连接，且连接数非常大的场景（比如，聊天服务器）
《代码的未来》读后感(三)：读书体验
对Matz大神的这本书还是蛮期待的 现在书以到手 刚读完前3章 书和我预想的也差不多 比起前一本程序世界来说好很多 程序世界里口水太多还重复
关于DSL那部分觉得很好 把外部DSL 和 内部DSL 还有DSL的优势定义都介绍了一下 简短明晰 再之又有结合一些语言来谈DSL 确实总的来说还是内部DSL的设计更优 当初学jee的SSH的时候 就被一堆XML恶心够了
Matz对未来预测这部分给出的是一些主管预测 这部分其实不大明晰 有些散乱 毕竟是从杂志文章中整理得
对于新潮语言这部分 不是太感兴趣 介绍也相对简略 一门语言能发展起来确实需要很长时间检验 Go倒是值得关注
再来说下书的质量吧 纸张什么的都是无话可说 但是代码的排版或者说印刷有点小问题 在试读的pdf里 代码块是有颜色的 但是书里的代码块颜色浅的几乎没有 去看了一下 不是我一个人的问题 是印刷的问题、、、
有几个无伤大雅的错误：
88倒数第3行 ：
悔==>会
123图15代码最后一行：
应该是 v := <- c (c后面的h多余)
《代码的未来》读后感(四)：不是神作也不是臭作
这本书本来就是将杂志上的连载收集起来出的一个合集。因为是杂志文章，普及性比较多，文章写得很松散很随意，浅出但不深入。 而且54万字超过一半是无意义的杂谈或卖萌式的评论。我不知道是因为日本人本来就习惯了这样卖萌的语气， 还是翻译故意要加入些有趣的元素， 但是作为一个一丝不苟的程序员对这样的卖萌非常不喜欢。
除了没用的东西， 剩下的东西都却都非常有用。作者提供了很多关于程序运行效率和开发效率方面的观点， 以及很多课本以外的，可以贯通计算机科学里各种领域的一些知识。程序语言方面介绍了一些每个人都需要知道的历史，垃圾回收和异常处理等编程必备知识的一些常见设计。性能方面介绍了超大规模（高性能）程序的设计要素，包括大规模储存（从hash 到 Distributed Hash Ring 到 NoSQL 数据库），大规模计算 （Multi-threading 到 Multi-processing 到 IPC/RPC， Async I/O， Event Driven 等）。 围绕分布式（云）技术还讨论了周边的诸如 CAP Theorem，SQL vs NoSQL 等理解云技术必知的花絮和背景。
读完的感觉是学习了编程 2， 3年的学生非常适合看这本书，世界观会一下子完整很多， 特别是对云技术感兴趣的同学。对于基础的要点（上一段提到的）书里都涵盖得差不多， 以每一个主题出发结合 Wikipedia 再用 Google 深入一下差不多就算是被普及了。可惜书里选用来介绍的一些技术框架我都没有听过，感觉赞誉并不是很高（也可能因为我是用 Python 的关系），而且还花了不少篇幅教你安装那些框架和调用她们的API， 在互联网时代书真的不用这么写的。
《代码的未来》读后感(五)：编程的未来是什么
代码的未来是 Ruby 之父松本行弘三年（2009-2012）专栏《技术的剖析》内容的集合。
书中有两点很有启发性：
1. 如何预测未来？极限思考法
2. 从软件开发中学习如何提高效率？减负，拖延，委托
IT 技术人的真正价值应该并非只有“最早和未来相遇”，还应该要拥有自己创造未来的力量——创造出比这本书所预见的未来的还要更加美好的未来。
第1章 编程的时间和空间
编程的本质在于思考，思考：
- 人们到底想要什么
- 想要的这些东西的本质又是什么
- 要实现这个目的严格来说需要怎样的操作步骤
计算机在不断变化，而算法则保持不变
使用极限思考法预测未来：
- 如果计算机便宜到极致会怎么样
- 如果我们大多数人都能买到超高性能的计算会怎么样
- 如果计算机的存储容量大到超乎想象会怎样
- 如果网络带宽变得非常大会怎么样
作者预测：
- 嵌入式系统软件开发会越来越多
- 充分利用CPU 资源：并行处理
- 高速 SSD为基础的数据库系统，面向个人的数据仓库之类的数据分析工具会流行
- 性能与带宽寻求平衡过程中，网络两端系统构成也会像钟摆一样摇个不停
第2章 编程语言的过去现在和未来
古代编程语言三巨头：Fortran，Cobol，Lisp
编程语言进化的方向：抽象化，也被称为黑箱化
未来编程语言进化动机，不是工具和语言的简化，而是将这些工具和语言的结果更简洁的表现出来
作者预测20年后编程语言要更关注分布处理和并行处理，关注 Haskell 和 Erlang
常用 DSL 语言：awk，sql，正则表达式，sed，xml ，json...
内存空间释放自动化——GC
- GC 的三种基本方式：标记清除，复制收集，引用计数
- 基于上述三种基本方式衍生融合的方式：分代回收，增量回收，并行回收
- 垃圾回收的统一理论：任何一种 GC 算法，都是跟踪回收和引用计数两种思路的组合
异常处理是为了将程序员进行错误处理的负担尽量减轻而产生的一种机制
第3章 编程语言的新潮流
下一代编程语言中作者看好 go 、Coffeeｓｃｒｉｐｔ 和 Lua ，不大看好 dart
Google 内部5大编程语言：C/C++，Java，Python，Javaｓｃｒｉｐｔ，Go
限制开发语言的种类，主要从降低管理成本上来考虑的
第4章 云计算时代的编程
布隆过滤器，判断某个数据是否存在的数据结构，是概率算法（偶尔会出错）
UNIX系操作系统中，同一台计算机进程间通信有：管道，消息，信号量，共享内存，TCP 套接字，UDP 套接字，UNIX域套接字
第5章 支撑大数据的数据存储技术
随着计算环境中的计算机数量达到几百台甚至更多，机器发生故障概率增加，在实际运营中就会发生延迟等问题，RDBMS 的特性 ACID 就很难满足，催生了 KV 存储模型
在大规模环境中，只能同时满足其中的两个：
- Consistency 一致性
- Availability 可用性
- Partition Tolerance 分裂容忍性
CAP 的解决方案 BASE
oSQL = Not Only SQL
云，大规模分布式环境
VoltDB，内存型数据库，值得关注
第6章 多核时代的编程
提高 CPU 效率：
- 流水线
- 超线程
- 多核：同构多核，异构多核
CPU 越来越快的时代要结束了，软件开发者必须要付出更多努力，了解多核计算模型
改善软件运行速度：
- 采用更好的算法
- 减少无谓的开销
- 用空间来换时间
多核的困难：任务分割，通信开销，可靠性
无论是从事什么工作，最重要的是提高效率
从软件开发中学会如何提高效率：
- 减负 减少不必要不紧急的工作
- 拖延 按紧急程度从高到低完成任务，碎片时间处理杂事
- 委托 团队合作，从单核到多核，考虑将工作分割成异步任务、减少沟通开销和提升任务可靠性
更多读书笔记参见何一涛博客
《代码的未来》读后感(六)：过去，现在与未来
本书是Matz在《日经Linux》上连载的各期内容的合集，虽然内容有些部分重复，但是内容还是很丰富的，主题也比较鲜明，与国内的某些合集甩开太远。
通书下来，个人觉得最精华的还是第2章：编程语言的过去、现在和未来。Matz通过简单回顾编程语言的过去，着重分析现在和未来的发展。主要分为以下几类：DSL，meta-programming，内存管理，异常处理，闭包。
DSL，即特定领域语言，将几乎只有程序员的编程语言进化成符合具体领域业务的特定语言，而且该语言与自然语言类似，方便非编程人员也可用其进行编程，可以解决开发人员对业务透视程度不够，业务人员无能力进行编码的矛盾。回想还在前东家码程序时，由于是游戏工作室，经常出现小工具方便策划实现自己的想法，这几乎是与DSL方向不谋而合。做为攻城师，如何把自己从代码中解放出来，如何让非编程人员方便的进行编程工作也是一种能力啊。
元编程，即可以自己写程序的程序。身为苦逼码农，还记得需求一日一变的痛若吗？还记得数据库迁移时，代码大动的尴尬吗？请用元编程利器，让你一劳永逸，面对千变万化，不动任何代码就是完善支持。善哉，这才是程序员的理想生活。当然，元编程并不是所有语言都支持，当然上古语言Lisp可以说是其始祖，但是便于理解，还是举个Ruby的例子，如下：
require 'builder'
uilder = Builder::XmlMarkup.new
xml = builder.person { |b|
.name("Jay")
.phone("123-123321")
}
#=> <person><name>Jay</name><phone>123-123321</phone></person>
代码中对person, name, phone标签是用方法调用实现的，但这些方法并不是Builder库所定义的。因为XML中的标签是任意定义的，不可能在Builder库中事先全部准备好所有方法，所以这就是元编程的力量。若要增加home标签，无须动Builder库的任何代码，只需直接调用home方法即可。完美生活啊。
内存管理。说到这个，不得不提业务说c/c++是如何难用，很大一部分是由于要开发者进行内存管理。虽然现代c++语言经过一定的封装可以做到不用自己进行内存管理，但是曾经坑害多少无知码农的阴影是不会这么轻易散去。所以，垃圾回收，将内存管理从程序员手上释放出来是巨大的福利。
异常处理。C代码中对各种异常返回值的判断，往往在程序中占有很大的比例，如下：
int main()
{
FILE* f = open("/path/to/file");
if (f == NULL) {
uts("file open failed");
} else {
uts("file open succeeded");
}
f.close();
return 0;
}
当然，这里只是举个简单的例子，现实情况比这个糟糕太多。写一个并不复杂的业务，假设只需要10行代码，但是对异常情况的判断并且处理，往往占据了大量的代码量，也许从开始的10行渐渐臃肿到了100行。这不仅对编码人员造成了大量的工作量，而且对维护人员进行代码学习也是一种负担。若采用异常机制，很容量让编码人员只关注重要的逻辑，而不用一头淹没在异常处理代码中。上文的例子，同样实现一个Ruby版本：
egin
open("path/to/file", "r") do |f|
uts"file open succeed"
end
rescue
uts"file open failed"
end
闭包，含有“包含”的意思。如其名称，闭包就是将数据包含在函数内，与面向对象正好相反，面向对象是将数据的行为包含在数据内。对于闭包，我目前还没有体会到其带来的好处，当然是巨大的好处，值得做为编程语言未来发展的方法的好处，所以就先搁着，等到感受到其巨大力量再来补上。
注：文件代码格式较撮，影响您的阅读，请见谅。
《代码的未来》读后感(七)：听语言大师谈编程语言
这本书其实是连载《松本行弘：技术的剖析》的合集，与其《代码的未来》，我觉得原名更符合这本书的内容。
刚开始看到书，翻开目录，发现这是什么啊，整个一个流行技术的合集，从摩尔定律讲到DSL，从C10K讲到nosql。但是仔细看下来，收获很大，有些地方又茅塞顿开的感觉。
一般的技术类书籍或者文章，都是讲"How"，怎么使用，结构如何，少有讲的清"Why"的，而Matz这本书虽然讲了很多技术，但是大部分都能从复杂的细节中脱离出来，只讲原理，并说清了原因，难能可贵的是，大部分都有Matz自己的见解，非常有参考价值。
可能是东方人的思维比较相近吧，整本书看得也不枯燥，花了一个周末看完了。
适合人群：对各项技术都有一定了解，但是尚未形成自身的知识脉络的中级开发者，看这本书会非常有收获。
《代码的未来》读后感(八)：图灵访谈之三十八：专访松本行弘
周：松本先生今年出版了新书《代码的未来》，这本书的中文版正在由我进行翻译，预计明年会在中国出版。您的上一本书《松本行弘的程序世界》在中国受到了读者的好评，这次的新书和前作相比有哪些不同，又有哪些看点呢？
Matz：《松本行弘的程序世界》一共涉及了14个话题，每个话题都是浅尝辄止，内容比较广泛但不是很深入，而这次的新书则是设定了一个大的主题——即对未来即将到来新技术的思考，因此内容比《程序世界》所涉及的范围要窄一些。此外，这本书还在时间尺度上进行了探讨，例如从计算机出现以来，到现在为止经历了怎样的变化，并由此来思考未来可能会发生的变化，也就是对过去和未来两方面都进行了思考。计算机的世界变化非常快，而这本书的目的在于探讨其未来变化的方向。
周：说起计算机的发展，您在书中还提到了关于摩尔定律的一些话题呢。
Matz：摩尔定律是描述计算机将如何发生变化的一个定律，书中所探讨的不仅包括计算机本身的变化，还包括计算机为周围的环境所带来的变化。
周：关于编程语言进化的方向，保罗·格雷厄姆在一篇名叫“一百年后的编程语言”的文章（参见图灵图书《黑客与画家》P156）中，主张“拥有最简洁最小核心的编程语言”将是未来发展的趋势。对于这一观点，您在书中表示“不同意”，这是为什么呢？您对编程语言发展方向的看法又是怎样的呢？
Matz：保罗是一个很喜欢Lisp的人，而Lisp所具备的特性正好符合他所说的“一百年后的编程语言”的样子，因此保罗认为一百年后的编程语言就应该变成Lisp这个样子。但实际上，Lisp这个语言的历史已经有50多年了，说实话，Lisp现在并没有成为一种有很多人在用的主流语言。我觉得这也许是因为Lisp对于大多数程序员来说不具备那么大的魅力，也就是说，作为一种“拥有最小核心”的语言，或者从某种意义上说是一种很“美丽”的语言，和程序员们所期望的语言之间，存在着一定的差距。如果一两年的时间里，Lisp的魅力没有被大家所接受，那还可以理解，但已经过了50年还没有被广泛接受的话，是不是它在本质上就不太符合大家的期望呢？“对人类来说好用的语言”和“拥有最小核心的语言”之间的这个差距可能是很大的，我觉得可能将来100年也没办法消除。至于未来的编程语言应该是怎样的，我觉得应该是兼具接近Lisp的运行模型，以及人类容易理解的语法这两方面特征，这么一看Ruby是不是更接近这样一种语言呢？
周：松本先生被称为Ruby之父，我们知道在编程语言的设计过程中，可能要做出很多选择，例如动态还是静态、基于原型还是基于类等等。在Ruby的特性中，您认为当初最难做的选择是什么？
Matz：在设计Ruby之前，我在上大学的时候还设计过另外一种语言，而那种语言是完全静态的，和Eiffel语言非常相似。而我原本也是特别喜欢静态语言的，不过上大学时设计的那种语言是以学术研究为目的的，多年之后，当我想设计一种编程语言作为自己的工具来用的时候，我就觉得还是动态语言实际用起来比较好用。抱着这样的想法，我设计了Ruby，现在看来这个设计还是正确的。那么当初对于Ruby应该是静态还是动态这个问题，也许算不上是最难的吧，但至少是我在设计中做出的“最大”的一个判断。而在此之后，因为是动态语言，那就借鉴一下Smalltalk和Lisp吧，Perl有一些功能也不错，于是如此这般吸收了这样一些语言的特性，也就显得比较自然而然了。Ruby的特点在于Mixin模块，而这个特点在Ruby诞生当时还算是非常罕见的，因为我不喜欢多继承，总觉得应该有一个更简单的方式，所以就设计了Mixin模块。
周：那么现在回过头来看，Ruby当中有哪些地方会让您觉得“如果当初设计成这样就好了”呢？
Matz：最开始的时候我的目标只是想实现Perl所具备的功能，因此从Perl借鉴了很多，比如说用美元符号（$）来修饰变量名之类的，现在看来觉得学得有点过了，搞得和Perl太像了。当然，除此之外还有其他一些小地方，但最主要的我觉得就是这个了，也就是跟Perl太像了这一点。刚开始的时候，还没有形成Ruby的语法习惯和文化，因此很多东西都是从Perl“抄”过来的，现在看来好像一股脑拿过来的东西太多了，里面其实有一些是不需要的。而经过一段时间之后，Ruby自己的文化已经形成，Rails出现之后又形成了Rails的文化，而到了这个时候再看的话，可能就会觉得这些Perl的部分好像没啥必要呢。
周：大家都认为“Ruby有现在的人气基本上都是由于Ruby on Rails的贡献”，您在书中也认同这个观点，那么您认为Ruby on Rails获得巨大成功的原因是什么呢？
Matz：首先是得益于Web的快速发展，几乎所有的软件开发平台都在瞄准Web这个领域。以往在用CS（客户端-服务器）架构来开发的系统，现在都可以在Web上实现了。在Web上能够开发的应用变多了，这是一个主要的背景。另外，Ruby的优势在于进行软件开发非常容易，也就是开发效率比较高。这两点结合起来，我认为就是Ruby on Rails成功的主要原因。
此外，Ruby还有一些比其他语言强大的特性，例如元编程（Metaprogramming）、通过猴子补丁（Monkey patch）所带来的可扩展性等等，通过这些特性，甚至可以对基础的类进行增强。DHH正是运用了Ruby的这些强大之处，开发出了Rails。而对于没有接触过Ruby的人，比如只用过Java这种比较“死板”的语言的人来说，会觉得“唉？居然还可以做到这样吗？”，我觉得这也是Rails成功的原因之一。
周：据说DHH曾经是准备用PHP来开发这样一个框架的，但后来却转向了Ruby？
Matz：对，因为PHP在元编程方面有很多限制吧。Rails推出之后，又出现了很多（在PHP上实现的）模仿Rails的开发框架，比如Symfony、CakePHP等等，但是Ruby所拥有的强大特性PHP却并非完全具备，即便不考虑它们各自的背景，只是单纯去对比这些开发框架的话，我还是觉得Rails更强大一些，我觉得DHH选择Ruby也正是看重了这一点。顺便，我其实是见过DHH的，在丹麦，那时候他还没开始学习Ruby，说不定那次见面也是对他产生影响的一个原因吧。
周：中国读者很关心的一个话题是，Ruby目前最广泛应用的领域就是Web开发，那么在Web开发这个领域之外，Ruby的发展方向又是什么呢？
Matz：的确，Ruby在Web开发领域被用得很多，例如Rails、Sinatra等开发框架。但编程的世界并非只有Web而已，我也一直希望Ruby能够从Web中走出去。在不久的将来，我认为Ruby有望被应用的领域，主要有三个。
科学计算（Scientific computing），也就是大学科研中所要用到的计算。在这个领域，Python、R、matlab等语言用得非常多。我希望Ruby也能够进入这一领域，为此我们正在开发一个叫做SciRuby的项目，希望借此推动Ruby在大学科研计算领域的应用。
高性能计算（High performance computing）。这个和科学计算有点接近，是运用超级计算机来进行计算的领域。和C++比起来Ruby确实要慢很多，所以大家都觉得Ruby不可能被用于高性能计算领域。东京大学一个研究生做了一个研究项目，将Ruby写的代码编译成C语言代码，然后再编译成二进制程序，这个过程中需要用到类型推导等技术，最好的情况下，速度能够达到C语言（指用C语言人工编写的同等程序）的90%。这个项目目前只发表了论文，还没有公开源代码，我希望明年这个项目的成果能够全部公开。
嵌入式（Embedded）开发。所谓嵌入式就是指在微型设备，例如手机、医疗器械、机器人，在这些环境下，现在的Ruby其实并不是很适合，内存开销很大，API也不合适，因此才需要开发适合嵌入式开发的，内存开销比较小的，并且具备面向嵌入式开发API的Ruby引擎，这也就是mruby。
以这三个领域为首，我希望Ruby能够在Web开发以外的领域有更多的发展。
周：Twitter主要是用Rails开发的，最近我看了一则新闻，说美国大选的时候Twitter遇到了前所未有的大访问量，Twitter称为了应付访问量的上升，正在从Ruby转移到其他语言，您对这个问题怎么看呢？
Matz：这里面原因很多吧。首先，Twitter刚开始开发的时候，没人知道Twitter会获得今天的成功，当时很多人觉得，这种只能写140个字的博客有什么意思呢？但Twitter却出人意料地获得了巨大的成功。在这个过程中，Twitter增加了很多新功能，在它快速发展的过程中，Ruby的贡献是相当大的。因为一个新功能从构思出来到付诸实现，可以用很短的时间就能够完成。Twitter刚开始开发的时候不可能考虑到会有现在这样大的访问量，也就是遇到了设计上的瓶颈了，因为一般的网站也不可能会有每秒上万的访问量，因此可以说现在的Twitter发展到当初在设计上的极限了。
为了解决这个问题，Twitter需要开发一个全新的架构，以应付现在越来越大的访问量。不过，即便要重写架构，我觉得沿用Ruby也是可以做到的吧？（笑）话说，一个网站在遇到设计极限的时候，有很多解决方法，比如重写架构、换其他语言等等，其中重写架构我觉得是最重要的，而实际上Twitter也正是做了这方面的工作。但在这个过程中，他们的工程师想要挑战一些新的东西，那么从编程语言上来说，就提出要改用Scala，因为Scala是编译型语言，性能也不错，正好适合编写新的架构，我觉得这样也不错。
在我看来，在网站所提供的服务还没有完全成型的时候，最重要的是能够对需求的变化做出快速的反应，这个时候就需要Ruby这样灵活性比较高的语言；而在网站获得成功之后，遇到了设计瓶颈，用一种新的语言，比如Scala，来编写一个新的架构，以节约一定的资源，我认为这也是很好的一个结果。Twitter转向Scala还只是在其核心部分，而在Web前端和一些内部工具上还有很多地方在用Ruby。其实，上个月我还去拜访了一下Twitter，跟他们的工程师进行了一些交流，Ruby还是用得很多的哦（笑）。
周：近年来随着智能手机、平板电脑等移动设备的普及，移动平台开发也变得非常热门。从编程语言来看，Android上是用Java，而iOS上则是用Objective-C来进行开发的，那么作为脚本语言，不仅限于Ruby，您认为在移动开发上面会有怎样的发挥呢？
Matz：目前，提到移动开发，在Android上用Java，在iOS上用Objective-C似乎是板上钉钉的事情，不过这也产生了一定的隔阂，比如某个App是为iOS开发的，如果要移植到Android的话，就得全部用Java重写才行。现在也逐步产生了一种新的尝试，例如PhoneGap、Titanium等框架，通过用Javaｓｃｒｉｐｔ、Lua等脚本语言，编写出来的App就可以实现在iOS和Android的跨平台移植。作为Ruby来说，也有一种叫Rhodes的框架，通过它就可以用Ruby编写出在iOS、Android以及Blackberry上通用的App。
以前移动设备和PC相比性能差距太大，如果App不能全速运行的话，就根本没法用了。但现在移动设备的性能已经得到了大幅度的提升，通过在通用框架的基础上，采用脚本语言来进行开发的方式，性能也逐渐变得可以接受，我想今后通过这种方式，用Javaｓｃｒｉｐｔ、Lua、Ruby等脚本语言来提升移动开发效率的做法，应该会越来越流行吧。对了，刚才我们说到mruby，其实用mruby来编写iOS和Android应用的项目也已经开始了呢，希望不久的将来这样的App能越来越多吧。
周：刚才您提到了mruby，而明天您的演讲题目是Ruby 2.0，可以就mruby和Ruby 2.0的一些亮点，做一下简单的介绍吗？
Matz：刚才我们也提到了，mruby是为了在微型设备上运行而设计的一种Ruby，它并非拥有Ruby的所有功能，相应地，能够在微型设备上工作才是它的长处。因此，在以往无法使用Ruby的一些设备上面，例如自动售货机、控制器、机器人等等，今后也可以用Ruby来进行开发了。说不定几年之后，在电视机、汽车等地方也能够见到Ruby开发的软件。
Ruby 2.0则包含了两个信息。第一，Ruby从开始开发算起，明年将迎来20周年了。而作为对20周年的纪念，是2.0这个名字所包含的最大的一个信息。如果但从变化来看，从1.8到1.9已经是一个非常大的变化，很多人表示说很不适应，而从1.9到2.0的变化，并不像版本号的变化看起来那么大。实际上，我的目标是保证在1.9上能运行的所有程序，在2.0上面也都能运行，不会因为引擎版本升级导致原来的程序就不能用了。
Ruby 2.0确实也增加了一些新的功能。比如说，现在的Ruby中，可以通过猴子补丁，对某个类中的方法进行添加和替换，但这样一来，所有的用户都会受到影响，可能有人觉得还是原来那样的好，不想跟着改，或者说这样的改动和我现在的开发会发生矛盾、冲突等等。为了解决这个问题，Ruby 2.0中可以限定猴子补丁的作用范围，这样就可以在团队开发、库开发中，避免一些改动对开发范围之外的其他人造成不必要的麻烦。以往Ruby可能都是用在小规模的项目中，而当项目逐渐扩大，开始由多个团队合作的时候，这样的机制就显得非常重要了。除此之外，Ruby 2.0中还有一些其他的新功能，也是针对团队开发的需求来设计的。
周：目前世界范围内广泛使用的语言大部分都是来自欧美的，作为例外大概只有来自巴西的Lua和来自日本的Ruby，您在书中也说这种情况让人感觉“很寂寞”，那么造成这种情况的原因是什么呢？要改变这种局面，我们应该做出怎样的努力呢？
Matz：关于Lua呢，其实如果你要说它是欧美的也可以，巴西是属于“拉丁美洲”嘛（笑）。要说亚洲或者东亚这边的话，那就只有Ruby了，真的是蛮寂寞的一件事。从世界范围来看，（对于编程语言来说）欧洲和美国的影响力应该是最强的，而亚洲虽然有众多的人口，但却没有能够出现很多的编程语言，确实挺寂寞的。
如果说对将来的期待，别的国家我不太清楚，至少在日本，其实是有很多人在开发各种各样的编程语言，但除了Ruby以外，其他的语言在日本以外几乎就没人知道了。如果对编程语言感兴趣的人越来越多，所创造出来的编程语言也越来越多的话，这其中应该就会有那么一两个能够取得成功吧。在日本还存在一个问题就是语言障碍，日本人除了母语以外，精通外语的人不多，有趣的是，居然有用日语来编写程序的编程语言呢。（周：说到这个，其实中国也有用汉语写程序的编程语言呢。）中国也有吗？果然。不过这些语言虽然有趣，却只能给日本人用，也就无法走向世界了。
说句题外话，我曾经收到过一个美国人发给我的一封邮件，他说你是个日本人，但Ruby看上去却跟英语没什么区别，因为Ruby程序都是用英语写的嘛，难道没有用日语写程序的编程语言吗？为什么没有呢？我只好回答说：有啊，只不过你不知道而已，即便知道你也没办法用嘛。
现在在日本对编程语言感兴趣的人不断增加，大概我总是在网上还有书里说编程语言多么有趣，多少也是受了我的这些言论的影响吧，现在有不少人在挑战设计新的编程语言。在这些新的编程语言中，如果能有千分之一的语言能够最终获得成功，我认为就是很好的结果了。我不知道中国、韩国，以及其他一些亚洲国家中，有多少人想要挑战这一领域，不过如果大家以我的这本书为契机，能够改变“编程语言是别人给我们的，我们只能被动接受”这种看法，继而抱有“自己创造一种编程语言也不错嘛”这样想法的人能够越来越多的话，这其中一定会有人获得成功。
说到开源，无论是日本，还是中国、韩国，在世界范围内发表的项目还很少，这也算是一个可以去努力的切入点。这里面可能有很多原因，比如英语很难学，（周：比如GitHub也很难用？）哈哈，GitHub在中国能用吗？（周：能用能用……）唔，还好还好。不过，这个（哔——）的影响还是很大的，有很多资料不太容易获得吧。（周：是啊，比如Go语言的官网就上不去呢。）啊！Go的官网上不去吗！果然是因为它是Google的吧（笑）。总之，需要面对的难题还是很多的。另外，在日本也是如此，程序员把大多数时间都用在了工作（挣钱）上，要进行开源项目之类的活动就比较困难了。10年前，开源这个概念在日本也没人接受，而现在大家都逐渐明白了开源的主要性，开源项目也就逐渐增多了，我想未来几年中，在中国应该也会产生类似的变化吧，我很期待。
而且，在刚开始做的时候，没人知道到底做什么会成功。我在设计Ruby的时候，也不可能想着Ruby很不错以后一定会在全世界广泛使用。因此，一种编程语言生逢其时可能更重要一些，但这种事情，你不去尝试一下是不会知道结果的。在中国，也一定会有一些编程语言或者软件因为生逢其时，从而走向世界并获得成功。
周：在书里讲到Dart的时候，您说过对于编程语言来说，生态环境是很重要的。那么要建立这样的生态环境，需要一些怎样的努力呢？
Matz：从用户的角度来看，用这种编程语言，对我有什么益处，这一点很重要。在Rails出现之前，使用Ruby的人，包括我自己在内，大多数都是觉得Ruby写程序很轻松，这可能是选择Ruby的主要目的。当然，Rails出现之后，因为“我要做个网站，Rails最快”这样的理由而使用Ruby的人变多了。因此，如果你设计一种新的语言，如果能够准确地传递给用户使用这个语言所能带来的好处，我想这样的语言成功的可能性会更大一些。
周：非常感谢，在采访的最后，请您谈谈对中国程序员的寄语吧。
Matz：在《程序世界》中我也提到了，我觉得编程的未来应该会以开源的形式发展下去，未来的创新性软件或者编程语言，可能都会以开源的形式出现。作为开源软件来说，别人做出来我可以免费使用，这一点大家都很开心。在经历了这个阶段之后，如果能够更进一步，将自己做的软件开源，使其对全世界产生影响，如果能做到这一步的话，你可能就会成为一名一流的软件工程师。中国的软件工程师，就我接触的这些人来看，大家都非常认真和努力地学习技术，我希望这些人之中，能够有更多的人迈出这一步，从而成为可以影响世界的一流程序员。
《代码的未来》读后感(九)：代码的过去，代码的未来
虽然本书关于代码的未来讨论的不多，而且有点头重脚轻。但是Matz的知识面还是很广的，而且语言也比较幽默。作为一本拓展知识面和回顾已学知识的书籍还不错。
1，语言本身是一种dsl，Matz吐槽Pual关于语言应该精简化的预测。我自己觉得是随着需求越来越多越来越复杂，语言本身的抽象能力应该是越来越强。Matz提到api和库涉及也是语言设计这点是很认同的。例如Erlang的Actor模式,各个语言中内置的接口其实都是一种抽象的dsl。表达能力和抽象层次是一种折中。内部dsl(fluentinterface)及外部dsl的比较对于dsl的设计业很有参考作用。代码只是一种工具，有些可能适用于解决特定的问题，当前如果要开发一个适应面很广的语言的话，不论从语法到工具再到杀手级应用都需要考量了。
2，GC大统一理论：扫描法(多了慢)和标记法(循环引用)的结合，前者引入了分代的方式。对于实时性较高的系统如果回收时加锁导致系统停顿是不能容忍的从而引入和增量回收。
3，闭包就是在过程中包含数据而对象是在数据中包含过程。动态语言VS静态语言：前者通过jit,特殊化来提高运行效率，后者通过类型推到和反射来扩张开发效率。Lisp:list process,all is list,模式匹配
4，云计算应该是说将原来在一个机器实现的各个功能分解抽象到了可扩张的集群上面，这样在设计上面就需要为scale考虑，互联网企业为了高可用舍弃了部分一致性，而对于传统软件只能舍弃性能。传统关系数据慢的问题在于日志,事务锁,内存锁,缓存管理等方面。
5，从应用服务器到数据服务器现在都提供了越来越多的scaleout的方案，例如使用blance和fork实现应用集群，使用hash链实现数据集群。
6，所谓水平分割，就是将一张表中的各行数据直接分割到多个表中。例如，对于像mixi这样的社交化媒体（SNS）网站，如果将用户编号为奇数的用户信息和编号为偶数的用户信息分别放在两张表中，应该会比较有效。 相对地，所谓垂直分割就是将一张表中的某些字段（列）分离到其他的表中。用SNS网站举例的话，相当于按照“日记”、“社区”等功能来对数据库进行分割。
7，我从软件开发中学会了如何提高效率，作为应用，总结出了下面几个方法： 减负(算法：更高效的思考方式，开销：自动化，用空间换时间：多笔记,花钱) 拖延(分清象限) 委派
总体来说，一方面开发所需的学习材料,ide,工具包越来越强从而开发特定功能越来越容易，但是需求的复杂性导致开发所需要掌握的知识面和整合能力也需要的越来越强。就像以前是几个人盖一个平房而现在是需要现代化的工具建造一个复杂的大楼。