大家读的最好的技术文章是什么样的?

2023-03-23 08:50:49 +08:00
 ufo5260987423

最近打算写一系列博文从工程上介绍 type inference 的实现机制。 如果有熟悉这方面的朋友可能知道,这部分文章国内外要么是学术掉书袋,要么是梗概概括性质的。很少有从工程的直觉去写的,中文互联网有其少。

基于此,我打算按照这样的逻辑去写: 1 、广泛引用我看过的“掉书袋”和“梗概”,按照他们可能的工程实现思路去组织文字,而不是按照他们使用的语言或者理论去组织。 2 、使用对比的方式,从多个层次指出实现机制在工程上的具体区别。 3 、让读者能够自行编码去尝试。这个方面由于我有一个开源项目scheme-langserver,可以让读者顺着我的项目去理解,甚至能够提交 request 实现读者想要的特性。

因此,很重要的一个方面是:大家读过什么好的技术文章,请把网址发出来。最好同时说明它在什么方面的特点让你觉得印象深刻。

5720 次点击
所在节点    程序员
31 条回复
mascteen
2023-03-23 12:46:52 +08:00
确定主题 确定结构 填充内容 反复修改
ufo5260987423
2023-03-23 13:16:20 +08:00
@yuruizhe #17 它们不是偏理论,它们只是没涉及工程直觉。
或者这么说吧,它们的关注点是帮你补充知识的漏洞,是告诉你怎么做,而不是告诉你为什么这样做。笑。
这是这类文章必然采取的形式,但是不是一种直接作用于工程上的好的形式。而我想要讨论的是后一种。
getadoggie
2023-03-23 13:34:22 +08:00
@tigerstudent 对的,就是这篇😂
InkStone
2023-03-23 13:57:30 +08:00
我感觉最好从历史沿革开始写,讲清楚每个步骤引入之后的变化,但不要过多采用比喻之类的手段,还是要落实到实践上。

同时把笼统的原理和过于具体的实现细节分开讨论。

没有例子可以举,这是看别的体系的书得出的结论
liuzhedash
2023-03-23 14:00:22 +08:00
vimtutor
ufo5260987423
2023-03-23 14:14:51 +08:00
@InkStone #24
我提一点,不是从历史沿革开始写,而是抓住最根本的问题,从工程直觉开始写。这就有几点要抓住:

1 、问题随时间演变,所以解决的方法也要变——但是工程直觉,所谓面多了加水水多了加面必须要写清楚,这样读者才能意识到,在直觉背后,自己缺少什么知识。

2 、工程直觉不能直接解决的问题,更多的呈现为某种技巧。不能假设读者自我发明这些技巧,而是要假设读者如何通过其他领域的工程直觉层层累积最后捅破窗户纸——这就要在叙述上有重点地去叙述。

3 、叙述上的重点包括应用场景、案例、以及思考过程的三个约束:逻辑链条长度,知识积累,和语言技巧。这里就响应了您关于“比喻”、“实践”和“细节”的问题。

以上三点的关系在于要把直觉放到第一位,能把握住更多的直觉,就能够降低后面特别是第三点的难度。
charlie21
2023-03-23 16:04:45 +08:00
“函数是一等公民”背后的含义
https://blog.leapoahead.com/2015/09/19/function-as-first-class-citizen/
直接聊清楚了纯函数为什么好测试(因为没有副作用),JavaScript 与函数式编程

此外,它预测到在推广一个 library 的时候,如果它在突出自己的纯函数概念,那么这个库给人的感觉就是它会 “非常好学”:借由纯函数概念,它十分容易建立起一个十分简约的心智模型。这种 “简约” 的感觉仿佛写 java 者 见到 Stream API ,写 C# 者见到 LINQ:这些函数式编程的应用一旦出现在 SDK 里它会带来一种 “解放大脑” 的感觉。

然而一个依赖纯函数概念而变得流行的库,这种 “流行” 即流行度的获得呢几乎是一种 “作弊” :纵使它所依托的纯函数概念十分精巧,但从根本上看,在观察(抽象的)函数式编程本身的时候(如上文所示),上文的结论之一就是任何纯函数本身几乎是没用的 —— 除了测试起来好测、因为没有副作用所以写起来爽、“听起来好听” 这种心理因素

精妙但无用!
软件工程本身的复杂度、如何控制复杂度,难道就能被一句 “纯函数没有副作用” 就能抹平的吗?做梦
软件工程关注点在哪里,这是不变的,也是一个人不能逃避的。简言之,作弊的甜头是会让一个人退步的

即使你用了纯函数主打的库,你也可以写出一个难以维护的项目:是的,这个库就是依托纯函数概念的 react.js 。或许可以这么说,正因为在进入一个纯函数主打的库的生态里(即 react.js 生态),所以一个难以维护的项目是更容易诞生的。

而且 react.js 本身将会如何变得臃肿是难以想象的!按照函数式编程本身推算,函数式编程只适合写工具类,而那些函数式编程的应用 比如 Stream API 和 LINQ 也就仅仅是工具类,它们是好工具,好就好在它是死的。而 react.js 是还在不停推出新版本的,它想干什么?

而如上文所示,如何管理状态 / 副作用 / 复杂度,本身已经不是纯函数编程关注的重点了。在那个氛围里绕了一圈的人们将会回到起点
ufo5260987423
2023-03-23 17:54:28 +08:00
@charlie21 #27
1 、你跑题了;
2 、你对于函数式编程的理解我持保留意见。
LXGMAX
2023-03-23 18:18:56 +08:00
微软的.NET 文档,真的想教会我使用
反之 Google Android kotlin 文档看得一头雾水
FENebula
165 天前
@ufo5260987423 这里的“工程直觉”是不是可以理解为对问题及其外延,在一定程度上通用的 know-how ?
ufo5260987423
165 天前
@FENebula #30
是 know-how-to-know
或者用搞哲学的那帮人的话来说,是认识论。我们做工程的,即使有的东西不知道,但是根据我们的经验我们必将知道。
wir muessen wissen, wir wuerden wissen.

举个例子,我做 scheme-langserver ,写了一个 DSL 用来做类型推断——在这个过程中,我重新“发明”了 gradual typing,soft type 等技术——当然最近写文档发现,其实学术界早就有了。但是他们的过程和我是完全独立的。

我在理论上有很多欠缺,但是不妨碍我在工程上有办法弥补,这种办法很多情况下就是靠直觉的。也就是靠我所说的“工程直觉”。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/926400

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX