方案与小话
这里并不是关于 Smalltalk 和计划的真正问题。我三周前才开始玩 Smalltalk，一直在 Squeak 和 Pharo 之间来回切换。两者都令人惊奇，对我来说，很难想象 Smalltalk 不是最流行的语言。一切都在一张图片中，我不需要交互式命令提示符、编辑器、Rdoc 网页等，我只需点击它就可以了，如果我打开 UiDesigner，我会得到一个 GUI接近QT4的应用程序。我的小型数据库有一些数据库实用程序，例如 magma。
不管怎样，我也开始在Racket中使用Scheme，虽然涉及到很多()，但它仍然很简单；这似乎从一开始就很合乎逻辑。我唯一发现的是有很多 schema/Lisp 方言。 Racket 似乎也是一个相当简单的环境，但是，值得注意的是，似乎有 Chicken 和 MIT Scheme。
我应该使用 Chicken 而不是 Racket 或 MIT 有什么特殊原因吗？反之亦然。良好的系统支持、数据库或GUI支持...等。
PS 我显然没有选择最流行的语言，但我很开心:-)
Not really a question as such in here regarding Smalltalk and Scheme. I only started playing in Smalltalk 3 weeks ago and have been bouncing between Squeak and Pharo. Both are amazing its hard to think to me smalltalk isn't the most popular language going. Everything is in the one image I don't need an interactive command prompt an editor a web page for Rdoc etc I just do it click it mess around, heck if I do UiDesigner Open. I get a GUI app close to QT4. There are database utilities for my small databases like magma.
Anyway, I also started to play with Scheme in Racket and though there are a lot of () involved it still had a lot of simplicity; it seems to be quite logical from the get go. The only thing I am finding is that there are a lot of scheme/Lisp dialects. Racket seems to be quite an easy environment as well, however, notably, there seems to be Chicken and MIT Scheme.
Is there a particular reason I should be using Chicken over Racket or MIT? Or Vice Versa. Good System support, Database or GUI support...etc.
PS I am clearly not picking the most popular languages but I am having fun :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Racket 和 Chicken 都有良好的库支持。 （GUI、数据库、网络等）。如果你只是想玩得开心，我建议你选择 Racket。它完全支持计划标准（R5RS、R6RS）和良好的文档。有一些好的 使用 Racket 作为实现语言的编程书籍。另一方面，如果您正在寻求编译代码在各种硬件上的可移植性，Chicken 可能比 Racket 更好。
Both Racket and Chicken have good library support. (GUI, database, networking etc). If you are just having fun, I suggest you go with Racket. It has full support for the Scheme standards (R5RS, R6RS) and good documentation. There are a few good programming books that use Racket as the implementation language. On the other hand, if you are looking for portability of your compiled code across a wide assortment of hardware, Chicken might be better than Racket.
如果 R6RS 对您很重要，请选择 Racket。 Chicken（以及其他）现在和将来都不会符合 R6RS 标准，因为人们普遍认为它存在缺陷。 R7RS 正在开发中，应该可以解决一些问题。就 R5RS 合规性而言，Chicken 努力保持在标准范围内（手册中有两页列出了差异）。 Racket 非常不同，以至于它不久前就放弃了“Scheme”这个名字。
也就是说，我更喜欢鸡肉。 Chicken 的 FFI 非常棒（Bind Egg 更是如此）。由于它被编译为 C，因此与 C 库的接口变得轻而易举。我什至将一些 Chicken 的运行时源文件（手册中记录的过程）直接添加到我正在开发的 iPhone 应用程序中，以及翻译为 C 的方案代码，它的工作方式就像一个魅力。不需要那样创建交叉编译环境，因为它都是 C 语言并由 XCode 编译。
鸡有很多蛋，而且每天都在长大。我建议查看鸡蛋页面 链接文本 看看它是否有您需要的内容。如果是这样，我强烈建议您尝试一下。
If R6RS is important to you, go with Racket. Chicken(among others) is not and will not be R6RS compliant, as there is a widespread perception that it is flawed. R7RS is being worked on and should address some of the concerns. As far as R5RS compliance goes, Chicken tries hard to stay in the standard (there are two pages in the manual listing differences). Racket is different enough that it shed the "Scheme" name a while ago.
That said, my preference lies with Chicken. Chicken's FFI is fantastic (even more so with the Bind egg). As it is compiled to C, interfacing with C libraries is a breeze. I have even added some of Chicken's runtime source files (a process documented in the manual) directly into an iPhone application I am working on, along with Scheme code translated to C, it works like a charm. There's no need to create a cross-compilation environment that way, as it is all C and compiled by XCode.
Chicken has a lot of eggs and growing every day. I suggest checking out the eggs page link text to see if it has what you need. If so, I strongly suggest giving it a try.