4 ms·

A good example of why interpreters are bad on mobile devices. The article notes that the squeak programs run "at the speed of a 233MHz ppc603e" and that memory

by jws 18y ago

A good example of why interpreters are bad on mobile devices. The article notes that the squeak programs run "at the speed of a 233MHz ppc603e" and that memory is very tight. Every processor cycle you execute on a mobile device drains your battery. If your interpreter runs 1/10th the speed of native code (a reasonable ballpark figure) then you are going to be burning 10 times the battery in the CPU. (more or less) Don't disrespect your user. Code native.

davidw 18y ago
You're assuming that the code is going to be burning massive amounts of cycles calculating something. That's likely not necessarily the case. The arguments for scripting languages on mobile phones are just as strong as they are for scripting languages elsewhere: Faster development time: it's important to know if people even like your app, and a quick prototype is often a good idea. Let more users write apps in the first place. Maybe Joe Schmoe has a neat idea for an app that would be great in his industry, but isn't much of a coder, and would simply get stuck with a more complex language. Keep in mind that this may be something as simple as a user writing code for their own phone, so they know what kind of tradeoff they're making. If you're using the right kind of languages, you can write the control code in a scripting language, and write speed-critical code in the lower-level language. Obviously, I'm biased, as I've spent massive quantities of time working on Hecl, and have seen firsthand that I can write small, but useful applications on platforms as limited as Nokia's S40 series (from 5 years ago).
jrockway 18y ago
Don't disrespect your user. Code native. What? Every VM worth its salt compiles the bytecode to something just as good as optimized C at runtime (it's called "JIT"). The JVM does this, Parrot does this, and even SBCL does this (even code you type into the REPL!). So basically, there is no performance reason to avoid VMs. If you're wondering why languages like Java and Lisp run slower than C on average, though, it's because the constructs are different. C is assembly; everything you write is basically a CPU instruction. CPU instructions run really fast. Things like memory management, cons cells, OO system MRO lookups, etc. don't run all that fast. So basically, you pay for expensive language features; you don't pay to be running on a VM. Finally, is it more disrespectful to provide a neat tool that burns battery, or to not provide the tool at all?

by jws 18y ago

davidw 18y ago

You're assuming that the code is going to be burning massive amounts of cycles calculating something. That's likely not necessarily the case. The arguments for scripting languages on mobile phones are just as strong as they are for scripting languages elsewhere: Faster development time: it's important to know if people even like your app, and a quick prototype is often a good idea. Let more users write apps in the first place. Maybe Joe Schmoe has a neat idea for an app that would be great in his industry, but isn't much of a coder, and would simply get stuck with a more complex language. Keep in mind that this may be something as simple as a user writing code for their own phone, so they know what kind of tradeoff they're making. If you're using the right kind of languages, you can write the control code in a scripting language, and write speed-critical code in the lower-level language. Obviously, I'm biased, as I've spent massive quantities of time working on Hecl, and have seen firsthand that I can write small, but useful applications on platforms as limited as Nokia's S40 series (from 5 years ago).

jrockway 18y ago

Don't disrespect your user. Code native. What? Every VM worth its salt compiles the bytecode to something just as good as optimized C at runtime (it's called "JIT"). The JVM does this, Parrot does this, and even SBCL does this (even code you type into the REPL!). So basically, there is no performance reason to avoid VMs. If you're wondering why languages like Java and Lisp run slower than C on average, though, it's because the constructs are different. C is assembly; everything you write is basically a CPU instruction. CPU instructions run really fast. Things like memory management, cons cells, OO system MRO lookups, etc. don't run all that fast. So basically, you pay for expensive language features; you don't pay to be running on a VM. Finally, is it more disrespectful to provide a neat tool that burns battery, or to not provide the tool at all?