He's been pretty clear in his email about the motivations (pointing to Grubers article) and they are really pretty obvious to an intelligent observer.
Only if intelligent observer is already surrounded with reality distortion filed.
I don't care what SJ said. Obviously he will say whatever he thinks is the best way to defend this move and minimize bad publicity... so let's not make it personal. Two intelligent observers might see it in a different way, and both ways might be far from actual truth... which also might be far from what SJ said.
this to me is a bollocks, non issue, if it were pretty much anyone else other than apple no one would be on their case, because no one would care.
Actually, no, if Microsoft did this, everyone would be up in arms. The truth is that Microsoft could easily block iTunes by saying it uses non-standard APIs. But Microsoft doesn't do this, because they aren't that evil.
I don't want Ford or Honda to dictate what brand of wrench can be used to work on their car.
This is already the case with nearly all auto manufacturers. There are a number of special tools,especially the diagnostic tools, that are generally only available to mechs with the appropriate manufacturer training and licensed business.
So give up trying to create a new situation where there isn't one. This is the way vertical markets have worked since vertical markets emerged, and it is legal and ethical.
It doesn't matter that some folks suddenly want to jump on one vertical market as being "abusive" because the requirement was made explicit in broad daylight. First look at all those other vertical markets that are operating happily and with the full blessings of even the newly indignant over Apple folks.
If one vertical market is OK, the are all OK, within the legal limits of monopoly market abuses. And we are nowhere near monopoly levels in Apple and computing, not even in Apple and mobile computing so that just leaves the question of are vertical markets OK or not? It is an all or none question, with all the unintended consequences to be paid if you decide to suddenly make the whole concept go away. But if you don't want vertical markets to go away, you can't just pick on one instance and say it's "wrong" or "bad". Logic and fairness just doesn't work that way.
There are two perspectives here, one as a user and one as programmer/developer.
First from the perspective as a user Apple skould be absolutely scared to death that app store will be flooded by software written by flash developers. I'm using the term "flash developers" very loosely here but flash has a well deserved reputation amonst web users that is not all that nice. In large part flash software is crap and it really doesn't matter if we are talking a banking site or a porn site, the vast majority of sites out there are prime examples of bad programming. Now consider this when a user has a problem with an app store program whom are they going to complain to first?
As a on again off again programmer I look at some of the comments here and here a common refrain between the lines. That is one of XCode is to difficult for me. Frankly if that is the case you are on the wrong platform. There is nothing difficult about Objective C and if your objections revolve around not wanting or being able to learn Objective C then frankly screw you, the platform doesn't need you.
This is not the same thing as argueing about programmer productivity which is an entirely different discussion. There is little doubt that different languages would pay off for some developers. Unfortunately Apple doesn't offer anything at the moment, but it is there right to do so. In the long run I'd really like to see a Python or Ruby IDE on iPad directly supported by Apple - will that happen?
As a side not even Apple has a poor history of supporting middle ware. AquaTK for TCL or Python being one very good (bad) example. It is pretty hard to dismiss their point here, especially on fast moving platforms like IPhone OS. It does make sense to promote you native objects and to make sure they are implemented by developers as quick as possible.
So yeah Apple more or less carpet bombed the developer landscape. Many think this is targeted directly at Adobe which is possible but we will never know for sure. Even if it was never targetted at Adobe directly, it makes me very happy to see them suffer.
One other thing that may be of a big concern to Apple is the fat that such adaptive layers add to programs. Sadly Apples recent device don't have enough memory to run Apples own ports, such as iWork, properly. This restriction could be a way for them tomask the problem for a bit longer. It may also be a sign that Apple really doesn't want certain classes of apps on these devices.
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
Oh, the ignorance... they don't.
The guts of iTunes and Safari are CoreFoundation which is C, Quicktime which is C and Webkit which is C++, all of which is 'native' to windows... that's about 80% of the code there (probably even more).
Someone can correct me if I'm hideously wrong, but the iTunes and Safari for windows at least are Carbonesque... recent safari builds have lost their 'Apple' look, so I'd wager that safari might have gone native at some point, and iTunes may still be using a carbon like wrapper to native win32. IIRC the Mac version of iTunes isn't even Cocoa yet.
The objective-c compiler will compile code for windows, this is true (GNUStep and Cocotron both use it), but there is little likelihood there is are Cocoa frameworks for windows. There used to be yellowbox, which was a remnant from OpenSTEP, but Apple have little incentive to maintain it... for just two applications, separate code trees for the user interface is a far more pragmatic approach.
Oh, the ignorance... they don't. The guts of iTunes...
I understood this was still Carbon and QuickTime. (Since QuickTime has a CarbonLayer/Toolbox that's ported to Windows, this helps it run cross platform). End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
I understood this was still Carbon and QuickTime. (Since QuickTime has a CarbonLayer/Toolbox that's ported to Windows, this helps it run cross platform). End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
So they are well aware of the negative effects of abstraction layer.
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
That is because Windows has exercised the right to allow such things.
Now if Microsoft were to prohibit such coding in favor of true native code and Apple complained, that would be hypocrisy.
As for this gentleman it seems like he's ignoring the reasons given as either illogical or simply lies (to cover up Apple's hatred of Adobe blah blah). He doesn't seem to care if it's the best thing to do etc. Various people have spoken out that the Adobe converter creates code that is up to 10 times the length you can do writing it by hand. On a platform with limited storage, a bloated app is not a good thing. And other potential issues have been pointed out.
So they are well aware of the negative effects of abstraction layer.
Yes. It let them create a solution that's worked for 8 years for a fraction of the time and cost it would of. The horror. They want to ban that for anyone else and make their customers/competitors eat those costs.
Again, we get back to the inane argument that iFart is a better app that some other App, because it it is written in ObjectiveC.
Yes. It let them create a solution that's worked for 8 years for a fraction of the time and cost it would of. The horror. They want to ban that for anyone else and make their customers/competitors eat those costs.
Again, we get back to the inane argument that iFart is a better app that some other App, because it it is written in ObjectiveC.
If I were apple, after witnessing the horror of quicktime on windows I would ban all middleware immediately.
End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
This hypocrisy charge is repeated over and over again in these threads, but there is nothing hypocritical about this at all. Apple is following the rules for Windows development as set by Microsoft. Microsoft follows the rules for Mac OS X development, as set by Apple. And iPhone OS is a different platform with different rules, set by Apple. There's no hypocrisy. Just different platforms with different rules.
Now, exactly what abstraction layer are they using that they forbid others from using?
Now if Microsoft were to prohibit such coding in favor of true native code and Apple complained, that would be hypocrisy.....
So would using libraries and abstractions that you forbid everyone else from using.
Quote:
Originally Posted by charlituna
Various people have spoken out that the Adobe converter creates code that is up to 10 times the length you can do writing it by hand. On a platform with limited storage, a bloated app is not a good thing. And other potential issues have been pointed out.
This is silly. Let me explain:
The best thing to do is write your code in perfectly threaded perfectly optimized machine code. It'll take 100 times as long, but it'll be smaller and faster. No one does this. Why? Not worth the costs.
All software is abstractions: we call much of "OOD" which is building lots of intermediary layers (assuming inheritance and polymorphism).
If you have 64 Gigabytes of storage, how much do you care if a useful program to you takes 1MB versus 2MB? Answer: not much (if you're sane). Increasing code size may be completely irrelevant on a program that has huge chunks of data.
In a perfect world, you'd only write in machine code and not that abomination ObjectiveC or ActionScript. In the real world, you might have a really useful, well working App written for Flash, and you want to put quickly put it on the iPhone. Since it's not much work, you do it over a weekend, it passes Apple's quality and you can give it away for free for the promotional gains it gets you. Or you can throw away your working solution, rewrite it in ObjectiveC -- create lots of new bugs, take months to deliver it, and then have to charge people for all the time you wasted. And users save some space they don't care about, or get some theoretical performance gains that they may never notice. Woo hoo.
Now, exactly what abstraction layer are they using that they forbid others from using?
Their browser interprets what language? HTML, XML, Javascript. What about PDF (that's a language too). They make programs that are intermediate interpreters of other languages: others can't. When they need more power or flexibility, they just change the rules. Apple's own rule says you can only use Javascript as interpreted by what they put in. So you can't even interpret Javascript on your own -- if they have a bug and you want to interpret around it, you can't. Browsers can't include their own Javascript interpreters that are faster and fuller featured than Apple. (Same for HTML and XML or PDF). Heck, most file parsers should be outlawed under apple's rules, because like it or not, file/data descriptions are a primitive programming language -- that's not "originally" in C or ObjC. And so on.
this to me is a bollocks, non issue, if it were pretty much anyone else other than apple no one would be on their case, because no one would care. If it had been apple circa 1999 no one would be on apple's back either, because no one would be threatened.
Now apple as much as sneezes and we have a ton of pundits commenting on it.
That is actually a good thing. It shows how well they have done and how relevant they are again. If Apple didn't evoke emotion they would not be as successful as they are and the membership at forums like this would pretty boring.
Having said that, there has always been healthy debate within the Apple user community. These days it seems the nouveau fans go a bit over the top in trying to show how loyal they can be...no disagreement or dissent is allowed.
To say "Flash Sucks" shows ignorant of software development. Flash is a tool. Do we argue "a screwdriver sucks? It does at pounding nails or cutting wood -- for driving screws, it isn't that bad. There are many Flash apps that are better than iFart, shaking babies, or jiggling booby apps that they
Unless it's a sucky screwdriver that slips out and gouges the wood and strips the screw head.
Actually, no, if Microsoft did this, everyone would be up in arms. The truth is that Microsoft could easily block iTunes by saying it uses non-standard APIs. But Microsoft doesn't do this, because they aren't that evil.
No, MS doesn't do it because they would be reopening a can of worms they are desperate to forget about.
I think Apple totally shits itself here! They are wrong, ignorant or just plain uninformed! Objective-C is an old and dated language (despite late improvements), not the sharpest tool in the box and APIs (in this case iPhone 4's) can perfectly transcend most language and platform environments without any impedance added between developer and platform. Jobs, please take a hike!
While I appreciate Apple's new policy and can easily agree that it is in their strategic best interests, at least in addressing 90% of their market, I think this decision kills many long-tail apps, and systems that require multi-platform support.
I am not a programmer/developer; I am a business owner. Say I want to build an app to serve electrical engineers in my office. We have 60% Blackberries and 40% iPhones. Neither set of users has a compelling reason to change handsets. There may be a business case for doing something that supports everyone, but we aren't going to build our business around any single platform. (We too have learned from past mistakes.)
If it doesn't make sense for just us, how about something that serves our entire industry. There are about 50,000 licensed, practicing Professional Electrical Engineers in the US. Selling to 20% of them that may have iPhones and be interested would be an optimistic target: up to 10,000 unit sales!
The problem is that there just isn't a real incentive to drive these long-tail applications, and even less for internal application development if you aren't supporting 2-3 platforms with minimal incremental effort.
I also hear programmer issues related to short-cycle programming efforts. Apple is right on this, but they sure are wrong.
Comments
He's been pretty clear in his email about the motivations (pointing to Grubers article) and they are really pretty obvious to an intelligent observer.
Only if intelligent observer is already surrounded with reality distortion filed.
I don't care what SJ said. Obviously he will say whatever he thinks is the best way to defend this move and minimize bad publicity... so let's not make it personal. Two intelligent observers might see it in a different way, and both ways might be far from actual truth... which also might be far from what SJ said.
this to me is a bollocks, non issue, if it were pretty much anyone else other than apple no one would be on their case, because no one would care.
Actually, no, if Microsoft did this, everyone would be up in arms. The truth is that Microsoft could easily block iTunes by saying it uses non-standard APIs. But Microsoft doesn't do this, because they aren't that evil.
I don't want Ford or Honda to dictate what brand of wrench can be used to work on their car.
This is already the case with nearly all auto manufacturers. There are a number of special tools,especially the diagnostic tools, that are generally only available to mechs with the appropriate manufacturer training and licensed business.
So give up trying to create a new situation where there isn't one. This is the way vertical markets have worked since vertical markets emerged, and it is legal and ethical.
It doesn't matter that some folks suddenly want to jump on one vertical market as being "abusive" because the requirement was made explicit in broad daylight. First look at all those other vertical markets that are operating happily and with the full blessings of even the newly indignant over Apple folks.
If one vertical market is OK, the are all OK, within the legal limits of monopoly market abuses. And we are nowhere near monopoly levels in Apple and computing, not even in Apple and mobile computing so that just leaves the question of are vertical markets OK or not? It is an all or none question, with all the unintended consequences to be paid if you decide to suddenly make the whole concept go away. But if you don't want vertical markets to go away, you can't just pick on one instance and say it's "wrong" or "bad". Logic and fairness just doesn't work that way.
First from the perspective as a user Apple skould be absolutely scared to death that app store will be flooded by software written by flash developers. I'm using the term "flash developers" very loosely here but flash has a well deserved reputation amonst web users that is not all that nice. In large part flash software is crap and it really doesn't matter if we are talking a banking site or a porn site, the vast majority of sites out there are prime examples of bad programming. Now consider this when a user has a problem with an app store program whom are they going to complain to first?
As a on again off again programmer I look at some of the comments here and here a common refrain between the lines. That is one of XCode is to difficult for me. Frankly if that is the case you are on the wrong platform. There is nothing difficult about Objective C and if your objections revolve around not wanting or being able to learn Objective C then frankly screw you, the platform doesn't need you.
This is not the same thing as argueing about programmer productivity which is an entirely different discussion. There is little doubt that different languages would pay off for some developers. Unfortunately Apple doesn't offer anything at the moment, but it is there right to do so. In the long run I'd really like to see a Python or Ruby IDE on iPad directly supported by Apple - will that happen?
As a side not even Apple has a poor history of supporting middle ware. AquaTK for TCL or Python being one very good (bad) example. It is pretty hard to dismiss their point here, especially on fast moving platforms like IPhone OS. It does make sense to promote you native objects and to make sure they are implemented by developers as quick as possible.
So yeah Apple more or less carpet bombed the developer landscape. Many think this is targeted directly at Adobe which is possible but we will never know for sure. Even if it was never targetted at Adobe directly, it makes me very happy to see them suffer.
One other thing that may be of a big concern to Apple is the fat that such adaptive layers add to programs. Sadly Apples recent device don't have enough memory to run Apples own ports, such as iWork, properly. This restriction could be a way for them tomask the problem for a bit longer. It may also be a sign that Apple really doesn't want certain classes of apps on these devices.
Dave
Let me summarize the whole thing:
* Can I code in C? Yes.
* Do I want to? No.
It is that simple.
Cheers,
Rui
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
Oh the Irony. And what hypocrisy!
Oh, the ignorance... they don't.
The guts of iTunes and Safari are CoreFoundation which is C, Quicktime which is C and Webkit which is C++, all of which is 'native' to windows... that's about 80% of the code there (probably even more).
Someone can correct me if I'm hideously wrong, but the iTunes and Safari for windows at least are Carbonesque... recent safari builds have lost their 'Apple' look, so I'd wager that safari might have gone native at some point, and iTunes may still be using a carbon like wrapper to native win32. IIRC the Mac version of iTunes isn't even Cocoa yet.
The objective-c compiler will compile code for windows, this is true (GNUStep and Cocotron both use it), but there is little likelihood there is are Cocoa frameworks for windows. There used to be yellowbox, which was a remnant from OpenSTEP, but Apple have little incentive to maintain it... for just two applications, separate code trees for the user interface is a far more pragmatic approach.
Oh, the ignorance... they don't. The guts of iTunes...
I understood this was still Carbon and QuickTime. (Since QuickTime has a CarbonLayer/Toolbox that's ported to Windows, this helps it run cross platform). End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
I understood this was still Carbon and QuickTime. (Since QuickTime has a CarbonLayer/Toolbox that's ported to Windows, this helps it run cross platform). End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
So they are well aware of the negative effects of abstraction layer.
Good point. Apple uses a compatibility layer (Cocoa) to get iTunes and Safari to run on Windows without having to rewrite them from scratch as native applications. And they do it in a different programming language than what Windows' native APIs are written in.
That is because Windows has exercised the right to allow such things.
Now if Microsoft were to prohibit such coding in favor of true native code and Apple complained, that would be hypocrisy.
As for this gentleman it seems like he's ignoring the reasons given as either illogical or simply lies (to cover up Apple's hatred of Adobe blah blah). He doesn't seem to care if it's the best thing to do etc. Various people have spoken out that the Adobe converter creates code that is up to 10 times the length you can do writing it by hand. On a platform with limited storage, a bloated app is not a good thing. And other potential issues have been pointed out.
So they are well aware of the negative effects of abstraction layer.
Yes. It let them create a solution that's worked for 8 years for a fraction of the time and cost it would of. The horror. They want to ban that for anyone else and make their customers/competitors eat those costs.
Again, we get back to the inane argument that iFart is a better app that some other App, because it it is written in ObjectiveC.
Yes. It let them create a solution that's worked for 8 years for a fraction of the time and cost it would of. The horror. They want to ban that for anyone else and make their customers/competitors eat those costs.
Again, we get back to the inane argument that iFart is a better app that some other App, because it it is written in ObjectiveC.
If I were apple, after witnessing the horror of quicktime on windows I would ban all middleware immediately.
End results, Apple still using abstraction layers that they forbid others from doing. At best they're hypocrites.
This hypocrisy charge is repeated over and over again in these threads, but there is nothing hypocritical about this at all. Apple is following the rules for Windows development as set by Microsoft. Microsoft follows the rules for Mac OS X development, as set by Apple. And iPhone OS is a different platform with different rules, set by Apple. There's no hypocrisy. Just different platforms with different rules.
Now, exactly what abstraction layer are they using that they forbid others from using?
Now if Microsoft were to prohibit such coding in favor of true native code and Apple complained, that would be hypocrisy.....
So would using libraries and abstractions that you forbid everyone else from using.
Various people have spoken out that the Adobe converter creates code that is up to 10 times the length you can do writing it by hand. On a platform with limited storage, a bloated app is not a good thing. And other potential issues have been pointed out.
This is silly. Let me explain:
The best thing to do is write your code in perfectly threaded perfectly optimized machine code. It'll take 100 times as long, but it'll be smaller and faster. No one does this. Why? Not worth the costs.
All software is abstractions: we call much of "OOD" which is building lots of intermediary layers (assuming inheritance and polymorphism).
If you have 64 Gigabytes of storage, how much do you care if a useful program to you takes 1MB versus 2MB? Answer: not much (if you're sane). Increasing code size may be completely irrelevant on a program that has huge chunks of data.
In a perfect world, you'd only write in machine code and not that abomination ObjectiveC or ActionScript. In the real world, you might have a really useful, well working App written for Flash, and you want to put quickly put it on the iPhone. Since it's not much work, you do it over a weekend, it passes Apple's quality and you can give it away for free for the promotional gains it gets you. Or you can throw away your working solution, rewrite it in ObjectiveC -- create lots of new bugs, take months to deliver it, and then have to charge people for all the time you wasted. And users save some space they don't care about, or get some theoretical performance gains that they may never notice. Woo hoo.
Now, exactly what abstraction layer are they using that they forbid others from using?
Their browser interprets what language? HTML, XML, Javascript. What about PDF (that's a language too). They make programs that are intermediate interpreters of other languages: others can't. When they need more power or flexibility, they just change the rules. Apple's own rule says you can only use Javascript as interpreted by what they put in. So you can't even interpret Javascript on your own -- if they have a bug and you want to interpret around it, you can't. Browsers can't include their own Javascript interpreters that are faster and fuller featured than Apple. (Same for HTML and XML or PDF). Heck, most file parsers should be outlawed under apple's rules, because like it or not, file/data descriptions are a primitive programming language -- that's not "originally" in C or ObjC. And so on.
Their browser interprets what language? HTML, XML, Javascript. What about PDF (that's a language too). .
Postscript is a language. PDF is just a document format, just like Word, Kindle format and mp3.
this to me is a bollocks, non issue, if it were pretty much anyone else other than apple no one would be on their case, because no one would care. If it had been apple circa 1999 no one would be on apple's back either, because no one would be threatened.
Now apple as much as sneezes and we have a ton of pundits commenting on it.
That is actually a good thing. It shows how well they have done and how relevant they are again. If Apple didn't evoke emotion they would not be as successful as they are and the membership at forums like this would pretty boring.
Having said that, there has always been healthy debate within the Apple user community. These days it seems the nouveau fans go a bit over the top in trying to show how loyal they can be...no disagreement or dissent is allowed.
To say "Flash Sucks" shows ignorant of software development. Flash is a tool. Do we argue "a screwdriver sucks? It does at pounding nails or cutting wood -- for driving screws, it isn't that bad. There are many Flash apps that are better than iFart, shaking babies, or jiggling booby apps that they
Unless it's a sucky screwdriver that slips out and gouges the wood and strips the screw head.
Actually, no, if Microsoft did this, everyone would be up in arms. The truth is that Microsoft could easily block iTunes by saying it uses non-standard APIs. But Microsoft doesn't do this, because they aren't that evil.
No, MS doesn't do it because they would be reopening a can of worms they are desperate to forget about.
I am not a programmer/developer; I am a business owner. Say I want to build an app to serve electrical engineers in my office. We have 60% Blackberries and 40% iPhones. Neither set of users has a compelling reason to change handsets. There may be a business case for doing something that supports everyone, but we aren't going to build our business around any single platform. (We too have learned from past mistakes.)
If it doesn't make sense for just us, how about something that serves our entire industry. There are about 50,000 licensed, practicing Professional Electrical Engineers in the US. Selling to 20% of them that may have iPhones and be interested would be an optimistic target: up to 10,000 unit sales!
The problem is that there just isn't a real incentive to drive these long-tail applications, and even less for internal application development if you aren't supporting 2-3 platforms with minimal incremental effort.
I also hear programmer issues related to short-cycle programming efforts. Apple is right on this, but they sure are wrong.