编程与诗歌之间不太可能的联系及其启示
我最近没有太多时间撰写关于编程的文章（尤其是考虑到我通常文章的长度）；但是有一些之前写的内容可以分享。这篇文章是在我39岁生日那天起草的一个Twitter帖子：那天我发布了我的新网站，并宣布“我很快会在这里写更多！”那是在2022年2月14日，距离俄罗斯全面入侵开始前10天。两年半后，我终于将其整合成一篇独立的文章，增加了清晰的观点、一些链接和结论。无论如何。
你很少看到诗歌（指写作和阅读诗作，而非Python工具）与编程一起被提及。而一旦有所提及，通常是以下两种方式之一：
- 将“灵魂”丰富的人文活动与“枯燥”的工程活动进行对比，或
- 使用“诗意”作为非正式的“美丽”同义词，说某段代码“读起来像诗”是说它很好、富有表现力，或是以某种方式使陈述者满意。
但我认为，将它们一起探讨可能会产生深刻的见解。下面是一些相关的思考。
我有资格谈论这个主题吗？
你自己评判吧。
从软件开发的角度来说：我是软件架构师，编写了超过25年的代码，是Ruby编程语言的贡献者，撰写了一些开源库、大量文章和某些文档项目；早年，我还做了很多Ruby指导工作，包括教导完全没有Ruby/编程背景的人。
从诗歌/写作的角度来说：自记忆中起我一直都在写散文和诗作；我的第一部小说最近刚刚出版。
在我二十多岁到三十多岁的十年间，我一直自认为是一名诗人为主。尽管我除了偶尔发表在杂志上或参加诗歌节，并未取得什么成就，甚至一度差点出版了我的第一本书，但后来出版社倒闭了。然而，我确实得到了足够的社区认可，足以相信自己至少对诗歌有些理解（即使不是精通）。
几年前我不再写诗了（转而写散文，这又另是一回事）。我的一些最近的文字可以在这里找到（主要是俄语，显然我已不再使用它）。
2017年我组织了一场著名的在线诗歌节，在那时这种形式还没有流行起来！（目前该网站已经无法访问，而且节日剩余的部分已经从互联网上消失，原因太复杂不便解释。不过，这次经历让我接触到大量来自西欧的作者——用多种斯拉夫语写作的人——如塞尔维亚语、克罗地亚语、保加利亚语、斯洛伐克语、波兰语等，这是一种非常有益的经验。）
我仍然读很多诗歌和关于诗歌的东西，并试图理解广泛的背景；今年，我开始了7uapoems项目，致力于翻译现代乌克兰诗歌，特别是那些正在服役中的士兵所写的。
话虽如此，我对文学理论并不十分了解，所以文中任何定义都是我自己尝试的结果。对于那些精通理论的人来说，可能会觉得这些尝试令人恼火或可笑。
我也不会在软件开发方面使用精确的理论术语进行讨论。我的思维和表达方式通常是“平易近人”的，不管好坏。
为什么我们写和读文学作品
一次粗略的定义尝试
为什么我们要写和读文学作品，任何文学作品呢？
大多数是为了分享一种体验。即去某个地方、亲历某些事件、感受某些情感、理解某些事物的体验。这是我们或许无法直接获得的体验。（当然，也有帮助重活熟悉体验的各种文学作品，但让我们不进一步复杂化。）
在这个定义下，诗歌本质上是一种更高效地分享难以理性表达的体验的方式。它依赖于某种“跳跃式”的理解，一个精心构造的短语的效果等同于五页密集的解释。“简化过头”是我的特点！
这实际上与“美”无关，“美”仅是一种可以用或者不用、甚至可以颠覆的诗歌工具；糟糕的诗句中，“精心构造”的句子可能会掩盖所传达的意义/经验的平庸性。
虽然我不再写诗了，但我依然坚信，在许多情况下，以“诗意”的方式传递体验是最高效的。据我所知，在写小说的同时我从未停止过做诗意的工作。有“散文式”的写作工具：构建情节、处理世界观、创造角色的动力，也有“诗意”的工具：选择基调、节奏和意象来吸引读者——这两种工具很可能会出现在任何形式的写作中，数量不同。
相反，如果你不喜欢读诗（甚至不知道为什么会有人这么做），那可能只是因为你还没有遇到能与你的体验交流的那类诗，或者你的性格不需要这种特定形式的写作。这只是个人特点，并不意味着你在其他文本中无法接触写作的“诗意工具”。这也希望不意味着你不能从我的对比中得到收获。
Artur Dron的诗《伊久姆圣餐》的一个片段。翻译是我自己的。
编程是如何相关的
在常见的“工程与艺术”思维框架中，编程似乎与诗歌对立。然而，在过去的几年里，当我在编程会议上羞涩地提到“……同时还是一个诗人”时，总会有一些人——通常是杰出的工程师——站出来说“我也是！”
通过Alex Bilzerian，由我的朋友Dima Ermilov指出。
我在很多时间里思考并写了许多关于感知代码为文本及其带来的直觉、方法和期望的文章。[这个博客的第一篇文章]（https://zverok.space/blog/2015-09-22-three-kinds.html）（九年前了！）是关于Ruby适合“作家式”程序员的文章；我最近的EuRuKo演讲中也把“在代码中书写故事”作为一个主要的主题。
从前面提供的定义来看，可以说写代码就是分享理解和实现过程的体验。
从这个角度来看，明显可以看到这里存在“诗意”工作的空间：在某种程度上对某些思维方式而言，从整体实现领域跃进的几个“句子”常是有益的。
这个话题颇具争议：任何试图用现代语言特性压缩意义的尝试都会遭到批评——特别是在Ruby社区看到这一点尤其令人难过，因为语言的设计意图和社区实践之间的差异似乎随着时间的增长而扩大。
“诗意”的方法在对理解跳跃更加友好的语言中变得边缘化，但这些语言不如日常散文那样可读，例如Perl和APL。（附注：最初的讨论部分是因为The Array Cast播客第一集触发的，他们明确提到了APL及类似语言中的诗歌。不过，即便在那儿，如果我没记错的话，它也更多是作为“美好/悦读”之类的通用形容词提及的，尽管简洁语言的用户确实更倾向于同意通过精心构造的一行文字直观地传递体验的价值。）
我认为，诗意的工作是一种有效的有用工具。
有时，"诗意"代码在草稿阶段有用，然后它会被扩展——完全或部分——成为更冗长的“散文”，涉及模块、服务和关注点。
有时，简练的、“直观”的表达是最好的形式，大多数读者也会认同这一点；同样的方式，一首诗的某些句子会成为谚语。我们在编程中称之为“惯用法”（我对这一术语有疑虑，但这是另一个话题）。
它可能是一个不常见的观点，但解决相同任务的代码量可能会有很大差异（数量级上的差异），如果采用“停下、思考、写一节”的方法（而不是“写20页通常的那种”）来解决问题的话。
而且，维护五行代码——甚至那些依赖于直觉的代码——无论如何都比维护20个文件的代码便宜。行业中的很大一部分在某个时候不再相信这一点，所以“不要编写聪明的代码”这种论点通常被表述为“两行‘简单的’代码对一行‘聪明的’”。
一张来自🇺🇦的明信片
请在此处停留片刻。这是你在文本中间的常规提醒，我是一名来自乌克兰的真人，在俄罗斯入侵仍在继续的情况下，请阅读以下内容。
一条新闻。 俄罗斯军队在波克罗夫斯克方向处决了16名乌克兰战俘。
一个背景。 俄罗斯如何违反《种族灭绝公约》。
一次筹款活动。 请帮助筹集资金，购买一辆后勤卡车！“通往乌克兰之路”是一个值得信赖的筹款组织，完全透明，并且真正了解我们军队的需求。
那又如何？
无论你是否赞同我的比较，你可能会对其实用价值产生疑问。像是，好吧，编程，或某些类型的编程，可能会或者不会与“诗歌创作”有些相似之处，但从长远来看这将把我们引向何方？
关键是，我希望看到更多的人用文学所受到的方式对待代码的句子和“段落”（方法或语句组）。我不是在说“让我们写出bEAuTifuL的代码并像蝴蝶一样自由！”这样的比喻。
我是指一种可以从不同的角度分析、讨论（或许还可以教会自己）思考方式：考虑潜在读者（不管是人还是编译器/解释器）会怎么理解。在这种情况下，表达的意义是如何传达代码背后的想法；是否可以用另一种方式表达来强调不同的方面。这是一种不那么死板的自动格式化和风格指南，并且比抽象的“可读性”或“聪明/简单代码”更为细致的对话。
然而，每次当我与人们（同事或仅是在线讨论参与者）进行这种对话时，总会陷入两个阶段：首先，“这一切都是主观的，并取决于每个人喜欢什么。” 当提供较少主观性的分析/解释关于文本/代码可能被感知的方式时，第二个也是最后一个阶段就是“也许，但是我不明白你为什么要如此关注这些细节，这些都是吹毛求疵。”
但我仍然认为这是一种值得进行的对话。我想看到例如对一个流行库的新版本进行一些“文学”批判，类似于“这是作者通常采取的风格方法，这种方式的效果是这样，很适合类似A的任务，但在情况B中会导致那些可能的误解…”但我们在这样做之前就会被贴上“主观”或“吹毛求疵”的标签，因为“嗯，它可以工作，你还想要什么呢？”
我们还需要认可并珍惜风格和形式的大胆实验，也就是“诗人的诗人”概念：那种即使在生产环境和团队中你很少会使用的代码，但它有助于探索你的编程语言表现力的可能性，并掌握其适当的使用方法。
最终的目标不是某种抽象的“美丽”或“工程卓越”，而是我们都共享的实际价值：可维护性，对变化的开放性——这些都受制于理解清晰度，而理解清晰度反过来取决于事物是如何表达的。
这也是为什么我总是不断地从不同角度回到代码和文本这个话题上。也许这并不是最后一次！
另见： “程序员是否梦想电子诗？”” ，这是Facundo Olano的文章，以略有不同的论证探讨了类似的话题。