views:

697

answers:

7

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 language 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.

+1  A: 

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.

luqui
Even if you don't write for speed Haskell is statically bound, not object oriented(Isn't dynamic dispatch fairly rare in haskell, not to mention object space overhead) , and ghc probably has more then a few trick up its sleeve with all that static immutable goodness. Python is an extremely dynamic language and is not yet!(some nice work is being done) that fast for a very dynamic language.
Roman A. Taycher
The programming language shootout seems to indicate that Haskell/GHC is 10-20 times faster than CPython(depending on platform). What is your basis for claiming GHC produces code that's "less than an order of a magnitude" faster? Assuming you take a "magnitude" to be a factor of 10, you appear to be provably wrong.
voxcogitatio
@luqui: another project targetting practically the same problem domain used python with the same C-lib and was too slow and went to C++. We need only one specific C-lib (Swiss Ephemeris), the majority of libs have to be written in native language. I simply do not like C# and Java-like VM style...Tried Scheme a bit, but I'm not Lisp-fan.
gour
@voxcogitatio: the shootout is useless for comparing language speed. The benchmarks do not resemble real tasks, and the code in most languages, including Haskell, has been highly optimised with no regard to safety, portability, or maintainability. It does not say anything about the performance of the language in real-world situations.
Porculus
@Porculus: All benchmarks are flawed. This does not in any way imply that guesswork and benchmarks are on equal footing.
voxcogitatio
@voxcogitatio, go look at some of the benchmark programs in the shootout. They are far from idiomatic Haskell. My claim about the speed of Haskell code is purely anecdotal based on experience. The kinds of things it does well compared to python are different, but for my reasonably-sized applications I wouldn't call the speed "blazingly fast". It's nice enough that I usually don't have to worry about performance, but it can't compete with hand-written low-level code (which, of course, takes 10x longer to write).
luqui
I forgot to mention that haskell speed and memory might be a bit unpredictable due to laziness.
Roman A. Taycher
+1  A: 

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).

Roman A. Taycher
That's true. I was considering gtk2hs, but people working on Mac GTK port told me wx is better, but there is no wxQT if we want to target MeeGo in the future - that's why we consider Qt. Scala is too close to Java for my preferences.
gour
A: 

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.

Porculus
It may be so, but when one works on a hobby project and giving it for free, it's, at least, expected to have fun with it as much 'obscure' it may sound. If the project would be my bread and butter, I'd probably think differently and listen to my job, but, here I do not have one. ;)
gour
Oops.. s/job/boss :-)
gour
"for it to be at all likely that you will ever attract a single other developer to your project" -- you are unfamiliar with the Haskell community.
Don Stewart
+9  A: 

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.

Don Stewart
"qtHaskell was developed for a commercial application, and is used by e.g. JoyRide Labs for their commercial games." - do you have some info about further status of this project, whether it will become more opened, roadmap etc. ? On D-side, QtD is suspended, and this is one of strong arguments for Haskell...
gour
According to the qtHaskell [documentation](http://qthaskell.berlios.de/doc/userGuide/license.html), the library is GPL licensed?
eevar
nice, i didn't know about qtHaskell
Martin DeMello
+2  A: 

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.

Corbin March
@Corbin: you're correct. Working on open-source project has lot about us. ;) Being mostly familiar with what is available in Haskell-world, I've started exploring the D-side (tools support, libs..) and then we'll know. Maybe something will change in regard to GUI support as well.
gour
+3  A: 

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).

Nylus
"I would say you should save yourself a lot of embarassment and choose D" - I did so and decided to use D for our project.
gour
A: 

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.

Lothar