Hacker News new | comments | show | ask | jobs | submit login

Looks like lots of time wasted in pro of "java developers" who can't be bothered to leave their confort zone and learn something else.

That and the demotion of native code in Android (native code there calls Java libraries) really make me question a lot of things.

There are a lot more Java libraries than Objective-C libraries. Especially at Google.

We write a lot of Java at Google, but I wouldn't call anyone a "Java programmer". We're just programmers. And like all programmers, if we can save time by writing a tool and letting the computer do some work, we will. Laziness, impatience, hubris, and all that.

My 5-engineer team at Google all write java day-to-day. But we've all needed to write python, especially scripts, and have it properly checked in and maintained. Not sure how you could get by most places in the company without being able to do that. Besides, skill in other languages is an asset; I've written C++ client library code to push for broader adoption of my project.

Well, Google is a different game, and I'm sure most programmers there are versed in at least a couple of languages.

But some (most Java devs?) devs look like they are "only Java" right now.

This is a Google project. I'm refuting the idea that we're loaded with "java developers" who can't step outside their skillset.

Actually this has nothing to do with Java developers, as much as people here likes to look down on them.

This has to do with calling a single command and blasting out an app for IOS once you have already written an app for Android.

If you note carefully Google could have done it the other way around, by implementing IOS shims on top of Android.

This would have been easier (as Google controls Android) and because Objective C code is low level code that is easier to port to high level Java code.

And it would have given an incentive to those who have already written IOS apps to port them to Android.

So why not do it that way? Because then everybody would develop for IOS first and Android second and few people would use the Android specific features. By going from Android to IOS, Android is the primary system, but Google still lover the cost of development of Android apps by having the IOS market articficially subsidise it.

It is the classing Jole post (http://www.joelonsoftware.com/articles/StrategyLetterV.html) with the twist that Google is lower the price of the complements to its complements (ie. smart phones are complements to Google ads and apps are complements to smart phones).

While there's a ton of Android apps, I'm pretty sure there's already a large part that targets iOS first simply because of how long iOS/app store has been around compared to Android.

Not to mention the iOS SDK is much nicer.

I think this is debatable. It's lamentable seeing it said as a truism without supporting information.

Speaking as someone who has developed on both platforms, it's definitely my experience. And that includes starting with an Android app and porting it to iOS - half of the stuff I had to add to Android to make it usable I discovered they had already built into iOS. Not to mention the poor choice of defaults, coping with device fragmentation, and the difficulty making Android apps look attractive via-a-vis iOS.

I haven't built ICS apps, though, so perhaps it's getting better.

It will be so much better to have Objective C Runtime on Android. I haven't seen any java based Android apps that run smoother than Google Chrome on Android, which I highly suspect that it was built using C/C++ instead of Java.

Learning ObjC is a one-time cost I've already paid. The problem is being continually confronted with all the compromises it made against safety and readability just to rush out semi-usable implementations thirty years ago. It's no longer necessary to regress to C and risk crashes and random misbehavior from unchecked pointer arithmetic and integer overflow and uninitialized memory, and debugging that (while sometimes fascinating) has long been a poor use of hackers' time.

How so? Looks like an opportunity to have some common code between the two platforms to me. Write your view layers twice. If you have a large amount of business logic write it once in Java and then part of the build or checkout process for iOS can be to translate this code to objective-c.

I've recently been diving into mobile dev and the short list of good options on having a common code base between the platforms seems so strange to me.

Actually common code on 4 platforms. We share Java code between the server, the web (via GWT), Android (already runs Java natively), and now iOS (via j2objc).

That's basically the reason for this. We have huge amounts of Java libraries, and we want to create and ship out features on 3 platforms simultaneously. Not having to write, say, an Operational Transform library 3 different times (JS, Java, and Objective-C) and keep them constantly in sync will go a long way.

Or it's a free tool that will save time for some developers who aren't "pro" Obj-C developers. Not much to complain about.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact