"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.
BTW this is not about Adobe vs Apple. This is about Unity vs Apple. And the freedom of programmers to choose their own tools rather than be forced by lawyers to use what is in the latter's capital interest.
I didn't say: "manual garbage collection" I said enhanced to support manual memory management-- quite a difference.
A good programmer plans when (and how much) memory to acquire and knows when to release it.
The alternative is to have the system do garbage collection: look around, continuously, for memory to free. While not as expensive on a typical computer, it is very expensive on an embedded system where battery, cycles, RAM, time and UEX are critical.
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
The only real issue is you won't be able to make use of the background services in your compiled flash app. They will have to terminate completely before the user can launch a new app (which is the case for all apps today).
I just read a comment to an article on the same subject over on Ars. The commenter is doormat. I do not have his permission to quote, but what the heck, its a great comment.
"I think you're missing Gruber's point - not that cross platform apps are bad, its that they underutilize the platform to its fullest potential. Adobe is going to ship CS5 soonish, but Apple just released the 4.0 OS SDK. And since its under NDA until launch, Adobe cant offer a set of tools compatible with OS 4 until after it ships, so any app developed on initial CS5 products wont support multitasking because it wont be updated. Likewise for other new OS 4 features.
The point is that Apple isn't going to wait for others (Monotouch, Adobe) to catch up with its OS releases. If they become the predominant tools in developing mobile apps, any innovation Apple puts into the OS isn't utilized unless its supported by Adobe or Monotouch. Kinda like Flash, Apple doesn't like relying on third parties in what it considers its "critical path" to the customer. If a link in the chain is outside of Apple's control its a liability for them. If they drop the ball like IBM dropped the ball with the "3GHz G5" then Apple looks like an ass, or at least its at a disadvantage.
Last edited by doormat on 09 Apr 2010 23:05"
To me, this makes a great deal of sense.
I know nothing about developing, or third party development tools, but I'm pretty sure that Apple wouldn't alienate a big chunk of it's developers without good reason.
Going after Adobe makes no sense, Apple wants to kill Flash, not Adobe. This would also be a pretty drastic action to take just to put a little hurt on Android.
However, not having a quick uptake on new APIs because none of the third party development tools were ready? Yeah, that's a big issue.
However, not having a quick uptake on new APIs because none of the third party development tools were ready? Yeah, that's a big issue.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Exactly.
Who gets hurt in the end by Apple's anti-competitive actions? The consumer.
Speaking to all the devs in the thread, have any of you contacted Apple to discuss your concerns (especially the Unity engine question)? I know all of you are passionate about your work and how consumers will be affected, so I'm sure that Apple will be able to provide some clarity here. It is in their best interests to help you.
Have the mods here ever thought about putting a separate section in AI for devs to showcase their work? As a keen AI member I would be interested to see what the resident devs here have cooked up. :-)
Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
He did mention OS 4 will reach the iPad in the fall.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Really? Do you think that Apple would do something which could harm the App store just for the sake of slowing down the release of apps on other platforms? The App store is growing faster than any of the others.
Or is it to lower Adobe's market cap by a few million? What possible good could that do for Apple?
You don't take action of this sort unless it has positive benefits for you. You don't cut off your nose to spite your face.
Love or hate Apple, you cannot deny that they are an extremely astute company.
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
The only real issue is you won't be able to make use of the background services in your compiled flash app. They will have to terminate completely before the user can launch a new app (which is the case for all apps today).
But isn't Apple trying to improve the situation we have today?
In the 4.0 preso Scott Forrestall said that Apple analyzed thousands of apps to see if they could identify how to do intelligent multitasking (in several flavors).
Based on my tinkering, so far, they've done quite a good job.
What Apple are attempting to do is satisfy end users with an intuitive and predictable way to run multiple apps,
If a compiled Flash app always terminates completely, then it will confuse the user and [appear to] perform poorly (takes too long to start, doesn't resume where I left off, etc). Likely, these apps would reflect poorly on the platform.
Apple sometimes appears arbitrary on what they support... If they choose not to support 1Gen iPhones and iPod Touches, why shouldn't they be able to deny support for compilers that they feel will degrade the UEX?
As to the developer community-- it's in Apple's interest to have developers concentrate on developing quality, specialized apps on Apple's ecosystem, rather than developing generic one-size-fits-all apps that run (poorly) on any system. Remember the Java tenet: Write once, debug everywhere...
To meet Apple's goals with third-party developers, they must set some rules and offer some incentives. If they do this right... all will succeed. If not...
But, even if the Flash issue(s) are competitive, rather then technical-- Apple's management would be doing a disservice to their shareholders if they knowingly permit competitors to dissipate Apple's hard-won market advantages.
Apple is in business to make a profit-- as are MicroSoft and Adobe. In an industry like this, companies cooperate on some levels and compete on others... that's life!
So using Apple tools suddenly makes a bad programmer into a good programmer? Bad code can be written in ANY language. Everybody knows and accepts that. So it isn't the reason for the new restriction. The business advantage it confers on Apple and the harm it does to their competitors is the reason.
How did you get that? What I meant was that if developers were developing using the XCode tools then a lot of the work needed to do things would already be handled by the APIs which Apple has refined for the minimal specs of the devices. Why reinvent the wheel when Apple's already given you one with less weight?
Quote:
Originally Posted by Amdahl
I wasn't aware that iPhone OS was based on System 7.
It's running on devices with at least 128MB RAM and 600MHz processors. It doesn't take a rocket scientist to realise that programming methods used on desktop and laptops aren't going to work on a mobile device.
TOTAL BS. Anyone who believes this needs their head examined. There is an agenda to kill flash which has nothing to do with multitasking, that's just the excuse of the day.
Personally, I feel it's not just about Flash. If you can't use a cross-compiler, that also means that developers hoping for an EASY way to have an app on Android, webOS AND the iPhone are screwed.
My McIntosh Classic had 25Mb RAM (???). It was able to run MS Word 5, I was even able to integrate scientific equations in there, did internet (imagine when they were only kb speeds), and most of the applications then that I needed for basic research -- including basic graphs, presentation, etc.
Honestly, for a very long time, there is not much in the succeeding versions of MS Word that I really used but the program has bloated with succeeding versions.
Every added line in the script can mean additional instructions requiring allocation of resources -- thus slowing execution.
Now, it is not unusual to have applications in the Gb range. Most of the scripts never used by the user, or they are repeated in other applications.
Apple is correct when it pared its OS scripts when it developed v10.6 for the OS X. And, further paring the OS X down to come up with iPhone OS.
CGC
Exactly my point. Because of limited resources programmers worked within that. Remember the imposed 640KB limit of DOS and Windows pre-large cheap amounts of RAM and HDD space?
I had my Amiga 4000 running 16 apps once and it only had 1MB RAM. Old school programming showed real talent but with more resources available to programmers it means programmers got lazy and so code gets more and more bloated.
Snow Leopard showed a reversal of that idea when they removed GBs of space from the OS. Admittedly a lot of that was due to removing PPC code and printer drivers but it's a bog step in the right direction. Less is more. Less superfluous code equals more refined code more refined code means less resources required less resources required means more resources for doing work.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Even if your last statement is true... isn't that what business is about?
When was the last time Adobe, Microsoft, Apple released open source on their key software?
Or encouraged potential customers to use a competitor's product instead of their own.
Last time I looked, none of these companies was in business for the good of developers, customers or competitors (or the impossible task of satisfying everyone).
The purpose of business is to make a profit at the risk of a loss... everything else is in third place!
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Those "anti-competitive business reasons" have changed the computer industry from the stagnant crap hole it has always been into a forward moving computer manufacturer changing the way we work with computers and mobile devices. It's all been for the good of the consumer even if they did step on some people's toes to do it.
They controlled the hardware so were in a position to jump from 68000 to PPC and later from PPC to Intel. Yes it annoyed a lot of developers but the ones who did well were the ones who changed as soon as possible. It also mean the latest developments in computing had a platform that could be progress their technology. Apple killed off ADB, Serial, and Parallel in favour of USB, it killed off VGA in favour of DVI and DVI in favour of DisplayPort because it makes sense in the long run.
You can all complain as much as you want now but in the future you will look back and realise that this was the turning point in computing where developers moved forward instead of using old worthless technology.
How does someone write an app that depends on system-supplied garbage collection and then deploy it on a system (iPhone OS) that doesn't provide this service?
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
Quote:
Doesn't even Mr. GoodWrench require only GM authorized Parts and Procedures?
.
Auto analogies are not apt. GM owns Goodwrencch in any case; it's their name for the service dept at their dealerships.
Quote:
Originally Posted by habermas
"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.
GC is a feature of Objective-C 2.0 runtime. As other posters have said, iPhone does not support ObjC 2.0, hence, no GC.
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
No, Apple does not need to do this for that reason. Whether it is in ObjC or not, the OS is going to make those kinds of judgments based on API calls, time spent in blocking APIs, or event timers set. It doesn't matter what dev tools was used to produce the binary code that the ARM chip is running, as it all ends up interfacing with the OS in the same way. Apple already enforces that with the ban on Private Frameworks.
Quote:
Originally Posted by LTMP
You don't take action of this sort unless it has positive benefits for you. You don't cut off your nose to spite your face.
Love or hate Apple, you cannot deny that they are an extremely astute company.
Uh, I guess you've never read much about Steve Jobs.
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
Auto analogies are not apt. GM owns Goodwrencch in any case; it's their name for the service dept at their dealerships.
GC is a feature of Objective-C 2.0 runtime. As other posters have said, iPhone does not support ObjC 2.0, hence, no GC.
The alternative is to have the system do garbage collection: look around, continuously, for memory to free. While not as expensive on a typical computer, it is very expensive on an embedded system where battery, cycles, RAM, time and UEX are critical.
Wrong on so many levels. This was true about garbage collection in 1995. A modern generational garbage collector allocates memory about 20x faster than malloc() does (all an allocation requires is incrementing a pointer into the heap; it's almost as fast as stack allocation).
And a modern garbage collector is more cache efficient because you're not constantly invalidating cache lines to retain/release reference counts. The total time spent on garbage collection is almost always significantly less than is spent on reference counting. Modern collectors are incremental too, so they never scan the entire heap in one go. Cocoa uses autorelease pools to defer object deallocation, which is WAY slower than garbage collection.
Furthermore, if you use a modern, strictly typed language, like any statically compiled JVM/CLR language, the compiler actually eliminates many object allocations all together using escape analysis. This makes the code run even faster than C++ stack allocated structs since the compiler can see several layers of the call stack and eliminate copying that C++ might naively do (and it's significantly faster than Objective-C's heavyweight objects). And since these languages don't use dynamic dispatch like Objective-C does, you get method inlining which further increases execution speed (Objective-C compilers can't inline anything because of the calling conventions and because classes are always open for extension).
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime. But you can natively compile Java (or Scala or C#) without the platform so you're just running native code linked with Apple's native libraries. And it will run faster and with less memory use than equivalent Objective-C code. And it will be more stable and more maintainable.
There's no reason that modern, static languages should be prohibited. Progress just happens to be collateral damage in Apple's war with Adobe. And Apple's users will suffer because of it.
Comments
"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.
BTW this is not about Adobe vs Apple. This is about Unity vs Apple. And the freedom of programmers to choose their own tools rather than be forced by lawyers to use what is in the latter's capital interest.
I didn't say: "manual garbage collection" I said enhanced to support manual memory management-- quite a difference.
A good programmer plans when (and how much) memory to acquire and knows when to release it.
The alternative is to have the system do garbage collection: look around, continuously, for memory to free. While not as expensive on a typical computer, it is very expensive on an embedded system where battery, cycles, RAM, time and UEX are critical.
.
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
The only real issue is you won't be able to make use of the background services in your compiled flash app. They will have to terminate completely before the user can launch a new app (which is the case for all apps today).
"I think you're missing Gruber's point - not that cross platform apps are bad, its that they underutilize the platform to its fullest potential. Adobe is going to ship CS5 soonish, but Apple just released the 4.0 OS SDK. And since its under NDA until launch, Adobe cant offer a set of tools compatible with OS 4 until after it ships, so any app developed on initial CS5 products wont support multitasking because it wont be updated. Likewise for other new OS 4 features.
The point is that Apple isn't going to wait for others (Monotouch, Adobe) to catch up with its OS releases. If they become the predominant tools in developing mobile apps, any innovation Apple puts into the OS isn't utilized unless its supported by Adobe or Monotouch. Kinda like Flash, Apple doesn't like relying on third parties in what it considers its "critical path" to the customer. If a link in the chain is outside of Apple's control its a liability for them. If they drop the ball like IBM dropped the ball with the "3GHz G5" then Apple looks like an ass, or at least its at a disadvantage.
Last edited by doormat on 09 Apr 2010 23:05"
To me, this makes a great deal of sense.
I know nothing about developing, or third party development tools, but I'm pretty sure that Apple wouldn't alienate a big chunk of it's developers without good reason.
Going after Adobe makes no sense, Apple wants to kill Flash, not Adobe. This would also be a pretty drastic action to take just to put a little hurt on Android.
However, not having a quick uptake on new APIs because none of the third party development tools were ready? Yeah, that's a big issue.
To me, this makes a great deal of sense.
...snip
However, not having a quick uptake on new APIs because none of the third party development tools were ready? Yeah, that's a big issue.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Exactly.
Who gets hurt in the end by Apple's anti-competitive actions? The consumer.
Have the mods here ever thought about putting a separate section in AI for devs to showcase their work? As a keen AI member I would be interested to see what the resident devs here have cooked up. :-)
Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
He did mention OS 4 will reach the iPad in the fall.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Really? Do you think that Apple would do something which could harm the App store just for the sake of slowing down the release of apps on other platforms? The App store is growing faster than any of the others.
Or is it to lower Adobe's market cap by a few million? What possible good could that do for Apple?
You don't take action of this sort unless it has positive benefits for you. You don't cut off your nose to spite your face.
Love or hate Apple, you cannot deny that they are an extremely astute company.
This is the origin comment: http://forums.appleinsider.com/showt...17#post1609017
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
The only real issue is you won't be able to make use of the background services in your compiled flash app. They will have to terminate completely before the user can launch a new app (which is the case for all apps today).
But isn't Apple trying to improve the situation we have today?
In the 4.0 preso Scott Forrestall said that Apple analyzed thousands of apps to see if they could identify how to do intelligent multitasking (in several flavors).
Based on my tinkering, so far, they've done quite a good job.
What Apple are attempting to do is satisfy end users with an intuitive and predictable way to run multiple apps,
If a compiled Flash app always terminates completely, then it will confuse the user and [appear to] perform poorly (takes too long to start, doesn't resume where I left off, etc). Likely, these apps would reflect poorly on the platform.
Apple sometimes appears arbitrary on what they support... If they choose not to support 1Gen iPhones and iPod Touches, why shouldn't they be able to deny support for compilers that they feel will degrade the UEX?
As to the developer community-- it's in Apple's interest to have developers concentrate on developing quality, specialized apps on Apple's ecosystem, rather than developing generic one-size-fits-all apps that run (poorly) on any system. Remember the Java tenet: Write once, debug everywhere...
To meet Apple's goals with third-party developers, they must set some rules and offer some incentives. If they do this right... all will succeed. If not...
But, even if the Flash issue(s) are competitive, rather then technical-- Apple's management would be doing a disservice to their shareholders if they knowingly permit competitors to dissipate Apple's hard-won market advantages.
Apple is in business to make a profit-- as are MicroSoft and Adobe. In an industry like this, companies cooperate on some levels and compete on others... that's life!
.
So using Apple tools suddenly makes a bad programmer into a good programmer? Bad code can be written in ANY language. Everybody knows and accepts that. So it isn't the reason for the new restriction. The business advantage it confers on Apple and the harm it does to their competitors is the reason.
How did you get that? What I meant was that if developers were developing using the XCode tools then a lot of the work needed to do things would already be handled by the APIs which Apple has refined for the minimal specs of the devices. Why reinvent the wheel when Apple's already given you one with less weight?
I wasn't aware that iPhone OS was based on System 7.
It's running on devices with at least 128MB RAM and 600MHz processors. It doesn't take a rocket scientist to realise that programming methods used on desktop and laptops aren't going to work on a mobile device.
TOTAL BS. Anyone who believes this needs their head examined. There is an agenda to kill flash which has nothing to do with multitasking, that's just the excuse of the day.
Personally, I feel it's not just about Flash. If you can't use a cross-compiler, that also means that developers hoping for an EASY way to have an app on Android, webOS AND the iPhone are screwed.
Some believe this might end up in court.
My McIntosh Classic had 25Mb RAM (???). It was able to run MS Word 5, I was even able to integrate scientific equations in there, did internet (imagine when they were only kb speeds), and most of the applications then that I needed for basic research -- including basic graphs, presentation, etc.
Honestly, for a very long time, there is not much in the succeeding versions of MS Word that I really used but the program has bloated with succeeding versions.
Every added line in the script can mean additional instructions requiring allocation of resources -- thus slowing execution.
Now, it is not unusual to have applications in the Gb range. Most of the scripts never used by the user, or they are repeated in other applications.
Apple is correct when it pared its OS scripts when it developed v10.6 for the OS X. And, further paring the OS X down to come up with iPhone OS.
CGC
Exactly my point. Because of limited resources programmers worked within that. Remember the imposed 640KB limit of DOS and Windows pre-large cheap amounts of RAM and HDD space?
I had my Amiga 4000 running 16 apps once and it only had 1MB RAM. Old school programming showed real talent but with more resources available to programmers it means programmers got lazy and so code gets more and more bloated.
Snow Leopard showed a reversal of that idea when they removed GBs of space from the OS. Admittedly a lot of that was due to removing PPC code and printer drivers but it's a bog step in the right direction. Less is more. Less superfluous code equals more refined code more refined code means less resources required less resources required means more resources for doing work.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Even if your last statement is true... isn't that what business is about?
When was the last time Adobe, Microsoft, Apple released open source on their key software?
Or encouraged potential customers to use a competitor's product instead of their own.
Last time I looked, none of these companies was in business for the good of developers, customers or competitors (or the impossible task of satisfying everyone).
The purpose of business is to make a profit at the risk of a loss... everything else is in third place!
.
It makes sense because you want to believe in Apple. They have proven there is no line they won't cross. That being the case, all they have to do is MANDATE apps support certain features or APIs. Blocking all dev tools except their own is done only for anti-competitive business reasons.
Those "anti-competitive business reasons" have changed the computer industry from the stagnant crap hole it has always been into a forward moving computer manufacturer changing the way we work with computers and mobile devices. It's all been for the good of the consumer even if they did step on some people's toes to do it.
They controlled the hardware so were in a position to jump from 68000 to PPC and later from PPC to Intel. Yes it annoyed a lot of developers but the ones who did well were the ones who changed as soon as possible. It also mean the latest developments in computing had a platform that could be progress their technology. Apple killed off ADB, Serial, and Parallel in favour of USB, it killed off VGA in favour of DVI and DVI in favour of DisplayPort because it makes sense in the long run.
You can all complain as much as you want now but in the future you will look back and realise that this was the turning point in computing where developers moved forward instead of using old worthless technology.
How does someone write an app that depends on system-supplied garbage collection and then deploy it on a system (iPhone OS) that doesn't provide this service?
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
Doesn't even Mr. GoodWrench require only GM authorized Parts and Procedures?
.
Auto analogies are not apt. GM owns Goodwrencch in any case; it's their name for the service dept at their dealerships.
"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.
GC is a feature of Objective-C 2.0 runtime. As other posters have said, iPhone does not support ObjC 2.0, hence, no GC.
This is the origin comment: http://forums.appleinsider.com/showt...17#post1609017
And here is another comment: this is not the reason Apple changed the language in the licensing agreement. The iPhone OS supports preemptive multitasking. It can easily run a compiled flash app in the foreground whilst also running multiple background services such as the voip service used by Skype and the background audio service used by Pandora. There is no real difference between this and running iPhone OS 3.2 with music playing in the background or talking on the phone.
Actually, the original ktappe post was http://forums.appleinsider.com/showp...9&postcount=85
And my reply was two posts later:
No, Apple does not need to do this for that reason. Whether it is in ObjC or not, the OS is going to make those kinds of judgments based on API calls, time spent in blocking APIs, or event timers set. It doesn't matter what dev tools was used to produce the binary code that the ARM chip is running, as it all ends up interfacing with the OS in the same way. Apple already enforces that with the ban on Private Frameworks.
You don't take action of this sort unless it has positive benefits for you. You don't cut off your nose to spite your face.
Love or hate Apple, you cannot deny that they are an extremely astute company.
Uh, I guess you've never read much about Steve Jobs.
A valid argument.. if garbage collection was the issue. Which it isn't. But maybe you can email Apple PR (don't forget to CC: AI) and give them the tip.
If GC CPU/power drain was the problem, the solution is you run it less often. Or create and discard less objects. It is not a big issue for the typical crApp. Java does require garbage collection, but it is provided by the Java VM (aka runtime). The cost, as you noted, is in occasional CPU use or increased memory footprint. The increased memory footprint allows less frequent execution of the garbage collector, compared to an equal load with less spare memory.
Auto analogies are not apt. GM owns Goodwrencch in any case; it's their name for the service dept at their dealerships.
GC is a feature of Objective-C 2.0 runtime. As other posters have said, iPhone does not support ObjC 2.0, hence, no GC.
crApp?
Blocking all dev tools except their own is done only for anti-competitive business reasons.
Thinking about it, anticompetitive is a funny word with funny meaning... like flammable and inflammable.
When someone uses a strategic advantage, a position of strength, to mitigate a competitor's advantage... isn't that being competitive?
Haven't Apple, Microsoft, Adobe and others tried to exploit their competitive advantages?
Maybe Apple should help Adobe with Flash so developers can write apps to help sell Goggle phones!
Would you buy a product from a company that was that stupid?
C'mon?
.
The alternative is to have the system do garbage collection: look around, continuously, for memory to free. While not as expensive on a typical computer, it is very expensive on an embedded system where battery, cycles, RAM, time and UEX are critical.
Wrong on so many levels. This was true about garbage collection in 1995. A modern generational garbage collector allocates memory about 20x faster than malloc() does (all an allocation requires is incrementing a pointer into the heap; it's almost as fast as stack allocation).
And a modern garbage collector is more cache efficient because you're not constantly invalidating cache lines to retain/release reference counts. The total time spent on garbage collection is almost always significantly less than is spent on reference counting. Modern collectors are incremental too, so they never scan the entire heap in one go. Cocoa uses autorelease pools to defer object deallocation, which is WAY slower than garbage collection.
Furthermore, if you use a modern, strictly typed language, like any statically compiled JVM/CLR language, the compiler actually eliminates many object allocations all together using escape analysis. This makes the code run even faster than C++ stack allocated structs since the compiler can see several layers of the call stack and eliminate copying that C++ might naively do (and it's significantly faster than Objective-C's heavyweight objects). And since these languages don't use dynamic dispatch like Objective-C does, you get method inlining which further increases execution speed (Objective-C compilers can't inline anything because of the calling conventions and because classes are always open for extension).
The reason Java is still slow and shitty on the desktop is because of the bloated java platform, not because of the language or runtime. But you can natively compile Java (or Scala or C#) without the platform so you're just running native code linked with Apple's native libraries. And it will run faster and with less memory use than equivalent Objective-C code. And it will be more stable and more maintainable.
There's no reason that modern, static languages should be prohibited. Progress just happens to be collateral damage in Apple's war with Adobe. And Apple's users will suffer because of it.
crApp?
I do believe he has coined a new word, acronym actually... and it seems to fit the OSFA cross-platform apps in discussion.
Here's a question:
How does a developer write a cross-platform app like Koi Pond?
.