Python/pyobjC Apps on iPhone now a possibility?

[Dr Mephesto]

I have been following the discussion about python and pyobjc on the
iphone, and it seemed to me that the app-store rules prohibited
embedded interpreters; so, python apps are a no-no.

But now it seems that the Rubyists have the option that we don't. It
seems there is a company, http://rhomobile.com/home, that has an SDK
that allows ruby programs to be embedded together with an interpreter
in an app! More interesting is the fact that several of these hybrid
apps seem to have been accepted on the itunes app store.

Here's a quote from a representative, found on this blog:
http://www.rubyinside.com/rhodes-develop-full-iphone-rim-and-symbian-apps-using-ruby-1475.html

"...First of all, to clarify, we precompile all framework and app code
down to Ruby 1.9 VM bytecode. This yields great performance
advantages. We also disable eval and other dynamic execution aspects
of Ruby. In the end, on all platforms your app gets compiled with our
framework all into one single executable, indistinguishable from any
other executable.

But even if we were shipping a fullon Ruby interpreter without
compiling to bytecode and leaving dynamic evaluation enabled (as has
been well remarked in the blogosphere by now) App Store rule 3.3.2
does not disallow interpreters but only downloading code to be
executed by the interpreter."

So, the question is, can the same thing be done for Python apps?

 

[J Kenneth King]

I have been following the discussion about python and pyobjc on the
iphone, and it seemed to me that the app-store rules prohibited
embedded interpreters; so, python apps are a no-no.

But now it seems that the Rubyists have the option that we don't. It
seems there is a company, http://rhomobile.com/home, that has an SDK
that allows ruby programs to be embedded together with an interpreter
in an app! More interesting is the fact that several of these hybrid
apps seem to have been accepted on the itunes app store.

Here's a quote from a representative, found on this blog:
http://www.rubyinside.com/rhodes-develop-full-iphone-rim-and-symbian-apps-using-ruby-1475.html

"...First of all, to clarify, we precompile all framework and app code
down to Ruby 1.9 VM bytecode. This yields great performance
advantages. We also disable eval and other dynamic execution aspects
of Ruby. In the end, on all platforms your app gets compiled with our
framework all into one single executable, indistinguishable from any
other executable.

But even if we were shipping a fullon Ruby interpreter without
compiling to bytecode and leaving dynamic evaluation enabled (as has
been well remarked in the blogosphere by now) App Store rule 3.3.2
does not disallow interpreters but only downloading code to be
executed by the interpreter."

So, the question is, can the same thing be done for Python apps?

I love Python and all, but it'd be apt to ask, what's the point?

The iPhone is running on what? A 400Mhz ARM processor? Resources on the
device are already limited; running your program on top of an embedded
Python interpreter would only be adding pressure to the constraints;
even if it was an optimized interpreter.

Might as well just suck it up and learn C/Objective-C .. it's really not
that hard. It took me about a day to pick up the language and another
two or three to finagle with the libraries.

 

[Dr Mephesto]

Sure, I am learning Objective C already, but the syntax is really
unfriendly after python.

I think it really depends on the type of app you want to write.
Anything held back by network delays or that sits around waiting for
user input are perfectly acceptable target apps. If you need speed for
something really intensive, falling back to C is still much nicer than
coding in Objective C. I agree that having a certain basic
understanding of objective C is a must, but having the option to use a
coder-friendly language like Ruby or Python can cut development time
dramatically.

If Ruby can do it (and it generally slower than python), why can
Python also get a legal iPhone interpreter?

 

[Aahz]

The iPhone is running on what? A 400Mhz ARM processor? Resources on the
device are already limited; running your program on top of an embedded
Python interpreter would only be adding pressure to the constraints;
even if it was an optimized interpreter.

<raised eyebrow> Ten years ago, a 400MHz ARM processor would have been
fast, and it would have been running Python 1.5.2.

 

[Piet van Oostrum]

A> <raised eyebrow> Ten years ago, a 400MHz ARM processor would have been
A> fast, and it would have been running Python 1.5.2.

My first Python experience at home was on a 40MHz 80486 (Python 1.5.2 I
think). It was a bit slow :=(

 

[J Kenneth King]

Sure, I am learning Objective C already, but the syntax is really
unfriendly after python.

I think it really depends on the type of app you want to write.
Anything held back by network delays or that sits around waiting for
user input are perfectly acceptable target apps. If you need speed for
something really intensive, falling back to C is still much nicer than
coding in Objective C. I agree that having a certain basic
understanding of objective C is a must, but having the option to use a
coder-friendly language like Ruby or Python can cut development time
dramatically.

If Ruby can do it (and it generally slower than python), why can
Python also get a legal iPhone interpreter?

It can if you want to write the interpreter.

I just don't see the point.

I can understand wanting a higher level language than assembler or maybe
even C, but that's precisely what Objective-C is.

Unfortunately, while the hardware for these mobile platforms is getting
better these days, it's still not where it needs to be to run programs
written in interpreted languages, IMO. Users typically only interact
with an app for around two minutes at a time. Your app needs to be as
fast as it can be. It's one of the few areas of software development
today where optimizations can be justified (the other are games and
scientific computing).

Trust me, if there were an SMS app for the iPhone that loaded faster
than the one that ships with it, guaranteed it would sell like hot-cakes
(if Apple would let it in the store of course).

If you do write the interpreter, let me know. I would certainly
experiment with it.

 

[python]

If you do write the interpreter, let me know. I would certainly experiment with it.

+2 over here!

Malcolm

 

[Stef Mientki]

I love Python and all, but it'd be apt to ask, what's the point?

The iPhone is running on what? A 400Mhz ARM processor? Resources on the
device are already limited; running your program on top of an embedded
Python interpreter would only be adding pressure to the constraints;
even if it was an optimized interpreter.

I don't know iPhone,
but I've done some experiments with 400 MHz arm, running Windows Mobile,
and found PocketPyGUI running very very well on these devices.

cheers,
Stef Mientki

 

[J Kenneth King]

I don't know iPhone,
but I've done some experiments with 400 MHz arm, running Windows Mobile,
and found PocketPyGUI running very very well on these devices.

cheers,
Stef Mientki

Sure, but it's pretty relative in the sense that it might be fast enough
if I'm sitting around but too slow if I want to enter some information
in the app before the next train comes.

As a programmer, I don't really see the benefit of using an embedded
interpreter on the iPhone. Objective-C isn't the greatest language, but
it's easy to learn and well supported. It also compiles into some
pretty speedy executables.

If you can sacrifice a little run-time speed for your users in exchange
for ease of development on your part, all the more to you.

My original point was that I don't see the benefit in that decision.

 

[Stef Mientki]

Sure, but it's pretty relative in the sense that it might be fast enough
if I'm sitting around but too slow if I want to enter some information
in the app before the next train comes.

As a programmer, I don't really see the benefit of using an embedded
interpreter on the iPhone. Objective-C isn't the greatest language, but
it's easy to learn and well supported. It also compiles into some
pretty speedy executables.

If you can sacrifice a little run-time speed for your users in exchange
for ease of development on your part, all the more to you.

My original point was that I don't see the benefit in that decision.

ok 20 years ago I might have agreed with you,
but now a days,
speed of development is a much more important decision maker than speed
of execution ;-)

cheers,
Stef