目前 Open Dylan 的实现有多成熟？
打开迪伦看起来真的很有趣。然而，在我将它用于实际开发之前，我想知道它的实现有多成熟。我知道 Dylan 本身就是一门古老的语言，并且已经被 Apple 使用过。
Open Dylan looks really interesting. However before I would use it in real development, I would like to know how mature the implementation is. I know that Dylan itself is an old language and it has been used by Apple.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，当前的实现 Open Dylan 自 95 年以来一直由 Harlequin 和Functional Objects 开发，然后于 2003 年开源。
成熟度是如何定义的？编译器包括 IDE（仅限 Win32，抱歉）、CORBA、OLE，总共 850000 行代码。这（几乎）是迪伦的全部代码。
这意味着，与其他语言不同，它是自托管的。编译器本身是用 Dylan 编写的（除了一些用于运行时/垃圾收集器绑定的 C 行（约 4000 行代码）。后端是本机 x86 代码或 C。
请不要将此实现与另外两个，分别是：Gwydion Dylan（也是用 Dylan 编写的；以前在 CMU 开发，现在也是开源的），它将 Dylan 编译为 C 和 Apple Dylan（封闭在 Apple 大存储中的某处）； ;）。
Well, the current implementation, Open Dylan, has been developed since '95 by Harlequin and Functional Objects, before it became open source in 2003.
How is maturity defined? The compiler includes an IDE (Win32 only, sorry), CORBA, OLE, all in all 850000 lines of code. This is (nearly) all Dylan code.
Meaning, unlike other languages, it is self-hosted. The compiler itself is written in Dylan (with an exception of some lines of C (~4000 lines of code) for the runtime/garbage collector binding. The back-ends are either native x86 code or C.
Please do not confuse this implementation with the two others, which are around: Gwydion Dylan (also written in Dylan; developed formerly at CMU, now open source as well), which compiles Dylan to C; and Apple Dylan (closed somewhere in Apples big storage ;).
根据Hacker News 的评论，它还没有准备好。他们刚刚开始重振该项目。
According to a comment on Hacker News it isn't ready yet. They just started to revive the project.
截至 2020 年 6 月 4 日，OpenDylan 项目中的文件详细信息，从 https://github 下载。 com/dylan-lang/opendylan，包括：
这样您就可以看到有 3,112 个 Dylan 文件，总共 30,643,409 个字节，而且 C 语言文件只有 104 个，仅包含1,288,062 字节。这支持了汉内斯的答案，但也某种程度上量化了事物。
为了弱化 stesch 的答案，它不应再被认为是相关的......
这看起来不像是一个“尚未准备就绪的项目”。
这看起来也不像是一个刚刚恢复的项目。
因此，请忽略“stesch”可能具有误导性的答案。
我研究编程语言，Dylan 是我的第一选择，因为：
迄今为止，他们已经为客户创造了惊人的价值。
使用类 C 语言（JavaScript、C#、C、Java 等）
能够学习一门伟大而强大的语言。
在C语言中，宏语言似乎是固定的，
完全不同的语言，有时需要额外的括号
使其正常工作，从而导致微妙的错误。
Lisp宏是在更高层次上实现的，
在编译过程中，
并且也使用相同的语言（Lisp）
不是完全不同的语言
因此它具有相同的“形状”（同像）并且更易于使用。
宏的使用在 Lisp 语言中更为常见
因为它不仅更强大，而且更容易。
如果您有兴趣，请阅读此内容：
D 表达式：Lisp Power，Dylan 风格
还有这个，对于了解 Lisp 宏为什么和如何强大：
让 Lambda 过来——Lisp 50 年
这是本书的大部分内容，可在线免费阅读。我购买了这本书的最后几章，关于性能的一章，以及在 Lisp 上实现 Forth 的一章，然后在 Forth 上实现 Lisp。 Lisp 和 连接语言 有很多强大的共同点（我拥有的那些） Forth、Factor、Joy 和 Cat 的一些知识），关于使用 Lisp 编写 Forth 的一章可以帮助人们了解这一点。
领域特定语言是我们武器库中的一个巨大工具，但我们还没有很好地使用它。 Lisp 的宏功能（以及 Forth 的类似灵活性）允许动态定义 DSL，作为正在创建的解决方案的完整补充。您扩展了语言——除了更常用的代码之外，还提供了表达解决方案的新方法。
稍微偏离主题，我有点喜欢 Factor 作为更好的 Forth。由目前在苹果公司工作的天才斯拉瓦·佩斯托夫（Slava Pestov）创建。
维基百科上的因子编程语言
Factor 网站
Slava Pestov 的关于 Factor 的 YouTube 演示
在他的视频中，Slava 解释说 Factor 是基于不仅有 Forth，还有 Lisp。我打算深入研究它，找出这意味着什么，因为我一直希望寻找在其他语言中实现的真正 Lisp 风格的宏功能。
编辑：
也在 Slava Pestov 的 Factor 视频中，他解释了为什么他的面向对象实现比许多其他语言更好，我认为这非常重要，因为很多东西都是建立在 OO 之上的。
As of June 4, 2020, the breakdown of files in the OpenDylan project, downloaded from https://github.com/dylan-lang/opendylan, includes:
So you can see that there are 3,112 Dylan files consisting of 30,643,409 total bytes, and also that there are only 104 files in the C Language consisting of only 1,288,062 bytes. And this supports the answer by Hannes, but also sort of quantifies things.
To deemphasize the answer by stesch, which should no longer be considered relevant...
This does not look like a "project that's not ready yet".
This also does not look like a project just being revived.
Therefore, please discount the possibly misleading answer by "stesch".
I research programming languages, and Dylan is my number one pick because:
who so far has produced an astounding amount of value to their customers.
who uses a C-Like language (JavaScript, C#, C, Java, and many more)
to be able to learn a great and powerful language.
In the C languages, the macro languages there seem bolted-on,
a completely different language, and sometimes requires extra parentheses
to make it work, leading to subtle bugs.
Lisp macros are implemented at a higher level,
further along in the compilation process,
and also use the same language (Lisp)
not a completely different language
so it has the same "shape" (is homoiconic) and is much easier to use.
Macro use is much more common in the Lisp languages
because it is so much easier, in addition to being more powerful.
Read this, if you are interested:
D-Expressions: Lisp Power, Dylan Style
And also this, for an understanding of why and how Lisp macros are powerful:
Let over Lambda -- 50 Years of Lisp
This is most of the book, online, free to read. I purchased the book for the last few chapters, the one on performance, and the one implementing Forth on Lisp, and then implementing Lisp on Forth. Lisp and the concatenative languages have a lot of powerful machinery in common (the ones I have some knowledge of are Forth, Factor, Joy, and Cat), and the chapter on writing a Forth using Lisp helps one to see this.
Domain Specific Languages are a huge tool in our arsenal that we have not done terribly well using. The Macro power of Lisp (and Forth's similar flexibility) allows the on-the-fly definition of DSL's as integral additions to the solution being created. You extend the language -- provide new ways of expressing solutions along side the more usual code.
On a slightly off topic, I sort of like Factor as a better Forth. Created by Slava Pestov, a genius currently working for Apple.
Factor Programming Language on Wikipedia
Factor Web Site
A YouTube presentation on Factor by Slava Pestov
In his video, Slava explains that Factor is based on Forth, but also Lisp. I intend to delve into that to find out what that means, since I've been hopefully looking for the presence of true Lisp-style macro power implemented in other languages.
Edit:
Also in the video on Factor by Slava Pestov, he explains why his implementation of Object-Orientation is better than many other languages, which I consider to be very significant, since so much is built on OO.