Ask HN: Good languages for closed-source desktop apps
53 comments
I would give up on "cross platform" desktop apps and use whatever the native language is for the platform. For Windows, that's C#/.NET. For Mac, Objective C/Cocoa. For Linux, probably C/Gtk or C++/Qt.
The problem with cross-platform apps is that you end up programming to the least common denominator of the platforms you support, and your app never has the performance or look & feel that users expect. Contrast: uTorrent vs. Azureus, iChat vs. Pidgin, TextMate vs. jEdit, etc. In a hyper-competitive desktop space, that often means death. Giant companies like IBM (Eclipse) or Mozilla (Firefox) can get away with it because the scale of what they're doing is very difficult for a small startup to replicate, but most micro-ISVs can't.
Yes, this is one reason why developing desktop apps sucks.
The problem with cross-platform apps is that you end up programming to the least common denominator of the platforms you support, and your app never has the performance or look & feel that users expect. Contrast: uTorrent vs. Azureus, iChat vs. Pidgin, TextMate vs. jEdit, etc. In a hyper-competitive desktop space, that often means death. Giant companies like IBM (Eclipse) or Mozilla (Firefox) can get away with it because the scale of what they're doing is very difficult for a small startup to replicate, but most micro-ISVs can't.
Yes, this is one reason why developing desktop apps sucks.
And it's not like Firefox or Eclipse (or Photoshop, to pick a commercial example) feels anything like a first-class citizen on the Macintosh. I'm not sure that there's much of a percentage in making cross-platform apps, really. The platform idioms and user expectations are just too different. Pick one platform and do a kick-ass job.
EDIT: Brain-fart: Firefox != Mozilla.
EDIT: Brain-fart: Firefox != Mozilla.
I agree with everything nostrademons is saying, cross platfrom apps are bad. I did some java desktop apps about 4 or 5 years ago and the ui was awful. i think it's gotten a little better... but still, native app is going to look far superior.
And that might even matter for some audiences. It doesn't for all of them: BCC had 2x the conversion for installations on Mac (where it is, ahem, distinctly non-native) relative to Windows.
Whether it matters depends a lot on how competitive the market is. If your app is head and shoulders above the competition in functionality, users will put up with a little UI ugliness. If most of the apps in your market basically do everything the user wants, they're going to decide based on what is prettiest/most responsive, which is usually the native app.
I still remember discovering uTorrent. I'd tried about 4-5 Bittorrent apps before then, including 3 wxPython-based ones and Azureus. They also basically did what I needed - they let me download, they let me keep track of existing transfers, and they let me throttle bandwidth. The difference was that uTorrent didn't take up a few hundred megs of RAM and didn't peg my CPU. The developer accomplished this by doing an end-run around all the layers of abstraction and keeping an eye on performance; it's much harder to do this with a cross-platform library in the way.
I still remember discovering uTorrent. I'd tried about 4-5 Bittorrent apps before then, including 3 wxPython-based ones and Azureus. They also basically did what I needed - they let me download, they let me keep track of existing transfers, and they let me throttle bandwidth. The difference was that uTorrent didn't take up a few hundred megs of RAM and didn't peg my CPU. The developer accomplished this by doing an end-run around all the layers of abstraction and keeping an eye on performance; it's much harder to do this with a cross-platform library in the way.
u right patio11, bendmorris should really tell us who the target audience is.
Well, if Java means Swing, you are extrapolating from a very bad example. For instance, the Qt library looks pretty native on most platforms, and with some platform-specific code (e.g. proper support for application menus for OS X) Qt programs can also feel native.
I wrote some small Qt GUI applications (mostly frontends to scientific tools), and most people don't notice it's not native.
Also, this depends a bit on your market. Some markets are more sensitive to nativeness than others, for instance, by operating system:
OS X > Windows > Linux/UNIX
In OS X people are quite used to polished native applications that conform to Apple's HIG, they will also expect it. Windows is somewhere in the middle, there are some widely used applications that do not look native. Linux/UNIX users seem to be completely oblivious to nativeness, since they are used to having a mix of Qt/Gtk+/Tk/Lesstif/whatever applications.
I wrote some small Qt GUI applications (mostly frontends to scientific tools), and most people don't notice it's not native.
Also, this depends a bit on your market. Some markets are more sensitive to nativeness than others, for instance, by operating system:
OS X > Windows > Linux/UNIX
In OS X people are quite used to polished native applications that conform to Apple's HIG, they will also expect it. Windows is somewhere in the middle, there are some widely used applications that do not look native. Linux/UNIX users seem to be completely oblivious to nativeness, since they are used to having a mix of Qt/Gtk+/Tk/Lesstif/whatever applications.
C++ with QT or wxWidgets is highly portable.
http://www.wxwidgets.org/
http://www.wxwidgets.org/
Maybe so, but it's still gonna stick out like a sore thumb everywhere. Meaning annoyed users, meaning the app is never ever gonna become a buzz on blogs and shit, meaning low earnings.
I have a counterexample which comes immediately to mind, but he wouldn't appreciate being mentioned. So, trust me on this one: uses QT, well-beloved by a traditionally underserved market, is "a buzz on blogs and shit" for that community, now has a boatloat of competitors, and doing "quite well indeed."
Does last.fm's desktop client stick out like a sore thumb everywhere?
On a Mac it sure does.
QT has a style system that can closely match the target platform.
So does Java Swing, but that never stopped Java from sticking out like a sore thumb everywhere.
Users become very sensitive to the details of the windowing system, and when a program breaks their expectations, they often consciously recognize what's wrong with the program, they just get frustrated. I'm thinking of things as subtle as whether you can create and rename folders from within a Save As... box, or what the tab order of fields in a dialog is, or what cursor shows up when you drag & drop items. It's very easy to get the look & feel 99% right and still have users feel that something is still very wrong with the app.
Users become very sensitive to the details of the windowing system, and when a program breaks their expectations, they often consciously recognize what's wrong with the program, they just get frustrated. I'm thinking of things as subtle as whether you can create and rename folders from within a Save As... box, or what the tab order of fields in a dialog is, or what cursor shows up when you drag & drop items. It's very easy to get the look & feel 99% right and still have users feel that something is still very wrong with the app.
Maybe just a bad example, but the QT doc says:
QT is way better than Swing. It's a laughable comparison, really. QT does such a better job at being native.
On Windows, Mac OS X, KDE and GNOME, these static functions will call the native file dialog when possible.
QT is way better than Swing. It's a laughable comparison, really. QT does such a better job at being native.
You make a good point with regards to the native look. Is this really done in practice, creating different versions of the same app to target different platforms? Not only would that require duplicating the code, but in my case I'm familiar with .NET and C++ but have never touched Objective C. It seems like it would make the most sense then to only target Windows, which is something I'm reluctant to do (I'm a Linux guy at heart.)
If I had to do a cross-platform app, I would make a shared core in a language that can run on all platforms[1] and than a native UI in whatever language/toolkit is used for the platform. This way, the only duplication that is needed is the UI. And honestly, cross-platform UI toolkits never quite fit in properly anyway.
1. I'd personally use C. But, thats only because I'm more comfortable in C than any other cross-platform language (C++, Java or any other JVM-based language, etc).
1. I'd personally use C. But, thats only because I'm more comfortable in C than any other cross-platform language (C++, Java or any other JVM-based language, etc).
Transmission follows this approach somewhat, it has Cocoa, Qt, Gtk+, Web, and console frontends. All frontends use a shared 'backend' in the form of libtransmission (in C).
http://www.transmissionbt.com/
http://www.transmissionbt.com/
If you put a gun to my head and told me "Write another desktop app", I'd tell you "Java", but you'd have to put a gun to my head. Balsamiq has also sold me on AIR. Unless you have a specific business requirement for it being on the desktop, though, the web overwhelmingly favors your interests as a businessman.
Thoughts on this at length are on my blog -- and if anything, a year later I believe everything here more strongly: http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-a...
With specific reference to decompiling your source code: it doesn't matter, because a) your application will be pirated anyhow and b) there is no difference to the end user the mechanism by which the pirated version works. Also, you shouldn't be worried about piracy unless you're selling to twenty-something white and Asian males, in which case piracy is one of many business-sinking problems you have. (If you're really worried about piracy, can I recommend web apps again, or at the least an integrated server component? Pirating the client lets you pirate the application like downloading Firefox lets you pirate Basecamp.)
Thoughts on this at length are on my blog -- and if anything, a year later I believe everything here more strongly: http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-a...
With specific reference to decompiling your source code: it doesn't matter, because a) your application will be pirated anyhow and b) there is no difference to the end user the mechanism by which the pirated version works. Also, you shouldn't be worried about piracy unless you're selling to twenty-something white and Asian males, in which case piracy is one of many business-sinking problems you have. (If you're really worried about piracy, can I recommend web apps again, or at the least an integrated server component? Pirating the client lets you pirate the application like downloading Firefox lets you pirate Basecamp.)
Pretty much. Java + Eclipse + SWT. In our case it's swing because I don't wanna mess with 100% portability since we're doing webstart.
Eclipse makes Java feel "dynamic" since it auto-compiles with every keystroke. Brilliant stuff, really.
Having said that, our server side will remain in 100% Common Lisp on the JVM. Since it's the part that sees near daily updates, unlike the client GUI which is code and forget.
Eclipse makes Java feel "dynamic" since it auto-compiles with every keystroke. Brilliant stuff, really.
Having said that, our server side will remain in 100% Common Lisp on the JVM. Since it's the part that sees near daily updates, unlike the client GUI which is code and forget.
Your article was an excellent read, so thanks for the link. I generally agree with a lot of what you're saying.
My potential audience is pretty targeted - mainly research scientists and possibly some government workers. They'll likely be more computer savvy than the average user (on average, at least - some scientists I know are just as bad as Grandma.) What I worry about in considering a web app is:
1 - People want to be able to run the software anywhere, any time, without a connection to the internet.
2 - When entering large amounts of data, which is potentially sensitive, into an application, it seems like people would trust a desktop app more.
Number 2 is subjective, but as a scientist myself, I would feel better about a program running on my own machine.
Any thoughts?
My potential audience is pretty targeted - mainly research scientists and possibly some government workers. They'll likely be more computer savvy than the average user (on average, at least - some scientists I know are just as bad as Grandma.) What I worry about in considering a web app is:
1 - People want to be able to run the software anywhere, any time, without a connection to the internet.
2 - When entering large amounts of data, which is potentially sensitive, into an application, it seems like people would trust a desktop app more.
Number 2 is subjective, but as a scientist myself, I would feel better about a program running on my own machine.
Any thoughts?
The latest version of HTML has the ability to do offline apps. i.e. you write your application in Javascript as a webapp, and it can run offline. You can store data locally in the browser and get javascript notifications when you are back online so you can sync.
Have you worked with any non-Java JVM languages? I can understand your recommendation of the platform for this use case, but the Java language itself seems like a lot of extra pain for minimal gain over Scala or Clojure.
I do not disagree that Java is a major pain in the keister. I played around with JRuby and an MVC framework (Monkeybars) which let you code a Swing app in a more civilized fashion than actually coding Swing apps. The tradeoff is a 20MB hit to your download size, which would have mattered to me back when I started. These days that is less of an issue because folks typically have nigh-ubiquitous high speed Internet access, but there is a fairly straightforward way to take advantage of that which is superior in every fashion.
Patrick, BCC is a web app but you charge a one-time fee, correct? Doesn't that present a structural problem is sales tail off and you're on the hook to spin the servers indefinitely
I get asked that by desktop software people a lot. While the one-time fee wasn't my most brilliant business model move ever, there is no structural problem here. Very, very few of my customers use BCC on a year to year basis. (I have a loyal few dozen, but something like half use it twice or less.) If it became impossible for me to sustain BCC going forward, I'd turn off sales and then gracefully shutdown after six months of notice. If they complain after that, I'll write them a check for their purchase price so that they can use one of my competitors.
However, since software doesn't rot and the BCC monthly server fees are mouse droppings even when it is going gangbusters, I could probably arrange for someone to support it for my entire natural life and beyond.
However, since software doesn't rot and the BCC monthly server fees are mouse droppings even when it is going gangbusters, I could probably arrange for someone to support it for my entire natural life and beyond.
[deleted]
Machine code can be decompiled too, even if not as cleanly. It would slow down efforts to make an unauthorized fork of the software as a whole, but anyone curious enough about individual bits and pieces could still see exactly what's happening. Closed source is really more of a legal block than a technical one.
Given that and the lack of popular, high-level languages that compile to machine code (C++ is the best I can come up with), I'd reconsider whether that's really a priority.
Given that and the lack of popular, high-level languages that compile to machine code (C++ is the best I can come up with), I'd reconsider whether that's really a priority.
True that any program can be reverse engineered. But for example with Python, you're not just handing them the program, but also the bytecode, which can be turned into source without spending much time. This gives a lot more information much faster.
I would prefer something like C++ which is about as obfuscated as you're going to get, but I'm curious if there are any higher level options that would save programming time.
I would prefer something like C++ which is about as obfuscated as you're going to get, but I'm curious if there are any higher level options that would save programming time.
Some, they are usually more obscure, e.g.:
- D
- Haskell
- OCaml
- Various Scheme/Common Lisp compilers
Some of them have Qt bindings (e.g. QtD and QtHaskell). Though it may be harder to hire programmers for any of these languages.
- D
- Haskell
- OCaml
- Various Scheme/Common Lisp compilers
Some of them have Qt bindings (e.g. QtD and QtHaskell). Though it may be harder to hire programmers for any of these languages.
I personally like C#.
If you use Gtk for the GUI, it's cross platform using Mono. Lots of closed and open source widgets, easy to write your own, and runs very quickly.
IMHO, the networking stack in C# is much more robust and provides better performance than in Java, and you can static link the runtimes to the app, making deployment of installer-free apps relatively easy using embedded resources.
Cheers! Randy
If you use Gtk for the GUI, it's cross platform using Mono. Lots of closed and open source widgets, easy to write your own, and runs very quickly.
IMHO, the networking stack in C# is much more robust and provides better performance than in Java, and you can static link the runtimes to the app, making deployment of installer-free apps relatively easy using embedded resources.
Cheers! Randy
High-level languages are hard to obfuscate. If you're going for difficulty in decompilation, you're pretty much stuck to low-level, non-interpreted languages.
.NET and Java are your best bets for relatively high-level desktop languages that are hard to decompile because since they're so widely used, obfuscation techniques are more advanced. But really if you want to create a difficult-to-decompile program, I think you're pretty much stuck with C or other non-interpreted, low-level languages (maybe try D?).
.NET and Java are your best bets for relatively high-level desktop languages that are hard to decompile because since they're so widely used, obfuscation techniques are more advanced. But really if you want to create a difficult-to-decompile program, I think you're pretty much stuck with C or other non-interpreted, low-level languages (maybe try D?).
C++ and QT
http://qt.nokia.com/
http://qt.nokia.com/
LispWorks with CAPI, here is some software written with it:
http://weitz.de/regex-coach/
http://www.netfonds.no/manual_pt_eng.php
http://lisp.ystok.ru/ygrid/index.html
or check on their page - http://www.lispworks.com/success-stories/index.html
I've started doing some small Perforce p4win clone in it - github.com/malkia/p4bee - it contains source code and binaries.
He might need to take a year off to master Common Lisp though.
Dunno, a year off sounds nice, but you don't need to wait that long to be competitive. Better find a GUI and an obfuscation solution for a language you already know now, than to dick around with new languages when you have a product to finish and ship.
If I must. I would do the app in Python or whatever, then spend 2-3 weeks designing my own custom loader. Some C-based stub code packer that load a python interpreter as a shared library then my code. Wrap everything up with some compression and verify integrity with some crypto.
Nearly every embedded scripting language can be shoe-horned with custom packer like this that looks a lot like Java's ClassLoader. If you want to take this to its engineering extreme, you might even be able to get remote binary update functionality, by fetching packed tarballs of new code from your server, after the necessary key exchange.
Dunno, a year off sounds nice, but you don't need to wait that long to be competitive. Better find a GUI and an obfuscation solution for a language you already know now, than to dick around with new languages when you have a product to finish and ship.
If I must. I would do the app in Python or whatever, then spend 2-3 weeks designing my own custom loader. Some C-based stub code packer that load a python interpreter as a shared library then my code. Wrap everything up with some compression and verify integrity with some crypto.
Nearly every embedded scripting language can be shoe-horned with custom packer like this that looks a lot like Java's ClassLoader. If you want to take this to its engineering extreme, you might even be able to get remote binary update functionality, by fetching packed tarballs of new code from your server, after the necessary key exchange.
Sounds cool. Any examples of people who have done something similar?
[deleted]
I used to crack sharewares and commercial apps as a kid. Of course I haven't seen anything like that, nope, no sah!
[Edit:
Ok, I have started hacking something up as proof of concept. Leave an email in your profile or shoot me one.
]
[Edit:
Ok, I have started hacking something up as proof of concept. Leave an email in your profile or shoot me one.
]
Put my email in my profile - I'm interested to see it.
Why not use cython and do only the sensitive stuff in c?
It is really interesting that the gui problem still isn't solved after so many years. Personally i think microsoft made the right thing by really decoupling design from code. I'm not using windows tough...
It is really interesting that the gui problem still isn't solved after so many years. Personally i think microsoft made the right thing by really decoupling design from code. I'm not using windows tough...
Freepascal + Lazarus for win/mac/linux desktop apps, if you dig pascal language.
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...
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.
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.
I believe the Haskell interface to wxWidgets is reasonably mature and widely-used (as Haskell libraries go).
Why would it be a stretch? (I've never been exposed to Haskell before.)
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.
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.
Yes, monads can be hard to get in the beginning, but they never felt like tricking the compiler to me.
If it's for Windows only WPF/Silverlight in C# is probably the most productive platform.
if you do go with the java desktop app, use the absolute layout. those complex layouts were very difficult to change.
Python + Titanium from Appcelerator
Air
Python + QT
Air
Python + QT
PyQt is nice, but damn, the other two are ugly slow dogs.
I just removed Air yesterday, and Appcelerator needs a bit more work.
I just removed Air yesterday, and Appcelerator needs a bit more work.
Air isn't the snappiest, but it works, and you can easily hire programmers to continue developing in it.
Appcelerator I'm less certain on, but they do seem to keep tossing effort at things.
Appcelerator I'm less certain on, but they do seem to keep tossing effort at things.
> I'm a Linux guy at heart
If you are going to use GTK+, take a look at Vala [1]. It's a C#-like language which is compiled into C. Much saner than coding in C. You can easily port your app to Windows/OSX, but, as others noted, non-native UI will be far from perfect.
I'm using this approach in an open-source project of mine [2], feel free to borrow the ideas.
[1] http://live.gnome.org/Vala
[2] http://www.spek-project.org/
If you are going to use GTK+, take a look at Vala [1]. It's a C#-like language which is compiled into C. Much saner than coding in C. You can easily port your app to Windows/OSX, but, as others noted, non-native UI will be far from perfect.
I'm using this approach in an open-source project of mine [2], feel free to borrow the ideas.
[1] http://live.gnome.org/Vala
[2] http://www.spek-project.org/
I'm looking for a high-level, efficient language, but it needs to be able to compile to machine code. For example, while I love Python, I would eliminate it here because an app "frozen" by cx_freeze or py2exe can be decompiled into source without too much effort.