最近几天相当激烈。其中一个争论，关于是否要用别的词语来替换 Redis 复制中所使用的词语，论点之一是：去做那些不会产生任何技术成果的工作，值得吗？

当我修改 Redis 源代码以尽可能去掉某个特定词语时，我开始思考，无论我对自己正在做的工作有何看法，我都是那种喜欢编写没有可衡量技术效果的代码的人。替换词语这件事本身就很烦人，即便如此，其中也有一些值得一做的技术挑战。但还有另一种代码，我认为它具有一种叫做“hack value”的特质。它或许解决不了任何技术问题，却依然值得去写。有时是因为编写代码的过程本身就是一种回报。另一些时候则是因为用非常高深的技术理念去解决一个毫无用处的问题。有时写代码纯粹是出于艺术原因。

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

我的注意力立刻被我最喜爱的计算机艺术作品之一所吸引：Georg Nees（格奥尔格·内斯）的 Schotter（https://en.wikipedia.org/wiki/Georg_Nees）。在绘图仪和 ALGOL 程序的帮助下，内斯探索了通过编写程序，利用混沌（随机性）和重复模式来生成艺术。Schotter 之所以引人注目，在于作品的简洁性以及观者能从中体会到的深刻含义。在一片完全平静与秩序的表象之下，深处隐藏着无序。或者，如果你把它倒过来看，它就像暴风雨中的大海。然而无论海面看起来多么汹涌，深海始终保持平静。

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

在继续之前，我想先向你们展示最终成果：

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

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

可以通过改变方块数量和输出分辨率来生成原作的不同版本。最后，源代码本身也想成为 literate programming（文学编程）的一个例子，它以更像教程的形式写成，描述每部分做了什么以及为什么这样做，而不是一个晦涩难懂的生成器。你可以在这里找到代码：

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

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

1. 它不能做任何在技术上有用的事。
2. 它做事应该很快，这样在生产实例上调用 LOLWUT 才是安全的。
3. 输出应该以某种方式具有娱乐性。

我为 Redis 5 编写了第一个版本，对于后续版本，如果我发现有人感兴趣，我会请其他为 Redis 做出过贡献的人来编写其他版本的 LOLWUT，否则我就自己再写（但我希望不是那样）。LOLWUT 应该提醒我们自己，我们所做的编程工作，最初并不只是为了产出有用的东西。起初，它主要是关于探索可能性。我希望 LOLWUT 也能提醒 Redis 社区，计算机是关于人的，不可能以一种无菌的方式，仅仅思考技术层面的影响来做推断。这里有使用系统的人，有构建系统的人，等等。