3 ms·

I don't mean to be difficult, but I'm not quite following. It seems to me that setting out concrete criteria would be more exclusionary than the current policy

by chc 14y ago

I don't mean to be difficult, but I'm not quite following. It seems to me that setting out concrete criteria would be more exclusionary than the current policy of "If it runs OK, we don't care how you made the sausage." The only reason I can see to want Apple to be less permissive is if we're beset by a flood of crappy alternative languages and we need some standards to hold language implementors to — but I don't see that problem being a real thing. So I'm a little confused about what you're looking for.

stcredzero 14y ago
> The only reason I can see to want Apple to be less permissive is if we're beset by a flood of crappy alternative languages and we need some standards to hold language implementors to I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance. For the most part, they are as I described -- they are architected such that the whole of the SDK is covered automatically, little or no manual intervention required. Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future. Apple was bitten once by the Metroworks Codewarrior thing, where a 3rd party environment was the de-facto way of doing development and became a brake on progress with their APIs. Introducing a standard where automatic coverage of newly released SDKs is the central point would get them out of the business of ad-hoc approval of such environments while protecting their interests. > So I'm a little confused about what you're looking for. Either you didn't have all of the background info, you didn't bring it to mind, or you think of those circumstances in a different way.
- chc 14y ago
  > I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance. Well, it's a little more than "those exist despite Apple's original stance." Apple explicitly changed its rules to eliminate that restriction in response to developers' feedback. > Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future. Ah, I think this might be where we are seeing things differently. Apple very clearly changed its rules to allow alternative languages, which means it's "supported right now," which I view as close to the maximal level of commitment one can get from Apple about anything. I don't feel like something more formal would indicate more of a commitment. Apple could change its rules to disallow alternative languages tomorrow; it could also do the same thing the day after it set down standards for alternative languages. After how abruptly Apple cut off Carbon and Java developers, killed development on the Objective-C garbage collector almost as soon as it was released, deprecated the garbage collector shortly after the App Store was released (meaning that GC apps were then banned from the store) and axed Rosetta after just two OS updates, I've come to realize that Apple has absolutely no qualms about changing its mind no matter how explicitly it supported something yesterday.

by chc 14y ago

stcredzero 14y ago

> The only reason I can see to want Apple to be less permissive is if we're beset by a flood of crappy alternative languages and we need some standards to hold language implementors to I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance. For the most part, they are as I described -- they are architected such that the whole of the SDK is covered automatically, little or no manual intervention required. Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future. Apple was bitten once by the Metroworks Codewarrior thing, where a 3rd party environment was the de-facto way of doing development and became a brake on progress with their APIs. Introducing a standard where automatic coverage of newly released SDKs is the central point would get them out of the business of ad-hoc approval of such environments while protecting their interests. > So I'm a little confused about what you're looking for. Either you didn't have all of the background info, you didn't bring it to mind, or you think of those circumstances in a different way.

chc 14y ago
> I think the reason why there aren't more alternative languages, is that right now Apple is completely arbitrary about accepting a language/environment or not. The fact that one still has RubyMotion, eero, MonoTouch, and a host of others, despite their original stance of no is a nice circumstance. Well, it's a little more than "those exist despite Apple's original stance." Apple explicitly changed its rules to eliminate that restriction in response to developers' feedback. > Your mind is stuck on "less/more permissive." What I'm asking for is "more explicit" and as a consequence an element of commitment. As it stands now, it's arbitrary, and Apple can just say no in the future. Ah, I think this might be where we are seeing things differently. Apple very clearly changed its rules to allow alternative languages, which means it's "supported right now," which I view as close to the maximal level of commitment one can get from Apple about anything. I don't feel like something more formal would indicate more of a commitment. Apple could change its rules to disallow alternative languages tomorrow; it could also do the same thing the day after it set down standards for alternative languages. After how abruptly Apple cut off Carbon and Java developers, killed development on the Objective-C garbage collector almost as soon as it was released, deprecated the garbage collector shortly after the App Store was released (meaning that GC apps were then banned from the store) and axed Rosetta after just two OS updates, I've come to realize that Apple has absolutely no qualms about changing its mind no matter how explicitly it supported something yesterday.