51–60 of 127 posts
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?)
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?)
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.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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.
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.
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.
I'm not as familiar with iOS ... is there broad language support for that OS?
Earlier quoted context omitted.
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 whic…
Working in C# right now and agonizing over the class hierarchy...
Earlier quoted context omitted.
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.
Are we really going to discuss this again? > code needs more debugging, it is harder to maintain and overall productivity is lower References?
Check the Dropbox's pain presentation: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
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.
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?