范畴类别思维


这篇文章的灵感来自斯坦福大学教授罗伯特·萨波尔斯基(Robert Sapolsky)的讲座,该讲座略过了一些分类思维的观点。我发现了解软件开发的某些方面很有帮助。

什么是范畴类别?
范畴思维是我们的大脑用来处理大量信息的技巧之一,由此就不需要处理指定对象的每个细微差别,大脑能在范畴(桶)中分离并处理较少数量的对象。作为软件开发人员,我可以假设这种“压缩”提高了处理和存储的速度(最好参考生物学的科学论文以获得更权威的意见)。

当我们必须处理连续信息时,这个技巧特别“有用”。例如,有完整的色彩范畴,但我们倾向于只区分其中的7种颜色。

范畴是一些任意选择的桶。它不一定由某些“逻辑”决定。范畴的选择可以由文化和语言决定,也可以随着时间的推移而变化。回到彩虹示例 - 并非所有语言都有相同的基本颜色词组。例如,俄罗斯和希腊都认为浅蓝色和深蓝色是单独的颜色。专业从事颜色的人如画家可以区分更多颜色(请记住“艺术家与普通人”?)。

相关理念:抽象思维,象征思维,刻板印象,模式识别。

怎么会出问题?
当范畴的选择是任意的而不是由某些普遍逻辑(如数学中的通用逻辑)所决定的那样,那么范畴思维就会导致问题。

1. 即使它们不同,如果属于一个范畴,它们也可以被视为相似:
当我们看相当远的物体a并且b时,且它们确实属于同一范畴,因此它们可以被视为同一类型。

在编程中,这个原则表现为“重复比错误的抽象便宜得多”

2. 即使它们相似,但是属于不同的类别,它们也可以被视为不同:
当我们看相当近的物体a并且b时,但它们属于不同的类别,因此它们可以被视为不同类型。
例如,关于CSS与CSS-in-JS的无限争论。从这些范畴的角度来看,CSS模块属于CSS-in-JS,但它更接近CSS的BEM方法。

3.在范畴中思考存在陷阱,很难看到全局
关注范畴我们有时会忘记暂停并重新评估我们正在处理的内容。
在编程中,这个原则表现为“仪器法则”,例如,如果你拥有的唯一工具是锤子,那么将一切都视为钉子是很诱人的。
例如,关于不同范式的争论,如OOP和函数风格。可以在两种样式中编写相同的应用程序,因此它背后有一些共同点,但程序员争论的是哪个范式更好。

对范畴的理解不同
范畴是任意选择的。当这些选择没有形式的基础时,不同的人可以选择不同的方式,这会引起混乱。
在编程中,这表现为粗略的术语,对于代码没有精确的含义或“品味”。
例如强类型和弱类型,有些人会因为内存不安全而认为C ++很弱,有些人会因为隐式强制而认为JS很弱,有些人会认为Go因为缺乏多态而变弱。在实践中,这个粗略的术语是无用的,必须用更精确的术语替换。

结论
请注意您使用的范畴,并确保您没有被困在一组桶中。
点击标题见原文

更多讨论:
将数学思维应用于诸如物理学之类的真实事物,总是始于领域的一些直觉。通用逻辑将无助于创建有用的定性结构,因此永远不会“决定”范畴的选择。
其实范畴的某些选择无关紧要。例如,我们选择以10为基数的数字,因为我们有10个手指,所以我们选择1 kg的值是基于这样的事实:在正常情况下,水的重量为1000立方厘米。而且,如果选择一些不同的度量方式基本上改变也不多。
由于信息本身是离散的,因此可以选择某些选项,因为可以将离散的范畴应用于离散的想法。例如,我们有奇数和偶数,并且这两个桶完美地描述了所有自然数,没有问题。
当您要描述连续信息时,范畴问题就开始出现了。您选择了一些范畴,但后来却忘记了本质上您是在处理连续的信息,而不是离散的信息。
 
具有适当属性的Unit是一个想法,Unit似乎也不严格属于范畴,因为对于某些东西,具有十进制和小数位数的Unit单元很容易且自然。这抵消了在连续信息上离散范畴思考的“不透明”危险。
还有另一个奇怪的问题,那就是“您如何确定信息在哪些尺寸或轴上变化?” 例如,如果OOP和FP是生活在某个连续空间中的两个点,那么我们如何选择将这些东西放在一个轴中?
因此,我们不仅不知道如何做出有意义的范畴,而且不知道如何描述做出选择的连续空间。
实际上,一维或多维连续体描述这一点的构想与我们在该连续体中做出的范畴区分一样,都是不完善的构造。