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.
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.
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...
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.
Exactly. 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.
There's a difference between typed and statically typed. Python is a strongly typed language, but it is dynamic.
> bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower
All of these observations are highly subjective.
> Developing experience:
I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough.
> code needs more debugging
That's a function of the problem and the developer. The run, check, edit cycle in python is a lot quicker than using your IDE to run, check, edit, compile. There are debuggers available for nearly every language that allow you to step and inspect.
> harder to maintain
Disagree. When you have code 1/5th (number pulled from my ass) the size codebase, maintainability can be much better. Unit testing helps, regardless of the language.
> productivity
A developer proficient in language [X] should be just as productive as a different developer proficient in language [Y]. Creating a massive type hierarchy of classes and interfaces is a tonne of overhead when you are trying to express a simple idea. In a language like python, you might write a simple class (or two), and use dynamic typing appropriately. A java developer may use code generation and IDE shortcuts to lessen the amount of total code they have to write though.
The advantages and disadvantages of dynamic and statically typed languages are fairly well known. Neither is perfect all the time and for each person. Just because you don't like dynamic languages, it does not mean they don't have their virtues.
> I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough.
What does it even mean? You can dump everything into one class hacky Python way if you want. You can use dynamic keyword if you don't care about type safety.
We're not talking about monolithic, do-everything, hacky classes. You could do the same thing in C#.
Static languages (usually) force you to use interfaces and sub-typing just so common code can be reused. Duck typing is a much nicer way of working - without having to jump through seemingly unnecessary hoops. The situation is even worse when you code for testability. Things that really shouldn't have an interface now require one, so you can mock out the object appropriately. This is all avoided in a language with duck typing.
This is actually where Go has a great impact. You get your static type checking without being forced to use explicit interfaces. It essentially uses duck typing for interface implementation.
You're free to enjoy static typing over dynamic typing all you like - but you shouldn't make the mistake of thinking dynamic typing is inferior in any way. It is different - just like imperative vs functional is different. You make a series of tradeoffs, that is all.
Yes, but it's not idiomatic C#. The point I've been trying to make is that both kinds of languages (dynamic and static) have their different virtues. You can drop down to dynamic in C#, but unless you have a very good reason, your co-workers will lynch you.
And .NET framework tend to overuse subclassing/overriding pattern where delegation is more appropriate. That frequently leads users also overuse subclassing/overriding.
If you're familiar with C#, Real World Functional Programming: With Examples in F# and C# [1] is an excellent resource for learning how and when to use composition over inheritance.
Functional programming usually leans towards composition, and OO programming towards inheritance. "Hybrid" functional languages, like F# and Scala, allow you to use both styles, mixing them in whatever way is most useful for the particular problem you're solving; "pure" functional languages, like Haskell don't offer OO-style inheritance, since composition is a better fit for combining side-effect free ("pure") functions.
tl;dr -- Composition is to functional programming as inheritance is to OO programming.
I 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.
I don't know about Ruby but Perl certainly isn't strongly typed. You can run 'print "5.0" + 6' and get 11 as the answer. That's weak typing and types are implicitly converted to whatever.
Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.
Ruby is strongly typed. I am not sure that's static or dynamic, but regardless of how it is implemented, Ruby lacks ability to offer type information to code-writing level toolsets because it doesn't force retaining of type information on field and function parameters.
So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects.
As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.
And users of dynamically typed languages will sometimes argue that the need for code generation tools is less necessary. You lose the ability to have tools do a lot of the work, but you also lose the need to have tools do a lot of the work. It's a trade off.
Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.
Sorry, but what are the problems with everything being an object? That's a feature. Python 3.4 now has @singledispatch, though I don't know where I'd use that yet.
To 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)
Historically they didnt, until hardware floating point wired up some registers to special hardware. Which is why C lets you cast; BCPL just has bit patterns.
I think you originally intended explicit type notation.
I recently discovered actual type doesn't matter that much, and the point is having an interface/protocol which enable compiler validation and tooling support. I learned this truth from Objective-C and Go. That's why I told actual typing system itself not important. Objective-C protocol is nothing about type, but defines nice interface for tooling support. Go interface defines set of promises, so actual object structure doesn't matter.
Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able.
This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided.
I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.
1. Dynamically strongly typed, but typing is limited to primitive types.
2. So actually it's untyped for objects which is really needs type information.
3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible.
4. So lacks ability to offer type information to toolset.
You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation -
1. Google = Dart,
2. MS = TypeScript,
3. Mozilla = Emscripten(in very unique way!)
I found one study[1] which concludes that unit tests are not enough to reveal all errors which would be revelead when using a statically typed language.
A small number of Python guys are trying to use more annotations for a sort of closer-to-staticly-typed Python. It's certainly not universal, or even a majority of developers.
I'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.
At 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.
I 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.
the 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.
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.
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).
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?
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.
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.
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.
For certain values of "preferred". Python bindings for Nokia-specific subsystems (contacts, location etc) were released months or even years after their statically-typed counterparts. You just couldn't build serious applications on S60 with Python, just the occasional script; on Maemo/Meego you could, if you'd waited several months for the eventual release of their largely-undocumented bindings, but you couldn't release them through the Nokia appstore anyway.
Python was simply not a first-class citizen on Nokia devices, 99% of development was done in C/C++. That's one of umpteen huge boats they missed at the time.
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?
I 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.
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?
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.
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?
Kivy 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
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.
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
Dalvik 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).
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?)
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.
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.
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...
The Kivy lead developer has just recently been working with native Android widgets in python-for-android. Stop by #kivy on Freenode and ask tito about his Google maps demo.
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.
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...
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.
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.
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.
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
--Chris