一向直接 TortoiseHg 和命令行。SourceTree 也就多点 git 支持，然而基本上也就这样。之前还有一些其它坑问题，具体记不清了（好像跟远程有关），就没接着用，反正 git 命令行再沙雕常用也就那么几条。

聊天记录这个地图炮吧，QQ 的聊天记录备份和搜索性能的问题上更想腾讯飞○。
（不限 IM 的话，Outlook 之流的也一般烂。）

@123qqqqqq 没付钱就不能吐槽了，什么逻辑？逼我付出机会成本，甚至我不本来不想用结果直接被随大流，还不能骂？
往大了说，我还嫌弃抢占市场劣币驱逐良币透支蓝星文明未来呢——好吧，区区个微信确实不配这个帽子，上纲上线太浪费了。换个例子吧，我说 Web 比起 Project Xanadu 各种意义上（包括让你只知道 Web ）就是翔，不服？

这是跟投资人、项目经理、产品经理、设计、市场、人力资源都有仇么，就这么咒这些人被顶岗？

好吧，即便做到了，更流氓的也有，比如说某几个厂搞驱动要特权的……
区别是这些东西掰个指头也数得出来，而且至少也没法偷偷摸摸自启就是了。
……不是很懂你们移动设备的所谓“生态”。

这锅还真不是个别厂商的问题了，大概比你们想的更大……
讲白了还不是什么 app lifecycle model 惯的，不给个退出的 UI 都能振振有词了。
要是一贯直接暴露进程给用户（系统管理员）看谁还敢跳。

@oma1989 一公顷=10000㎡，一打=1dozen=12，一提是指 6 听易拉罐吧……虽然有愣了一会而是不是 1twip。
@occam88 666.66㎡那个是一亩……因为市制单位不是十进制一路货反而印象深刻。（类似地，“一丈”）。

敏感性这个因人而异。不过就已经被接受的术语来看，大多不至于难以辨别。被吐槽最多的还是引起歧义和误导这样实际上容易直接引起交流障碍的例子，包括你所说的重名——这里一个总的原则是实用性：发明术语首先是为了沟通和交流的需要，而不是为了显得表面上的若即若离的构词巧妙和其它什么有的没的装×理由。（反面教材：“堆栈”“鲁棒性”之类。）
另一个观点：如果术语的选用各有优劣而无法决断或者避免冲突而退让（比如 memory 为了不和 storage 冲突而被迫翻译成“内存”，尽管原文经常压根就可能没“内”——“在线”的意思）倒有商榷的余地，但明知有一个各种意义上都明显优于其它的情形还刻意要用不合适的替代，那就有问题了。历史习惯在合理性上占一定地位，但同样地基于实用性原则，我的判断是不能以辞害意。因此就 endianness 这样的情况，我虽然可以接受两者，但使用倾向是很明确的。
往大了说还有两点：
1.按照目的优先顺序排序这是个普遍的工程选型的策略，而不只是关于翻译的问题。这里的原则我能很容易地一贯地保持，而要在个别翻译问题上搞特例就太麻烦了。
2.应理解自然语言本身受到语言习惯的影响的现象，但也不是说就该从俗从众。这里方法论和上面的一致，首先还是看理解：越无知的，越无权判定内涵——而不是看“历史”“习惯”，“谎话说多了就是真理”。当然有个现实是……歪曲成语和念白字的太多了，搞得语委都怂了……如果无法达成一致，原则性的下场就是这样的说法直接剔除出语料库，而不是妥协。而小圈子的领域特定术语就可以有更激进的策略：对原意的解释权从来就不该在 dssq 的大众上——否则效用就极其可疑：发明这样的术语意义何在？要是向以讹传讹退让，真正有需求的涉众对语言使用的实用性何以体现，靠迫真制造新词来填坑？（例：“打 call ”。）

实用的自然语言的可编程系统也就个别专家系统能够负担，通用的设计据我所知都不存在。
所谓英文编程基本也是 YY 出来的——从英文里拿了几个单词的玩意儿就好意思叫英文了？
大部分中文编程的逻辑类似。

@shijingshijing 你也说了你了解到的这些是指 architect 的工作，而且还特指“一个大型公司一条大的产品线上也就一个”的这种（老实说就你说的项目里其实我确实不太信就只有一个人能叫 architect，这不符合 BP 吹水的普遍需求，对 HR 工作也不利），但标题里“找到一份基础架构方面的工作”和“感觉如果能够找到一份 infra 方面的工作对于技术成长会很好”和你说的差太远了吧。走 individual contributor 也并不矛盾啊。

以身作则，不作不死，是鉴。

