clojure

本文主人公从事软件开发近 20 年，既在大公司待过，也在小公司待过。在他的职业生涯中，发现了很多跟技术选型相关的各种问题：应该选新潮的技术还是无聊的技术？应该搭建极客范的技术栈还是使用基础的工具？应该用开发者喜欢的还是维护起来省事的？他对此作了深入的剖析，希望能帮到你。（多图流量预警！） ​ 我叫 Dan McKinley，坑里的那个人就是我。 我现在在一家叫作 Mailchimp 的公司上班。更早之前是在 Etsy，因为在 Etsy 待的时间比较长，所以后面会更多地提到我在这家公司的经历。其实在离开 Etsy 之后，我也在其他几家公司干过。 我既在大公司待过，也在小公司待过，还创办过自己的公司。在经历了这些公司之后，我注意到了一些现象。 大公司有自己的做事方式，他们提供了“沙盒”一样的环境，在这样的环境里，会有人满足你的需求，帮你答疑解惑，让你感觉受到了“百般宠爱”。 但我也经历过几个过渡时期，在这些过渡时期，需要自己解决一些棘手的问题。 首先，如何选择合适的技术？ 另一个我比较关心的问题是：如何让开发人员开心地使用这些技术？因为我自己也是开发者，所以这一点对于我来说比较重要。如果有可能，我会尽量让自己过得开心些。 如果你问开发人员什么东西会让他们开心，他们通常会说：“如果可以使用 Clojure 作为开发语言，我就会很开心”。我不否认，当他们说这些话的时候

.NET Core 是微软力推的新平台，影响力好像还越来越大。为了对这一行业趋势有所准备，最近把自己搞的编程语言的编译器从 .NET 移植 .NET Core ，以实现跨平台在 Linux 上运行，然而失败了。 原因是 .NET Core 类库中 AppDomain 、 AssemblyBuilder 、 ModuleBuilder 、 ILGenerator 等等缺失了一些很核心的方法或类型，导致无法编译通过。 核心缺少这些无法编译成功，也不能生成最终的二进制文件。那些以前可以在 .NET CLR 上运行的开源语言 .NET Core 对它们来说已经没有了吸引力，现在没有一个跟进到 .NET Core 上，所以也没有办法从开源项目中获得帮助。比如说 Clojure CLR ，我下载了它最新的编译器源码，它还是用 System.Reflection.Emit 命名空间生成 IL 指令。 微软要在 .NET Core 上废弃了 System.Reflection.Emit 那一套东西。我拼命研究的那套生成 IL 的知识要作废了。这让我想到了 Sliverlight 、 XNA 、 Windows Phone 的下场。我辛辛苦苦钻研到的这部分知识又被归零了，让我想到了刷卡时为零 ( 萨卡什维利外号 ) 。 我又想到现在微软现在是用 Roslyn 编译 C# 的，而且 Roslyn