
Android: The Land That Python Forgot - myko
https://speakerdeck.com/pyconca/android-the-land-that-python-forgot-christopher-neugebauer
======
chrisjrn
Ohai!

I wrote the talk, and just want to let you know that you can _watch_ it over
at
[https://www.youtube.com/watch?v=p77BR6e1uoo](https://www.youtube.com/watch?v=p77BR6e1uoo)

\--Chris

~~~
rcfox
Thanks for transcribing the talk onto the slides. Most people don't, and just
post their mostly-useless slides.

~~~
seszett
Yes. Actually, when I saw it was just slides I simply closed the tab because
they're most often useless, not adapted to presenting something on the web.

After seeing your comment I went back to it, and indeed, the talk is there,
which was unexpected and great.

~~~
chrisjrn
Glad you enjoyed it – I find I present better if I have notes. Glad they have
extra utility for you!

------
programminggeek
You can replace Python in Ruby or Lua for the most part and also Android with
iOS. Dynamic languages aren't yet a big deal and I think it's because they
don't bind well or give you a significantly better developer experience than
Objective-C or Java on these platforms do.

RubyMotion is probably the closest I've seen to making a language like Ruby or
Python a very compelling mobile developer experience while maintaining the end
user experience.

That basically means you need to write a Python compiler for iOS or Android to
make it compelling, which means adding type checking and at some point
developers start asking why they aren't just using Java in the first place...

~~~
pekk
If you think Python is a worse Java then there is something important you have
missed.

~~~
skrebbel
If you think that programming languages are strictly worse or better than
others on a linear scale, then there is something important you have missed.

~~~
rizalp
Always use the correct tools for the Job. Pragmatism wins

~~~
merusame
thumbs up.

------
pekk
It isn't that Python forgot Android, or Python developers don't care about
mobile. It's that Google decided to base Android on the JVM and make Java the
primary language for developing on the platform. There's nothing Python could
have done about that.

~~~
ygra
One very prominent point in those slides is that Android is _not_ based on the
JVM, which complicates things for plenty of things that expect Java on JVM
instead of Java on Dalvik (e.g. Jython).

~~~
chrisjrn
Yup. If we had Jython, this talk wouldn't have needed to have been written.

And I'd probably be working to improve Jython as we speak.

~~~
voltagex_
I wonder if this new ART system shipped with 4.4 changes anything - Google
like Python and Go so maybe they'd have them available as languages that
target the runtime?

PS. See you at LCAU2014!

~~~
KMag
ART is an install-time compiler from Dalvik bytecode to native code. It
improves CPU, RAM, and battery usage, but still requires whatever code is run
through it to be converted to Dalvik bytecode.

If we don't currently have a way to run Python on a Dalvik JIT, then we don't
currently have a away to run Python on ART.

~~~
voltagex_
Why did they go to an install-time optimizer instead of inventing something
better than Dalvik?

~~~
KMag
Well, continuing to run legacy apps efficiently is almost certainly a
requirement. Presumably it's also a requirement for them that the Java
semantics easily and efficiently map to their program representation.

An AoT compiler instantly makes everyone's favorite Android apps start faster,
and many of them run faster, without having to wait for (sometimes defunct)
publishers to re-compile the apps.

A static single assignment representation that matches the Java semantics,
such as Michael Franz's SafeTSA, would be better than Dalvik bytecode if
they're going to do install-time generation of native code.

In any case, I hope they continue to promote architecture-independent
distribution formats for apps and libraries. I've said for a while that I
think compiling directly to native code is going to eventually be treated like
we now treat hand-written assembly... a last resort for small pieces of code
that need speed and have been found to not be efficiently served by more
abstract tools.

------
zokier
I'd point out that Python was the preferred high-level language at pre-MS
Nokia. There was Python for S60 for a long time, even before either iOS or
Android existed. More recently Nokia made new Python bindings for Qt, PySide,
to be used on Maemo.

~~~
_random_
Could it be the reason Symbian was slow and eventually failed? Were they
interpreting or compiling Python?

~~~
zokier
> Could it be the reason Symbian was slow and eventually failed?

No, and no. I don't think Nokia ever shipped any significant amounts of Python
code themselves.

> Were they interpreting or compiling Python?

It was the standard CPython interpreter.

~~~
stuaxo
A friend of mine was playing with python and opengl es on series 60 phones
(symbian) - and it was completely fine.

[Even with pretty unoptimised python].

------
smoyer
To me, it's more that Android forgot to include other languages. But maybe it
was intentional? You have no choice but to write drivers for the phones
special hardware, but you don't have to write bindings for all those drivers
to other languages ... only the ones (one?) you chose to support.

I'm not as familiar with iOS ... is there broad language support for that OS?

~~~
Timmmmbob
Language support has nothing to do with drivers... All the hardware drivers
have C or C++ interfaces.

~~~
smoyer
And every C/C++ interface requires a set of language bindings that allow you
to call them from say ... Python (if you want to call that Language
supported). If the core language runs on a device but you're constantly
calling native code, why not write in the language that's considered native?

------
mkonecny
The first half of the deck is about what a smartphone is. You should cut those
out and get to the subject matter.

~~~
lnanek2
Lots of times you are talking to people who have been writing enterprise/web
stuff for decades and never dipped into mobile. Especially at a conference for
a language that is pretty much not on mobile at all. I think it was
appropriate.

~~~
chrisjrn
The talk was at mostly web developers. The second and third parts of the talk
were about why the web doesn't cut it as a platform.

Part 1 was there to lay the groundwork. Basic? Maybe, but it's necessary.

------
rdtsc
Just point out, this talk mentions: kivy -- A python kit for a portable,
touch-focused UI that works on Android as well.

I used to follow it initially but noticed the project seems to have slowed
down. There haven't been as many releases lately. Anyone have more info on why
that might be?

~~~
Buttons840
There have been a few dozen commits in the last week. It may have slowed down
because the project reached many of it's objectives?

~~~
rdtsc
That makes sense, nothing wrong with that. I was thinking major refactoring or
something like that.

------
squidsoup
Jessica McKellar touched upon this in her keynote at Kiwipycon this year
([http://www.youtube.com/watch?v=d1a4Jbjc-
vU](http://www.youtube.com/watch?v=d1a4Jbjc-vU)).

Another area of deficiency in the Python ecosystem that concerns me is the
lack of any client-side web development story. Languages like Clojure and
Kotlin clearly recognise the importance of this, yet as far as I can tell
there doesn't seem to be much interest in projects like Pyjs.

------
eliben
Thought-provoking presentation, well done.

When I think about most Android apps I use (and especially my toddler
daughter's games), I can't imagine 95% of them need the faster execution speed
of optimized Java or NDK code. IOW, they could have been written in Python and
enjoy:

1\. Faster development 2\. Portability across devices

------
tantalor
What about performance? Seems one of the biggest concerns on mobile devices is
to achieve high performance with low overhead.

What kind of penalty comes with a separate python runtime?

~~~
chrisjrn
You're running the Python interpreter as a native executable, so it's roughly
comparable to Dalvik.

If you want performance, write it in C, optimise it. That's what the NDK is
for.

------
dochtman
I was wondering about the NDK here. How much of what the SDK provides is also
provided by the NDK? Could you do UI stuff by building a Python extension
around the NDK? (Probably not, since it would've been done already?)

~~~
izacus
Practically nothing - this is a common question we get from programmers that
come from other platforms. You have OpenGL/OpenAL and that's mostly it.

The main difference is that most other platforms run in native code and then
VM languages bind to that native code (e.g. Python/Java calling out to
syscalls, WINAPI functions, etc...) while Android OS actually is written and
runs IN Java. As soon as basic Linux kernel is up, Dalvik is started and THEN
the rest the OS (UI compositor, audio manager, process/activity manager,
SurfaceFlinger, etc.) is loaded as Java classes. Android is basically Java
code that calls out to native code for acceleration (like most Python
libraries) not the other way around as you're used to from other platforms.
Think of Android more like "boot to Java" than a Linux distribution.

Which means there are no native calls to be called - whole Android API is a
Java API. So if you want to implement another language or write an app in C,
you need to still have a JNI bridge between your language/code and Dalvik
which lets you call Android to draw UI on screen, access data about
filesystem, system services, schedule service startups, add icon to launcher,
show notifications, ... anything really.

This is also probably the biggest reason why we're not seeing other languages
on Android - binding Python and Java API together isn't really easy,
especially due to different language design philosophies.

------
eonil
What's wrong with embedding python interpreter as a C library?

~~~
chrisjrn
That's pretty much exactly what python-on-android does; the problem is that
you don't get access to any of the Java/Dalvik-based libraries, which includes
all of the UI programming libraries.

~~~
jonmrodriguez
Couldn't a language-bridge library use Java reflection to accomplish a lot of
what's needed?

~~~
bayesianhorse
That is already done with pyjnius. The missing part is providing more pythonic
and more productive ways of using it. Currently it is extremely awkward...

My guess is that someone will write a pythonic UI framework based on the
Android API...

------
colig
How much of the 'batteries included' approach of Python will work well in the
Android environment?

It reminded me of this: [http://www.tinypy.org/](http://www.tinypy.org/)

------
diego_moita
If Guido Van Rossum can't convince his own coworkers to support Python in
their own platform who else can do it?

Meanwhile, Lua is not doing bad in both Android and iOS.

~~~
eonil
This is the best logic I ever heard in this thread.

Guido is working in Google, and Google doesn't support Python on Android.
Python is just secondary scripting language even in Google, can't take a
strategic support. Their primary product/platform language was always
languages with forced type (an)notation - Java/C++.

Same thing happen on C#. Anders Hejlsberg couldn't convince any other MS
product teams to use C#, so C#/.NET literally abandoned for years. MS is
advertising C++11 now, and Mr. Hejlsberg is working on another C#.

As far as I remember, the only support was XNA came from DirectX team, but it
actually discouraged the addition of C# by proving inferiority of C# on game
development.

~~~
to3m
Well MS fucked that one up, didn't they? They should have ignored C++11, and
got Hejlsberg to design a new one ;)

Regarding C# and/or .NET's abandonment - is this really the case? It certainly
doesn't seem like it, with new revisions of the CLR coming out somewhat
regularly, seemingly with new bits in each time. There's been LINQ, this new
async thing, Rx, and that XML UI thing. And I know Silverlight is dead, but
nothing dies without having been alive first! And I'm sure if you actively pay
attention to the ecosystem - I don't, I use C# as a fancy MFC - you'd be able
to reel off a whole pile of other things. It might not be quite the PR darling
that it was in its youth, but it doesn't quite seem dead yet...

It might be true that teams at MS don't use it.

~~~
eonil
I am not sure that we're talking on same context… but anyway.

I invested much time on C# 1.0 to 3.0 for XNA, and MS never give a shit on XNA
for years and finally fucked me up. XNA doesn't exist anymore. Happy time with
MS was the biggest reason made me to learn C/C++. Ironically, now Unity3D is
working well with that C#.

Anyway now I am on C++11 on Xcode(You should know what I mean!) and happy
because I don't need to worry about any abandonment. C/C++ is core language
for any practical platforms (including browsers!), and I don't need to
`IDispose` all my source codes by vendor's decision.

XNA stuff was my personal experience, but at least for me, MS surely abandoned
the platform, and will do it again at any time. And this was possible because
their core teams are not using XNA. In other words, strategic support.

Maybe not yet on other fields, but I feel the time is close. The proof is, of
course, the TypeScript. If you haven't checked it, google it right now. MS
decided to make a new language instead of porting CLR on Javascript. I am sure
that stuff is post .NET/C# (I mean post buzzword) of MS. If you don't believe
MS will abandon .NET, think about how MS themselves will be damaged if .NET
abandoned. Virtually none. None of their product core is _based_ on .NET.
Anyway even after they abandon .NET, it will keep taking periodic update like
they did on ActiveX for last decades.

------
nirai
performance performance performance.

And it is not just about direct user experience either.

Even if a given app may be written in Python it will probably drain the
battery faster, since for each bit of work that would have taken X cpu cycles
with Java, you would spend 20X with Python, not to mention memory handling,
etc...

A language is just a tool, use the right one for the Job.

a Pythonista

~~~
captainmuon
Not sure about that... actually most (well-written!) android code is already
pretty wasteful with resources, because its abstractions upon abstractions.

To get a simple button on the screen, you need an Activity with a Fragment
with a View with the button inside, with a few more layers inbetween. The gui
is loaded from multiple XML files and resources, with lots of dynamic property
binding going on. And even don't get me started on data storage and SQLite...

Writing an app in python wouldn't add much to this - it actually may allow you
to avoid a couple of layers (the dreaded FactoryFactory syndrome of java).
Python's weakness is number crunching, and I agree, you wouldn't want to do
that in Python on Android. But just to show a gui, or to access a web api,
python's performance should be more than enough.