@af463419014 你这里有明显的误读。
1.文本编码问题即便在历史上有影响，例如输入和输出转换的问题，但现在已经有完善的方案解决，不会引起设计的困难。
2.作为单位的 byte 是由具体语言规定的。ISO C 和 ISO C++中 byte 以 character type 定义，具有 CHAR_BIT bit，其中 CHAR_BIT>=8。
POSIX 进一步限定 CHAR_BIT == 8。Java 等一些语言也直接假设 byte 具有 8 个 bit。大部分实现也符合这样的假设，以至于 byte 被不严格地作为 octet 的替代单位。但这不是 byte 的本来含义。
作为反例，原版 TAOCP 的 MIX 使用 6bit 作为 1byte。
3.ASCII 是 7-bit encoding。
4.编码转换上的歧义本质上只有字符集表示上的原因，可以使用字符集并集解决。现在一般直接使用 Unicode，约定外部编码为 UTF-8。
5.所谓的英文编程跟 ASCII 基本无关。例如，ISO C 和 ISO C++约定的 basic source character set 并没有涵盖整个 ASCII，事实上也有用 EBCDIC 的实现。而 extended source character set 早就被提议支持 Unicode 的特定子集了。前几天还有见过#define emoji 乱飞的……

自然语言在表达精确含义的技术要求上通常是劣等的，因为：
1.具有太多没有被清楚认知的歧义现象。
2.包括歧义在内的文法性质通常不是人为有意引入的，而是演化上自然存在的。或者说，缺乏正向的“设计”。
3.对演化路径不甚了解，连文法理论的框架基本目前都在逆向的过程中，没有严格公认的构造能写出 spec，且进展缓慢。
作为典型自然语言书面语的中文符合所有这些问题。所以整体上这样的方案是不靠谱的，并且其投入产出完全不成比例——要想达到和人工语言类似的可靠性，基本就顺带先把中文相关的 NLP 问题解决了。现实证明，这个比设计可编程系统的难度要大得多。

嘛，其实一般来讲翻译的整体语感因人而异吧。我觉得 k-means 这个和 knn 的中文说法还是比较符合惯例也没疑问的，虽然可能因为我也不常看这些原文所以反而不太会有这样的障碍的原因。
不过有些是确实明显应该发现问题的。这里面还有不同的情况。
第一类，一些翻译非一一对应的同义词，如 order 和 sequence 这里虽然中文都是“顺序”，但是含义是有差别的：前者强调“有序”，后者强调“序列”。如果了解原文，同时又是中文母语使用者，这些应该不难明确，并不需要翻译家的程度就容易明白。这些都是影响非常广泛的常用构词单元，至少对技术人员来讲分辨清楚不该算是苛求。
另一类是翻译构词不当。我举例说的“堆栈”，就是偏义复词在翻译上的滥用。这样的翻译明显很糟糕，因为“堆”和“栈”偏偏就是有明确所指的两回事，所以至少回过神来真清楚原始含义之后，就应该容易认识到翻译容易引起误会问题而辨别出什么是不恰当和应当避免的。因为陷入为主而坚持不恰当的翻译，一定程度是不可理喻的。
第三类是更复杂的，就像 endianness 和 byte order 这个问题（我另外有回了）——还不只是中文问题了，原文就有洞。
简单来说就是 endianness 这个用典：
1.不太符合要表达的准确的含义（只有大端和小端，而不是和其它序）；
2.而且相当早就被误用了，以讹传讹（既不是大端又不是小端的 PDP-11-endian 很有年头了）；
3.还有更多的歧义（虽然一般是指 byte order，但也可以指 bit order，虽然后者往往用 bit endianness 区分强调）。
所以我在正式场合用 byte order，除非是明确排除非 BE/LE （特别是明确不要求 bit/byte ）的情况。
（类似的情形，应该 octet 的地方就不用 byte。）
如果不是很清楚这档子破事来用，就得推测含义，而每次都要由内行的承担启发式瞎蒙以免歧义的开销实在太不公平。
退一步讲，日常也就算了，至少涉及 spec 的问题我不会退让。
这算是翻译问题上比较复杂的情况了，但我认为仍然有必要推敲清楚——实际上理解上也没多复杂。

另外：
1.我翻了一下叫“逻辑回归”倒应该是有些年头了，维基上词条也就叫“逻辑回归”，醉了……
2.用不恰当的翻译不一定就是啥都不懂，但如果不懂原文是啥的前提下，要只会这样不靠谱的术语还很懂，是不太能让人信服的。因为正常情况下几乎不可避免的会遇到不同的翻译，而且其它翻译明显更好的情况下，一般人都不会固执不合理的翻译不放。所以比较合理的推测是孤陋寡闻，只见过使用不当翻译的例子，也许懂一部分，但不太可能全懂了。另外，要懂原文的，如果遇到翻译存疑，大可直接用原文或者至少说清楚对应的原文是啥，没有道理非用不被对方接受的翻译引起交流障碍。
3.实际工作中，如果发现术语翻译偏差，先约定清楚用什么翻译或者干脆直接用原文不应该造成问题。这类沟通细节上的问题，没必要扣帽子。

@iyaozhen。看到营养跟不上，一激灵莫名其妙突然想起硬盘空间满了该清理了…… 2333