代码之髓笔记

一旦出现程序错误，很多人可能会惊慌失措。其实那只是语言处理器在仔细阅读了你的程序后，告诉你它哪里不明白而已。只有理解了这一点，才能和语言处理器打交道
设计不存在任何解析矛盾的语法体系是十分困难的。随后要再融入新的语法时不与既有的语法发生冲突，这个尤其困难。正因为如此，现实中程序设计语言仍然保留有不少别扭复杂的编写规则。

PS:js程序员应该能感同身受，做为web浏览器端几乎可以说唯一的语言，设计之初有太多的坑，之后缝缝补补又要向前兼容，导致现在很多js中很奇怪的地方。
也许有人要问，那到底用什么容器好呢。事实上，万能的容器是不存在的。根据容器的使用目的、使用方式和操作类型的不同，最适宜的容器类型也会相应地变化。是想要节约内存、节约计算时间，还是两样都没有必要节约。没有绝对的正确答案，而是需要根据当时的状况仔细分析，寻求最佳平衡。这是非常重要的。

PS：可以说“没有银弹”真的是很高瞻远瞩的看法，二十年前（应该没记错），《人月神话》的作者就说出了这样的话，然而直到现在，我们还是在挣扎着，在各种工具和方案中寻求平衡。
我们是怎样理解世界的呢?我们将生活中遇见的事物总结为特定的 “物”的概念，它们就是诸如桌子、椅子、银行贷款、公式、人、多项式、三角形、晶体管之类的东西。我们的思考、语言以及行动就是建立在指示、说明和操作这些所谓的“物”的基础之上。我们在用计算机解决问题的时候，有必要将现实世界中的“物”的模型在计算机中建立起来。
但我也深知，这个地球不是单靠程序员运转的，现实中还有很多不依赖于程序实现方式的解决方案。

PS：程序员做久了有时候会产生一种“程序员思维”，或者叫“技术至上思维”，放眼望去，其实程序员是人群中比较少的比例，所以大多数人应该不认可这个思维，虽然科技的进步改变了人类的生活，可是世界太复杂了，更多的事情是无法用代码来解决的。
我们很容易更加关注 How 的问题(即如何去实现)，实际上，What (要实现什么)和 Why(为什么要实现)的问题也是不可忽略的。How 充其量只不过是手段。然而时间是有限的，干劲是宝贵的，要把它们用在真正需要的地方。