4 ms·

Most of the time it's not the CPU that is using most of the energy. It's the mobile or wireless connection, the GPS and the screen.

by rapala 13y ago

K0nserv 13y ago
Good point. A better argument against the interpreted approach is that interpreted languages to a larger degree tend to be rather dynamic. With a platform like iOS where release cycles are fairly lengthy(not that this is really Warranted IMO) a static language is much more sensible. It's obviously a lot better to find as many bugs as possible before shipping and I would argue that this is much easier in stricter static languages. Frontend javascript for example is fine being dynamic and interpreted because it's easy to hotfix issues
- rapala 13y ago
  I don't see a reason why a modern language, static or dynamic, could not have both a compiler and an interpreter. Most Lisps have both, Haskell has both. Also, most interpreted languages actually have a compile phase before the actual interpreter. I do agree with you on that any platform should have a staticly typed language as a first class citizen.
  - K0nserv 13y ago
    What would be the use case for the interpreted version? I would assume it would be usable for the development process, surely running interpreted code on devices would be a total waste if compiled code is available?
    - rapala 13y ago
      During development is probably the best use case I can think of. With editor integration an interpreter is a tremendous help when coding. At least Lisps, Ruby, Python and Haskell have this kind of "development environments' to a some degree. I think GHCI even doubles as a debugger.
Pacabel 13y ago
I think that hardware factors like those are generally irrelevant when it comes to purely software issues, like we're discussing here. In this case, we're talking about an energy consumption penalty imposed solely at the software layer. Aside from arguments about the screen perhaps not needing to be used as long when the software completes its operations faster, I think it's probably safe to say that such hardware-specific energy consumption due to the factors you mention would be constant in both the case of compiled applications and the case of interpreted applications.
- hueving 13y ago
  >In this case, we're talking about an energy consumption penalty imposed solely at the software layer. The point is that we may be wasting time talking about a negligible amount of the total battery assumption.
mantrax 13y ago
The reason the CPU is not using most of the energy is because it's not used all the time. And that's by design. Every single thing possible under the sun is done to keep the CPU off for even a split ms on mobile. Because if you start using the CPU all the time, your battery is done.

Most of the time it's not the CPU that is using most of the energy. It's the mobile or wireless connection, the GPS and the screen.

by rapala 13y ago

Most of the time it's not the CPU that is using most of the energy. It's the mobile or wireless connection, the GPS and the screen.

K0nserv 13y ago

Good point. A better argument against the interpreted approach is that interpreted languages to a larger degree tend to be rather dynamic. With a platform like iOS where release cycles are fairly lengthy(not that this is really Warranted IMO) a static language is much more sensible. It's obviously a lot better to find as many bugs as possible before shipping and I would argue that this is much easier in stricter static languages. Frontend javascript for example is fine being dynamic and interpreted because it's easy to hotfix issues

rapala 13y ago
I don't see a reason why a modern language, static or dynamic, could not have both a compiler and an interpreter. Most Lisps have both, Haskell has both. Also, most interpreted languages actually have a compile phase before the actual interpreter. I do agree with you on that any platform should have a staticly typed language as a first class citizen.
- K0nserv 13y ago
  What would be the use case for the interpreted version? I would assume it would be usable for the development process, surely running interpreted code on devices would be a total waste if compiled code is available?
  - rapala 13y ago
    During development is probably the best use case I can think of. With editor integration an interpreter is a tremendous help when coding. At least Lisps, Ruby, Python and Haskell have this kind of "development environments' to a some degree. I think GHCI even doubles as a debugger.

Pacabel 13y ago

I think that hardware factors like those are generally irrelevant when it comes to purely software issues, like we're discussing here. In this case, we're talking about an energy consumption penalty imposed solely at the software layer. Aside from arguments about the screen perhaps not needing to be used as long when the software completes its operations faster, I think it's probably safe to say that such hardware-specific energy consumption due to the factors you mention would be constant in both the case of compiled applications and the case of interpreted applications.

hueving 13y ago
>In this case, we're talking about an energy consumption penalty imposed solely at the software layer. The point is that we may be wasting time talking about a negligible amount of the total battery assumption.

mantrax 13y ago

The reason the CPU is not using most of the energy is because it's not used all the time. And that's by design. Every single thing possible under the sun is done to keep the CPU off for even a split ms on mobile. Because if you start using the CPU all the time, your battery is done.