不得不说，总是要学会学习的... 其实就是从你 不注意的『前端』方面，也会看到不少你觉得很巧妙的解决方式
你之前都不知道，或者存在误解\想的太简单（比如因为我不熟悉图形混成，把 shape 的 Background 当成了一定是背景色、不能是『底下』的 shape... 比如我不知道重复的 shape 可以使用很多 shape 组合成，而且还可以让混成器切掉一些叠合图）
虽然之前的确隐约有这种感觉（迫真自我安慰）
果然实践最重要

如果有喜欢前端的同学，我推荐 《Qt5.9 C++ 开发指南》那本，对（基于 Qt5 Paint 的）图形绘制和混成讲的很清楚。
不过我没有多看，而且说句题外话，我算法也不太好（不会动态规划，dfs bfs 勉强会一点点）

FP.js 是第一个我手写解析组合子的设计/实现
它还存在很多不足，比如错误信息的嵌套本来不应该传递字符串，以更好地表述解析错误的信息
比如 Feeder 架构冗余，而且没有实现本来绝对可以实现的随机 mark/reset
比如语法错误在 possible 解析器里处理的不好，会使得一些错误 unsound 并且导致报错信息莫名其妙；当使用 new Error workaround 的时候更是完全不可取，它还会破坏掉 runParser 的 Either 封装。

未来，如果还有机会，我会用 Java 8 重新实现一个 PEG 解析组合子，新组合子的错误处理将基于嵌套异常捕获计数（这样就可以在不依赖专门语言工具的情况下做到尽可能小的运行时开销）、解决 possible 的『盲目重试』问题（并且也将提供 更多类型的异常，SoundPfail）（补充：其实 def/let/just 的问题只是我个人对解析组合设计的不好而已，这是在讲以后框架上可能的一个改进）。并且将会可能支持一些解析器组合时的优化/动态分支重排序/字符串扫描 SIMD 优化什么的

#blog #recomended https://coolshell.cn/articles/2424.html #statement #OOP

3）Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。

这个观点我非常支持。测试和文档应该描述侧面，不是你的实现本身。写过于重复的代码是愚蠢的，以用户的视角思考问题。

6）”Googling it” is okay!

Google只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度的使用Google，只会让你越来越离不开他，你越来越去要去立马告诉你答案，而你越来越不会自己去思考，自己去探索，去专研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们的智力发展大大的没有好处。

这个绝对赞 #statement 我很讨厌（永远只会）有问题就找 Google，抄代码的程序员，这样的程序员没有进步的空间，也说明他们不热爱自己的事业

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言，了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

看本频道的人应该已经在自己设计实现编程语言、DSL 了（跑

9）Design patterns are hurting good design more than they’re helping it.

很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱动编程”，正如第一点所说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

我们应该解决问题，不是崇拜刻板的方法论。最好的是最合适的，不是平均评价最高的

https://coolshell.cn/articles/3745.html #Haha #dev 笑死我了
https://coolshell.cn/articles/3778.html

水管工2：我去拿个扳手。

事主：好！终于！等等，你就拿来一个扳手？可是你们有三个人哦。

水管工1：不这样的，先生！我还是在这里做个初始的Presentation，我一会就走了。但是，我还是会对项目的进度非常感兴趣的。我会打电话过来参加明天的 stand-up meeting。

水管工2 ：另外，和你阐清一下，我们两个留下来的会分享同一把扳手，因为我们是结对水管工……

水管工3：……你能看到这会更有生产率，我们轮流使用这把扳手。并能保证很高的质量以及持续的工作激情！

事主：我没搞懂——你们以前应该就干过这个事了吗，不是吗？500美金的出场费还不能让你们有工作激情？

水管工1：你得想得长远一些，先生。你看，我们可以一起来经历整个过程。这是多么令人兴奋的事！我对此超级兴奋！

#China #Low 🇨🇳 富强！民主！文明！和谐！自由！.... 说不下去了还有7项呢。

#recomended #sysadmin #db https://coolshell.cn/articles/17680.html

很抱歉 看起来今天是没有办法了呢...
我有 1. 做事情耐心不够持久 2. 做完一件事情就很松懈 的坏毛病... 不过也是蛮需要体谅的，毕竟我做任何事情都很难考虑到身体

这个暑假，我在写 Promise-Java 的时候，（对 Break timer 的容忍）已经是极限了
实际上之后我根本从没有在安排下休息一分钟，像这样子一直工作 是不行了呢... （另一方面，其实我打字的速度也没有得到太多的提升，反而不如从前了呢...）

不过总之，我还是勉强对这个暑假 满意
虽然咸鱼过太多，但多少有点进步。不用再说希望，就是继续带着不确定生活下去吧~

