10 ms·

The nice thing about Android is you don't have to use Java. Many other languages target the JVM, which is often trivial to convert to Dalvik (it depends on the

by vito 16y ago

The nice thing about Android is you don't have to use Java. Many other languages target the JVM, which is often trivial to convert to Dalvik (it depends on the language). Right now I'm working on an entire app in Duby (a Ruby-like language with static typing and type inference, with no baggage; reaches native Java speed easily), and loving it. All I had to do was change my compile command to dubyc and I was ready to go. JRuby is in the works, and apparently Scala is possible, and I'm sure many others are working on it too. I've never written an iPhone app, and this is my first Android app, but I find the API and the SDK to be perfectly easy to work with; it was very easy to get started and quickly start prototyping. I'd like to know what parts of the Cocoa APIs you consider delightful though, just out of curiosity.

amock 16y ago
What makes Cocoa and Cocoa Touch really nice isn't that parts of them are delightful, it's that all of the parts work really well together. They were written to take advantage of Objective-C and the tools were built for using them. Interface builder makes UIs really easy and CoreData makes persistence almost automatic. You should try building an iPhone app and see how it compares.
- orangecat 16y ago
  You should try building an iPhone app and see how it compares. I have, and Android wins for me. Cocoa Touch is a decent API (in most cases; what's with NSImage vs CGImage vs CIImage?), but Objective-C is seriously outdated. It usually needs more boilerplate than even Java, and manual memory management, lack of namespaces, and header files are silly in 2010.
  - KirinDave 16y ago
    Well ObjC straddles a very interesting place. It's as low-level as C++ but has high level message passing method dispatch as well. If it seems a little crufty, it's because it's living in a very peculiar place trying to serve a variety of masters. Hopefully 4.0 will start to pave the way for the ObjC2.0 stuff to come to iPhone. They are really big improvements to the language. Also, rule-based syntax translators could give you a ton of stuff as a preprocessing pass to your code. Write something for NSArray literals and you'll be a hero.
    - crux_ 16y ago
      Isn't one of the big problems here that "rule-based syntax translators" are kind of disallowed?
      - KirinDave 16y ago
        Not if they produce straightforward objective c. How would one even separate such code generation from the use of regular #define?
        daeken 16y ago
        You're right, they couldn't tell. But that doesn't mean they're not disallowed -- unless you're writing C, C++, Obj-C, or Javascript, it's disallowed, period. But that doesn't mean people won't do it.
        KirinDave 16y ago
        I'm not sure I agree that code translation is entirely disallowed. Part of the problem, though, is that the legalese in the iphone 4 revision is maddeningly obscure and unhelpful. We're not even sure if embedded Lua interpreters are really banned. I'm sure Apple is considering that very question.
    - elai 16y ago
      Yes, something to replace the super crufty NSArray / NSMutableArray / NSSet / NSDictionary, syntax would be really good. Small talk message passing was meant to have short, small one symbol binary operators, but unfortunately that elegance is not there in objective c.
      - glhaynes 16y ago
        Over the life of the code, I'm only gonna type it once; I may read it a hundred times.
        16y ago
  - swannodette 16y ago
    > more boilerplate than Java whatever. Objective-C is far closer to the elegant dynamism of SmallTalk than Java. > manual memory management Makes sense. This is a resource constrained device. > lack of namespaces This is a phone not an enterprise server. > header files On a device with an underpowered processor the focus on C-based languaged has been paying back serious dividends as far as the responsiveness of the platform's applications.
  - umjames 16y ago
    Assuming we're only talking about the iPhone APIs, then there's no NSImage or CIImage (Mac OS X desktop only). As for UIImage and CGImageRef, which are on the iPhone, UIImage is an Objective-C class, whereas CGImageRef is a C opaque struct. CGImageRef comes from the CoreGraphics (aka Quartz) lower-level 2D drawing APIs (implemented using C functions). This framework was around before the iPhone as it is also found in the Mac OS X APIs. UIImage gives you the ability to use a CGImageRef as an object. It doesn't expose all of the functionality found at the CoreGraphics layer, but it can be easier to use with other ObjC classes.
    - orangecat 16y ago
      You're right, I was thinking of desktop Mac OS X there, and an especially annoying section of code where I was trying to get those three image APIs to talk to each other. Apple did in fact remove a lot of cruft and duplication in the iPhone API, and that's good. Still, there are a number of cases like that where you have to switch between ObjC method calls and straight C functions. Not a huge deal, but it's clearly not the SmallTalk-style pure OO.
- vito 16y ago
  I would try it out, but right now my iPhone is on Craigslist and a Nexus One is in the mail. :) I run Linux so that wouldn't be very easy to do anyway. Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts). I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well. Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.
  - catch23 16y ago
    You know, interface builder existed before the iPhone. Developers used it to build out interfaces for Mac applications which could run on devices with a big variety of screen sizes. Interface builder is screen size agnostic for the most part. When apple first released 3rd party app support, their iphone sdk didn't even support interface builder.
    - vito 16y ago
      I never said IB was iPhone-specific or made for it. I'd used it myself before that. Why are iPhone apps upscaled or letterboxed on the iPad, though?
