@opentrade #16 哈哈哈老哥你好，像你致敬！

我八年前（别笑，我年纪好大了）也是这样的，你主要是见得还不够多。见多了以后就对自己有数了。
没事儿，年轻人碰壁是好事儿，碰多了要么墙裂了，要么你就长记性了。

@jones2000 #23 老哥和我的想法是一样的。

@mingqing #19 是的，当然有人有反馈的话更开心 233.

@artnowben #18 向您学习。
我的项目也不算 demo 性质的，是可以实际用的。但是领域太小众，估计比较难办。下半年努力大概能找到一个持续使用的行业用户吧。

@matrix1010 #14 另一个原因是 lsp 这类项目本身就 star 偏少啦。

@matrix1010 #14 哈哈哈哈，是的！

@articoder #156 哈哈，要是没有能力验证，也不敢用这玩意儿吧。

@keyv #11 感谢你的回复，加油！

@articoder #154 感谢老哥的回复。
不过我觉得这个平衡模式就离题万里了。type racket 对 r6rs scheme 做了一些超纲的加强。
超纲的意思是说，type racket 加强的这些能够用于构建 type system 的东西在可见的未来不会被加入下一个标准，即 r7rs scheme 。
这样的回答还不如原来呢 2333

@enchilada2020 #9 我觉得你需要和#5 讨论下 23333

@keyv #7 感谢你的回复，我能从你的回复里面得到很多东西。
你后来有再从事相关工作或做相关的开源么？

@pengtdyd #5 我完全同意什么学习资料就不要往简历上写。
不顾不足 1k 的 star ，就不硬核，这个标准是否有点武断。不考虑领域背景嘛？
纯粹求教。
毕竟在 language server protocol 这个领域，很多学术界的探索项目 star 数量也不多啊。

@cbdyzj #2 所以你会看什么？那种八股的肯定是看都不看咯。

@enchilada2020 #1 所以，怎样成功的项目会让你觉得是绝对性因素？嘿嘿

之前请同事帮忙测试了一下（用 new bing ），我的结论是：它能准确理解我要检索的东西，检索能力达到我的 85%以上。但是对于互联网上不存在的东西，它也没什么办法。特别是关于 hindley-milner type system ，它找到的是 racket 上我已经看过的一段代码。这让我挺惊艳的，毕竟那个代码隐藏的比较深，不太好找。
结论：面向搜索引擎编程的那部分的程序员会死掉 30%吧，剩下 70%负责把老板的话转述给 chatgpt 或者类似的东西。
https://i.imgur.com/8sDoBHs.png

@voidmnwzp #20 感谢回复。
1.go 这个规定很正常啊，但是不能文件夹里面有文件夹，把结构弄的深一点嘛？因为我对 go 不熟悉（ 8 年前，那时候我还是本科看过一点点），所以就不再评论了。
2.关于目标。一般我们做开源尽量做人无我有，做一些自己遇到的特殊场景。你给自己设置的目标是一个 state-of-art 的场景。也就是说，场景是常见的（似乎是），但是要求太高，一般需要不断做工作打磨才能完成。所以你玩 3a 当然就任务完成的半吊子。而且，为了完成这种任务，不知道你是否采取了一些奇技淫巧——绝大多数情况下这些奇技淫巧是牺牲可读性的，这也就造成了你的现状：看不懂自己的代码。
3 、“总是涉及到好几个模块”这个涉及到本质问题：目标高但是完成度不高，自己又不太写文档和 commit ，功能耦合也高，性能 state-of-art 难度大。

建议：以后写这种项目，不要急于求成一下吃胖子，要把下层结构单个儿写出来做组合。不要怕上层整合不了，大不了重构嘛。你这又不是什么挣大钱的项目，应该有比 python 扔掉若干个大版本重构还要大的勇气 2333
你要觉得自己的项目是 jvm 那种，那倒是有人给你写注释和文档了 2333

@wzzzx #17 谢谢夸奖。

哥们，我看了一下你的项目结构，大概……明白你是在哪里遇到困难了。
我用自己的项目 scheme-langserver （ https://github.com/ufo5260987423/scheme-langserver ）做基准，对你的项目进行一下评论，说的不一定对，请批判：
1 、对于任何来阅读你的代码的人（包括你自己）来说，你必须假设这是一个黑箱子，他们什么都不知道。那么，在这种情况下应该提供一个统一的出入口。对于 c 语言的代码来说，main 就必须要暴露在代码的根目录下的那个.c 文件里。这不是不可以做妥协，而是要尽力抓住这个原则，让人家尽快找到黑箱子的出入口；我不熟悉 go ，你大概率也不熟悉我用的 scheme ，但是我的根目录下面只有 run.ss 和 scheme-langserver.sls ，入口显而易见。你的则看不出来。
2 、代码的目标不清楚，似乎一开始是 tcp 推送的一个 server ，那为什么要有一个文件夹叫做 http 什么的？中间的需求变化了，当然就有问题了。我自己的建议是，利用好打包工具，分包去写。例如我的代码中用到了 match 宏，我是单独写了一个包（ ufo-match ）发布在 akku 上，然后自己随时取用。总之，对于某一个包，完成了最初预定的功能就尽量不要动，要动就肯定是大规模重构。
当然你会问：可是我并不能一开始就看清楚自己想要什么啊。
3 、这就需要你一开始就做好架构设计。什么是好的架构设计，就是架构的不同部分抽象程度足够高，功能重叠足够少。从你的目录结构来看，你这点做的不好。一个文件夹就代表了你抽象的一部分，这一部分下面就那么大猫小猫三两只。可想而知，文件夹命名没有给出足够的信息。
比如 protocol 下面是 pack 和 unpack 两个文件。protocol 是这个意思么？而且 pack 和 unpack 为什么不合并为一个文件呢？
persist ，全称大概是 persistent ？下面一个是 test 文件一个是 db——db 就是 persist 的全部么？
4 、commit message 要么不写，要么就好好写。你可以看到我的 commit 大部分都是 fix 。因为修正的都是无关紧要的问题。只有比较难的我才去稍微认真的写一下。

先评论这些，有什么问题和意见我们可以再交流。