所以请允许我咸鱼一下.... 只做最后一点必须的处理 就发上分享 😊
之后我会做一些低负荷的事情，总是挑战那些不容易想到的事情 太耗费精力了
很抱歉 人的精力是有限度的呢.... 以后尽可能学会控制自己的傻劲，必须和策略以及判断推测 结合起来吧

🖕 tail

    要做到——知其然，知其所以然。所以，只能不断的学习基础知识以及和这个技术关联的知识，就像Wikipeida一样，当你进入一个词条的时候，就会伴随时一堆新词条，于是，当多年后，我看到 

“知识广度是深度的副产品”

这句话时，简直就是说到我的心里去了。

https://coolshell.cn/articles/17446.html
真的是说到我的心里去了 #statement #coolshell

这个博主 30 年的技术积累真的不是盖的啊！ 为什么眼界就这么开阔；观点就这么有力度 而且从最小的一行代码到实际跨国级别的服务架构 都这么深刻，还了解过这个行业多久之前的历史和知名的人物、重要的软件作品和观点文化

真的是优秀啊！

有缺点尽管提，我不像 @ice1000, 我的时间比较不宝贵（也不像 @drakeet 不接受你的意见）。 啥时候你找到了就和我说，是真的我就给你答复，不是真的我就告诉你为什么

对上面冰封哥没太多意见，毕竟如果是我这种问题的话 也是怪浪费时间的
就像你问我某个非常简单的『（数学）分段函数如何实现』我也有可能不会多说几句话

当然，我对 drakeet 是真的有点意见的，这个我不否认。

其实一个人有自己信仰的理念、有自己崇拜的人是很正常的 #dev #statement

计算机科学、或者所有这些有着不一样理想的领域，都不缺乏各种做的很不错的人，比如 CS 吧，Emacs 的作者 Stallman，MIT AI 实验室之前出来过 63 年开发出 Scheme 的 Guy Steele, Sussman、John McCarthy、算法领域的 CLRS、密码学的 Diffie-Hellman、创造了 RSA 的三个人、第一门被广为使用高级程序设计语言 Fortran 的设计者、C89 原型的设计者 Ken Thompson、Dennis、BCPL/CPL 的理论家、组合子领域的 Moses Schönfinkel, Haskell, Church, Kleene、各种逻辑学家/数学家、在二战时期破译纳粹密码的人、还有在各种人们生产生活中改变了世界（比如各种网络层上应用的东西）的那些了不起的程序员发明家，Alan Kay、C++ STL 的作者 Alexander Stepanov、Aaron Swartz、Python 之父、James Gosling、Matz，他们做了了不起的事情，也有自己身上发光的地方，不都值得被崇拜吗？

中国有句古话（🐸）叫做『美人在骨不在皮』
同样的，这些人不仅仅是有着在业内行外都让人瞩目的成就或者广为人知的事迹 — 但不止存在这些，还有他们所伸张的东西，他们的信仰、他们技术上的创意、他们的影响和美德，这和『肤浅表面』是无关的。概率，不能说明事情本身。

都说宗教有信仰自由，喜欢 Linux、P2P、Freedom、各种『小众』文化的人，在优秀的程序员里其实也不是少数，为什么就要和这点信仰过不去呢？

信仰也是上进的，是因为你的认同，因为你也想过或者要做同样的事情 这是一种坚持

有人看不起那些崇拜明星的人或者喜欢年轻娱乐圈『小鲜肉』的人，觉得他们就是看个脸皮，就这个问题我保持中立，但是，如果是对那些真正的『前辈』，做过了不起事情的人 难道『认可』『共鸣』甚至『崇拜』 就是错误的吗？
崇拜是你的自由，不是所有崇拜都是类似宗教信仰一样的无判断 完全服从的崇拜。这个博客作者的观点和视角真的令我非常折服。
希望大家在评价前，记得三思哦~

如果你有理由，为什么不能敬仰 ，只要你觉得他们很好、你认同他们（虽然这显然不怎么样...）、或者你希望自己能够做到他们的某一个发光点，在保持客观公正评价的同时，对他们有应有的尊敬甚至崇拜，有何不可。

反而是没有所敬仰的人才是很可怕的 — 因为这可能意味着你『目中无人』 — 甚至是危险的，因为这可能意味着你的见识还不够，你不知道有那么多有比你强、比你，不知道他们到底有多 NB，你们之前的差距有多大，容易使你膨胀、容易使你自满、容易使你停止那一点好奇的脚步，阻止你真正的进步，甚至使得你目中无人、自以为是地去做一些 会觉得是黑历史的事情 — 太危险了！

最后关于这个 @drakeet 崇拜王垠呢... 自然是很有理的。我没有自己打脸，但是我只是批评了他『崇拜』的表面，我上面发的还真就是『自以为不一样』 — 你看，(1) 不管我看不看王垠的博客，首先我是有在做他讲的那些理论的，这一点有实际编程经验可以作证（Kotlin Lime S-exp 编程语言、FP.js、FP.js 的解析组合子和 DefLang、MonkeyVM、LLVM 的代码生成尝试、Haskell BinOps、C++ 实现二元操作解析器 什么的，宽泛的类型理论我也有讲一些）
(2) 我“转发”一些崇拜的人的观点时，总会加上自己的看法，我不为崇拜而崇拜，我真的是非常看得起他们的某些发光点（虽然有贬低别人抬高自己的嫌疑，说明白话，但 drakeet 对王垠的崇拜，我从来没见过他有着实地去实践王垠推崇的东西，也没见他公开品读王垠的文章，我还不知道他究竟是喜欢王垠哪一点，并且在绝对有实践时间的前提下，他也没有去真正耐心阅读王垠的文章，这种文章是需要看三遍以上的。）（我觉得，如果他真的看懂了，开个玩笑，以他的性格一定会立刻到处发布，为那些引用有意思的信息 拍案叫绝的emmm）

至于为什么共鸣呢？因为我之前也拿『深度』和『广度』去比喻一个人的『技术层次/水平』（真正的相同观点不止这一处），即使之前我都不知道这个作者居然和我的观点有这么多相通之处。因为观点相投，所以（我个人）觉得作者真的很优秀。

https://coolshell.cn/articles/4235.html #coolshell （翻译文

与此同时，我们所有的人都在相互地克隆和模仿（译注：参看中国的C2C）。你需要一个Java程序员，我是一个Java程序员，你也是一个Java程序员，我的邻居也是一个Java程序员。我们之间有什么差别？其实，基本没有差别。好吧，我有一些jQuery的经历，太好，所以，你知道怎么来做一个折叠式的菜单？当然，我可以Google一下，然后剽窃别人最好的代码给你 :)

中国编程抄袭之风的确是 🌚

#\№你不知道你不知道的

这个世界上有几十亿行代码可以被 几百万行更快，更清楚，更简单的代码所取代，因为无论是谁来写，他都不可能知道他所不知道的东西。

非常赞同这个观点，我自己就是这个理念的真实例子

我怎么就只知其一不知其二呢？...？到底是不知道技巧，不知道还能有这种变换方式
我怎么就看不到 100 = 1 * 10 * 10 呢？

怎么得出这个简单的结论，由此写出比别人短十行好看十倍的代码，这才是简单背后最复杂的事情啊！

人和人之间的差距到底是什么，就叫理论大佬列几个式子让学生写、FP 大佬列引两条式子，费三四分钟写一行、OI 大佬想一分钟费五分钟写七八行 pass、你断断续续想半天，最后写十分钟改两分钟，最终成品四五行、小部分人想五分钟写十分钟暴力查错二十分钟弄出来十几行易错/难维护/难看懂/低性能的代码、绝大部分人想半天觉得莫名其妙，查下资料抄过来解决，找不到就玩完了、少部分人，完全写不出来。

—

和高手在一起工作真是超爽无比。你也许以前经历过，他们每说的一件事总是新鲜的，总是有意思的，你能从他们每一行的代码中学到很多小技巧，你几乎可以感觉到你的大脑在不断膨胀:)。

大佬们真的总是非常有趣的，你看我实现 Lime 的时候、我写 FP.js 解析组合子的时候、我写可动态二元优先级的 infix 链解析器的时候、我写 SIMD /并行计算的时候，哪个的初始原因不是看到了大佬在做，然后我了解理论后，也手痒写了类似的？
如果不是看到了类似冰封哥、Sleepwalking 这样的真·天才（不要欺骗自己了吧，『明明他们的努力也看在眼里呢』），知道自己到底有多菜，我恐怕不会像今天这么谦虚（迫真）了。

“很多时候，你缺少的不是知识而是热情”！

我也 echo 一下

https://coolshell.cn/articles/3005.html #Java
对 JavaEE 的复杂化讽刺的很好.... 不得不说，这个例子里对设计模式的使用的确非常无聊，什么 DirectoryFactory, Directory, Descriptor, Service, Model Factory ServiceLocator, Model Factory, Model, Bean getter, Context... 我去... 起一大堆有时候还真是不必要的名字，到处『松耦合』... 我都快记不住这些名词了，什么 Adapter、什么 Strategy、Facade、Command... 尤其是 Adapter 什么的，起一个莫名其妙的名字，真的有必要？ loadFromFile / writeTo(OutputImpl) 有这么困难？为什么非得取个带设计模式的名字？ Kotlin 的 『Singleton 模式』就是一个 object Simpleton {}, 模板双检锁 Singleton 应该被视为耻辱，而不是了不得的见闻