Haskell or D for GUI desktop application?

I like haskell and many things connected with it as its type-engine, lot of packages at Hackage, nice community, active development etc.

Otoh, I had experience that some people gave up on our planned project considering Haskell too complicated (monads, lot of jargon from academia...) to grok (coming from C++ background), so it might be easier to bring some devs to our open-source project if we'd use D.

We want to develop general desktop application which needs to have database back-end (probably sqlite3), use C-lib for some extensive computational tasks (ephemeris calculation) and use Qt toolkit since we hope to provide 'light' version for MeeGo in the future.

Ability to document source-code easily as well as maintainance are impotant factors since our feature list is long and considering we'll develop in our free time, it may require long time to write everything what we'd like.

Python & other scripting languages are too slow for the project and I do not want go back to C++ after so many years, iow, prefer some more higher-level programming...Without going into too many details, I've excluded some other langauges as well (Go, Clojure, Java..) which brings list down to Haskell vs D.

One concern regarding D is that recetly QtD project was suspended, so I'm curious if in the short term one can even count D as adequate option.

Any pro/cons which one might be more suitable as general programming langua开发者_StackOverflow社区ge covering Linux/MaC/Windows platforms?

Edit: Let me just add link to the post I sent to D list where I explain in more detail about our requirements.

Let's tease out some requirements here, and I'll try to make the Haskell case. Perhaps the D fans or others could try to do the same.

• Desktop application

So Haskell's certainly used for desktop and server-side applications. The tools are available for all modern desktops, just using the Haskell Platform.

• Database backend

Well known database backends for Haskell, that have significant use, are HDBC-* and sqlite, though there are many others.

Other commercial groups that have used database-driven apps in Haskell include: Galois (our sqlite library is linked above); Deutsche Bank (see the talk); Hustler Turf Equipment (home of HDBC).

• C libraries (hence FFI bindings)

Haskell has a high level, widely used FFI, that is a standard part of Haskell 2010.

• Use of Qt

qtHaskell was developed for a commercial application, and is used by e.g. JoyRide Labs for their commercial games.

• Source code documentation

Haddock is widely used. Other analysis tools like: graphmod and sourcegraph also help with requirements documentation.

• Maintainance

Several commercial users have cited purity and strong types as easing the maintainance burden for applications over long project cycles, as they make it easier to make local, safe changes to code. Purity reduces the complexity between components, and types ensure refactorings are sound.

• Other facts

Size of the community -- the open source Haskell community is thriving now, on par with other large FP languages (Erlang, Scala). The commercial users are funding direct development of GHC, ensuring its long term availability, and there are many experience reports to draw from. Hackage and Cabal help mitigate risk by making it easy to pull in new open source work -- saving you time.

I am wary of your comment:

Python & other scripting languages are too slow for this project

Haskell written in a straightforward style will probably be less than an order of magnitude faster than python. It is possible, by nitpicking over the details of a Haskell program, to make it as fast as a low-level C program, but it is tricky, time consuming, and requires a lot of knowledge about eg. GHC's code generation mechanism.

You say you are already using C bindings, so what does speed matter? I am just worried that you are throwing out a lot of great tools based on an assumption that you haven't checked. It sounds like you want a tool with great library support more than anything else.

What about Scala, Scheme, C#/VB.NET (on mono)? I can't imagine what bizarre criteria would cause you to restrict your options to Haskell and D.

That said, Haskell is a great language. If it fits your project, go for it. Just open up your mind a bit so you don't choose Haskell for the hell of it, when there is some other tool out there that will allow you to do 10% of the work for the same results.

Aren't programming languages like girlfriends, sandwiches, and carnival rides? Once you eliminate the rubbish, your favorites are more about you than them.

Since neither Haskell or D are rubbish and both are capable of handling the items you mention (except for out-of-the-box Qt support - if you absolutely need it, D might not work), take some time to figure out which works best for you and your idiosyncrasies. Build a prototype with each language. Fetch some data from sqlite and display it in a gui. If you're still undecided, build each prototype on a different OS to make sure cross-platform development is what you expect.

We can repeat what we've heard about caviar and share our personal experiences, but you'll have to try it to know if you like it.

Last I heard that the gtk+ and wxWidget haskell bindings were more widely used(possibly more bug free) then the qt ones.

What about scala either with native java widgit or with qt java bindings-qtjambi, looking at their website it looks like it is fairly well supported by the community(they already have a 4.7 beta).

I have recently started to learn Haskell and measured timing for a simple example found in "Learn you a Haskell for great good." The example writes out all the right rectangles with integer sides less than 400 (in the tutorial it was less than 10, now I know why). The timing in WinGHCi was >34s (on a 6 core 3.3 Ghz AMD, 64bit Windows 7), not to mention the memory use indicated ~6GB. For a comparison I wrote this program in Ada (triple nested loops) and the timing was <0.1s. I would say you should save yourself a lot of embarassment and choose D. D is in the same category as Ada/C++ (actually it borrows a lot from Ada) but has many modern features and a very nice free compiler. There is a recent book about D by Alexandrescu and having read a good part of it I can testify that you can learn the language entirely within weeks (rather than years in the case of Haskell).

Python may be slow, and C++ may be ugly, but those who insist on working in their favourite obscure language must be prepared to work alone.

Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project -- unless you think you're developing the killer app that will be to your language what Rails was to Ruby.

I want to tell you why i would not use D for the project:

The status of the tool chain of the system is scary. There is one compiler DMC that seems to be working on Windows and Linux. This one will never go open source and seems to be a pet project from Walter Bright not from Digital Mars.

The gdc compiler is buggy and works only with a D 1.0, most of the 2.0 extensions is not available. The project seems to have no maintainers and GCC source is a total monster so don't expect that there are a lot of people who will take over this project.

The llvm compiler is buggy and works only stable with a subset of D 2.0. The project seems to have a maintainer but is progressing slow.

And the state of support for anything else then 32bit Intel is weak. I'm not sure about amd64 and i think there is no hope to ever get support for ARM.

Based on this i lost all hope that D has enough developers to be a save language pick for a company doing a larger mission critical application. You will fight with the tool chain and even pray to go back to C++ often.

I can't comment on Haskell, other then you should not expect programmers becaming Haskell experts. This might be a reason to quit their job - it surely would be a reason for me.