WildUtah 16y ago
Scala and Clojure run like molasses on Dalvik and JRuby will likely be the same. The Dalvik VM that Android targets is not like the JVM and one of its deficiencies is that it supports dynamic languages very poorly. Duby may run fine on JVM but if it's really Ruby-like, it'll be bad on Android. No. If you want to write professional-quality apps on Dalvik, you'll be writing in Java or another language just as weak in imagination and straitjacketed. Which is not to say that Objective-C is an improvement. At least iPhone apps used to offer Lua or even Scheme scripting. No longer.
- Markr 16y ago
  Duby compiles to Java. So the performance is identical to Java.
  - ptomato 16y ago
    X compiles to assembly, so the performance is identical to assembly.
  - catch23 16y ago
    I doubt this. Any language could compile to Java, but that doesn't mean the performance will be the same. Technically, every language compiles down to assembly, but only apps written in assembly can compare in speed usually.
- vito 16y ago
  Duby has been absolutely great on Dalvik so far. Like I said, Duby is not a dynamic language, it just provides one of its main benefits through type inference and a drastically less verbose syntax. I translated the same code from Java to Duby (reducing its size and making it a whole lot more fun to work with) and noticed absolutely no drawbacks. That's not to say there weren't any speed decreases, but if there were they were too small for me or anyone to care about. Do you have any benchmarks or references for Scala and Clojure's speed on Dalvik? I haven't been able to find much. (That's curiosity, not snootiness.)
- strlen 16y ago
  Scala is more statically typed then Java. It's not a dynamic language, type inference (what makes it look like Ruby to some) is done by the compiler. Modern (i.e., based on concepts dating back to late 70s and 80s instead of 60s and early 70s) statically typed languages don't have to the have the verbosity of Java and C++: see F#, OCaml and Haskell. It does use reflection for certain types of pattern matching (only similarity with the JVM dynamic languages), but I'd expect most of the issues (note: I haven't tried myself) are due to the Scala compiler specifically targeting HotSpot.
halostatue 16y ago
When a non-Java language is considered a first-class citizen for Android by the Android development team, I will consider developing for it. I applaud the external efforts to do other languages, but unless they're "blessed", they have too great a chance of disappearing.

by vito 16y ago

amock 16y ago

What makes Cocoa and Cocoa Touch really nice isn't that parts of them are delightful, it's that all of the parts work really well together. They were written to take advantage of Objective-C and the tools were built for using them. Interface builder makes UIs really easy and CoreData makes persistence almost automatic. You should try building an iPhone app and see how it compares.

orangecat 16y ago
You should try building an iPhone app and see how it compares. I have, and Android wins for me. Cocoa Touch is a decent API (in most cases; what's with NSImage vs CGImage vs CIImage?), but Objective-C is seriously outdated. It usually needs more boilerplate than even Java, and manual memory management, lack of namespaces, and header files are silly in 2010.
- KirinDave 16y ago
  Well ObjC straddles a very interesting place. It's as low-level as C++ but has high level message passing method dispatch as well. If it seems a little crufty, it's because it's living in a very peculiar place trying to serve a variety of masters. Hopefully 4.0 will start to pave the way for the ObjC2.0 stuff to come to iPhone. They are really big improvements to the language. Also, rule-based syntax translators could give you a ton of stuff as a preprocessing pass to your code. Write something for NSArray literals and you'll be a hero.
  - crux_ 16y ago
    Isn't one of the big problems here that "rule-based syntax translators" are kind of disallowed?
    - KirinDave 16y ago
      Not if they produce straightforward objective c. How would one even separate such code generation from the use of regular #define?
      - daeken 16y ago
        You're right, they couldn't tell. But that doesn't mean they're not disallowed -- unless you're writing C, C++, Obj-C, or Javascript, it's disallowed, period. But that doesn't mean people won't do it.
        KirinDave 16y ago
        I'm not sure I agree that code translation is entirely disallowed. Part of the problem, though, is that the legalese in the iphone 4 revision is maddeningly obscure and unhelpful. We're not even sure if embedded Lua interpreters are really banned. I'm sure Apple is considering that very question.
  - elai 16y ago
    Yes, something to replace the super crufty NSArray / NSMutableArray / NSSet / NSDictionary, syntax would be really good. Small talk message passing was meant to have short, small one symbol binary operators, but unfortunately that elegance is not there in objective c.
    - glhaynes 16y ago
      Over the life of the code, I'm only gonna type it once; I may read it a hundred times.
      - 16y ago
- swannodette 16y ago
  > more boilerplate than Java whatever. Objective-C is far closer to the elegant dynamism of SmallTalk than Java. > manual memory management Makes sense. This is a resource constrained device. > lack of namespaces This is a phone not an enterprise server. > header files On a device with an underpowered processor the focus on C-based languaged has been paying back serious dividends as far as the responsiveness of the platform's applications.
- umjames 16y ago
  Assuming we're only talking about the iPhone APIs, then there's no NSImage or CIImage (Mac OS X desktop only). As for UIImage and CGImageRef, which are on the iPhone, UIImage is an Objective-C class, whereas CGImageRef is a C opaque struct. CGImageRef comes from the CoreGraphics (aka Quartz) lower-level 2D drawing APIs (implemented using C functions). This framework was around before the iPhone as it is also found in the Mac OS X APIs. UIImage gives you the ability to use a CGImageRef as an object. It doesn't expose all of the functionality found at the CoreGraphics layer, but it can be easier to use with other ObjC classes.
  - orangecat 16y ago
    You're right, I was thinking of desktop Mac OS X there, and an especially annoying section of code where I was trying to get those three image APIs to talk to each other. Apple did in fact remove a lot of cruft and duplication in the iPhone API, and that's good. Still, there are a number of cases like that where you have to switch between ObjC method calls and straight C functions. Not a huge deal, but it's clearly not the SmallTalk-style pure OO.
vito 16y ago
I would try it out, but right now my iPhone is on Craigslist and a Nexus One is in the mail. :) I run Linux so that wouldn't be very easy to do anyway. Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts). I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well. Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.
- catch23 16y ago
  You know, interface builder existed before the iPhone. Developers used it to build out interfaces for Mac applications which could run on devices with a big variety of screen sizes. Interface builder is screen size agnostic for the most part. When apple first released 3rd party app support, their iphone sdk didn't even support interface builder.
  - vito 16y ago
    I never said IB was iPhone-specific or made for it. I'd used it myself before that. Why are iPhone apps upscaled or letterboxed on the iPad, though?

WildUtah 16y ago

Scala and Clojure run like molasses on Dalvik and JRuby will likely be the same. The Dalvik VM that Android targets is not like the JVM and one of its deficiencies is that it supports dynamic languages very poorly. Duby may run fine on JVM but if it's really Ruby-like, it'll be bad on Android. No. If you want to write professional-quality apps on Dalvik, you'll be writing in Java or another language just as weak in imagination and straitjacketed. Which is not to say that Objective-C is an improvement. At least iPhone apps used to offer Lua or even Scheme scripting. No longer.

Markr 16y ago
Duby compiles to Java. So the performance is identical to Java.
- ptomato 16y ago
  X compiles to assembly, so the performance is identical to assembly.
- catch23 16y ago
  I doubt this. Any language could compile to Java, but that doesn't mean the performance will be the same. Technically, every language compiles down to assembly, but only apps written in assembly can compare in speed usually.
vito 16y ago
Duby has been absolutely great on Dalvik so far. Like I said, Duby is not a dynamic language, it just provides one of its main benefits through type inference and a drastically less verbose syntax. I translated the same code from Java to Duby (reducing its size and making it a whole lot more fun to work with) and noticed absolutely no drawbacks. That's not to say there weren't any speed decreases, but if there were they were too small for me or anyone to care about. Do you have any benchmarks or references for Scala and Clojure's speed on Dalvik? I haven't been able to find much. (That's curiosity, not snootiness.)
strlen 16y ago
Scala is more statically typed then Java. It's not a dynamic language, type inference (what makes it look like Ruby to some) is done by the compiler. Modern (i.e., based on concepts dating back to late 70s and 80s instead of 60s and early 70s) statically typed languages don't have to the have the verbosity of Java and C++: see F#, OCaml and Haskell. It does use reflection for certain types of pattern matching (only similarity with the JVM dynamic languages), but I'd expect most of the issues (note: I haven't tried myself) are due to the Scala compiler specifically targeting HotSpot.

halostatue 16y ago

When a non-Java language is considered a first-class citizen for Android by the Android development team, I will consider developing for it. I applaud the external efforts to do other languages, but unless they're "blessed", they have too great a chance of disappearing.