emacs该如何应对neovim和oni?


#61

(我倒是不大喜欢 gradual typing,终归是一种无奈之举,在一些设计时候就没有考虑类型系统的语言上加装一个类型系统,其实挺累的。倒不如 static typing,写程序的开始脑子里就有类型这玩意了,而不是写到一半回头再装回来)

APL 是真的好啊,可惜快成为时代的眼泪了


#62

我这种菜鸡只会把ts当java用,手写类型签名,当然偶尔也用下union type

所以用他干嘛,享受value restriction这些吗


#63

TS 再怎么也是 JS 上面的类型系统啊,不如 ML 原生的类型系统啊

声明:没用过 Reason(

P.S. 前端圈的语言里类型系统好使的也就 PureScript 吧,然而这玩意能用来干活吗?


#64
  1. 用 Reason React 开发图形界面。ReasonML 和 React 是同一个人开发的项目,有优先支持。

  2. ReasonML 和 OCaml 的语法树等价,所以可以用性能优秀的 OCaml 编译器来编译。

  3. 从 Reason 编译出来的 JS 代码更像手写的。


#65

ReasonML 跟 React 之间的联系是——React 的最初作者现在在开发 Reason。联系是在的,但不意味着 React(Facebook)对 Reason 的支持能有多高。

后两条确实是 BuckleScript 的优势(虽然我没理解 human-readable compiling output 除了证明编译器开发者的能力以外对实际项目有什么意义),所以如果是我,我会选择 BuckleScript 而不是(在 ML 系语言里再一个 JSX(来证明自己毫无创造力或者一味讨好 JS 开发者)的 )Reason


#66

:rofl: 讲真的不要把什么帖子都往 PL 上带啊((((


#67

可是不用 JSX 为啥要用 Reason。

比如一起做项目的 normie 只会 JS。老夫得带带人家,不能给他们看不懂的代码,然而也懒得去教别人。

再比如 PureScript 那样用特殊的 calling convention 会让 interpolate 更麻烦一点。


#68

都被骗进 Reason 了,其实再骗骗去写别的(真正好的)也不是不行嘛


#69

能生成可读 JS 的只有 Reason 和更蛋疼的 Parenscript。不用 node 的更是只有 Parenscript。


#70

不是啊,Reason 背后不是 BuckleScript 吗,不能直接写 BuckleScript 吗?

另外,你不会是自己写 Reason 然后生成 JS 做工作代码?


#71

写 ReasonML 也能生成 OCaml,Reason 的语法还更 terse 一点少打几字。

老夫送人情帮搞交互设计的同学(其實是別的专业的,快毕业了唯一能选的必修课要写代码然而苦手)做做小网站写点 React,对前端和网页沒什么兴趣。

对啊实在太过于生草了


#72

第一次看到 human-readable output 的使用场景


#73

作者在这解释了又开新坑的原因:https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.md

Oni2 项目描绘的愿景很诱人,但具体到实现又充满挑战,有大量的工作要做。

上游也在开放 api,给 ui 更多权限:https://github.com/neovim/neovim/commit/e2cc5fe09d98ce1ccaaa666a835c896805ccc196


#74

然而oni2已经准备抛弃neovim自立门户了

基于进程间通信的前后端分离架构看起来很爽,最终还是会遇到各种各样的bottleneck。unix哲学罪孽深重

这也是我不喜欢xi editor的原因


#75

额。。。libvim 上游依然是 neovim,怎么可能“抛弃”呢?它是专为 oni2 定制的瘦身版,某种程度上和 neovim 团队所做的部分工作重叠。

之前 neovim GUI 的开发痛点之一,就是无法满足高度定制的需要。比如 GUI 想自己绘制 minimap、平滑滚动、状态栏、补全菜单等等,会发现和 neovim 本身功能冲突。

neovim 团队正逐渐将 tui/view 层抽离出来,并提供 GUI 相关的事件 API,以解决该问题。只不过 libvim 在这点上做的更加激进罢了。


前后端分离架构,毫无疑问是未来趋势。各种各样的 bottleneck,其实是跨平台开发工具的坑,以及历史遗留问题。


#76

听说过khtml和webkit的故事吗,就算libvim不会反噬nvim,libvim开发者要自己加新功能然后合并不会上游这种事情太常见了

我意思是neovim这种基于字节流进程间通信的方式是野蛮低效的。


#77

纠正一下:刚看了下 libvim,上游是 vim 而非 neovim。

两者不具有可比性,看下关注数就知道。libvim 要解决的是 GUI 开发中 view 层碍手碍脚的问题,除此之外没别的。

前后端分离架构,允许任何语言写的插件与主进程沟通,允许与远程服务器沟通。


#78

还要解决怎么解析VimL的问题

我没说前后端分离架构有问题,我一直在强调nvim那种msgpack传来传去的有问题,你看libvim这个就好多了,直接做成C库,用FFI binding调用不比msgpack强?

所以不同时精通Python,Ruby,Javascript,Lua,C,Rust感觉vim插件都看不懂了,还是emacs适合我等鶸鸡 :joy:

突然就感觉X11架构上吊打Wayland了(确信)


#79

通用统一 的标准传递数据,这正是该架构设计的妙处。

不用懂多种语言,直接使用就行。如果是开发者,则用精通的语言开发插件。

以上两点,都是 LSP 发展的精髓。


#80

依稀记得 @LdBeth 说lisp machine进程间可以传object而非字符串,上这个论坛总算学到了一点

此处多写了一个“鸡”