[译文] 关于 Golang 的一个令我深深叹服的特性

[jemygraw]

http://golanghome.com/post/155

[dorentus]

看了 https://codereview.appspot.com/5285042/patch/9001/10003 这个我就真不明白了……

本来：
1) 通用知识里的 Map 没有任何对 key 顺序的假设
2) Go 实现的 Map 保留了 key 顺序（按文章里的说法）
3) 有些人写程序的时候依赖了 2)（按文章里的说法）

于是 Go 选择了更改实现来故意 break 3)。这没有问题。
但是为啥要这么实现……如果没有其它原因的话，这种简单粗暴的方式（加了个随机偏移量），和文章里面说的 Javascript/PHP 过于迁就用户的做法有什么区别……

[dorentus]

@jemygraw
说到范型，几乎很难提到 Java 的啊，前有 C++，后有 C#，都比 Java 更早提供范型机制。

@hhkbp2
我记得 Go 是把防止程序员犯错放在第一位的，让程序员开心排在后面；所以按这标准的话，拒绝泛型，减少潜在的错误，但是写起代码来很累，还真的是“正确”的事情 :)

[yxz00]

服点好低。。

[jemygraw]

@dorentus 嗯，其实这篇文章的要点是，作者赞赏google这种知错就改的做法。防止程序员依赖这种一致性，因为在以后的迭代中，很有可能就不一致了。

至于javascript和php迁就用户的缺点，我就不讨论了，我也不知道。
但是，有一点就是用户的需求往往只能呵呵呵。

[abscon]

很好，我决定使用哈希表时顺便取得一个随机数，因为现在的实现确保了我可以做到这一点。golang不会因此又修改实现吧？

[jemygraw]

@abscon 应该不会。

[wulin]

“针与干草堆的问题（在干草堆里面找针）”,
说的是php里面类似这样的函数http://cn2.php.net/manual/zh/function.strpos.php

[jemygraw]

@wulin 欢迎到Go友团评论。

[chemzqm]

php，javascript，perl这些脚本语言主要的关注点是如何让开发者更快的编写代码，这就导致了大量的代码依赖于许多模棱两可的特性最终很难维护，而Go的设计者更注重语言的品味，因为相比与少写几行代码，让程序员可以更快速的正确理解代码往往更为重要。

[jemygraw]

@chemzqm 终于遇到一个有理性思维的人了。

[est]

这个。。。。。。。。。。。python 的dict 不也一样么。虽然不是随机的，但是是根据hash顺序而不是插入顺序遍历的。

[generic]

@jemygraw 你的例子和Java generics没有关系，因为Java在没有generics之前，排序就是像举例那样实现和使用的，有generics之后也一样。唯一区别就像你指出的，Java interface是nominal，go是structural。

C++/Java的泛型主要为了解决homogeneous container使用时总是需要cast的问题。判断go有没有C++/Java式的泛型，看使用非语言内建容器时是否总需要cast即可。

[generic]

@dorentus 有趣的是C++/Java泛型本身也是为了“防止程序员犯错”，即在使用容器时cast错类型。
要说原因，各语言的泛型系统都很复杂，在新语言初期效费比不高。Java泛型也是相当晚才加上的。

[abscon]

@generic h C++的泛型本意是抽出算法的共性，避免重复代码。妥妥的正能量，没有这么强的针(xiao)对(xin)性(yan)来避免dynamic_cast出错。事实上，C++引入template后开启了而不是关闭了很多可能性，避免继承自一个共同的鸡肋然后cast来cast去这种恶心的做法只是其中的一个可能性而已。

[generic]

@abscon 你这个解读呢，在现在这个时间点没错。我们还可以再高大上一点：C++的泛型是一种metaprogramming机制。
可是我们看问题还要有历史的角度。Bjarne Stroustrup在程序语言理论方面并没有很深的涉猎，C++ templates并不是在理论指导下设计，而是逐步演化来的。Templates最初要解决什么问题，看当初引入templates后实现的第一批库即可。
Templates带来的可能性，是使用过程中逐步发现，而不是有意识设计的结果。（尽管Stroustrup在D&E中把这部分归功于他的设计哲学。注意，仅仅是设计哲学。Stroustrup在设计那些使STL成为可能的语言特性时，本来还是针对homogeneous container的具体问题，而并未有意识地支持metaprogramming。）
正因为templates这种无意识的特点，用它作metaprogramming时才有各种语法复杂和scalability问题。我们根本上是在用一把由锤子演化来的菜刀。
不过，即使Java generics这种有意设计的结果也相当复杂，Go暂不采用也很正常。

[abscon]

@generic 所以我得祈祷golang的设计者每做一个决定时都全知全能，预见未来，否则就像是剃须的时候把下巴剃伤了

[jemygraw]

@abscon 这个和想生下来就是高帅富是一个逻辑。哈哈。

[kavinyao]

@dorentus 用linked hash map就行，性能牺牲微乎其微。Ruby 1.9之后的hash就是这么实现的。

[abscon]

@jemygraw 我不太清楚，不过 @ddzz 正好是这么看待golang 的粉丝的 http://v2ex.com/t/122446

[jemygraw]

@abscon 我突然很想做独裁者。