Jeff Atwood在谈论Markdown缺乏方向时提出了一个特别的论点。在过去五年中Markdown的实现数量迅速增多,但规范却受到冷落。我也为Nu写了实现,这个实现基于PHPMarkdown。当时,我已经意识到Markdown有点没落,PHPMarkdown的更新和修订相当频繁,它还附带了测试套件。最后,从我本身来看不用把原始版本当做Markdown规范的参考,选择PHPMarkdown而不是原始版本做参考实现。现在各种Markdown实现如雨后春笋般冒出(几乎所有流行的语言都有,用到了各式解析算法),我们不禁要问,是否需要一个比较的基准,规范是否已经非常完整。

其他人说的几句话

我认为PHPMarkdown的创造者和支撑者Michel Fortin洞悉了这个论点的本质。他解释了PHPMarkdown的目标和PHPMarkdown Extra出现的原因。基本上,PHPMarkdown可算是正确的Markdown,而Extra是新想法的试验田。他还对Atwood假定的Markdown的三个bug做了解释。鉴于我将PHPMarkdown作为参考标准(在一定程度上认为Extras可以算潜在的未来规范),我对Fortin的回应十分认同。

Daniel Jalkut也从开源软件开发者的义务角度做了回应。基本上的说法是,如果你给予了免费的东西,你对用户没有任何额外的义务。在开源界尤其如此,因为用户可以简单地获取代码,为自己的需要进行改动。虽然这种说法比较适用于消费品,可能也适合开放的源代码(尽管要面对这样的现实:开源项目大部分时间以缓慢痛苦的方式死去),但我不认为这模型可直接套用在这里。稍后我会给出解释。

最后,Github有它自己风格的Markdown,并且得到Gruber明确认同,但这算不上什么。这也证实了开源软件的潜力,声援了Jalkut的主张。但是,我不认为它很大程度上削弱了Atwood的论点。

这是规范,不是代码

Markdown不只是个简单的Perl脚本。有段时间它是用来处理格式化文本的Perl程序。但现在它是一个规范。现在Markdown的实现不只一份,而是有几十个。它们都试图得到同样的效果。这是复杂问题的一部分。

我们来考虑一下Atwood的两个基本观点:

问题几乎在John Gruber上,正是他给我们带来Markdown,也是他,成为了Markdown发展和成熟的最大阻碍。

现在最坏的事都遇到了。上层缺乏领导,一堆各自为政,缺乏协调的社区努力推进Markdown,其中没有一个算是正式的标准。

第一个观点Gruber是阻碍Markdown成熟的障碍,先放到一边再说,我不认为第二个观点可以被轻视。它是一个无法回避的重大问题。看看有多少Markdown的Ruby实现。天哪,大家都发现Rails已经不得不重写了Markdown吧。

我们再进入Github风格的Markdown及PHPMarkdown Extra的问题。当然,针对网站做些细微调整是好的(得到Gruber正式支持),那规范算什么?有关于单词中的下划线及如何改变格式化的观点。Fortin对在PHPMarkdown依然保留这种做法给出了很好的解释,但他也说,他在PHPMarkdown Extra改变了规则。如果这一想法得到足够的支持,我们可以改变规范吗?

必须明确指出,下划线应指示单词有下划线,而不是强调。只有链接能用下划线是一派胡言,这样做忽略了书面语言的标准约定。但我无法改写Markdown规范。

最后,Markdown的强大在于它是一个写得很好的标准。人们喜欢这语法,最重要的是,喜欢它的可移植性。几乎所有流行的脚本语言都有实现,并且很容易在基于web的应用程序中实现(感谢PHPMarkdown,Python和Ruby的有价值的实现)。Markdown是一个只学一次,但经常使用的技能,而且因为它传播的越来越广泛,变得更加有用。它不只用在web。我有根据需要可以将Markdown文件转为PDF和RTF文件的脚本(尽管先转为HTML,但在理论上Markdown是个和输出无关的规范)。

该规范从面世以来还没有重大的改变,尽管Gruber自己的网站现在有各种新的元素,如脚注。footenotes是PHPMarkdown Extra的一部分,但开发者可以进行选择。他们会按照第一次进入市场的Extra的风格来做或创建自己的语法吗?他们仍保留两个空格表示换行或他们用每一个段落里面的回车做换行吗?他们必须遵循的下划线规则或是可以改变它么?

Gruber的Markdown版本适合他自己。GitHub的也适合他们自己。最终我们将不得不得到Markdown的多个版本,适合不同的场合,仍不会有个现代的典型版本。越来越多的人把自己的想法加入自己的实现当中,Markdown作规范不断稀释。由于实现的分歧,Markdown用户面临学习不同实现的差异或限制自己只用核心规范功能的复杂选择。限制和混乱不会吸引用户,Markdown将成为让人不感兴趣的选择。最终,像我这样的人可能希望完全打破规范,让下划线“_”实际上意味着单词下划线。

前进还是结束?

Atwood似乎认为Markdown需要继续改进。我不禁要问这真的那么有必要么。就我目前看到的,Markdown的方式覆盖到了我格式化的大部分需求。我不需要脚注或引文及其它很多功能。在一定程度上Markdown是完备的。如果它从不改变,我将继续使用它,直到找到更好的工具。

如果它已完成,我们需要一个参考。它不一定是Gruber的作品,开源社区更好。我们需要创建一个Markdown的参考编译器,来生成准确,无缺陷,完全符合规范的代码。我们还需要创造一些比较输出的标记(至少在HTML中),这样可以让实现和参考者进行比较。

附带参考编译器,Markdown规范的核心语言得以保留。额外的Markdown风格,可以在适当的时候分出来。大的变化(如在Extra中的),甚至可以是不同名称的新分支,表明它们不是真正的Markdown, 而是加入一些改变的扩展。

或许我们可以委任某人(想到了Gruber)作为Markdwown的仁慈独裁者(benevolent dictator for life,BDfl)。没有额外的代码需要被添加到Markdown.pl(Perl应用程序),它只是几十个实现中的一个(还可能过时或废弃了)。相反,BDfl只需要提供意见,并批准扩展Markdown规范的建议。社区来扩展参考编译器及更新自己的实现。

这本不用说,但我发现它往往需要反复地说:产品更新带来碎片化的市场。不是每个人都会仅仅因为规范改变,就把自己最爱的Markdown实现升级到最新版本。更新和其它事情一样,可能会打乱使用习惯,尤其是在上层作针对全站点的改变。有一个稳定的规范,可能是一个主要特性,而不是一个严重问题。

原文见:On The Future Of Markdown


这篇文章来自于精炼软件(From Concentrate Software)公司博客,主要是是软件开发者的思考,不过更新很慢,最近一篇还是2011年8月:(。这个公司的创始人是Grayson Hansard,公司目标是给苹果用户提供有用的软件,详情及公司名字来历可以参见这里,中间有部分关于他们开发软件的信念很有意思,与大家共勉:

借用一句话,软件不是终点,而是旅程。好的软件是有生命的,也就是说要不断地推敲打磨,才能接近理想的样子。FCS会珍视每一个反馈,想尽一切办法提升程序的品质。