Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android: The Land That Python Forgot

speakerdeck.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Android: The Land That Python Forgot

#111

Post by jsmeaton »

eonil wrote: post #97
yason wrote: post #55

Earlier quoted context omitted.

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 d…

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,…

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.

Re: Android: The Land That Python Forgot

#112

Post by smoyer »

Timmmmbob wrote: post #104
smoyer wrote: post #56

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?

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

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?

Re: Android: The Land That Python Forgot

#113

Post by benrousch »

chrisjrn wrote: post #14
eonil wrote: post #9

Earlier quoted context omitted.

Do you mean you want something like Mono's Xamarin in Python?

It'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.

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.

Re: Android: The Land That Python Forgot

#114

Post by klibertp »

eonil wrote: post #98
nilliams wrote: post #88

Earlier quoted context omitted.

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.

Re: Android: The Land That Python Forgot

#115

Post by voltagex_ »

profquail wrote: post #84
voltagex_ wrote: post #79

Earlier quoted context omitted.

Where's the best place to brush up on composition vs inheritance?

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. [1]: http://www.amazon.com/Real-World-Functional-Programming-With...

I thought composition vs inheritance was strictly an OO, not a functional thing?

Re: Android: The Land That Python Forgot

#116

Post by KMag »

voltagex_ wrote: post #81
chrisjrn wrote: post #69

Earlier quoted context omitted.

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.

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!

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.

Re: Android: The Land That Python Forgot

#117

Post by emiljbs »

wukix wrote: post #34
starnix17 wrote: post #28

Earlier quoted context omitted.

Lua can easily be compiled and used on both Android and iOS.

Or Lisp, which compiles and has optional type declarations https://wukix.com/mocl

Isn't that just a subset of Common Lisp? It doesn't support runtime compilation, right?

Re: Android: The Land That Python Forgot

#118

Post by profquail »

voltagex_ wrote: post #115
profquail wrote: post #84

Earlier quoted context omitted.

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. [1]: http://www.amazon.com/Real-World-Functional-Programming-With...

I thought composition vs inheritance was strictly an OO, not a functional thing?

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.

Re: Android: The Land That Python Forgot

#119

Post by voltagex_ »

KMag wrote: post #116
voltagex_ wrote: post #81

Earlier quoted context omitted.

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!

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.

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

Re: Android: The Land That Python Forgot

#120

Post by voltagex_ »

profquail wrote: post #84
voltagex_ wrote: post #79

Earlier quoted context omitted.

Where's the best place to brush up on composition vs inheritance?

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. [1]: http://www.amazon.com/Real-World-Functional-Programming-With...

Yeesh, $40 for the ePub directly from Manning, or $33 from Amazon for the print edition with a free ePub.
Post reply on HN