我心目中的定义很明确：

抬杠=故意抬高原 assertion 的判定标准使得陈述不再成立的行为。

比如「大家其实都不喜欢抬杠」←这个断言里，「大家都」圈定的范围其实是比较模糊的，在允许语义相对模糊的情况下，我说「都」，可以约等于「在全体人群中均匀随机采样得到的样本空间内，大部分」。抬杠的做法即，由于「大家都」并没有明确指代哪个部分，我现在把精确度标准提高，那么「都」是一个全称量词，∀n(n∈自然人):¬(n 喜欢抬杠)存在反例： ∃n(n∈自然人):n 喜欢抬杠，原断言变得不再成立。

用人话来说就是
原断言：「大家其实都不喜欢抬杠」
抬杠：「怎么能说都，就是有人喜欢抬杠」



因此 「杠」字就是那个「标准」
日常交流其实大部分的「标准」都是隐含的，比如当前这句话的「大部分」就没有指出具体是哪些部分。
当语境不需要显式指出所有标准细节，而又存在一个拎出某个细节试图使断言失效的行为，那么这个行为就是「杠」

我来翻译：

「我会一点 x86 汇编，但是不会调试 vm 语言的字节码，是不是不需要会？」

其实系统自带全盘加密是最好的……
灵活性问题建议分多一个区解决

/t/834415
/t/837270

----

大部分人都会看完内容，但他们仅仅想对内容的一小部分发表看法而已

建议下次 h1 加粗写「仅限对本句观点发表评论」

----

没有 ios 设备，现在 ios 不能用字符组合的复杂密码了？

@lujunliang 模板只有在用到的时候才会实例化，实例化前被剔除掉的话根本不会进入语法检查阶段。 trait 类的所有成员最终只会留下 BaseType**推导结果** 的定义。在这个类里写一个 int a(){return "X";} 编译器都是不管的。所以只把声明留下来不要函数体也可以，反正最后编译器不会去检查这个函数的定义在哪里，只是用声明计算类型而已。

https://godbolt.org/z/vq6hM4534

定义一个 trait 类，其中有一个类型成员 BaseType：
当 T::Base 存在时 using BaseType= T::base
当 T 继承自 SomeBase 时 using BaseType=SomeBase

另外介绍一下这个站：
https://cpppatterns.com/patterns/function-template-sfinae.html
https://cpppatterns.com/patterns/class-template-sfinae.html


我几乎每回重新写 trait 都要来查一下。。

只用神州和 e 嗨，除了贵点啥毛病都没有。

两家都能手机自助开锁取还，e 嗨还有 etc ，app 里还车结算。

我刚开始学写代码的时候能记住 10 多个 C 库函数和几十个 Windows API/MFC 类成员函数，参数不说记得很熟吧，有几个大概是些什么还是比较清楚的

后来呢，接触了 c++ stl / java （ android ）/ kotlin / python / golang / haskell ，写了单片机的工程、嵌入式的 linux kernel 和 bootloader 、golang 的 crud 、vue 的 速成页面、unity 的小玩具 …………


别说什么 API 了，sql 语句我都得翻个文档出来参考。
更搞笑的是， 我觉得 dash 还是比较好用的，但后来 dash 也用得越来越少了，还是直接浏览器 google 文档，因为连 dash 搜索我要打什么前缀都要搞不清了：

https://i.imgur.com/7CpSZnH.png

先建倒排索引呗还能咋的，反正只遍历一次

反正架构方案就要求了前端必须完整存储所有 data ，那我为了加速多建几种用于索引的数据结构谁都 blame 不了吧

函数式的精髓在于「符号演算」，本质上是一些公式代换，所以是在处理复杂对象关系和约束时才比较好用，并不是说函数式就比过程式更优雅，先走出误区。

再说实例。
你展示的一个 getdetail 的过程：
1. 调接口
2. 验证拉取结果
3. 对参数进行「变换」
这个描述本身就非常过程化，有明确的分段步骤，并不存在关系约束的语义，所以用函数式写本来也不适合。

当然也不是不可以，我们换个描述：

