4 ms·

That's a little misleading. Managed code/Silverlight on WPS7 is the equivalent of the iPhone SDK. How low-level does this guy want to go?

by johns 17y ago

martythemaniak 17y ago
Kinda funny coming from an Android-centric blog, since by that definition, Android's Java-on-Dalvik apps aren't "native" either.
- rbanffy 17y ago
  AFAIK you can write native apps for Android. It's just that they won't run on every Android phone, but will be tied to specific architectures (not a big problem since all Android phones seem to use ARM).
wtallis 17y ago
iPhone apps are compiled down to ARM machine code. .NET managed code is bytecode for the CLR virtual machine. That's a significant difference.
- johns 17y ago
  OK, technically it is different. In practice, it isn't. If you want to build on the iPhone, the SDK gives you an API to use the phone's features. If you want to program against WPS7 you're getting a version of Silverlight with APIs to give you access to the phones features. Both are abstractions over a lower-level. Both are native to the phone (as opposed to web apps, which is the common distinction made on the iPhone).
  - bensummers 17y ago
    Using the CLR "future proofs" it. The iPhone can't use another processor without recompiling all the apps, but Windows Phone is processor independent. Not that it really matters as it looks like the ARM monoculture is going to continue for a while. At least ARM is a sensible architecture, unlike the power-sucking monstrosity that is x86 and the hardware to support its weird and wonderful instructions.
    - malkia 17y ago
      Java has been like that since a long time, and yet it's problematic on small devices. CLR or compiled code is not the issue here - it's the hardware - resolution, number of buttons - that stuff. For games - compiled code and no garbage collecting might be better, but it's doable with CLR too (and actually I preffer CLR with JIT on the device more than compiling).
      - rbanffy 17y ago
        J2ME comes from a time when people imagined phones based on lots of very different architectures and code that would be seamlessly portable between vastly different devices. This is not how it turned out (at least not for now).
    - rbanffy 17y ago
      In reality, if there is no processor fast enough to run an application on top of a virtual machine with speed that is comparable to other platforms, the app is "present-proof". It may run well in the future, but, by then, what's the point?
      - bensummers 17y ago
        The compilation doesn't have to be on the device. The CLR has always supported ahead of time compilation. What if Microsoft's App Store did the compilation before it was downloaded to your device?
  - potatolicious 17y ago
    In practice it is different - part of the main difference right now between iPhone, Android, and webOS is how responsive the first is compared to the other two. Snappy UI is a gigantic selling point - speed matters. It is also, IMHO, the main failing point for Palm. It's easier on the iPhone to do more with the same hardware while maintaining UI responsiveness.
  - wtallis 17y ago
    You're using the term "native" to apply to APIs, and giving it the meaning of "not platform-independent". The generally accepted meaning of "native" when used in the term "native code" is "not run on a virtual machine". This is also the definition of native that is in use when native is applied to "applications" or "apps". "Applications" is pretty close in meaning to "code", and "applications" are very different from APIs, so I don't see how you justify interpreting native with a definition that is only applicable to APIs.
    - johns 17y ago
      I understand what you're saying. I was trying to address the context of the article which I interpreted as saying that there were no "Native apps" which in iPhone discussions is the contrary of web-only apps. It seemed to me that the author was confusing how Silverlight works on a desktop browser to how it would work on a mobile device (which we don't even know yet, it's possible they could be compiled down to machine code, though very unlikely).
      - wtallis 17y ago
        "Native Apps" is only equivalent to "web apps" on the iPhone because VMs aren't allowed on the iPhone, not because web apps don't use iPhone-specific APIs.
  - rbanffy 17y ago
    > In practice, it isn't. How exactly it isn't? iPhone apps run natively on the ARM processor inside the device. .NET code run off pseudocode on a virtual machine. You appear to confuse the CLR with an operating system.
malkia 17y ago
I don't think it's the equivalent. First native iPhone apps are compiled. Second Apple specifically made it that garbage collector is not used, although they released it for Mac OS X (Objective C 2.0 runtime). Here is how low-level - "C", and assembly - for example you can use (depending on the ARM version) various math libraries on the iPhone to get speedup. Check the oolong engine for more details.
- abolibibelot 17y ago
  There's a lot of people here who seem to think .NET bytecode (or Java for that matter) is run by the VM. How 90's of you guys. It's compiled on first run, so technically there's no difference with (iPhone) Objective-C apps. The GC may factor in, though.
  - malkia 17y ago
    Maybe, but where it is compiled? On the device itself, right? If that's the case - what kind of compiler we are talking here? A really good optimizing compiler would probably use a lot of memory, and cpu clocks. I'm not expert, so I might be totally wrong about it. Just thinking out loud.
  - nomoresecrets 17y ago
    http://developer.android.com/reference/java/lang/Compiler.html http://developer.android.com/reference/java/lang/Compiler.ht... "The Android reference implementation does not (yet) contain such a JIT compiler, though other implementations may choose to provide one." I thought that was one of the complaints about Android/Java - the VM runs the code; there's no JIT. That's why the prototype Dalvik JIT that was announced very recently was big news. It certainly wasn't announced in the 90s, anyway.

