过去几天相当激烈。在关于是否应该将 Redis 复制中使用的词汇替换为其他词汇的争论中，有这样一个论点：去做那些不会产生任何技术成果的工作，到底值不值得？

当我尽可能地修改 Redis 源代码以去掉某个特定词汇时，我开始想，不管我对正在做的这份工作本身持什么看法，我就是那种喜欢写不会带来可量化技术效果的代码的人。替换词汇这件事本身就很烦人，即便如此，其中也还是有几个值得一做的技术挑战。但还有另一种代码，我认为它具有一种叫做“hack value”的特质。它或许解决不了任何技术问题，却依然值得一写。有时是因为写代码的过程本身就很有回报；有时是因为用非常高深的技术去解决了一个毫无用处的问题；有时写代码仅仅是出于艺术原因。

在某种程度上，过去几天在 Twitter 上那场大多缺乏依据、混乱而激烈的讨论，让我觉得我们已经离 60 年代最早的那批黑客很远了。随着年纪渐长，我发现越来越难以用一种黑客视角来谈论技术——那种没有围墙、没有预设观念、以探索本身为边界的视角。如今，你说的每句话都有对应的最佳实践，每一个想法都有禁忌。对于这种新局面，我只想说 LOLWUT，因为我并不认同它，它也并不代表我所理解的黑客精神。所以，我的想法是，花一些在技术上毫无用处的时间，去探索一下 60 年代的某些东西。

我的注意力立刻转向了我最喜爱的计算机艺术作品之一：Georg Nees 的 Schotter（https://en.wikipedia.org/wiki/Georg_Nees）。在绘图仪和 ALGOL 程序的帮助下，Nees 探索了如何通过 caos（随机性）和重复的图案来编写生成艺术的程序。Schotter 之所以引人注目，在于它的简洁以及观者能从中体会到的深刻意味。在一片完全平静、有序的表象之下，深处却藏着混乱。或者，如果你把它倒过来看，它就像暴风雨中的海面——表面看似汹涌，深海却依旧平静。

有可能把一件艺术品变成一条数据库命令吗？这很有挑战性，因为 Redis 主要通过命令行界面来使用。如今的终端固然比过去花哨得多，但要显示像样的图形仍然很困难。另一方面，实时计算带来了巨大的优势：一件艺术品可以是动态的，每次生成时都会有所不同。

在继续之前，我想先给大家看看最终效果：

尽管分辨率很低，原作的构思依然得以保留。为了实现这一点，我用了一个最近被多个试图在文本控制台中展示有趣内容的程序所采用的技巧：利用盲文 Unicode 字符集来创建一个比控制台单个字符更密集的像素矩阵。具体来说，每个字符可以容纳一个 2x8 的像素网格。

实验的第二部分是让这件艺术品参数化：

可以通过改变方块的数量和输出分辨率来生成原作的不同版本。最后，源代码本身也希望成为文学编程的一个示例——它写得更像一篇教程，解释每一部分是做什么的、为什么这么做，而不是一个晦涩难懂的生成器。你可以在这里找到代码：

https://github.com/antirez/redis/blob/unstable/src/lolwut.c

LOLWUT 从 Redis 5 开始也将成为一项传统。在 Redis 的每一个大版本中，这个命令的功能都会完全改变，只有几条固定的规则：

1. 它不能做任何有实际技术用途的事。
2. 它做事必须足够快，这样在生产环境实例上调用 LOLWUT 才是安全的。
3. 输出必须以某种方式让人觉得有趣。

Redis 5 的第一个版本由我来写，至于之后的版本，如果有人感兴趣，我会请其他为 Redis 做过贡献的人来写其他的 LOLWUT 版本，否则就还是我自己来写（但我希望不是这样）。LOLWUT 应该提醒我们自己，我们所做的编程工作，最初并不是仅仅为了产出什么有用的东西而开始的。起初，它更多的是关于探索可能性。我也希望 LOLWUT 能提醒 Redis 社区，计算机是关于人的，不可能以一种无菌的方式、仅仅考虑技术层面的影响来思考问题。有使用系统的人，有构建系统的人，诸如此类。