代码越少越好。现在我知道，有时候如果代码行数更多，就更容易阅读/理解，这是值得的

我以为这将是一场过山车之旅，里面有飞驰的汽车、放荡的女人、私人飞机和大胆的冒险。等着瞧吧，直到我得到那个职业顾问....

我很早就开始学习编程了。那时我14岁左右。我有各种疯狂的想法，但不要问我准确的时间，因为那是很久以前的事了。

Ok, so, I believed for a while that if you use the term synchronize in Java, then Java solves this nasting synchronizing thing for you I believed for at least half a year, likely more, that static typing would improve performance. I believed that freeing something would return memory back to the OS. I believed that malloc calls boil down to checking if there is enough free space on the OS, so malloc would be inexpensive. I thought a long while that Java was built with all the benefits and flaws of the other languages in mind, into a "perfect blend" that would take the best properties of the other languages and reject the mistakes. I vastly overestimated the number of cases where LinkedLists outperform ArrayLists. I thought that NP-hardness was a proof that no INSTANCE could be solved efficiently, which is trivially false, for a while. I thought that finding the best flight-plan on travel agency web sites would take so long because of the "Travelling Salesman Problem", as I proudly chuckled to my relatives (when I was small, alright?!)

还能想出更多。不知道我坚持了多久。对不起。

PS: 啊，好吧，这个被清除得并不慢，但我看到新手时不时地这样做，所以我想你可能会感兴趣:我还认为要存储不确定数量的东西，你需要为每个东西声明一个新变量。所以我要创建变量a1 a2 a3…，而不是使用一个变量a，我将它声明为一个向量。

Unix和Linux操作系统设计得很好……我可能应该限定这个(!)

首先，这一观点被一些反真理的观点所强化，例如:

每个后续开发的操作系统最终都以对Unix的拙劣重新设计而告终(Lisp也是如此，在那里它更正确)。 构成“Unix哲学”的一系列规则。这并不是说他们错了，而是暗示Unix本身紧跟他们的步伐。

更确切地说，它们设计得很好/做得很好，当然其中一部分确实如此，但即便如此，这也只是相对的判断，相对于一些糟糕的Windows版本。下面是一些做得不好的事情的例子:

配置一团糟，特别平面文件配置不好 C语言在很久以前就应该被(类似D语言的)语言所取代 Shell脚本是精神分裂。它不利于开发，因为它是为快速输入而设计的速记。 目录结构命名不当 GNU工具链是不必要的神秘 一般目的总是胜过特殊目的的信念

总的来说，它们需要不必要的专业知识来操作。或者更确切地说，有大量的知识，而只有适度的理解。

也不全是坏事。Linux在政治上更好，不会被业务需求所破坏，但遗憾的是，在很大程度上，很多技术高地已经失去了。

用汇编语言进行优化=重写。

When I first really understood assembly (coming from BASIC) it seemed that the only way to make code run faster was to rewrite it in assembly. Took quite a few years to realize that compilers can be very good at optimization and especially with CPUs with branch prediction etc they can probably do a better job than a human can do in a reasonable amount of time. Also that spending time on optimizing the algorithm is likely to give you a better win than spending time converting from a high to a low level language. Also that premature optimization is the root of all evil...

在不浪费字节和CPU周期的情况下编写高效的程序是非常重要的。

但随着经验的积累，它与字节或CPU周期无关，它与你的思想流有关，连续的，不间断的，就像一首诗。

本质上，不要太努力。