内啥……弱弱的给自己的项目打个广告，四月可能有重要更新：gradual typing 。
https://github.com/ufo5260987423/scheme-langserver

@charlie21 #27
1 、你跑题了；
2 、你对于函数式编程的理解我持保留意见。

@InkStone #24
我提一点，不是从历史沿革开始写，而是抓住最根本的问题，从工程直觉开始写。这就有几点要抓住：

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

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

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

以上三点的关系在于要把直觉放到第一位，能把握住更多的直觉，就能够降低后面特别是第三点的难度。

@yuruizhe #17 它们不是偏理论，它们只是没涉及工程直觉。
或者这么说吧，它们的关注点是帮你补充知识的漏洞，是告诉你怎么做，而不是告诉你为什么这样做。笑。
这是这类文章必然采取的形式，但是不是一种直接作用于工程上的好的形式。而我想要讨论的是后一种。

用了十年 ubuntu （ from2012 ）
工作环境其实用 wps for linux 够了；打游戏 steam 上的游戏大多数都够了。
很多人讲 windows 不可替代，在某些税务和办公系统的确是这样的，但是越来越少。
唯一给你一个建议就是，ubuntu 不要用最新的 LTS 版本，要用上一代的。折腾起来文档比较多。

@mumuy #67 哈哈那应该用一堆小种语言来写项目

@andyJado #22 一个文件有几万行……用 vscode 打开都没法语法渲染了吧……
1 、我现在是按照文件更新的；
2 、如果一个文件几万行，且 10 个函数，那一个函数平均几千行代码，笑。
3 、我不能确定你的修改是否只对函数内部的语义有影响，如果你确定的话，把更新索引的粒度下降到函数也是可以的。

笑，你的困难我都遇到过，还是前置知识缺课的缘故。
以及，如果你以后想要进一步研究 static analysis 的工程实现，可以 github 看我的 scheme-langserver ，master 分支前天刚推了 deductive inference system 上去。笑

@BrodyYoung #64
计算机领域很庞大，具体学习哪个方向你要自己找，找的时候遵循几个原则：
1 、兴趣为王而不是挣钱为王——大家都想挣钱，但是能让你挣到钱的是你的独特的价值。尊重你自己的兴趣，在长达十年的时间里面不要放弃，一直投入，总能有一点起色的。
2 、多看看别人的好的项目，你看的多了，自然就知道什么好什么不好。
3 、国内的开源很多是产业和资本为王，但是当下的裁员潮已经证明了他们的道路走不通。回归程序员自身的需求，回归人民的需求是很重要的一个出路。具体怎么做，自己去想，不想和瞎想都是死路、邪路。

我自己现在注重的领域是计算机语言学（区别于计算语言学 computational lingua ，英文好像是 Computer programming language ？），这个领域在国内据说只有清华和南大有专业方向，一方面说明就业市场小，另一方面也说明门槛高。但是我自己觉得里面的知识工业化应用其实也就那样，挺简单的。2010 年的很多博士论文其实很简单，现在我们仍然可以追踪发展进度，并且把一些东西产业化。而且，产业应用中的一些东西在学术界思考的比较少，还有很多可以突破的方向。

我自己曾经研究的领域是 NLP ，emmm 也就是几篇论文而已，可以灌水养活自己了反正。
------
计算机语言学的话，可以送你几个思考的方向：
1 、如何用逻辑编程减少 bug ，这方面可以从 miniKanren 那边学习一点歪招。如果能通过比较麻烦的编程，减少 bug 和 debug 的精力，对于很多领域是有用的。比如汽车和飞机，总不能一边飞行一遍 debug （笑）。
2 、一些 api 系统的 request 之间是有语义关系的，比如必须先执行某个 api 再执行另一个，这是一个 DSL 的系统。也可以做一点小小的工作。

@dnsjia #62 给大佬点赞。

@BrodyYoung #60 囧，你这个 github 表演痕迹太重。
给你几个关键词，楼上请自己翻一下：
1 、没 fork ；
2 、弄了一堆 spring ，netty 之类的东西，点开一看，就一个 initial commit 或者“整理代码后提交”——这™有 50 多个 star ？可见你项目的 star 的质量就比较低。
对于一些经历和我类似的面试官而言，repo 来自 v 站的浏览量与 github star 的转化率大概是不到千分之一。你的项目可能有一千人访问过么？我觉得不可能；
3 、你的 readme 完全没有一个对大家开放的思维，连简介都称不上。没有开放的思维，很多情况下就是肚子里没有东西。
4 、我看到了很浓重的培训班痕迹，这是我的臆测，也许你只是参考培训班建立了自己的知识体系。但是对于搞开源的人来说，我们恰恰最不需要的就是那种体系。

我这话说的比较重，因为我也做后端（但是我不用后端程序员定义自己）。从我的角度看：表演式开源要不得。笑。

@dayeye2006199 #58 2333 你这样说，我老脸一红。

@moonrailgun #55 向巨佬致敬。您的项目完成度很高，您关于“通过解决开源项目遇到的问题，这种解决问题的思维我想才是真正的加分项”我完全赞同。
实际上简历上所有的东西都应该有这样的倾向：怎么解决困难，关键点。而不是罗列项目经验。但是很多时候我看别人的简历，都没有这个意识，奇奇怪怪。

@SonnyBoi #51 你这样的话其实等于……没有对你 folk 的代码做出贡献，明白我意思吧？
就是你用了人家代码，但是你的修改不是在人家的代码基础上，这其实是一个单向获取过程。这个过程我无意评价。
不过你做论文用到人家代码，如果论文能公开并且标明用了哪些代码的话，其实我觉得简历效果会更好。

@boris1993Jr #49 感谢你的回答。果然我还不是自宅警备队一员，完全不懂什么 A 岛 2333

@mumuy #35 仔细一看你这太大佬了，66666 ！
你们前端 star 太多了，我们这个小门小户的领域也就是搞搞 Program language 的解析啥的，不能和你们比。

@lyhiving #39 怼的漂亮 23333 ，强势插眼等待更新。

@boris1993Jr #43 强势插入你们的对话（笑）；
你那个 XoW 看起来挺好玩的。就是……X 岛是啥（笑），以及 UWP 是不是以前用来做 windows phone 的那个东西？这玩意儿现在还在什么地方用？
请不吝赐教。

@xiaojun1994 #45 我不是大佬，我可能只是混的时间比较长跟不上你们的节奏 2333