12 ms·
Android: The Land That Python Forgot
- mkonecny 13y agoThe first half of the deck is about what a smartphone is. You should cut those out and get to the subject matter.
- lnanek2 13y agoLots 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 13y agoThe 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.
- programminggeek 13y agoYou 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...
- camus2 13y agothe irony is the use of javascript in solutions like Titanium,to code ANYTHING but the ui ( the business logic is in javacript , the ui is native ). I like the approach though, it's a better approach than phonegaps and likes. the only drawback : doesnt seem the engine they use is opensource.
- dottrap 13y agoIn Titanium, you code both the business logic and UI in Javascript. The Javascript UI APIs Titanium provides call native APIs under the hood. Titanium is open source; the repository can be found on GitHub.
- gcb1 13y agoThose languages does not focus on portability.
- petsagouris 13y agoThe main focus of Lua has been portability.
- gcb1 13y agointo other languages, not systems.
- pekk 13y agoIf you think Python is a worse Java then there is something important you have missed.
- raverbashing 13y ago"write a Python compiler for iOS or Android to make it compelling, which means adding type checking" No PyPy is a (JIT) compiler for Python, no type checking addition needed.
- eonil 13y agothe point is adding type system, not compiling it.
- nilliams 13y agoPython has a type system.
- Alphasite_ 13y agoEnforced type system is probably what he meant, i.e. annotations had a practical application at the moment.
- nilliams 13y agoI'm not just being purposefully obtuse here. When read in the context of his upstream comments, I don't think we can make any assumptions as to what he meant.
- eonil 13y agoAt least, what I mean was an ability to offer those type informations to automated tools - auto-completion system. How actually Python type doesn't matter. Python lacks the ability by not forcing type (an)notation. This is fundamentally different with type-inferencing/deducing system such as Haskell, Go, C++11.
- klibertp 13y agoI think it's not "fundamentally different". Type info is there in the code, it's just much more implicit and requires much more work to extract and use. One thing which does just this is Jedi project (for python) and it's absolutely astonishing how much data you can get out of it! Also I think that dynamic languages were meant to run inside a dynamic environment. For example in Pharo Smalltalk (probably all Smalltalks) every single piece of metadata is runtime data. Static analysis has no sense, because in Pharo there is no "static" at all - everything happens inside a living environment and (for example) as soon as you write a method it's turned into CompiledMethod object which has all the data about the method you would ever need for you to query easily. Good luck implementing better refactoring tools than those in Smalltalk for any other language. Essentially the same approach is used in Emacs Lisp. For example, if you see a function you don't recognize, you can jump to it's definition. The thing here is that Emacs doesn't know where the definition is because of static analysis - it just has this compiled chunk of code in memory which happens to have a name you're looking for. This chunk of code knows a location of it's definition and many other pieces of metadata which are all available on runtime. It of course doesn't work if the function isn't already loaded into Emacs. Most statically typed languages retain almost no type data in runtime. Most dynamically typed languages have almost no type data on compile time. I see this as largely equivalent. So I guess what I want to say is that there is no fundamental difference in what the dynamic and static languages are, but there is (and should be) a very fundamental difference in how they are used. Choosing the between the two is I think almost exclusively a matter of preference. A good programmer should feel comfortable with both, though.
- starnix17 13y agoLua can easily be compiled and used on both Android and iOS.
- eonil 13y agoI like to add some more. That's correct that the type system is the crucial attribute as a platform language. But that's not the only reason. It's also for correctness, safety, productivity and manageability. That's because a platform is huge and complex monster. So all those properties are archive-able only by automated tools, and those tools need rich metadata for each word of code. Type information is crucial metadata, and it's mostly impossible to make high quality tools without those informations. That's why all the designed modern platform (=system) languages are all mostly typed. From C/C++/Objective-C, to Java, C#, Go, Rust, Dart, TypeScript… In fact, it doesn't matter the language actually statically typed, dynamically typed, duck-typed, or completely untyped. The point is an ability to offer accurate metadata for automated tools, and type system is the best ever invented. So languages lacks the ability cannot be a platform's primary language.
- nawitus 13y agoExactly. I've never understood why someone would prefer a untyped language. It's just a bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower. Untyped languages are fine only for small scripting languages.
- vidarh 13y agoI doubt you really mean untyped languages. Untyped languages includes many assembly languages, BCPL and some Forths. It does not include typical scripting languages like Perl, Ruby or Python - all of which are strongly typed.
- chrismonsanto 13y agoTo be pedantic, assembly languages do generally have multiple types, if by 'type' we mean 'a set of values disjoint from other sets of values'. For example, x86 has the types integer, floating point, MMX, SSE, and registers of these types cannot be confused for each other. It's just that these classifications/types aren't so useful, and we can't make our own (and perhaps all we really wanted was a distinction between integer and pointer)
- davvolun 13y ago> at some point developers start asking why they aren't just using Java in the first place... Hasn't held anyone back on non-mobile systems, right?
- chrisjrn 13y agoOhai! 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
- anandroiddev 13y agoGreat talk, thanks for posting it! I really like how thoroughly you cover the problems with and potential work-arounds for using a non-Java language with Android. Your analysis applies to many other languages besides Python. I wonder if it would be worth making a language-neutral version of the talk.
- rcfox 13y agoThanks for transcribing the talk onto the slides. Most people don't, and just post their mostly-useless slides.
- seszett 13y agoYes. 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 13y agoGlad you enjoyed it – I find I present better if I have notes. Glad they have extra utility for you!
- nashadelic 13y agoThanks for taking the time out and putting in all the notes. Very helpful and I'm sure, time taking for you. Much appreciated!
- eliben 13y agoGreat presentation, thanks for sharing it. Why isn't Kivy or one of the other existing solutions good enough for your needs?
- eonil 13y agoWhat's wrong with embedding python interpreter as a C library?
- chrisjrn 13y agoThat'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.
- eonil 13y agoDo you mean you want something like Mono's Xamarin in Python?
- chrisjrn 13y agoIt's a possibility – Qt's there, and in fact Kivy is a pretty good solution. The problem I raise in the talk is that such libraries will always lag behind the state of the art for Android GUIs, which makes them less attractive.
- jonmrodriguez 13y agoCouldn't a language-bridge library use Java reflection to accomplish a lot of what's needed?
- 13y ago
- rdtsc 13y agoJust 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 13y agoThere 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 13y agoThat makes sense, nothing wrong with that. I was thinking major refactoring or something like that.
- camus2 13y agolooks awesome but i've never been able to install it on my windows machine ,it complains about my graphic card. But it looks neat.
- benrousch 13y agoKivy itself is still under very active development. Also, there is a lot of work in auxiliary projects - like python-for-android, pyjnius, kivy-ios, pyobjus, and buildozer - from the Kivy team. https://github.com/kivy https://github.com/kivy
- pekk 13y agoIt 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 13y agoOne 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 13y agoYup. 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_ 13y agoI 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!
- chrisjrn 13y agoMy guess is that it's still Java-like under the hood -- at the very least, calling out to API endpoints will be... Probably doesn't change much at all. (Though I'd love to be wrong).
- KMag 13y agoART 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.
- zokier 13y agoI'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.
- shmerl 13y agoWhile Maemo is irrelevant, Python can be perfectly used with Mer and Sailfish.
- girvo 13y agoPySide is pretty neat, though I am not very good with Python
- _random_ 13y agoCould it be the reason Symbian was slow and eventually failed? Were they interpreting or compiling Python?
- zokier 13y ago> 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 13y agoA 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].
- fidotron 13y agoIn fairness, Python for S60 was a special kind of pain, especially the way it mixed Python threads with ActiveObjects. Being able to REPL on a device from a terminal on another machine was fairly useful though.
- 13y ago
- tantalor 13y agoWhat 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?
- ygra 13y agoDalvik isn't very fast already; I doubt a native Python runtime is that much slower for lightweight tasks. The usual caveats apply, of course, in that you shouldn't try to do things that are ill-suited to your target platform (be it Python or Dalvik).
- chrisjrn 13y agoYou'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.
- deleted 13y ago[deleted]
- dochtman 13y agoI 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?)
- bsaul 13y agoAgree, it seems like a topic worth mentionning at least.
- izacus 13y agoPractically 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.
- smoyer 13y agoTo 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?
- _random_ 13y agoI don't think so. Look at C# - completely alien to JVM yet getting more and more cross-platform traction via Mono and Xamarin. I think it's more about language robustness and appeal. Also switching from Java to C# you loose less than when switching to Python language feature wise.
- Timmmmbob 13y agoLanguage support has nothing to do with drivers... All the hardware drivers have C or C++ interfaces.
- smoyer 13y agoAnd 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?
- nirai 13y agoperformance 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
- chrisjrn 13y agoNot really -- most mobile code is simply glue for UI event handlers and the like. And Python's really good at writing glue code. Just like when you're coding in Java, code that needs performance is native, and written in C. Python would idle just as well as pure java if it needed to :)
- captainmuon 13y agoNot 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.
- eliben 13y agoThought-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
- colig 13y agoHow 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 13y agoIf 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 13y agoThis 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.
- html6 13y agoGuido works at Dropbox now.
- eonil 13y agoMy mistake.
- to3m 13y agoWell 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.
- squidsoup 13y agoJessica 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.