Hacker News Reader

Comment by axod | Hacker News Reader

It's an interesting idea that the language choice is somehow related to the quality of apps produced, and an excuse for another "Java sucks!" rant, but has pretty much no basis in reality.

The article doesn't seem to mention the millions of J2ME games available on run-of-the-mill phones, which are pretty high quality. So the argument that it must be Java's fault is completely misguided.

Just one 'top list' of J2ME games available, showing some pretty professional titles, by big names and small alike:

http://www.jamster.com/fw/goto/games

More likely to be the fact android is still relatively new, comparatively small market size, etc that is keeping more professional game/app developers away from it. But I'm sure it'll mature if the market size increases.

Please get away from this "Languages are soooooo important!!!" bs. Languages just don't matter. They don't.

View on HN

"Languages just don't matter. They don't."

I find this discussion very intriguing in light of Apple's now-infamous ToS clause 3.3.1 (can only use C/C++/ObjC on the iPhone). So is okay that Apple's limiting the languages you can use, because they doesn't matter? Or is this still evil on Apple's part for trying to be restrictive?

I'm not trying to troll here; I'm honestly interested in people's opinions.

That clause is Apple's attempt to prevent a flood of low-quality ported apps. Therefore the argument would be that if languages don't matter, Apple's policy is misguided, and if languages do matter, Apple's policy actually makes sense. (Neither position has any connection with the evilness/goodness of said policy).

Personally I tend to believe that languages do matter, and therefore Apple's policy makes sense as a way to prevent crappy ported apps, but it's still evil. It's not impossible to produce a great ported app, just more difficult; plus, porting apps isn't the only reason why you might want to run non-Objective-C code.

>porting apps isn't the only reason why you might want to run non-Objective-C code.

The Objective-C language being one very good reason for wanting to run non-Objective-C code.

Frankly, I'd much rather they adopted a direct appstore policy to reject apps that don't feel native or performant enough, rather than coming up with a second level of indirection that assumes all apps not written in their approved language of choice has those qualities.

That's exactly the sort of ambiguity people have been complaining about with the app store since it started. Nobody wants to be left guessing about what they have to change to get an app approved.

Yes, I don't like that either. But its better than painting everyone with a broad stroke.

It's no different from saying 'the last 10 apps that were submitted from Podunk were all poor, so no developer from Podunk is allowed to write iPhone apps'

Languages are just tools, but the ones I've been using have had an impact on the evolution of my coding.

Java is really great for server apps, but I've yet to see a desktop app that is reasonably performant. Ok, Eclipse is not horrible, but it takes about 2 GB of RAM. I don't know what it is about the SDK or language, or people who write software for it, but it seems impossible to produce a reasonably performant java desktop app.

We're talking apples vs oranges here.

I'm with you - Java doesn't excel particularly on conventional PC desktop apps. But that's a world away from mobile apps.

The vast majority of run-of-the-mill phones run Java J2ME apps very well.

For example:

http://www.jamster.com/fw/goto/games

The top games are pretty high quality. But the rant against Java fails to mention the billions of J2ME games downloaded... convenient.

It hasn't been my experience, especially since the JVM's parameters need to be tweaked for it to accept that much memory ... the heap size is limited by default because the JVM doesn't release free memory to the operating system.

In practice the JVM does quite well on memory usage, its only flaw being that it doesn't release memory back. If your Eclipse instance ends up using 2 GB that's because it does lots of stuff and needs 2 GB of memory.

Either way, Eclipse is comparable in memory usage with Visual Studio, which has most of its components written in C++.

The only problem with using Java for desktop apps is with native integration with the OS ... Java GUI toolkits suck badly, except one which isn't really popular ... Qt Jambi.

But in the case of Android, this discussion is not really relevant ... they use their own VM that has different optimization goals (so any comparison to the JVM is apples vs oranges), and every component you use is native to Android.

the JVM doesn't release free memory to the operating system.

Not true. The Sun/Oracle JVM at least most definitely releases free memory. It's just rather reluctant to do so - but that, too, can be tweaked via the -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio parameters

Java performance just isn't straightforward. Startup time alone really taints the perception of an app before you get to working with it. Another sore spot is resource loading. Once the JVM is all warmed up it's generally humming along at a great pace, computationally speaking.

Check out Processing for a nimble Java app.

It's quite possible to create responsive Java desktop apps. It's just that it takes an experienced Swing developer who has learned all the hard lessons about building that type of app.

That said, yes, many Java developers write bad code, but so do developers who write in other languages. Java just gets a higher profile because unfortunately the Java community has a tradition of writing libraries and APIs that sacrifice usability for flexibility (that's the kindest way I can put it, anyway).

Slightly off-topic: Am I the only one who feels that Eclipse is the IDE equivalent of a hair shirt? I find its UI sluggish, its insistence on imposing its ideas about project management on you irritating, and to be generally overcomplicated. To me, NetBeans, former versions of IntelliJ, and VS are much nicer products (mind you, half the time I still just use an text editor though).

Regarding IDEs, after using eclipse for years, I recently tried Netbeans and found its UI sluggish, its ideas about project management on you irritating, and its configurability sorely lacking...

In my experience when working with Java the old Borland JBuilder worked well and was reasonably responsive, Eclipse was a pig no matter how I tweaked it, Netbeans kept me happy.

I'd like to know what you think about my desktop Java apps, fleitz. Do note that the apps are not fully functional, but that's my shortcomings, not Java's:

http://www.assembla.com/wiki/show/jtuils

IDEs are a special case, and not necessarily representative of the platform -- they're trading memory for speed on purpose. Cross-referencing and API lookups have to be fast, memory footprint is far less important.

Something like the Eclipse RCP mail app demo could provide a more representative baseline memory footprint of the platform (http://www.eclipse.org/articles/Article-RCP-3/tutorial3.html). The Eclipse platform can be quite compact without the IDE features, JDT & online help indexing, etc.

> Languages just don't matter. They don't.

Explain recursion in Applesoft (or any other 8-bit) BASIC.

The tools I have used have, yes, deeply impacted my professional development.

Had I not seen Smalltalk in mid 80's, I would have liked C++. Had I not seen Python and Zope, I would find Java and servlets and all the stuff built on them cool.

Edit: Had I not learned APL (and, to a lesser degree, Perl), I would not write program as well documented as I do now.

Reply on news.ycombinator.com