那得看你炒的是不是大 A

空格可以组成 tab ，但 tab 没法拆成空格。

长此以往空格替代 tab 不是很正常的嘛。

我寻思这不就是 curated 和 blazing fast 的中文版本（

我对协程和线程的理解倒是，协程就像函数一样是有组合性，可以自由组合、混入的。线程就没有这个能力。不过这个视角可能对于自底向上从操作系统角度看进程和协程来说没有太大意义。

想起来我第一次自学 python 就感觉很难，学了 6 次都失败了。

所以还是很佩服一下子就能入门的程序员的。

因为现在的 AI 不是强人工智能。

而且 AI 已经算好的了，隔壁区块链前几年吹上了天现在一地鸡毛，再退一步，企业级微服务云原生分布式管线之类的东西，最后到底解决了啥问题呢？也不好说。

具体是什么样的呢？

以及你的链接里面提到了 zone.js ，虽然我找不到理由，但直觉让我感觉 zone.js 其实是歪路，有点 dirty hack 的味道。

不过只是一个直觉，可能不靠谱。代数效应这玩意都没什么人研究，现在也没有真的用于生产的代数效应框架或语言，所以可能也是没办法的吧。

我对 JS 了解有限，从 PL 的角度讲上下文和传参数你也提到了。代数效应是函数式编程里面解决可变变量、副作用这些问题又不想引入 monad 传染性的思路，那作为不纯的 JS 语言，也许可以反过来用可变变量和副作用来实现本来你想用代数效应做到的东西。。。。不过这似乎又回到 XY 问题了（

依稀记得有道题用 Kotlin 的 coroutine 来模拟 Haskell 的 do-notation 。不知道能不能用 async/await 。。。写到一半又发现 XY 问题在看着我。

然后写完了回过头看也有点不知所云，但也想不到别的思路了（

@SenseHu 这玩意本身也是很模版化的吧，自动化本身倒也没多难

@sillydaddy 确实是这样

@kenshinhu 我自己的项目里面就没什么产品经理可言了…话说过来哪怕生产项目，也总有相对稳定可以提出来测试的部分吧？

@zhouyin 并不会，就像上面有个评论说的，测试本身都是自动化的。我想说的「写测试」更多是说一些测试用例或者构想可能的使用场景，这些东西算是我可以比较容易地去想很多的东西（不写代码的前提下）

@guiyumin 认同，三类代码的划分法也基本上是我的思路

@levelworm 我的理解是这个问题可能比起智商倒不如是语言设计的问题。你也多次提到了「要是他不叫 map 好理解一点」。

也许换个语言会好很多（不过如果是工作要求就没办法）

感觉如果语言本身没有直接提供代数效应支持的话，依赖注入还是很麻烦的一件事情

不过是个 Functor 而已。

或者也许 Python 的 lambda 语法太丑了。要是换成 map (fn x => x + 1) [1,2,3,4] 这不就清晰多了吗。

List comprehension 这玩意能出现的前提是它是个 monad ，按照那个著名的话，monad 得先是个 functor ，换句话说能写出 list comprehension 的东西，它也肯定会写得出 map……这不就变成先有鸡还是先有蛋的问题了。

你说的提升是面向就业（短期，三个月这种）还是出于兴趣？

@Orlion 诶，感谢指路（似乎发现了好东西）

我感觉还有容易断线、断线的时候会一直反复读条加载，还有玩到一半直接卡回桌面。

@letianqiu
@glcolof

打算做的是纯函数式编程，语法接近 ML 系或 Scala 或 Haskell （肯定没那么精简，我也在看哪些语法叠起来相对简单而不那么容易产生二义性）。长期的规划以后再看了，也许可以添加少量 OOP 功能，但肯定不是 Java 的路子。

话说过来 C++、C#和 Java 的解析难度是跟那个泛型标记有关吗？如果从我的路子讲倒是不太用担心这个问题……？毕竟按照 ML 系的类型推导，大部分时候并不需要显式标记类型，类型标记语法也可以设计成避免出现尖括号嵌套这种情况的样子。不过我不确定其他地方是否会遇到别的 LL(1)无能为力的例子了。

@Orlion

手写 LR 也可以的吗？记得都说 LR 语法好像不太适合手写反而比较适合 pg ？但我并不打算现在就考虑设计 pg 的事情。

@ftfunjth

我这边的话，快速实现可能就靠 parser combinator 了，这倒是我原先就有的路径，快速出活是真的快，但这也就回到题目里面的问题……快速写完原型后，这个原型能够长期不断扩展嘛？推倒重写应该还是基于相似的技术选型和路径，而不是说比如今天用了 flex+bison 明天改成 parsec 这样的吧。主要担心的是会不会到头来推倒重做的难度会后期逐步加大，然后语法已经复杂到重构的代价很高昂了。

@qieqie

我没有说「 parser generator 」搞不定我的语法，我想说的是我不太想用 parser generator ，因为不想被技术栈限制或者被 pg 的设计思路所限制（这是以前我遇到过的问题）。

@mahaoqu

也就是说这个问题的回答可以说是「手写递归下降足以覆盖」嘛？明白了，多谢。

@w568w

是在实现自己的语言……目前的进度大概是跳过了 parser ，实现了个解释器和类型系统。大概是计划三五年做出能真的用得上的语言（而不是简单的 toy lang ）。

@jones2000

我做的流程应该相当标准了，只是我觉得其他部分跟我想讨论的话题无关而已。解释器和类型系统我都实现了，但为了节省时间我直接跳过了 parser 步骤手写了百来个硬编码的 AST 树的测试用例，然后现在想回过头复查一下 parser 话题而已。至于中间代码和优化那些又是别的话题了。

用表驱动和高阶函数会比较好