我觉得用 scheme 写个 DSL 兼容 Elisp 应该可以，然后慢慢用 scheme 重构原来的 Elisp。
elisp生态的力量太强大了，elisp外围插件是全球黑客几十年的结晶。
熟悉emacs的黑客很容易造出emacs核心，但是emacs外围插件的工作量太大了，这也是为什么这几十年一代又一代替换elisp的努力都白费了，也是所有another emacs都挂了的原因。
elisp只能渐进式改进，真的要现代化的改进核心是要有懂图形开发的黑客加入，大多数elisp黑客都是终端字符流高手。
3 个赞
Guile 已经凉了。
从长远看，我也不认为换 Scheme 有什么好处。
看懂楼上各位大佬都非常吃力啊 =.=
哈哈，你不正是那位懂图形开发的黑客吗？ 有没有想过设计一个新的 BeyondEmacs ？
不过好像万事俱备，只欠语言 
不但需要懂图形开发，还要懂程序语言设计 
在我对Emacs的生态理解而言, 我已经造了: GitHub - emacs-eaf/emacs-application-framework: EAF, an extensible framework that revolutionizes the graphical capabilities of Emacs
这个就够了, 既通过 python/qt 补强了 Emacs 的图形性能不足, 又保持不对核心 elisp 生态的侵入, 在保证现在 elisp 生态持续发展的基础之上, 拓展 Emacs 的图形渲染能力.
重新用 Qt/Gtk+ 做一个 Emacs 不会成功的, 原因主要是, 不论图形性能多么强大的编程语言, 都没法替代 Lisp 语言对编辑器核心的高速开发的能力, 更无法替换几十年 Elisp 黑客的巨大插件生态.
我自认为不如世界上很多 Elisp 黑客, 也不枉然想凭自己的能力和现有的Emacs黑客军团玩军备竞赛, 精力和智力总量都不是一个量级的.
6 个赞
现在的CPU结构也不能承载一个现代化的计算机了
现在的操作系统也不能承载人工智能了
现在的程序员也不能承载软件的未来了
现在的房价也不能承载中国的梦想了
接下来
你还想抱怨什么呢？
outrageous
玩emacs就要有盘核桃的耐心
light table了解一下
有个偏题的事情一直想说，虽然现在说有点晚了。Deepin Linux 不应该花大力气去开发 Deepin Mail、Deepin Note之类的应用，做系统是在做平台，最重要的是搭建一个平台，可以让开发者很方便地发布应用，特别是像苹果那样成功的 AppStore，现在提交应用到深度商店的方法太原始。你把这些应用抢着做了，让其它开发者无事可做了，平台不能跟开发者抢生意，更何况这类应用Linux上已经有太多了。最重要的是能提供一套统一的API、开发文档和教程，想要开发DDE应用，都不知道该从哪开始，DTK文档都找不到。
希望 Deepin Linux 能继续维护一个社区版本，哪怕原来的公司被官僚收购腐败倒闭了，也能靠社区继续下去。
2 个赞
还想抱怨现在的程序员已经不能讨论一些有深度的话题了，他们只热衷于改配置、装插件、修BUG。 Nowadays, we do programming by poking.
Programming by poking: why MIT stopped teaching SICP
现在的CPU架构懂得跟着进化，CISC、RISC、SIMD、GPGPU、FGPA、TPU。 现在的操作系统也懂得跟着进化，容器化、分布式、实时操作系统，为大数据、AI、IoT提供支撑。
后面两条倒是很对，我看现在某些程序员已经不能承载软件的未来了，只会从故纸堆里捡宝，每当业界出现什么新技术的时候，他们就说老祖宗早就发现了。比如 Lisp 语言多牛B吹了这么多年，又有多少新的应用是用Lisp写？同样冷门，人家就是宁愿用Rust、Haskell、Idris、OCaml，就是不用Lisp。
1 个赞
我已经离开 deepin 了, 请不要 @ 我这种事情, 我不关心, 谢谢.
6 个赞
话题终结者，赞！
我知道你离开了，但是如果有一天可能你还会想要重来，去创建另一个新发行版的时候（可能像CentOS之于RHEL，或者Linux Mint之于Ubuntu之类的），可以考虑下这个建议，想一想是不是方向搞错了。
听说你离开后一段时间仍然每天登录 Deepin BBS，毕竟投入那么多精力还是有感情的。
大多数人只会站在现有成功者的模式去批判那些正在成功的团队应该怎么怎么做, 关于操作系统怎么做, 大多数人都是啥都不会的键盘侠, 没有做过操作系统的人根本不知道操作系统真正的困难在哪里.
如果你没有做过十年以上的操作系统的开发, 请不要借用朋友圈烂大街的理论去评论别人.
我不认同你上面的言论, 但是我尊重你发表言论的自由, 同时也请你尊重我, 不要再 @ 我关于 deepin 的事情, 我不想参与讨论, 也不感兴趣. 谢谢
6 个赞
- CISC: 1964 IBM System/360
- RISC: 1960’s, various
- SIMD: 1966, ILLIAC IV
- GPGPU: well, it’s only meaningful after the definition of GPU came up, so just don’t count it. In fact there’s no difference to SIMD.
- FGPA: 1982
- TPU: it’s one instance of ASIC, which can be dated to 1981
- Container: 1979, Unix V7
- Distributed: 1960, ARPANET
- AI: 这个不用多说了，ML 理论基础都是老早的了。传统 AI？ARPANET 就是用来做这个的。
- IoT: 1985
2 个赞
你说的是对的，你做系统架构设计当然不能因为外行评论而改变设计。但这个不是技术问题，而是市场问题。 不是我不尊重你，但看到你第一句话我真的要笑了，事前看，这世界上哪一个团队不是正在成功的团队？
Windows做了几十年操作系统，可在强行自动更新的设计上仍然触了众怒，Win 8/Win Phone不也照样翻车？难道是因为MS没有做过十年以上的操作系统的开发？
这种道理你也想不明白那也不用谈了
有问题么？ 1965有人提一个问题：大家有没有觉得现在的CPU设计不适合高效处理图形任务？
然后呢？这些 ELisp 程序员为什么还是不懂如何 Handle IO Error？上次看到有人嘲笑NPM安装失败了都不懂得清理现场回滚，他们要是知道先进的ELisp也不处理，就又能开开心心地 rm -rf .node_modules 了
当然有问题
现代的这些东西只能算对这些老理论的实现。