News for hackers. Stuff that matters.
Re:Ask HN: Good languages for closed-source desktop apps by pshc on Saturday October 02, 2010 @06:01PM (#1751456)
Haskell is high-level, fast, and its optimized machine code would be nigh impossible to decompile in my opinion. Unfortunately it'd be a bit of a stretch to write a large GUI app in Haskell at this point...
Re:Ask HN: Good languages for closed-source desktop apps by wtracy on Saturday October 02, 2010 @06:10PM (#1751477)
I know there's GTk+ bindings for Haskell. I don't know if there's any others.

Can anyone comment on the quality of the GTk+ bindings, or the existence of any other bindings?

I have enough experience with GTk+ from C and Python to say that it creates really nice, snappy UIs under Linux, but it's really hard to make it "feel right" under Windows, and pretty much impossible to make it "feel right" under OS X. On those platforms, it will almost always stand out the same way that Java apps do.

I'll also say that Haskell, while awesome, is a PITA to learn.

Re:Ask HN: Good languages for closed-source desktop apps by Zak on Saturday October 02, 2010 @06:20PM (#1751499)
I believe the Haskell interface to wxWidgets is reasonably mature and widely-used (as Haskell libraries go).
Re:Ask HN: Good languages for closed-source desktop apps by bendmorris on Saturday October 02, 2010 @06:02PM (#1751459)
Why would it be a stretch? (I've never been exposed to Haskell before.)
Re:Ask HN: Good languages for closed-source desktop apps by Zak on Saturday October 02, 2010 @06:09PM (#1751472)
UI operations, and IO in general tend to feel a bit out of place in Haskell. It often feels like you're trying to trick the compiler in to accepting your program instead of just saying what you mean. That said, if you can cleanly separate logic and presentation in your code, it might not be too bad.
Re:Ask HN: Good languages for closed-source desktop apps by danieldk on Saturday October 02, 2010 @08:34PM (#1751746)
Actually, I think I/O is really clear in Haskell. Haskell is a pure functional language, and in that world side-effects are not possible (since a function should always return the same value, given the same input). For this reason functional languages like Haskell introduce monads, which allow you to model imperative languages (with state and order). I/O is performed in one such monad (the IO monad), and programming in the IO monad just looks like imperative programming. The tricky part is that you cannot get pure values out of the IO monad (since it is impure), which may entice programmers to let the IO monad 'leak' intro programs to much, rather than lifting pure functions into the monad.

Yes, monads can be hard to get in the beginning, but they never felt like tricking the compiler to me.