@
clino 代码可读性好还是不好，根本上取决于两类因素：代码自身的构造；读者的理解能力。光从一个角度考虑得到的不全面的结论难以说明多少问题。是不是习惯了就会“好很多”，也得看代码写的怎么样和读者的理解水平怎么样两方面，没法一言蔽之。
要使特定领域的语言来作为一个问题的解决方案具有可操作性，一个重要的前提是读者必须具有对这个领域足够熟悉。不管是不是针对工匠，没有这个前提的“臆测”都是下下之选——这可能会让一个解决方案看起来可行，却埋下更高的因为理解错误带来整体失败的风险。如果你说的“可读性”好包括能让外行臆测比较容易撞大运蒙对的话，那我情愿可读性更差一点，排除掉不合格的读者，免得逼所有人都一起低效。大部分工匠更喜欢怎么样我没法下定论，但我相信，干大部分活的工匠不会乐于为蒙出来的问题买单。
从绝对意义上来说，只要用户有超过一种语用习惯，语言的分化是不可避免的。消极避免语言分化基本上算不上是可行的选择。实际上用户需要的结果是尽量达成合理的共识，这跟分化并不全然矛盾。在工程上，形成共识的一种主要手段是参照规范。无论在此之前如何减少了分化，也不会取代这个步骤，这个意义上刻意从语言设计上避免分化，在这里就成了过早的优化。
进一步地，在特定的环境下，因为语用习惯的多样性导致的“可读性差”是不是真能成问题，也未为可知。如果使用的代码总是由具有足够领域经验的用户编写的，一组项目中在参照规范之前取得领域含义的共识来解决“由于一个给定的符号可能是一个变量，函数或操作”这样的问题都不怎么困难。
而如果说要让所有用户都形成统一的风格，上面所说的“事后”方法自然的确不怎么可行，非得要做到就基本只能残害语言设计的灵活了；但这同样没有多少现实意义：取得共识的成本大于收益，还仅仅因为习惯问题就提前把一部分可能发挥价值的潜在用户排除掉了。
顺便，利用语言的分化恰恰能够更快捷地设计DSL并观察有效性。至于文化之类另当别论。