Ask HN: Good languages for closed-source desktop apps

https://news.ycombinator.com/item?id=1751372

by bendmorris • 16 years ago

15 51 16 years ago

news.ycombinator.com

Just wanted to get some opinions on this - if your goal is to write closed source, cross platform desktop apps, what are some good languages to consider?

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.

cookiecaper• 16 years ago

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

Vargas2• 16 years ago

C++ and QT

http://qt.nokia.com/

nostrademons3• 16 years ago

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.

Vargas2• 16 years ago

C++ with QT or wxWidgets is highly portable.

http://www.wxwidgets.org/

joey_bananas• 16 years ago

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.

andrewtbham3• 16 years ago

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.

patio115• 16 years ago

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.

microtonal4• 16 years ago

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.

jfb• 16 years ago

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.

bendmorris6• 16 years ago

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

Zev• 16 years ago

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

microtonal4• 16 years ago

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/

gdl• 16 years ago

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.

bendmorris6• 16 years ago

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.

microtonal4• 16 years ago

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.

pshc• 16 years ago

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

bendmorris6• 16 years ago

Why would it be a stretch? (I've never been exposed to Haskell before.)

Zak3• 16 years ago

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.

wtracy• 16 years ago

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.

Zak3• 16 years ago

I believe the Haskell interface to wxWidgets is reasonably mature and widely-used (as Haskell libraries go).

patio115• 16 years ago

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

Zak3• 16 years ago

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.

patio115• 16 years ago

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.

mahmud4• 16 years ago

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.

bendmorris6• 16 years ago

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?

rmc• 16 years ago

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.

gte910h2• 16 years ago

Python + Titanium from Appcelerator

Air

Python + QT

mahmud4• 16 years ago

PyQt is nice, but damn, the other two are ugly slow dogs.

I just removed Air yesterday, and Appcelerator needs a bit more work.

gte910h2• 16 years ago

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.

malkia• 16 years ago

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.

mahmud4• 16 years ago

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.

bendmorris6• 16 years ago

Sounds cool. Any examples of people who have done something similar?

ecommando• 16 years ago

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

andrewtbham3• 16 years ago

if you do go with the java desktop app, use the absolute layout. those complex layouts were very difficult to change.

mfinas• 16 years ago

Freepascal + Lazarus for win/mac/linux desktop apps, if you dig pascal language.

yawniek• 16 years ago

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

alexkay• 16 years ago

> 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/

woan• 16 years ago

If it's for Windows only WPF/Silverlight in C# is probably the most productive platform.

Ask HN: Good languages for closed-source desktop apps

Related Stories