That's a little misleading. Managed code/Silverlight on WPS7 is the equivalent of the iPhone SDK. How low-level does this guy want to go?

by johns 17y ago

That's a little misleading. Managed code/Silverlight on WPS7 is the equivalent of the iPhone SDK. How low-level does this guy want to go?

martythemaniak 17y ago

Kinda funny coming from an Android-centric blog, since by that definition, Android's Java-on-Dalvik apps aren't "native" either.

rbanffy 17y ago
AFAIK you can write native apps for Android. It's just that they won't run on every Android phone, but will be tied to specific architectures (not a big problem since all Android phones seem to use ARM).

wtallis 17y ago

iPhone apps are compiled down to ARM machine code. .NET managed code is bytecode for the CLR virtual machine. That's a significant difference.

johns 17y ago
OK, technically it is different. In practice, it isn't. If you want to build on the iPhone, the SDK gives you an API to use the phone's features. If you want to program against WPS7 you're getting a version of Silverlight with APIs to give you access to the phones features. Both are abstractions over a lower-level. Both are native to the phone (as opposed to web apps, which is the common distinction made on the iPhone).
- bensummers 17y ago
  Using the CLR "future proofs" it. The iPhone can't use another processor without recompiling all the apps, but Windows Phone is processor independent. Not that it really matters as it looks like the ARM monoculture is going to continue for a while. At least ARM is a sensible architecture, unlike the power-sucking monstrosity that is x86 and the hardware to support its weird and wonderful instructions.
  - malkia 17y ago
    Java has been like that since a long time, and yet it's problematic on small devices. CLR or compiled code is not the issue here - it's the hardware - resolution, number of buttons - that stuff. For games - compiled code and no garbage collecting might be better, but it's doable with CLR too (and actually I preffer CLR with JIT on the device more than compiling).
    - rbanffy 17y ago
      J2ME comes from a time when people imagined phones based on lots of very different architectures and code that would be seamlessly portable between vastly different devices. This is not how it turned out (at least not for now).
  - rbanffy 17y ago
    In reality, if there is no processor fast enough to run an application on top of a virtual machine with speed that is comparable to other platforms, the app is "present-proof". It may run well in the future, but, by then, what's the point?
    - bensummers 17y ago
      The compilation doesn't have to be on the device. The CLR has always supported ahead of time compilation. What if Microsoft's App Store did the compilation before it was downloaded to your device?
- potatolicious 17y ago
  In practice it is different - part of the main difference right now between iPhone, Android, and webOS is how responsive the first is compared to the other two. Snappy UI is a gigantic selling point - speed matters. It is also, IMHO, the main failing point for Palm. It's easier on the iPhone to do more with the same hardware while maintaining UI responsiveness.
- wtallis 17y ago
  You're using the term "native" to apply to APIs, and giving it the meaning of "not platform-independent". The generally accepted meaning of "native" when used in the term "native code" is "not run on a virtual machine". This is also the definition of native that is in use when native is applied to "applications" or "apps". "Applications" is pretty close in meaning to "code", and "applications" are very different from APIs, so I don't see how you justify interpreting native with a definition that is only applicable to APIs.
  - johns 17y ago
    I understand what you're saying. I was trying to address the context of the article which I interpreted as saying that there were no "Native apps" which in iPhone discussions is the contrary of web-only apps. It seemed to me that the author was confusing how Silverlight works on a desktop browser to how it would work on a mobile device (which we don't even know yet, it's possible they could be compiled down to machine code, though very unlikely).
    - wtallis 17y ago
      "Native Apps" is only equivalent to "web apps" on the iPhone because VMs aren't allowed on the iPhone, not because web apps don't use iPhone-specific APIs.
- rbanffy 17y ago
  > In practice, it isn't. How exactly it isn't? iPhone apps run natively on the ARM processor inside the device. .NET code run off pseudocode on a virtual machine. You appear to confuse the CLR with an operating system.

malkia 17y ago

I don't think it's the equivalent. First native iPhone apps are compiled. Second Apple specifically made it that garbage collector is not used, although they released it for Mac OS X (Objective C 2.0 runtime). Here is how low-level - "C", and assembly - for example you can use (depending on the ARM version) various math libraries on the iPhone to get speedup. Check the oolong engine for more details.

abolibibelot 17y ago
There's a lot of people here who seem to think .NET bytecode (or Java for that matter) is run by the VM. How 90's of you guys. It's compiled on first run, so technically there's no difference with (iPhone) Objective-C apps. The GC may factor in, though.
- malkia 17y ago
  Maybe, but where it is compiled? On the device itself, right? If that's the case - what kind of compiler we are talking here? A really good optimizing compiler would probably use a lot of memory, and cpu clocks. I'm not expert, so I might be totally wrong about it. Just thinking out loud.
- nomoresecrets 17y ago
  http://developer.android.com/reference/java/lang/Compiler.html http://developer.android.com/reference/java/lang/Compiler.ht... "The Android reference implementation does not (yet) contain such a JIT compiler, though other implementations may choose to provide one." I thought that was one of the complaints about Android/Java - the VM runs the code; there's no JIT. That's why the prototype Dalvik JIT that was announced very recently was big news. It certainly wasn't announced in the 90s, anyway.