这是一个创建于 72 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近打算写一系列博文从工程上介绍 type inference 的实现机制。 如果有熟悉这方面的朋友可能知道，这部分文章国内外要么是学术掉书袋，要么是梗概概括性质的。很少有从工程的直觉去写的，中文互联网有其少。
基于此，我打算按照这样的逻辑去写： 1 、广泛引用我看过的“掉书袋”和“梗概”，按照他们可能的工程实现思路去组织文字，而不是按照他们使用的语言或者理论去组织。 2 、使用对比的方式，从多个层次指出实现机制在工程上的具体区别。 3 、让读者能够自行编码去尝试。这个方面由于我有一个开源项目scheme-langserver，可以让读者顺着我的项目去理解，甚至能够提交 request 实现读者想要的特性。
因此，很重要的一个方面是：大家读过什么好的技术文章，请把网址发出来。最好同时说明它在什么方面的特点让你觉得印象深刻。
 |
1
getadoggie 72 天前 via iPhone  5
记得看过 tailscale 官博写的内网穿透的原理文章，把内网穿透的原理从头到尾写的非常详细和完整，有条理，给我印象比较深刻，建议可以参考一下
|
 |
4
vivipure 72 天前
|
 |
5
vsitebon 72 天前 2
一种是技术文章： https://pomb.us/build-your-own-react/ 交互式教程
一种是科普文章： https://ciechanow.ski/gps/ 我认为我看过的最好的科普文章（之一，因为这人写了好几篇介绍不同技术的文章） |
 |
6
NessajCN 72 天前
archwiki
|
 |
7
ruoxie 72 天前
最近看的话，是 chatgpt 给的，因为全网根本搜不到，内容：整洁架构中如何使用 react-query
|
 |
8
Kontinue 72 天前
从头到尾能够连贯的讲清楚一个东西的就是好文章
|
 |
9
yunyuyuan 72 天前
谷歌有一篇关于写技术文章的教程 https://developers.google.com/tech-writing/overview
|
 |
10
zhuangjia 72 天前
收藏了，虽然不一定会看。楼主提了一个好问题~
|
 |
11
jmc891205 72 天前
Inverse lithography technology: 30 years from concept to practical, full-chip reality, Journal of Micro/Nanopatterning, Materials, and Metrology, Vol. 20, Issue 3, 030901 (August 2021). https://doi.org/10.1117/1.JMM.20.3.030901
|
 |
12
assiadamo 72 天前
https://draveness.me/
但好久没更新了 |
|
13
getadoggie 72 天前 via iPhone
@boatrain1111 对，当时看的中文翻译版，有分块的目录
|
 |
14
tigerstudent 72 天前 2
|
 |
15
sadfQED2 72 天前 via Android
|
 |
16
wheat0r 72 天前
能把是啥、为啥、咋办说清楚就够了
|
 |
17
yuruizhe 72 天前
|
 |
18
ho121 72 天前 via Android
我认为最好的是 man pages 和 msdn
|
 |
20
samin 72 天前
AWS 官方相关产品指导文档
阿里云官方相关产品指导文档 |
 |
21
mascteen 72 天前 via Android
确定主题 确定结构 填充内容 反复修改
|
 |
22
ufo5260987423 OP @yuruizhe #17 它们不是偏理论，它们只是没涉及工程直觉。
或者这么说吧，它们的关注点是帮你补充知识的漏洞，是告诉你怎么做，而不是告诉你为什么这样做。笑。 这是这类文章必然采取的形式，但是不是一种直接作用于工程上的好的形式。而我想要讨论的是后一种。 |
|
23
getadoggie 72 天前 via iPhone
@tigerstudent 对的，就是这篇😂
|
 |
24
InkStone 72 天前
我感觉最好从历史沿革开始写，讲清楚每个步骤引入之后的变化，但不要过多采用比喻之类的手段，还是要落实到实践上。
同时把笼统的原理和过于具体的实现细节分开讨论。 没有例子可以举，这是看别的体系的书得出的结论 |
 |
25
liuzhedash 72 天前
vimtutor
|
|
26
ufo5260987423 OP @InkStone #24
我提一点，不是从历史沿革开始写，而是抓住最根本的问题，从工程直觉开始写。这就有几点要抓住： 1 、问题随时间演变，所以解决的方法也要变——但是工程直觉，所谓面多了加水水多了加面必须要写清楚，这样读者才能意识到，在直觉背后，自己缺少什么知识。 2 、工程直觉不能直接解决的问题，更多的呈现为某种技巧。不能假设读者自我发明这些技巧，而是要假设读者如何通过其他领域的工程直觉层层累积最后捅破窗户纸——这就要在叙述上有重点地去叙述。 3 、叙述上的重点包括应用场景、案例、以及思考过程的三个约束：逻辑链条长度，知识积累，和语言技巧。这里就响应了您关于“比喻”、“实践”和“细节”的问题。 以上三点的关系在于要把直觉放到第一位，能把握住更多的直觉，就能够降低后面特别是第三点的难度。 |
 |
27
charlie21 72 天前
“函数是一等公民”背后的含义
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 是还在不停推出新版本的，它想干什么？ 而如上文所示，如何管理状态 / 副作用 / 复杂度，本身已经不是纯函数编程关注的重点了。在那个氛围里绕了一圈的人们将会回到起点 |
|
28
ufo5260987423 OP |
Select Language