搞清楚一个概念：
骂人甚至杀人的权利可以说人人都有，毕竟我们不讲究广义上的犯罪预防。
重点是做完事之后的后果。
直接、可能、间接、长期利益伤害包括但不限以下清单：
收获所有人的鄙夷。
收获较差的心情和脾气。
健康得到恢复（发泄）或者得到损害（负面情绪）。
收获作者的律师函或者法院传票（没错，骂人也是需要承担法律后果的）。
作者心灰意冷，失去项目的更新维护可能。
收获糟糕的性格和人生（毕竟行为产生习惯产生性格产生人生）。

列表或许不止三米长，但页边没有足够的空位所以我也就不继续列了。

上万年的文明历史，所有社会都不约而同认为合作和鼓励是正面的，骂人打人是负面的，绝不是巧合。
想清楚后果以后，还想骂就去骂吧。反正嘴在你身上谁也管不着对吧。

个人认为：
1，在优异的 Home 键交互设计下，iOS 的小圆点真的是个渣渣一般的功能。
2，阅读圆点的初衷是暂时性的延后阅读，然而小圆点的交互体验和 UI 表现真的是个渣渣一般的设计。

把保留字和注释放在一起统计显然不公平啊。
另外，按照 java 规范的尿性来说，漫长的命名应该按驼峰拆开以后分别统计嘛。

@silencefent 看到三个爸爸我差点噗出满屏来，直到我被告知还有一个品牌叫做四个爸爸。。。http://www.fourpapa.com/

看到远大于进来的，我袖子都撸起来了你跟我说这个？

开放本身没有错，开放是吸引力，开放是创新之源，开放是避免同质化的途径之一。
但窗户打开，难免就会有苍蝇进来。关窗吗？自绝之路。正确的做法是完善从线下到线上的安全体系、监测体系、事后惩戒体系。
windows 占了你说的多少个优点？开放、一堆 Undocumented、蛋糕足够大。win 的生态也确实足够糟糕的。那怎么办呢？

一句话之内判断是不是推销。
如果是，不挂机放桌上。

我觉得影响不大，和办公室同事们也一直很融洽。
直到有一天，GM 改了一下参数，眼神和意念可以造成物理伤害。
现在我坐在轮椅上，跟你谈一下中华美德中谦谦君子表里不一的问题。

空间？空间是最不值钱的。4T 硬盘搞起。
比起这个，干净整洁、管理成本低、冲突概率低、索引速度快。。。各种收益都比空间要大得多。
而且，一般人手里也不会有那么多份项目在活跃，不活跃的项目尽情打包、存档、放服务器好了，并不占（你的）空间。

什么你是搞 python 的？ python 依赖环境才多大啊，我居然浪费这么多口舌解释空间的价值问题。
我还以为你搞 java、搞 node 呢！

对不起可能您与我司的数据分析岗不太匹配，
但我依然发掘到了您的一些闪光点，只要是人才，我们求贤若渴。
请问您是否会考虑我司的销售岗？

宽于律己，严于待人。

大项目用小框架——核心紧凑，结构稳定，定制化灵活。
小项目用大框架——练习，探索，充分预留发展空间。

大人用小碗——慢食，轻食，避免过饱，优雅，从容。
小人用大碗——长身体，男子汉气概，方便折腾。

如果装逼需要，类似的扯淡道理我可以编出一箩筐。
————————————————————————————
另外我还发现一个现象，一句话，不管它携带了什么信息，只要携带以下不同寻常的特征：
数字浓缩：五讲四美三热爱、八荣八耻、一带一路
对仗：空谈误国、实干兴邦
押韵：要想富，少生孩子多种树、人有多大胆，地有多大产
反常理：宁要社会主义的草，不要资本主义的苗

那它就是一个成功的 slogan，容易被不明真相的群众相信、传播、解读、崇拜。至于其价值，倒是次要了。
————————————————————————————
话说回来，有没有业界调查，关于现实项目中
大项目用大框架，小项目用小框架
vs
大项目用小框架，小项目用大框架
的统计对比数据？

没想到楼里这么多拿 demo 说事的。。。不是自我阉割就是法盲。
白天讨论别人“擦边球”，晚上抓起枪就突突突的吃鸡，知不知道杀人是死罪？双标玩的溜。
其实他们都未必意识到自己双标了，而仅仅是“赌博会被抓碰都不要碰”和“这么多人吃鸡都没事”两个浅层事实简单相加的结果。

@just1 所以说法律认定标准在哪里？要件有哪些？
主观上是否以营利为目的，客观上是否具有聚众赌博、开设赌场、以赌博为业的行为。对于虽然多次参加赌博，但输赢不大，不是以赌博为生活或主要经济来源的；或者行为人虽然提供赌场、赌具，本人未从中渔利的，都不能认定赌博罪。其中情节严重的，可按《治安管理处罚法》有关规定处理。

不要老爷说什么就低头认怂，好歹争一口合理合法。

中午是什么？不都是 12 点吃外卖吗？

首先，先搞清楚你把数据加载到内存后打算干吗。
这坨数据就是比你内存大，和格式无关。哪怕它是再精简不过的 bin 格式，哪怕我用 c，都无法解决 8G 内存读取 800G 数据的矛盾。
唯一的出路，就是根据数据格式和需求确定解析和计算模式，部分解析，部分计算，分治然后汇总。

建议的几种读取方式：
1，SAX 了解一下，事件流驱动的 xml 解析思路，搬到 json 上毫无问题。
2，切割原 json 文件，给它补上恰当的开始、关闭符来确保结构。
3，自己实现解析器，最 low 的状态机实现起来很简单的。然后一边解析一边处理一边丢弃。
4，如果 json 数据有某种特征，预处理一下。（比如结构体其实不复杂元素也不多，但里面有个字段的值超大，那么先文本处理 json，把这个字段抽取出来形成外部文件，json 内只留个文件名索引）其实很多超大数据集要么结构简单只是数据条数多，要么条数不多但单条比较大，很容易做针对性处理。

sep 参数支持正则表达式。如果你的分隔符和字符串能用某种正则来做区分，那可以把单纯的"|"字符替换成正则来做分割。
第二个问题，这确实不是合法字符啊。最好是搞清楚来源是什么。很有可能是读时就读错了，最好解决掉。否则这行数据有可能是脏的。