1. setdetail 接受「 raw 数据的变换结果」，最终将结果闭包展开，暂时先不管它内部什么样
2. 「 raw 变换结果」可以写为将「变换」应用到「 raw 」上 ← 函数化
3. 「 raw 数据」可以看做将「请求提取子（包含验证子）」应用在「数据源」上←函数化
4. 「数据源」是一个「输入请求类型然后重封装为响应类型的 monad 」←函数化
5. 「请求类型」 由 「请求类型变换子」应用在「请求数据」上得到←函数化


你觉得这优雅吗，我觉得一点也不，还非常麻烦和抽象，每一个「变换子」（即函数）都得绞尽脑汁才写出来，这些步骤也不可能比过程描述要少。


像 map 和 filter 这样的函数已经是函数式最适用的最小场合了，提供一个输入数组和输出数组的约束函数，把这个约束应用在原数组上得到新数组。这不函数化吗，不够优雅吗？

以防后面的人一脸懵逼点进来又一脸懵逼点出去，放个搜索结果：
https://www.jianshu.com/p/122240596c99

woc 长见识了，今天才知道还有这种东西

称得上设计 hacking 了

@devswork

当你 **产品的用户告诉你** 他们有两三个服务中心要冗余备份但统筹管理，你的产品满足不了需求的时候。

而不是「为了方便将来能卖给」 有这种规模的用户而提前用上这样的架构



toC 的话，约等于，「用户没在微博上发网站怎么挂了」，就别用，用不上。

@PerFectTime 你好，个体户要房产证

@yunshangdetianya

> 接口作用就是限制和约束类型

正相反。

静态类型语言的变量，类型是「唯一的」。你可能一下 get 不到有多唯一，我举个自己初学 oop 时对我帮助很大的例子

- 你的程序有两个窗口
- 窗口 A 叫 A ，B 叫<嘎>
- 你给窗口 A 声明了一个类型 type WindowA struct{ Title: A }
- 窗口 B 的类型 type WindowB struct{ Title: <嘎> }

现在你想判断鼠标点击了哪个窗口：

func findWhichClicked(x,y int) (T){}

问题来了： 应该返回什么类型？返回 A ，那么点到 B 这个函数就给不出数据了，反之亦然。
那……返回他们的公共类型？

type WindowA{Window; Title }
type WindowB{Window; Title }// AB 都来自 Window
func findWhich(x,y int) (w Window){}

但还是有问题： 我想获得点到的窗口的标题：

w := findWhich()
w.Title() // ?

做不到！
我永远只能获得 Window 的标题， 不能获得 WindowA 或者 WindowB 的标题。

「这事简直跟我是男人了就不是人了一样荒唐」！！


你可能会疑惑了，那用个公共变量呗

if inA() {w=windowA}
else if inB(){w=windowB} // 类型不匹配！，无法将 WindowA 类型的变量赋值给 Window 类型




------


接口：
type <有 title> interface {Title() }
func findWhichClicked(x,y int) <有 title> {} // windowA 和 windowB 都可以实现 <有 title>
w.Title() // w 可以是任何 <有 title>类型，运行期决定

如果 w 是 windowA ，那么调用 windowA 的实现，是 B 调用 B 的实现。





------


想想这句话： 「我要使用一个变量，它可能代表不同的东西，但类型又得是唯一的」

还速率…… 我甚至都不知道苹果配的那根 usb 线能不能传数据

除了拿来接电源真的没试过其它用途

@herozzm
@OldNio

公司电脑离职肯定会回收的，但有个通行做法是一定年限后所有权可以归你。比如阿里就是 4 年，4 年到了可以选换新或永久保留（鸡贼）。不过用这么久了也都到淘汰年限了，所以你懂的……

公司电脑也不是说就完全不能干自己的事，我还得登录自己的私人账号不是，但另一台 windows 主机打游戏还是很必要的。我和周围认识的所有人都是组一台台式机打游戏，主力生产工具用公司的笔记本，除非有很特殊的需求才会自己再添一台笔记本。

原则 1 ，同一领域和用途的重复持有就浪费了
原则 2 ，在特定领域里使用最适合且最好的