3 ms·

Even so, there's a difference between disallowing frameworks and disallowing bindings to other languages. Bindings are relatively simple to keep up to date. I

by mooism2 17y ago

Even so, there's a difference between disallowing frameworks and disallowing bindings to other languages. Bindings are relatively simple to keep up to date. I find it difficult to believe Apple would add a language feature to C/Objective-C/C++ that wouldn't essentially already exist in Java/Python/Haskell/etc. Not because Apple wouldn't be willing to do it, but because there aren't any game-changing language features waiting to be incorporated into modern programming languages. Blocks already exist in most languages as (more powerful) closures.

stevenwei 17y ago
It's an interesting thing to consider. Take the case of multitasking, where you end up passing a block to be executed as a background task. I wonder how well that will translate to other languages, which as you say, have similar constructs but perhaps varied differences in scoping rules, memory handling, etc?
cmeranda 17y ago
Bindings in themselves might be relatively simple to keep up to date, but binding documentation, error handling, etc, are not. Take a look at the Python bindings for Clutter (C graphics library w/Linux roots). Clutter is sponsored by Intel and well-maintained, and yet the Python bindings are several versions behind and the documentation is a mess. In a consistently evolving language and/or framework, every linkage creates delays.
mbleigh 17y ago
Changes to the iPhone SDK happen around yearly at best. Even vendors such as Adobe can manage a yearly release cycle. Beyond that, why does this need to be in the ToS of the SDK at all? If they only want applications that do a good job of supporting their APIs, then when a new app is submitted for inclusion in the App Store they can say "Hey, your app sucks for multitasking." The concern should be quality of application, not the toolchain used to develop the application. I suspect that many Flash-to-iPhone conversions would be rejected from a performance, stability, or other perspective, but there are better frameworks (such as Titanium) that play extremely nicely in the ecosystem and can be used to build real, performant applications.

by mooism2 17y ago

stevenwei 17y ago

It's an interesting thing to consider. Take the case of multitasking, where you end up passing a block to be executed as a background task. I wonder how well that will translate to other languages, which as you say, have similar constructs but perhaps varied differences in scoping rules, memory handling, etc?

cmeranda 17y ago

Bindings in themselves might be relatively simple to keep up to date, but binding documentation, error handling, etc, are not. Take a look at the Python bindings for Clutter (C graphics library w/Linux roots). Clutter is sponsored by Intel and well-maintained, and yet the Python bindings are several versions behind and the documentation is a mess. In a consistently evolving language and/or framework, every linkage creates delays.

mbleigh 17y ago

Changes to the iPhone SDK happen around yearly at best. Even vendors such as Adobe can manage a yearly release cycle. Beyond that, why does this need to be in the ToS of the SDK at all? If they only want applications that do a good job of supporting their APIs, then when a new app is submitted for inclusion in the App Store they can say "Hey, your app sucks for multitasking." The concern should be quality of application, not the toolchain used to develop the application. I suspect that many Flash-to-iPhone conversions would be rejected from a performance, stability, or other perspective, but there are better frameworks (such as Titanium) that play extremely nicely in the ecosystem and can be used to build real, performant applications.