@buckbuckgo 我是很不理解为什么这个问题会有不成熟的理解和争论。你给的链接大体上也仍然只是说，这是习惯问题。这不算错，但是不全面。
从语法分析的角度看，如果语法严格地设计成上下文无关文法，后置和前置是对偶的，至少对最常见的几类 parser 的构造来讲不会有根本上的困难性的差异。
这个意义上，理解成习惯差异基本是准确的。
然而这里说的实际并不是前置和后置问题。关键在于，C-like 的声明符，根本上是中缀的（还不严格地上下文无关），所以导致很多对这类语言学艺不精的用户的理解问题。误以为这种设计属于类型标记的“前置”，也算是副作用之一。相关问题我在另一个回复有提过，重复一遍：
github.com/FrankHB/pl-docs/blob/master/zh-CN/about-syntax.md#%E5%85%B3%E4%BA%8E%E5%8E%86%E5%8F%B2%E9%81%97%E7%95%99%E9%97%AE%E9%A2%98%E7%9A%84%E4%BE%8B%E5%AD%90
就语法设计的目的来说，无论是后置还是真正意义的类型前置的语法，都比这种夹杂中缀的设计好得多，不说简化 spec 和 parser 需要的测试用例，至少不会那么容易因为歧义恶心到人类读者。
除此之外，在语言教学上，很多人一开始就是从 C-like 语言入门而不熟悉，导致先入为主的偏见。这是这种不彻底的习惯来源的一个解释。
不过我个人很不喜欢这种编程入门姿势。须知，类型标注乃至类型本身对语言不是都个别语言设计者赏赐的嗟来之食，而是语言设计实践中后验地构造上去的。缺乏这种自然的认知可能也是形成奇葩的习惯的重要理由。
我主张更自然的做法是先拿一种不要求 explicit typing 的语言入门，一边考虑清楚为什么应该需要有类型，然后再纠结 类型标注应该怎么放的哲学问题——这要求不能太早地拿 manifest typing 的语言影响世界观以便能有效地避免误会，同时也便于之后理解如何一般地从无到有地设计类型系统。这也是我为什么建议 SICP 第一版（使用经典的 latent typing 的语言）而抵制用 C 这样的语言入门学编程的原因之一。

@ppphp PL 不一定是直接拿来编程的。其它的用法至少包括定制语言实现，以及拿来 spec 去 derive 新的语言。
虽然直接拿来写代码的用户最多，但这些人的作用也更容易被其他用户写的代码取代。语言发展得越久，这部分解决方案越成熟，这样的用户就越来越不重要。例如，内建的元编程普遍代替用户使用外部脚本编码的能力要求，仅仅是为了生成代码而掌握脚本的开发者在市场上的重要性越来越低，只会这样的技能竞争的开发者就会逐渐被市场淘汰。
而不想被语言牵着鼻子走的开发者，多少必须了解语言在用来编码以外的实用意义，其中对大多数人最明显和差不多最容易的就是评估对选型的影响，而这和理解设计非常相关。
一个好语言，实用上应该是容易满足需求的语言，这并非能通过直觉就能判定，而需要选型分析作为基础。
除此之外，所谓写得快，（只要设计得不要故意找茬）更多是语言面向的问题域决定的，解决不同问题的语言之间没多大可比性。然而不论一门语言原本面向的是什么问题域，上升到公共的通用领域，就要求语言必须容易被定制。越是通用的高级语言，这些用途的界限就越不明显，也要求越强的抽象能力和设计的一致性。
评价这样用的语言是不是够用（先不说好），要求用户需要有熟练理解不同语言设计和实现的经验，这对大部分只是满足写得快跑得快的用户来讲是非常高的门槛。对 PL 理论的理解可以降低这个门槛，因为现在已经很难彻底设计出的新的好用的机制，而基本上所谓的新语言都是堆砌已有的设计而已，这些设计很大程度上是 PL 理论中已知的（尽管理论基础仍然非常不全面）。
在这个背景下，开发者理解的所谓对语言的直觉是分档次的。有的开发者只能粗糙地认识到某个具体语言的代码写起来容易不容易（而且没写过不被坑还不知道），另一些开发者能在不写具体代码的时候光凭阅读语言的 spec 就能看出某一类语言在项目中有什么坑，高下立判。
至于实际项目为什么用看起来蠢的语言？无非是妥协。不说培养直觉的问题，光是阅读 spec 就需要投入时间，这比直接暴力试错慢得多了。只要使用的语言不是没有可用的实现（而得自己糊一个），这样的收益并不明显。对只需要用一种或者少数几种 DSL 就能大致满足需要的领域，效率显然太低了。
但这反过来也就说明，这样的领域还有更重要的本领域内部的业务问题没解决清楚，没发展能到利用通用的可编程性和自动化普遍地提升该领域问题的解决效率而已；对口味不挑的非专家，随便一个不要太反人类的语言就能基本糊弄过去了。
另外你看来有个显然的误区，认为解决问题的难度和“聪明”有关系。而从可用性来讲，大多数搞数学的还真在这方面明显不够聪明； Python 这样已经被实现出来的语言再烂也比大多数数学家平时使用的语言像样。

就凭屎一样的触屏精度，主流 Android 设备到现在也没搞定出 WM 电阻屏设备的体验……（虽然吃灰的 Note 倒是有几个。）
当年硬是用笔戳了近万行代码；现在，呵呵……

10 年了，基本用不上，没买过。
硬币也一个没动，前几年倒是借此测出来过 bug。

