使用 Haskell、wxWidgets（通过 wxHaskell）或 GTK（通过 Gtk2HS）？
各自的优点和缺点是什么？ 它是否会根据您的目标平台而有所不同（我主要在 OS X 上工作，但希望我的程序也能在 Linux 和 Windows 上工作）？
Which is better for developing GUI applications with Haskell, wxWidgets (via wxHaskell) or GTK (via Gtk2HS)?
What are the pros and cons of each? Does it vary depending on which platform you are targeting (I would primarily be working on OS X but would like my programs to work on Linux and Windows too)?
发布评论
评论（4）
[免责声明：我是 wxHaskell 维护者]
两者都是稳定且相当完整的 GUI 绑定，您可以放心地为大多数项目选择其中之一。 两者都具有某种程度的“更高级别”Haskell 绑定，但在这两种情况下，您都需要投入相当命令式的“C”风格编码才能完成任务。 我的印象是，wxHaskell 允许您在更高级别的绑定上花费更多的时间，但我没有做太多 GTK2HS，并且无论如何，您肯定会发现自己正在为这两个库的包装器做薄端工作 -我认为这两种情况下的整体编程“复杂性”是相似的。
因此，让我们以基本功能为给定，并专注于差异。 请注意，我真诚地相信 GTK2HS 是一款出色的作品，如果您选择它，您会感到高兴。 我下面所说的大部分内容都是个人对这些差异的看法，以及为什么我选择自己从事 wxHaskell 工作。
GTK2HS 有一个更大的团队致力于它，并且发布得更频繁。 wxHaskell 更新不那么频繁，但核心团队很活跃，并且定期进行错误修复，但主要新功能的添加速度比我们希望的要慢（我们都有日常工作）。
wxHaskell 在所有支持的平台上提供真正的本机应用程序外观，开箱即用。 当然，GTK2HS 是 Linux 上的本机，并且在 Windows 上有一个相当好的本机主题（即足以满足除了学究之外的所有人......），但在 OSX 上具有 GTK 外观和感觉，并且取决于是否安装了 X11。 我相信 OSX“原生”GTK 库正在开发中，但被认为相对不成熟。 一旦稳定，GTK2HS 应该能够轻松地从相同的“部分原生”外观和感觉中受益（例如 GTK OSX 屏幕截图）。
如果您不在 Linux 上，wxHaskell 可能更容易构建（如果您托管 Linux，则 GTK2HS 可能更容易），但老实说，构建两者都相当复杂，因为这两种情况都存在大量依赖项。
分发基于 wxHaskell 的应用程序稍微容易一些（恕我直言），因为它具有较少的库依赖性。 我在 Windows 上主要使用 InnoSetup 来分发应用程序，在 OSX 上则以应用程序包的形式分发应用程序。 我承认，只需要少量的额外工作，GTK2HS 就可以完成同样的工作，所以这可能是支持 wxHaskell 的最弱的论据。
我个人认为wxHaskell 对闭源（例如商业）开发更友好。 当然，这是无休止的争论的主题，所以我只会说 wxHaskell 属于 wxWidgets 许可证 明确允许闭源开发。 GTK2HS 是 LGPL，所以你需要询问你的律师 - 尽管我必须明确指出，许多人和公司已经得出结论，LGPL 与商业开发兼容； 我工作的公司的律师得出的结论是，这不适合我们的项目。
我认为如果 Linux 是我的主要开发和交付平台，我可能会使用 GTK2HS。 然而事实并非如此：我主要交付给 Windows，偶尔也交付给 OSX，并且我认为 wxHaskell 更适合这些平台，尽管这两个选项都支持所有三个平台。
我希望这对您的选择有所帮助。
[Disclaimer: I am a wxHaskell maintainer]
Both are stable and fairly complete GUI bindings, and you could choose either for most projects with confidence. Both have some degree of 'higher-level' Haskell bindings, but in both cases you will need to drop into rather imperative 'C' style coding to get things done. My impression is that wxHaskell allows you to spend a little more time in the higher-level bindings, but I've not done much GTK2HS, and in any event, you definitely find yourself working on the thin end of the wrapper for both libraries - and I think the overall programming 'complexity' is similar in both cases.
Therefore, let's take the basic functionality as a given and concentrate on the differences. Please note that I genuinely believe that GTK2HS is an excellent piece of work, and that you will be happy if you choose it. Most of what I say below is a personal take on the differences, and why I choose to work on and with wxHaskell myself.
GTK2HS has a larger team working on it, and is released more regularly. wxHaskell is not updated as frequently, but the core team is active, and there are regular bugfixes, but with major new functionality being added rather more slowly than we would like (we all have day jobs).
wxHaskell gives true native application appearance on all supported platforms out of the box. GTK2HS is, of course, native on Linux and has a pretty good native theme on Windows (i.e. good enough to satisfy all but pedants...), but has GTK look and feel on OSX, and depends on having X11 installed. I believe that an OSX 'native' GTK library is under development, but is considered relatively immature. Once this is stable, GTK2HS should be able to easily benefit from the same 'partially native' look and feel (e.g. GTK OSX screenshot).
wxHaskell is probably a little easier to build if you are not on Linux (GTK2HS is likely easier if you are Linux hosted), but both are pretty complex to build, to be honest, as there are a significant number of dependencies in both cases.
It is slightly easier (IMHO) to distribute applications based on wxHaskell, simply because it has fewer library dependencies. I distribute applications using mainly InnoSetup on Windows, and as App bundles on OSX. I would admit that with only a small amount of extra work, the same could be done with GTK2HS, so this is probably the weakest argument in favour of wxHaskell.
It is my personal opinion that wxHaskell is friendlier to closed source (e.g. commercial) developments. This is, of course, the subject of interminable flame wars, so I will only say that wxHaskell is under the wxWidgets license which unambiguously allows for closed source development. GTK2HS is LGPL, so you'll need to ask your lawyer - although I must make it clear that many people and companies have concluded that LGPL is compatible with commercial development; the lawyers at the company I work for have concluded that it is inappropriate for our projects.
I think that if Linux was my main development and delivery platform, I'd probably use GTK2HS. It isn't, however: I deliver mainly to Windows with occasional OSX, and I think wxHaskell is a better match to these platforms, although both options support all three platforms.
I hope this will help you with your choice.
需要考虑的是，目前让 wxHaskell 在 Mac OS X 上本地工作稍微容易一些。GTK2HS 依赖于 GTK，GTK 确实有一个在 Mac OS X 上使用本机小部件的实现，但该实现不像 wxWidgets 实现那么容易构建对于 Mac OS X 来说是。
因此，如果您想开发无需 X11.app 即可运行的代码，目前使用 wxHaskell 会稍好一些。
但请注意，这种情况正在迅速改变：
http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework
展示了如何在 Mac OS X 上将 GTK2HS 与本机 GTK+ 一起使用。GTK2HS
的优势之一是它的 GLADE 支持，使得简单 UI 的开发非常快速。 wxHaskell 中的高级组合器减轻了大部分优势，但它们确实需要更深入地了解您希望界面的外观和行为方式，因此更难以探索性方式使用。
A consideration is that currently it is slightly easier to get wxHaskell to work natively on Mac OS X. GTK2HS depends on GTK, which does have an implementation using native widgets on Mac OS X, but that implementation is not as easily built as the wxWidgets implementation for Mac OS X is.
Therefore, if you want to develop code to run without X11.app, currently you are slightly better off with wxHaskell.
Note however that this is quickly changing:
http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework
shows how to use GTK2HS with native GTK+ on Mac OS X.
One advantage of GTK2HS is its GLADE support, making the development of simple UI very quick. The higher level combinators in wxHaskell mitigate most of that advantage, but they do require a deeper understanding of how you want your interface to look and behave, and therefore are harder to use in an exploratory fashion.
我的信息相当不完整，但既然你还没有答案，也许不完整的信息总比没有好。
要问的问题是：该工具包只是类似 C 功能的包装器，还是有一个附加层为该工具包提供了更“类似于原生 Haskell”的 API？ 当 wxHaskell 在 Haskell 研讨会上首次宣布时，原生 Haskell API 的开发看起来非常有前途，但仍然不完整。 看起来 wxHaskell 的“Haskellized”API 仍在开发中，而 Gtk2Hs 项目根本没有提到这个问题。 因此我推荐 wxHaskell。
I have pretty incomplete information, but since you have no answers yet, maybe incomplete information is better than none.
The question to ask is this: is the toolkit just a wrapper around C-like functionality, or is there an additional layer that gives the toolkit a more "native Haskell-like" API? When wxHaskell was first announced at the Haskell workshop, the development of the native Haskell API looked extremely promising, but was still incomplete. It looks as if the "Haskellized" API for wxHaskell is still being worked on, whereas the Gtk2Hs project doesn't mention this issue at all. For that reason I'd recommend wxHaskell.
就我个人而言，我会研究某种反应式包/扩展。 它似乎与范式更加接近。 您可以以声明方式指定图形内容，而不是强制指定图形内容。 示例（不代表任何特定语言或实现）：
Buttonclicked 和 z 将在每次 x 和 y 更改时自动更新。
然后你可以在某个地方有一些看起来像这样的逻辑：
但这一切都非常模糊。 只要看看一些真正的反应式接口
Personally I would look into some sort of Reactive package/extension. It seems to sit with the paradigm much much closer. Instead of specifying your graphical stuff imperatively, you can do it declaratively. Example (not representative of any particular language or implementation):
Buttonclicked and z will be automatically updated every time x and y change.
You could then have some logic somewhere that looks something like this:
This is all very fuzzy though. Just look into some real reactive interfaces