离职前的几周工作很清闲, 我又有机会开始做我的"听译大师系列"了, 观看和听技术访谈也成为我上班路上一个打发时间的小爱好. 我原本认为这些访谈其实不会有太多的新意, 因为你能找到很多文字资料来了解到相关信息. 但是听的次数多了, 我发现的确有不少东西从文字材料中是找不到的. 这些软件英雄们在访谈中流露出的想法能让我们更多一层地了解他为什么会做出那样的设计. 最近突然发现了另外一个好的技术视频网站, 就是 googletechtalk , 在其中发现了今年2月20 号, ruby 创始人去 google 总部做关于 ruby 1.9 的讲演录像, 大概地听了听, 觉得很有趣. 尤其是在提问环节, 有些问题很怪, 比如为什么 Matz 总是在圣诞节前发布 ruby 版本, ruby continuation 库等等. 不过 matz 的日本式英语发音实在是太糟糕了, 听起来很别扭. 整个讲演中, matz 显得有些腼腆和局促. 不过还不时显露出点幽默感, 比如他上来就一句, "欢迎来到 ruby 的世界, 尽管 google 不让使用 ruby 语言", 引得台下哄堂大笑. 其实听起来不算太累, 但是敲字把它记录下来实在有点麻烦, 我只能选取我觉得比较有意思的段落来翻译了. 我下载了这段视频, 将其中感兴趣的片段截取下来,上传到"土豆网", 大家可以对照我的翻译来看, 有不正确的地方, 欢迎指教, 我的英文也不算太好.
听译原文如下:
---------------------------------------------------------------------------------------
guido: 你好, matz, 我是 Guido van Rossum , 欢迎来 google, 很高兴你能来这儿. 我一直在考虑你所说的字符串类型, 它们是否在 ruby 1.9 中有所改变. 但我注意到了你所给出的例子中, 直接索引字符串的操作, 比如, 字符串的第三个字符是个日文字符, 你是在内部是否使用了 utf-8 作为字符编码的表示, 如果是这样的, 你如何高效的实现这种直接访问?
matz: 我们是直接使用 Raw byte 序列作为字符串的内部数据的表示. 没有单独的内部编码, 我们曾经经历过一些转码的问题, 所以不想做这种从别的编码转换到 unicode 编码的处理, 这些来回编码的问题, 如果处理 utf-8 编码, 我希望由 utf-8 自己来处理, 如果是传统的编码,比如 shift-jis 编码, 就让 shift-jis 来处理. 我们用 C 来实现内部编码结构, 就是用一系列的函数来访问, 比如获取索引字符, 取得字符串的长度等等. 我们使用一种, 该怎么说来着, "过滤器"(filter) 来给你一种错觉, 好像在访问一系列的字符, 你可能会觉得这样做效率不够高, 但就我们长期的经验来看, 这种错觉的做法一直在 ruby 中使用, 在大多数情况下, 如果你使用正则表达式处理, 这么做还不错. 很多基于字符串的处理都是基于正则表达式的, 所以,如果正则表达式的处理做了优化, 就不会有很大的问题, 很多严重性能问题就可以避免
guido: 是的, 但是听起来这样做, 通过数字索引字符串中单个字符的操作效率不会很高, 我大概能想到的是, 比如, 使用这个 api 来反转一个字符串序列, 就可能有问题. 如果你从字符串的最后开始迭代, 你想知道字符串中有多少字符, 获取最后一个字符, 打印倒数第二个字符, 等等, 这些操作的效率不会太高.
matz: 是的, 比起那些用 utf32 来作为内部表示的做法来说, 这样做效率是不会太高的. 我们在内部的 Raw byte 序列中的确没有那些 O(n) 的操作来访问某一个特定索引字符, 但是在大多数情况下, 我们会使用一些技巧(tricks)来减小复杂性.
guido: 是的, 我同意, 在大多数时候, 让正则表达式引擎来处理这些的确工作的很好.
扫一扫
2465
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