@vus520 信号去月球一个来回只要两秒钟多点。1 小时够到火星几个来回的了。要给 10 个小时，那快够冥王星一个来回了。

@lincanbin 觉得恶心是要有理由的，不只是不一样。
另外，语法相对语义是次要的。语法完全长得一样的，语义上有点看上去不起眼的差别，在使用体验上都可以彻头彻尾的不同的语言——比如变量默认通过引用共享和变量默认保持独立（前者通常依赖 GC ）。设计新语言可以完全套用已有语言的语法而不需要标新立异。相对地，要和现有语言的语义不同的特性，足以成为设计新语言的理由。
（题外话，有的语言设计者认为自己的语言特性设计得足够和现有设计的语言显著不同，因此故意发明风格怪异的语法规则以示足够的区分；历史经验表明，这很可能是妄自尊大且效果不彰的。）

@hakono 还好意思定义什么叫“吵”了，啧啧。

没看到这就是单方面对自以为是的智障理解的挞伐碾压么？

我也没说限制死就不对，但麻烦往把事情整清楚的方向限制行么？还有，明明限制得很半吊子，不要装作限制得很成功好么？

为什么 C 下面指针应该 int *ptr 还是 int* ptr 都能浪费一堆时间吵半天？这个问题正好经了：
https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-syntax.md#%E5%85%B3%E4%BA%8E%E5%8E%86%E5%8F%B2%E9%81%97%E7%95%99%E9%97%AE%E9%A2%98%E7%9A%84%E4%BE%8B%E5%AD%90

对这类只要有点知识基础，不用思考多少时间就能得到理应一边倒的答案的简单问题，居然还要反复纠结大方向——说到底无非是因为蠢：看不出蠢设计烂在哪里一目了然的蠢，无法理解应该采取什么应对而擅自逃避的蠢，没搞清来龙去脉胡乱选取了不切实际的方案自以为是认为解决了的蠢。

至于为啥需要这么多字解释？你可以认为，这是因为中文对付基础缺失而理解能力低下的用户还是比较吃力的，不得不这样罗嗦讲清楚前因后果，才能弥补先前的无知导致的沟通障碍。要是反过来认为这也能造成麻烦，那大概是一开始就没搞清楚说的问题是什么。

哦 Rob Pike 那篇记错了，直接看 http://lambda-the-ultimate.org/node/4554。
虽然 on interfaces 那个回复也多少暴露出不清楚 structural typing 了。

@cmdOptionKana 你都不敢去找被黑的史实在哪，都好意思提资历？何况搞 UNIX 在 PL 山头上还真是民科啊……当年不要瞎吹无名师和万行码那坨，直接把 C 和 shell 这种半生不遂的可移植 DSL 整像样了，现在哪用得着重复发明那么多一个不比一个烂的鸡肋？
另外讲道理，PL 虽然差不多算是个现在还没怎么成型的学科，但但凡现在有点存在感的理论源头，辈分可是比图灵高的（最直接的像图灵的导师一辈）；图灵自己这方面没多大建树，后来的相关议题也被人跑题岔到递归论上去了，根本对现在几个主流阵营都没影响。拿图灵奖在 PL 这方面体现存在感的当然不是没有（像 Scott、Liskov ），但如果要计较对当前设计直接能参照的影响，那么历史上几乎全是偏工程的非主流成就（某种意义上最纯粹的也就是 Hoare 拿的，可惜对主流设计影响过于间接； Milner 搞的是一坨方法论到现在还没验证怎么全的偏门 DSL ； Nygaard 和 Naur 是时泪而且有一部分就是实现上的工作； EWD 和 JB 啥的设计在长远角度看更不入流；各种程度上凭开创性设计最该拿的 McCarthy 是因为别的理由获奖的；而 Thompson 和 DMR 拿奖是因为 UNIX ），能说明啥呢？
至于我黑的，一是 Rob Pike，具体内容是所谓 on Go interfaces 洗 golang 的设计，不懂装懂的外行问题在 LtU 就有我就不废话了；二是 DMR，把 Ken Thompson 搞的好好的 vector 愣是整成了半残 array 而让不少后来人各种凌乱。你看不懂说的啥就算了，张口就来？也是有胆色了。

@no1xsyzy 操作界面又不见得是 UI，特别还是频繁指望用户自己折腾 API 当 UI 用的玩意儿……
Emacs ？编辑器？一坨 elisp 运行时上的壳罢了。

@gemini767 恁就是有本事钦定非商业组织没权用软件的带手子？

@ruyuejun @hakono 不巧，大括号问题就是显然的蠢。要钦定说风格统一就得写死换行这个未必说得通的逻辑也就算了，非得选择逼人一起犯二不找打？
大括号换行党的常见主要理由是，{ 和 } 对齐能提升人解析代码的视觉上的效率，这绝大程度是和经验以及习惯无关的客观优势。
反过来呢，不换行党又是什么理由？节约垂直空间？别侮辱智商了，要节约行数你为啥不钦定 } 也不换行？嫌弃写成 }}}}}} 像 Lisp 一样丢人不够有个性？
那咋不干脆把{}去掉呢（反正 free form 的优越性都已经不要了）？（又没脸 Py 了是吧。）
……嘛，动机上诛心，可能理由看着还是不够有说服力？那再看看效果——比如如果用户误用了{前换行，会怎么处理，强制你写对？不巧，golang 的 spec 里用的类似是 js 的插入 ; 的屑方案……于是像 switch 后的 { 要手贱换行，效果就比某些人想要的统一风格呵呵得十万八千里了。