Apologies folks, rant coming up...
On Wed, 29 Sep 2010 22:02 +0100, "Andrew Coppin"
On 29/09/2010 07:33 PM, Steve Schafer wrote:
The issue isn't that there aren't a lot of Windows developers who have an interest in Haskell+GUI development. The issue is that nearly every Windows developer who looks into Haskell+GUI says, "This stuff sucks," and walks away, because they're interested in developing applications, not wrestling with GUI toolkits.
Yep, that's the one.
[snip for brevity]
How do you do that in Haskell? Well, you can either install and configure a complete Unix emulator and then compile wxHaskell from source (?!), or you can use Gtk2hs, which still requires you to manually install and configure GTK+ and compile the entire library from source code. And even then, your developed application will only run on Windows boxes that have GTK+ installed (i.e., none of them). All of which is a far cry from "install IDE, click some buttons, run the wizzard, job done".
Then again, let us not claim that this is only a problem for GUI stuff. If you want to access a database, or run compression algorithms, or play sound, or do absolutely anything else which requires talking to C-land, you've going to have to face a world of pain on Windows.
As one of the people trying desperately to make this better on Windows (i.e. as wxHaskell maintainer...), I'd have to add that aspects of GHC make this much harder than I'd like. Take the specific case of wxHaskell, since I'm familiar with it. The 'requirement' is pretty straightforward in principle. What I want is: 1) Make wxHaskell easy to build and install on all platforms. 2) Make wxHaskell work in GHCi for 'exploratory' programming as well as for compiled executables Bear in mind that as I have a (very) demanding day job and a young family, I actually have no more than 3-4 hours a week (at best) to spend maintaining wxHaskell. Bear in mind also that my interest in wxHaskell was always to be able to develop software in Haskell, not fight with linkers and build systems (I get enough of that at work, thanks). While that's my personal problem, and others may not have the same issues, so please feel free to not care at all, it's worth bearing in mind... wxHaskell consists of a set of C bindings over the C++ core of wxWidgets. Broadly speaking, these unmangle the C++ names and do little else. Now, wxWidgets, being C++, links against libstdc++ (a not unreasonable requirement). MinGW, which is the underlying framework used by GHC only knows how to link libstdc++ statically, but the way cabal constructs link commands means that when wxcore gets loaded, GHCi attempts to load libstdc++ dynamically. You're dead. OK. Next step is to build the C wrapping as a separate DLL. In this case libstdc++ can be statically linked with the wxc DLL and the dependency on libstdc++ can go away. Trouble is, you now need to construct a C++ build system for a DLL in Cabal. Lots more custom build hooks, and some of what goes on under the hood is magic. However, eventually you get something which builds a DLL with only mildly sucky dependency management. Problem is now to pick this up in GHC and GHCi. After several weeks I still don't have the right stanza to invoke the linker. Next make sure that this all coexists with the inevitable several instances of MinGW, Cygwin and others which exist on the machine of a typical developer who uses Open Source code - ideally throwing in a nice mix of 32 and 64 bit variants of same, and with completely random path orderings. What would work best for me is something which is, I think, conceptually quite simple: allow Cabal to pull DLLs (or .so or .dylib or wwhatever) from some standard place (maybe in the Cabal tarball for a package), and add them to the link lines correctly, plus put them somewhere GHC will know about them for the future. This means that I, as wxHaskell developer, could build 'known good' wxWidgets DLLs, plus a known good wxc DLL and package them with wxcore, and end users would stop needing to care about building for themselves. This would let me use more appropriate build systems for the non-Haskell components without requiring users to download and install an insane number of libraries and developer tools - IOW, it puts the burden of building libraries on the library maintainer, but takes away the burden on the library maintainer of making this work for everyone else's machines, and documenting it, keeping the build documentation up to date and simple enough for people who don't want to become C or C++ developers to understand! As it is, in order to maintain what is a conceptually simple set of bindings, I need to become a deep expert in: - Customizing Cabal build hooks - How GHC and GHCi construct their link stanzas (is this documented anywhere?) - Installing and using MinGW - since this the only thing GHC guarantees to have available, so I'd like to use it to make life easier for others (much as I like gcc on Unix platforms, it's a long way from working as I'd expect on Windows) - MinGW quirks (like the inability to link libstdc++ as a DLL, and it's strange notion of import libraries) It would be nice if GHC and GHCi had a better story in respect of DLLs on Windows, but I accept that at least part of the problem is the underlying dependency on MinGW, so it's probably hard to solve this one.
It seems that because this stuff is such a PITA on Windows, nobody uses Haskell on Windows. And since nobody uses Haskell on Windows, nobody is fixing these problems. So they just stay here, forever.
Actually, I don't completely agree. I think that the issue is that making things better on Windows (and likely OS X as well) requires co-ordinated and agreed action across a number of areas. This means getting a moderate number of people, most of whom give up their time and effort for free, and for the good of the community, to agree on what is needed and to prioritize it in a co-ordinated way. The action needed by any individual might be relatively small, but without community agreement and action, the end goal cannot be achieved. Some areas probably need to be addressed by people whose primary focus *is* Linux (or other Unix) because that's what they use on a daily basis. They might well prefer to spend their valuable time on goals closer to their own hearts than in making life better on Windows, but the fact is that a better sotry on Windows probably does require some work in areas like GHC and Cabal, whose maintainers are, I suspect, mainly Linux users. Of course, the fact that this is all in the area of building and linking code, a notoriously revolting and unrewarding area of software development, and far less sexy than, say, inventing a morphism more unpronounceable than the Zygohistomorphic, probably doesn't help. Sorry for the rant, but just my $0.02 Regards Jeremy -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com