1. key是uuid本来就是哈希表算法的基础，hash函数就应该是自己设计的。Java里边你要让一个对象是hashable的，也得写hash函数。
2. 和collection相关的处理统一用lodash或者underscore来处理。_.map(collection, function(value, key) {...} ) 一点问题没有。本来forIn就不在《the good parts》里边。
3. split提供默认值的话，你难道不会骂娘说为什么要默认成这样，我让你默认是逗号了么？在多数场景下反而会提高debug的难度。不指定separator就默认为undefined，字符串里没有undefined就分不开，返回自己有什么问题么。
4. 针对第一个需求，如果真的想优雅实现的话。可以自己将普通的hash封装一个hash类，要加入新的键值对时首先调用键的hash函数求出字符串型的uuid，再存入普通hash中，注意处理碰撞，因为js没有链表，应该只能用闭散列。取的时候也调用键的hash函数算一下，再找。
任何一项特性的引入都会伴随着复杂度的提升。我用python的时候就会觉得，卧槽干嘛简简单单一个字符串要搞这么多编码，卧槽干嘛数据库里边查出来一个数字序列化成json会报错（decimal is not serializable）。这些东西你想想都有道理，因为本来字符串就是bytes+encoding，默认采用utf8或者ascii都犯了过于主观的错误。decimal作为高精度数字类型确实和普通的float/int是不一样的。但是这些人为引入的复杂度对解决问题起到任何帮助了么？想想有多少时间是浪费在处理这种事情上，而不是真正的业务逻辑上了。
比方说泛型，你觉得map<string, Any>是一个特例，那其实根据scala的思想，没有对类型推演的逆变和协变，泛型也是不够完整的，即便是map<any, any>也是不够泛化的。(
http://www.tuicool.com/articles/vaAnmq)
关于比较，我就问一声，各位大神什么时候会在自己的程序里边写出这样的代码？有多少时候是因为语言设计的缺陷导致自己调了几天bug的？
我个人的观点是：Javascript有很多傻逼的地方，但是只用到(
http://book.douban.com/subject/2994925/)的话，它就已经是一门伟大的语言了。