其实双方都有一定的道理，总之看完收获还是很多的，了解了 Julia 语言的现状与优缺点，不过 Julia 这个语言除了缩进语义与下标从 1 开始我个人不太喜欢外，确实也是挺有意思的，具有很多 Lisp 特性（如类似 CL 的宏），通过 JIT 和 LLVM 在保证抽象能力的同时又具有强劲的性能，不过目前 Python 的生态 Julia 估计一时半会是追不上了。
Jilia并没有明显的优势，生态还差得远，未来不怎么看好。
julia语法没有强制缩进吧
Julia 的缩进确实不算语义，因为有 end 作为终止符，不过对于多个表达式还是更喜欢用括号括起来
结果这哥们平时也不用 CL，用的还是 python, lol，看了一下里面还有一些对 CL 理论错误的地方。
至少那个说转到 julia 的人我以前在 Common Lisp 的 IRC 频道里面还经常见到，他说的很多也符合我对 IRC 频道里交流的观察。顺带他好像是 vim 用户，文章里也说了他不太喜欢 emacs
我好奇的是 他从 2008 年就开始接触 common lisp，那时用的编辑器应该是 Emacs. 相当于用了十多年的 emacs ，为啥还是不喜欢 emacs，应该已经习惯成自然了呀。。。
我觉得只要不是PL theory入脑学麻了，正常不应该会为了「支持所有编程语言理论里的特性」去用这个作者都自称不稳定的库。看到就 37 个 star 就该明白不是什么靠谱的库，怎么看都只是个 hobby project。
这个才是「靠谱」的 PL 专家䃼完 CLOS 的样子，还有专门的 paper 讲解。
他直接没用过 emacs，用的是 vim 的 vlime 或者 Slimv，后者大概也是 2009 左右开始有的。
然后到现在 vlime 也还是难用得要死。
他另外一篇文章提到了他用 vim 写 Common Lisp 用了7年。到 2015才开始用 emscs，2017 的时候试了 Spacemacs。后来 Spacemacs 开发管理忙到啥样都是有目共睹的，之前在 IRC 的时候（18~19）他应该转回去坚持用 vim 了。
julia在类型设计上我觉得非常奇怪。julia存在不可实例化的类型叫做抽象类型（其实不如直接叫类），同时可以实例化的类型不可被继承，只有抽象类型可以被继承。感觉这种设计反而会带来大量无必要的设计模式上的负担，比如每次设计一个具体类型，往往会去考虑要不要日后拓展这个类型，然后还要设计一个这个具体类型的抽象类型父亲，诸如此类，在语言层面上就有鼓励过度设计的倾向，最后就像是陷入了臃肿累赘的设计模式怪圈。
他自己的 numericals 就在用这个库，从性能方面考虑，其实这个库没有解决 CL 的痛点，它的主要思想就是尽可能地在编译期获取类型信息然后进行内联以获得高性能的泛型函数，但是对于编译期无法确定的类型这招就行不通了，可是编译期能确定类型的话我觉得没太大必要使用多态函数，而 Julia 可以通过 JIT 解决这个问题。而从运行时派发的角度考虑，这个库其实还是有点实用性的，作者称搭配他的 extensible-compound-types （相当于重新实现了 CL 的类型系统， Shadow 掉 CL 自带的 deftype, check-type 这些）可以允许用户自定义复合类型，然后对这种类型进行派发，但缺点就是比 CL 自带的 Generic Function 还要慢得多。
只有自己用，只支持 SBCL，根本没解决啥问题。用 deftype 设计复杂 contract 的类型我认为是滥用，是看到别人吹类型系统咋样就去不加思考地模仿，CL 类型就是数据类型，不是用来给你做 XML validation 的。
LIL 这样才是把函数式编程和OOP有机结合。多态类型是让你用来写有组合性的程序的，而不是为了多态而多态就抄个 C++ 的 template 这种设计上就有缺陷的东西
其实也没那么不堪，像 ECL 和 CCL 也是可以运行的，像 lisp-polymorph 这些库也是基于它的，至少也是受到 generic-cl 作者认同的。LIL 这个库确实不错，只可惜不更新了，作者转投 Gerbil Scheme 去了
感觉他就不是资深Lisp开发者，这属于标题党了
mfiao 确实是 CL 开发者，还是用 CL 做游戏的。
LIL 自带实现的那些 Okasaki 提出的函数式数据结构，都是之前没有其他 CL lib 能实现的。光这点就比加些可有可无的 overloading 语法糖逼格高多了。