

Squeak on the iPhone - stcredzero
http://news.squeak.org/2008/06/11/squeak-on-the-iphone/

======
jws
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
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).

------
pmjordan
I thought there was a restriction on VMs and interpreters on the iPhone?

~~~
jrockway
The restriction is _telling_ Apple that you are publishing a VM or
interpreter. If it looks like an app and it just happens to use Squeak
internally, they'll never know. (The joys of closed source ;)

