依云's Blog

这是 Stackoverflow 中一篇答案的粗略翻译，原文地址 http://stackoverflow.com/a/2302230/296473^已失效。

1. 没有人听说过它。没有人会使用他们根本不知道的东西。

2. 不够流行。人们认为最流行的语言就是最好的语言，因为如果它不好的话，它就不会流行。实际上这根本不成立。最流行的语言最流行，仅此而已。Haskell 不流行是因为它不流行。这就是 Haskell 里经常用到的「递归」。不管来自命令式编程世界的人们怎么说，递归在现实世界中非常常见。

3. 它不一样。人们总是害怕新事物。

4. 它很难。人们认为 Haskell 难学难用。这显然和第三点有关。Haskell 里充斥着一些高深晦涩的术语，如「单子就是自函子范畴中的独异点，有什么问题吗？」（译注：这句话真难译 :-( ）。普通人可理解不了这个。

5. 有风险。大多数公司不想第一个吃螃蟹。Haskell 的用户太少了，所以很少有用户愿意尝试它。（看吧，又是递归。）

6. 招不到程序员。首先，按第二点，会 Haskell 的人很少。然后，大多数人相信第四点，所以找不到愿意学习的程序员。使用一门招不到程序员的编程语言风险太大了。（好吧，我们回到第五点了。）

7. 库。这可能是最重要的一点，所以我多说一些。

   A. 质量。有很多库，可是质量参差不齐。大多数 Haskell 库（Hackage）是个人的业余项目，文档欠缺。有些不完整，有些已经不再能用，有些在特定情况下会出错。

   B. 多个不兼容的库。你能够使用 Haskell 连接到数据库。但问题是，存在一堆这样的库，让人很难分辨出哪些是被支持的库，哪些在几年前就已经烂掉了。而且，在 Haskell 中连接数据库也不像开个 ODBC 连接那样简单。针对每种数据库，每个库都用不同的后端。在数据库支持的广泛性上 Haskell 做得不错，连新出现的 Mongo 或者 Cassandra 数据库都支持。开源可能没有给予 Haskell 以深度，但给予了其以广度。

   C. Windows。几乎所有重要的库（比如加密、二进制数据文件格式、网络协议、数据压缩、连接数据库等）是 C 语言库的包装。它们在 Windows 上编译不了。因为 Windows 是市场上最大的目标平台，这是个大问题。

8. 效率无法预测。由于对 Haskell 缺乏了解，很多人甚至都不知道这一点。很多人直接就认为「Haskell 效率低下」。这不对。事实是，很难预测一个 Haskell 程序的效率。微妙的、没有明显关联的不同有时可能导致效率的巨大差异。（译注：蝴蝶效应啊？）

9. 正确性。大多数公司对正确性并不重视。它们不在意质量。它们只要尽可能迅速地把代码扔出去赚大把大把的钞票就好了。如果代码有 bug 的话，它们就向客户卖补丁。把代码写对没用；重要的是快速把代码写出来。Haskell 会用优美的解来回馈那些坐下来深入分析问题的人。大多数公司不喜欢这样；他们只要尽可能快地把产品搞出来，以后再修正它，如果还有以后的话。

的确有少数地方正确性很重要。这些地方基本上要么是级别甚高的安全系统，要么是金融系统。（译注：交集不为空？）就我所知，Haskell 在这些领域还是比较流行的。

最后说两点：

• 我还记得不是太久前人们还叫嚷着「C++ 是给菜鸟的玩具！你应该用像 C 这样真正的编程语言。」现在再看看有多少大型 C++ 程序？

• 人们总是在说 Lisp 是「下一个里程碑性语言」。他们说了多久？已经 40 年了？Lisp 比几乎所有主流编程语言都要老。现在看看有多少大型 Lisp 程序？

我不知道 Haskell 的命运终将如何。我觉得，Haskell 好的思想会被像 C# 或者 F#、OCaml 这样的杂交语言偷取。人们依旧不会使用 Haskell。它太不一样了。

不管怎么说，关于为什么业界不用 Haskell，见以上观点。它太罕见、太不流行、太奇特，库也不完善。大约就是这样。

后记：

也许，照耀大地的永远是在众恒星中普普通通的太阳，人们永远不会知道在宇宙的某个角落里曾经诞生过一颗绝美无比的小星星。这个世界是不完美的，否则如果它是完善的，缺少了不完美，它还完美吗？这个世界是不公平的，流星划过苍穹，带给多少人希望，而它自己却身殒，不留下一点痕迹。

我从某处下载的QQ2010，其它都好，就是登录时焦点在密码框时，QQ就会崩溃。解决办法是使用QQ自带的软键盘输入密码。但在这个「半字母顺序」排列软键盘上找需要的需要实在费事。作为一名 Linuxer，我自然得想办法将其自动化。

很久之前就已经看到这个Xpresser软件，但可惜的是，它在Arch下跑不起来。但我从中学到了简单的图像匹配，再加上自己对 Xtest 的了解，解决方案呼之欲出。

本来是三个月前就打算写篇文章的，因各种原因迟迟未写。现在因为各种原因再次折腾这家伙，还是写出来分享一下吧。使用OpenCV做图像匹配部分我就不写了，有兴趣的自己去看 Xpresser 或者 winterpy 中的代码。

首先，介绍一下依赖。本脚本依赖众多的东西，其中我自己写的部分在 winterpy 里有，主要是 OpenCV 图像匹配，以及之前写过的 Xtest 调用、使用 GDK 截图。最终，我利用它们写成了 xauto.py 库，功能还十分欠缺，但自动登录Wine QQ足够了，因为我做这些的主要目的就是这可恶的QQ。

几点说明：

1. 执行以下命令禁止QQ记住用户信息，这样再次启动时焦点会在输入QQ号的地方而不是会导致崩溃的密码框。如果你使用我给的压缩包的话应该可以跳过。
   ?

   1 2 3

   rm -rf Users/All\ Users mkdir Users/All\ Users chmod -w Users/All\ Users

2. 需要 wine 1.3.32 或更低，以及 wine_gecko 1.3 或更低。新版本在调用 IE 的组件进行显示时会崩溃，这包括「消息管理器」、「查看聊天历史」、「聊天窗口」的侧栏等。
3. 我执行的是自己包装过的具有隐私保护功能的「rwine」程序。不过也不是特别安全，QQ仍能够访问剪贴板、截图等。
4. 密码当然是明文保存。你觉得有必要折腾的话可以自己修改。
5. 程序中需要的图片自己截。应该很容易知道应该截哪里。这样也避免了字体不同导致图像匹配失败。
6. 此版本的 QQ 可以在这里下载：115 网盘。

另注：更简洁好用的 TM2009 没有 wine 成功，登录时弹出错误。

2014年3月25日更新：TM2009 以及 TM2013 后来均 Wine 成功了，并且在输入密码时不会崩溃。详情见此文。

在编辑 Word 文档时，记住 Microsoft Word 是危险的会很有用。

因为毕业设计的关系，需要使用 Word 文档。我用的是 Microsoft Word 2007，因为没有理由让我使用更旧的版本，而我也没有更新的版本。这才使用几天，我已经忍不住要来吐槽了。

几天前，寝室断电。于是乎，几百字不翼而飞。Word 有自动保存文档以供恢复，但默认是每十分钟才保存一次。这比我手动保存的频率还低。那次断电，Word 是唯一给我造成损失的软件。是的，我的火狐打开了若干标签页。但是没关系，除了最后几秒打开的标签页，其它时候火狐异常退出再打开时，所有的标签页都还在，只要重新载入就可以了。如果已经在某网页里输入了较多文字的话也没关系，Textarea Cache 会帮我保存它们的。至于自己最常用的 Vim，更是无需担心。Vim 默认每输入 200 个字符，或者停止操作 4 秒就会将修改写入交换文件。所以，我从来没有在 Vim 里在没有误操作的情况下丢失大量文字。

好吧，既然 Word 默认的 10 分钟太久了，那我改短点总行了吧？于是我把它改成了 1 分钟。结果，在我尝试在页脚插入页码的时候，我发现突然卡了一下，右下方出现了绿色的进度条。不过在我注意到它时它已经完成了。因为生疏，所以我又继续弄好了一会儿，然后，绿色的进度条又出现了。我看清楚了，它在保存文档。很慢，看样子是完整地保存了一份。Word 这次不仅仅是卡住了，而且——它崩溃了！哦不，在微软的字典中没有「崩溃」这个词。最多只能说是「异常退出」。当然这个词也不常用。微软最常用的是「程序遇到问题需要关闭」。就是这么一个框跳了出来，问我要不要发送报告。好吧，你发吧。点击「发送错误报告」，Word 继续卡在那里……等了会儿，我不耐烦地点了取消，它还没反应。最后终于反应过来，Word 告诉我有一大堆文档「已经修复」。这个我已经见怪不怪了，打开阅读的文档，我不记得做了任何修改，但 Word 总是喜欢问要不要保存。再看看那篇在自动保存中崩溃的文档，「已经修复」的版本格式已经乱掉了。我还是从自己手动保存的版本继续吧。

用 Vim 久了，以前在 Windows 下养成的随时保存文件的习惯渐渐地消失了。现在，重返 Windows，重返 Word，我得在使用过程中时刻提醒自己，要随时手动保存。自动保存并不可靠，甚至还可能是崩溃发生的根源。撒销什么的也不再可靠，要记得编辑一段时间去资源管理器里选中文档，Ctrl-CCtrl-V下，不然，当自己不小心把排版弄乱而 Word 又撒消不回来时就郁闷了。

2011年12月25日更新：Windows 也一样不可靠，竟然应用更新后置我打开的众多文档和程序于不顾，自动重启，完成后还不恢复打开的应用程序——

Rcode, 即「Run Code」的缩写。Vim 拥有多种脚本语言的接口。有时候需要对文本进行较复杂的处理，但是在单行的命令行里能写的代码功能有限。你可能会立即想到，先把代码写到一个文件里再加载。没错，这就是 Rcode.vim 为你做的。2.0 版本在原来简单的「编写」->「执行」基础上添加了代码保存功能，可供重新载入（并加以修改）。此特性是由易名建议的。

命令和键映射：
:Rcode		启动 Rcode，需要一个参数指明语言，如 vim、
		awk 等。使用 <C-D> 可以查看所有当前被
		支持的语言。会开启一个新的缓冲区，请把你的代
		码写在里边。此命令可以接受一个范围。

:RcLoad {name}	加载之前保存的代码。
		「name」是「{lang}/{filename}」的形式，这和
		保存的参数有些不同，因为脚本需要知道代码的语种。
		此命令可以接受一个范围。

:RcSelect	列出所有已保存的代码，使用数字来选择。

在 Rcode 的缓冲区里：

<C-CR>
:Run		在你启动 Rcode 时的缓冲区上执行代码。
:Save {name}	保存代码以在日后可使用「:RcLoad」命令载入。

别名：
在 Python 中，「v」为「vim」模块，「b」为当前的缓冲区对象。
在 Lua 中，「b」为当前的缓冲区对象。 

设置：
g:Rcode_after	执行代码后的行为。
		0 什么也不做，1 关闭该窗口，2 关闭的同时也不
		要记住代码，不然下次使用「:Rcode」命令时会显
		示此代码。默认值为 1。

g:Rcode_snippet_path	代码保存的路径。
			默认值是 "$HOME/.vim/rcode"。

下载地址。

一直不怎么懂关于音频的配置，所以一直没管这方面，直到遇到小麻烦。我把gnome-volumn-control干掉之后，发现音量无法调到 100% 以上了，某些视频音量太小听不清。这才第一次正视音频配置。

其实也说不上有多么「正视」，因为我只是在 ArchWiki 上找了几条命令执行了下而已。

安装了以下软件包：

• pulseaudio-alsa, 就一个配置文件，用处不明
• pamixer-git. 命令行调节音量用的，Awesome 音量 widget 改用这个了
• pavucontrol, 图形界面的音量调节工具。更新后的 Awesome 音量 widget 上点右键运行它，可以针对不同的程序进行调节

另外，在 mplayer 的配置文件中加了ao=pulse这行。

就这些了。

之前一直在用 gnome-sound-applet 来调节音量。今天终于脱离了它。

GNOME 越来越臃肿了。今天系统出了点小问题，查看日志时再次看到 dbus 报怨 NetworkManager 没有运行的错误。我是直接用的 ArchLinux 的network服务连网的，根本不需要 NetworkManager 掺和，可是自己要用 Empathy，而它奇迹般地依赖 NetworkManager。。。虽然试了下强制卸载，最后只成功pacman -Rdd几个其它的包，没能在保证 Empathy 能用的前提下干掉 NetworkManager，心中多有不甘。于是开始打 gnome-sound-applet 的主意。

gnome-sound-applet 这东西是 gnome-control-center 的一部分，其依赖了 15M 左右的奇怪 GNOME 组件。这个 applet 也很鸡肋，本来是显示和调节音量用的，结果黑黑的图标在我的灰色 Awesome 面板上并不容易找到，花了良久才习惯。另外就是，该图标本身不提供任何信息，查看音量时需要把鼠标悬停过去，心中多有不爽。好在今天这些问题一并解决了。

参考来源是 Awesome Wiki 的这个页面，不过这里的代码太老了，不能用，自己参照rc.lua的其它部分以及 wiki 和 reference 修改之后才能用。最终的效果是这样子的：

你应该很容易能猜到最右边的就是音量控制了，因为它前边有个八分音符符号“𝅘𝅥𝅮”。鼠标操作很简单：单击切换静音，上下滚动调节音量。静音时百分号会被红色的“M”取代。

贴代码：

记得把 tb_volume 加到 wibox 里去。

这里是我的整个 Awesome 配置。

2013年3月11日更新：Awesome 3.5 版本语法变化较大，请到我的 github 上查看相关代码。

不知道怎么搞的，新版 MongoDB 自带的 mongo shell 现在不支持 readline，而且使用一个极简到工作不正常的 linenoise。编译时加上 readline 也没用。虽然内建了简单的历史记录和补全，可是历史记录不能搜索，补全只能像 Vim 命令行默认的那样一个一个切换不能像 bash/zsh 那样全部列出来。这些还不是最令人郁闷的。最让我受不了的问题和十年前的 DOS 版 WPS 里遇到的差不多——当年的 WPS 里删汉字一次只删一半，现在的 mongo shell 里删汉字一次只删三分之一！而且光标定位是错的，按字节算的！

于是乎拿 Python 写了一个 shell。不愧是 Python，内置的东西真不错，不到100行就写好了。不过用到了自己另外的库函数，另外用到了自己的 colorless 程序来高亮显示查询结果。如果不想要 pygments 这个依赖的话，可以用 less 程序代替。以下贴个无高亮版的，高亮版的见 github。

本来我是懒得去做这种东西的，可鉴于以下几个原因，还是弄了一个。

• Mike 也 +1 了
• 代码很简单
• 方便分享到 Google Plus
• 反正从国内访问本博客也不容易，就不在乎这个 +1 按钮很可能出不来了

代码如下，真的很简单：

我把它加到了每篇文章的末尾，因为我不认为没看完文章的读者会需要用到它。看不到按钮的读者请自行解决对 Google HTTPS 的访问问题。

一日即将按算好的时间外出。将系统挂起，出门时检查下手机，却郁闷地发现电脑时间又慢了！十几分钟啊。。。。

我的手机是和移动运营商的网络时间同步的，因此不出事故它是可靠的。看来电脑的时钟也应该同步下了，不然过段时间要手动调下。

毫不犹豫地在ArchWiki里搜索NTP，按wiki进行操作。这wiki写了那么长，其实只要对时的话操作很简单。

1. sudo pacman -S ntp安装
2. sudo rc.d start ntpd启动 daemon
3. vim一下/etc/rc.conf，加入开机启动项中，同时把hwclock干掉

就这么三步。至于同步的时间服务器，默认的pool.ntp.org就挺好的。ntpd 启动后系统时间并没有马上改变，而是过了几分钟才在我不注意的时候悄悄同步准确了。

今天再一次在 yaourt 的输出中瞥见 mingw 这几个字符，好奇地看了下说明：A C and C++ cross-compilers for building Windows executables on Linux。这个不就是传说中的交叉编译器么？

试试看。以前自己在虚拟机里为 Windows 编译过很多次的 vim，要是能弄到真机下来编译效率应该会高很多。（不，我不是说虚拟机的性能差，而是 Windows 下跑 mingw 这种一堆进程的东西效率差。）

说干就干，几十 M 的 mingw-gcc 及其依赖下好，git archive all|tar x -C ~tmp/vim弄份崭新的 vim 源码，把以前在 win 下用的Make_ming.mak拷过来改改，设置CROSS=yes什么的，然后开始编译！然后很快就出错了，找不到编译器i586-pc-mingw32msvc-gcc。唔，我确实没有那个东东，只有i486-mingw-gcc，去把CROSS_COMPILE这个变量改了就好。然后再 make。这一次的结局是——找不到 Python/Ruby/Lua 的头文件、找不到它们中的符号……好吧，你这交叉编译器当然找不到它们，先注释掉好了。然后重新编译，很顺利地出来个 gvim.exe 了～拿到 Windows 虚拟机里跑一下，一切正常～

好开心，第一次玩交叉编译就成功了。不过还有些小遗憾：没有那些外部脚本语言的支持。这可怎么办呢？我上哪儿找用于交叉编译的库呢？光想是没有用的，还是得尝试。用 Linux 版的库肯定不行，那就试试 Windows 版的。先拿 Python 3 支持测试。把 Windows 下安装的 Python 3 文件夹复制过来，修改下路径，再 make。很正常地，我的第一次尝试总是不成功，好在也不是大问题：Make_ming.mak里写的 include 目录不对：

看看自己的 Python 3 目录，这里的win32inc应该是include。改改就好了 ;-)

嗯，顺利成功了！接下来，把 Windows 版的 Ruby 和 Lua 也弄过来就不用再跑到虚拟机里去编译 Windows 版的 Vim 了！嗯，NSIS 也有 Linux 版，虽然是在 AUR 里。

最后，编译好的 gvim 还是在这里。