The fundamental shift in principals and morality is about who gets to control and exploit the work of an artist. The accepted norm for hudreds of years of western civilization is the artist exclusively has the right to exploit and control his/her work for a period of time. (Since the works that are are almost invariably the subject of these discussions are popular culture of one type or another, the duration of the copyright term is pretty much irrelevant for an ethical discussion.) By allowing the artist to treat his/her work as actual property, the artist can decide how to monetize his or her work.
You've just described how music makes YOU feel, but it's not YOUR music. If I create and own something, I'm allowed to decide how to distribute it. And yes, that means I'm allowed to sell it $9.99 album only with only one good track, even if that is stupid.
What you're saying is something like if I saw your car, and I felt it "triggered mystical experiences in the otherwise mundane", I should be allowed to break in and drive it around. And then put it back so everyone could else could use it (thus satisfying the non-exclusive nature of music.)
The law is also built to deal with this situation as well. Copyright eventually expires, and then the art comes into the public domain. I do have issues with companies trying to extend the amount of time work falls under copyright, but I feel the general spirit of the law is the right direction.
The article makes another interesting point. If I'm not allowed to have exclusive rights to decide how to distribute my work, I'm not as likely to create it in the first place. Traditionally, the physical nature of art made it hard to reproduce. In Beethoven's day, you couldn't record his symphony and then bootleg it. You couldn't photocopy the works of Charles Dickens. This provided more natural protection to revenue streams. It didn't make it impossible to copy works, but it sure wasn't easy to type set and reprint Oliver Twist.
But these days, if my creation can be copied instantly and easily, I'm likely not even to move past the creation stage. I'll just go get a job at McDonalds where I can earn more money flipping burgers. You can't really have your "transformative experiences" if the person who created them decided to hand out fries at a drive thru instead.
Well, nevermind, apparently I missed part of the summary. Looks like he found a way into the Ecuadorian embassy, so I guess the question is, how will he find his way out of the UK from there?
In theory, he doesn't have to. Why does he have to leave the Ecuadorian embassy?
Would they even need to sneak him out? I am not really sure how asylum works; if Ecuador says, "Yes, Assange has asylum here," would the UK government have to allow them to move Assange to an airplane and fly him out of the country?
Nope.
The Ecuadorians have diplomatic immunity, not Assange. Assange doesn't suddenly gain immunity by proxy.
(Google hired the WebOS team, so lets see what happens, Android design is all over the place right now)
They hired the Enyo team, not the WebOS team. Enyo is a web framework, and reports indicate those employees were put into the Chrome team, not the Android team.
Google did pick up a few WebOS employees, most notably WebOS's UI designer, but that happened well before even Android 3.0.
How so? This isn't preventing any software from running on PCs, if you actually read what's going on you'll see the only difference is MS is providing a key for their OS such that you can use the standard UEFI feature called SecureBoot if you want to.
Sure it is. The system will actively block you from running a non-MS signed OS unless you disable secure booting (which is on by default.)
How many users do you think are going to know how to disable secure booting? How many places can OEMs find to put that option?
I don't think the problem was Topolsky's line of thinking. It's that despite his motivations, he brought a knife to a gun fight. Despite being right, he still got his ass handed to him because Emanuel was so confident, to the lay person, he looks right.
Does it really matter why? The fact of the matter is that Macs ship with an open EFI and BIOS emulation, and can boot any operating system. That makes Macs a heck of a lot more open than PCs after this transition occurs.
Who puts the fire out if Facebook catches on fire?
Not Singapore, that's who. If he's doing business in Singapore, that's not the US's business. But if he's doing business in the US, he's earning profits under the US, not Singapore.
Not to mention he was definitely in the US when Facebook was starting up, which is where they took the most advantage of the government. The idea behind the government making things easier for startups is that when they start making piles of money, the government gets a cut. The government, by giving startups tax breaks, is basically acting the same as a ground floor private investor, both of whom would expect a payout for their investments.
It's not a matter of not giving investors incentives. It's a matter of giving them reasonable incentives, then them turning around, giving you the middle finger, and not paying their fair share after being giving major tax breaks and government protection.
Just because you're wealthy or a large corporation doesn't mean you get to skimp on your share of the check when it's your turn to pay up.
It's an upgrade if you owned any previous version of Mac OS on that machine.
If you have a Mac, Apple doesn't really need to check that, do they? Unless you'd like to point me to a Mac OS-less Mac Apple sells. In fact, that's their exact check. That you own a Mac and are therefore licensed for an existing version of Mac OS.
Wrong. Apple clearly sold both Snow Leopard in 2 forms. Full license ($129) and Upgrade from Leopard ($29).
Previous to that, Apple did sell full boxed licenses. There was no "upgrade license" versions for anything other than machines that shipped around the same time as the OS release.
No, that's wrong. Apple sold two licenses: 1) A license if you owned any previous version of Mac OS. 2) A license if you owned the preceding version of Mac OS X.
There is no "license if I never owned Mac OS on this machine." Apple doesn't sell any machines without Mac OS, so that wouldn't make very much sense, would it? That's why it mentions all of this in the legal agreements with Mac OS X, which everyone likes to hand wave and ignore, because hey, you're willing to be a lawyer when it comes to buying a "full" copy of OS X to be "legal", but at the same time totally willing to ignore the EULA and define "full" with your own definition.
Nope. If you're running a Mac, you're licensed for OS X, and you can just install whatever version you want.
But again, you have to have an existing Mac OS license. Mac branded hardware implies Mac OS license.
(The only thing that makes it more complicated is if you bought 10.7 through the app store. If so, you have to install 10.6 first in order to get app store access. Newer Macs can install 10.7 from web directly from the firmware though.)
Back in the day, Psystar was able to buy full copies in the store. That's changed in the last couple of years. Still, it's not hard to get a copy for your hackintosh.
They were never full copies. Again, Apple has never sold full copies in the store. They are all upgrade licenses from existing version of Mac OS.
I never saw what Psystar did that was actually wrong. They bought copies of software, installed them on machines, then sold those machines.
Apple doesn't sell fully licensed copies of OS X. They only sell upgrade copies. And the only way to get your initial copy of OS X is to buy a Mac. You can buy it in a box at the Apple store, it's still only an upgrade copy.
It would be like if a Windows OEM was buying upgrade only copies of Windows, hacking them onto blank machines, and then selling them.
People may not like it, but that's the way OS X is licensed.
...features that have been in every other operating system for years.
I can't believe people get excited for this. Now we have to deal with all the fanboys who every time they see these things in other operating systems are going to yell about people ripping off Microsoft.
AT&T has no LTE footprint at all here in Oregon. Yet Apple can still sell the iPad LTE here and call it that. Why? Because if/when AT&T finally brings LTE here, the device will work on it.
I get the whole "consumers walking out of the store thinking they have LTE service" thing. Seems like the simple solution is just to call it an "LTE Ready" device. You've got the LTE modem, and you're ready for the service.
It's an interesting post, but I don't know if it's a great rule of thumb.
I'd agree that using accessors and mutators may not be safe at init or dealloc time. And a property may be backed by an accessor/mutator instead of a synthesize (which, in response to the conversation above, is why synthesize exists in the first place.)
But, at the same time, there are certain risks to not using accessors/mutators. If you have to unsubscribe from notifications, or clear delegates, you might do that within a mutator. This would make the opposite true, it would be risky NOT to use the mutator.
Honestly, if you are writing custom mutators, you should be aware you could get nil as an input, and if you get nil as an input, don't go down the path of doing all your other lovely state mutating things because you have no input.
So part of me agrees with mmalc that you should not use accessor/mutator methods directly in dealloc. But I disagree that you should not use properties, even if they may abstract an accessor/mutator. Not to mention, I picked up that design pattern from people at Apple, so I know they're doing it too.:)
Technically these days you just need one thing, the @property. You don't need anything else. Hard to get less redundant than one definition.
On iOS, you never need the ivar that you put in, so that's needlessly redundant. That's user error, not a language issue. That reduces you to three required references at worst. The property, the synthesize, and the dealloc reference. New LLVM makes the synthesize go away, older LLVM with ARC killed the dealloc reference. So these days you're down to 1 line of code.
Under Obj-C 1.0 it would have been two, the ivar, and the dealloc.
Like I said, you don't seem to have a firm understanding, which is kind of dangerous when critique a language that you don't really know. I took two years of Spanish in high school, doesn't put me in a position to claim I understand Spanish and it's a horrible language.
Honestly, from your example code, it certainly looks like you've worked with Obj-C, but it doesn't look like you really had a strong understanding of it. Not that I don't blame you, with Obj-C 2.0 it became a little harder to understand, but Apple is cleaning that up.
LOL, you deduced that from a couple of lines of code hurriedly typed into a web form? Gimme a break. I could just as easily say something like, "based on your reply, it looks like you've worked with Obj-C, but not much else; you haven't been exposed to enough development to see the weaknesses in your language of choice or appreciate the value of the alternatives." (I'm not saying this is the case, but see how it comes across?)
Thanks for your reply though.
Well, you're critiquing the language, so yes, I'm assuming that you're actually writing out something well reasoned. I mean, we're talking about an example where you are pointing out Objective C's redundancy by writing out needlessly redundant code, so yes, I thought it was fair. Otherwise you're just trolling.
About half of these have been fixed (and were actually new problems that didn't exist in Objc-1.0). Obj-C 2.0 introduced some of the "don't repeat yourself" issues with things like properties and consistency issues between the new property syntax and the existing syntax, but with the new LLVM you can just declare properties and not have to synthesize. In addition, ARC takes care of the memory management code. New LLVM also has Obj-C constants which take care of things like your dictionary example. You haven't needed a backing ivar, so that NSString *title; line in the interface can go.
(Your code is also in bad form. You shouldn't do [title release]. It should be self.title=nil. Much cleaner, and you get the same thing without doing a roundabout around the property. You also clear the reference to reduce any chance of accidentally hitting a dealloc'd object.)
As far as complaining about method names... That seems like a personal taste thing... And honestly, it's considered good form to have long method names these days, because the method names themselves become the comments, and it makes extremely clear exactly what the method does. And autocomplete should keep you from having to type out the entire method. There's been a lot of coding standards material written on why this is a good thing. You may not like it, but it seems like a majority of people actually do, and if you're writing APIs or classes, people aren't going to like short method names very much. Writing long method and variable names that describe exactly what they do was one of the first pieces of advice I got in my programming career, and it's served me very well.
It's actually one of my biggest pet peeves when a C developer starts writing Obj-C stuff. They use these short, truncated method names for no apparent reason, when a longer name will reduce confusion when the code is shared. (And making your code reusable is one of the tenants of Obj-C for very good efficiency reasons.)
As far as XCode, yeah, it sucks. We all know it. But every IDE has it's quarks. Eclipse is slow and also somewhat unstable, and Visual Studio has it's own quarks. There has been a lot of pressure on Apple to make XCode better, and indeed each release seems to be more and more stable, with 4.0 being the low point.
Honestly, from your example code, it certainly looks like you've worked with Obj-C, but it doesn't look like you really had a strong understanding of it. Not that I don't blame you, with Obj-C 2.0 it became a little harder to understand, but Apple is cleaning that up.
Given that Java is one of the top languages, it's a valid point if we're talking about vendor lock in monkeying with the list. If it wasn't for Android, Java would be lower on the list.
If we're talking about C#, there are quite a few new APIs under Windows 7 that are C# only. Is that vendor lock in?
Every vendor has a favorite language, and every vendor builds their new runtimes around it. This hardly goes into vendor-lock in. If I want to use Windows Presentation Foundation, I have to use a managed language in the.Net runtime. I wouldn't be doing so because the.Net languages are necessarily better, but I would have to because of the dreaded "vendor lock in." Microsoft decided not to release an unmanaged version of WPF that I would use with straight C.
Is that a horrible evil thing? No. Microsoft clearly feels that.Net is their future, and they want to concentrate on that. My point is everyone does this, and if Objective-C was a crappy language, developers would have avoided it. Instead, they were chomping at the bit for Apple to release an Obj-C SDK for the iPhone.
And just like iOS, it's impossible to do an Android app without using Java. Sure, just like iOS, there are abstraction toolkits, support for C/C++, etc. But you can't do an Android app without Java.
Yet I didn't see any complaining about Google forcing "Java vendor lock in" in your posts, and complaining about that being unfair.
Before people start flaming me, please consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself.
Not only does Objective C have an extremely rich set of libraries from both Apple and the community (UIKit and Foundation are arguably the best mobile development APIs out there), but Objective C is compatible with all C and C++ libraries.
So I'm not exactly sure what the point is. I suppose if you have to use a C library one could say "Well see, you have to use C anyway!". But at least for me, the important part is while I'm using C, I'm still encapsulating that code in Obj-C.
Slashdot Mirror
I think Lowrey says it best here:
The fundamental shift in principals and morality is about who gets to control and exploit the work of an artist. The accepted norm for hudreds of years of western civilization is the artist exclusively has the right to exploit and control his/her work for a period of time. (Since the works that are are almost invariably the subject of these discussions are popular culture of one type or another, the duration of the copyright term is pretty much irrelevant for an ethical discussion.) By allowing the artist to treat his/her work as actual property, the artist can decide how to monetize his or her work.
You've just described how music makes YOU feel, but it's not YOUR music. If I create and own something, I'm allowed to decide how to distribute it. And yes, that means I'm allowed to sell it $9.99 album only with only one good track, even if that is stupid.
What you're saying is something like if I saw your car, and I felt it "triggered mystical experiences in the otherwise mundane", I should be allowed to break in and drive it around. And then put it back so everyone could else could use it (thus satisfying the non-exclusive nature of music.)
The law is also built to deal with this situation as well. Copyright eventually expires, and then the art comes into the public domain. I do have issues with companies trying to extend the amount of time work falls under copyright, but I feel the general spirit of the law is the right direction.
The article makes another interesting point. If I'm not allowed to have exclusive rights to decide how to distribute my work, I'm not as likely to create it in the first place. Traditionally, the physical nature of art made it hard to reproduce. In Beethoven's day, you couldn't record his symphony and then bootleg it. You couldn't photocopy the works of Charles Dickens. This provided more natural protection to revenue streams. It didn't make it impossible to copy works, but it sure wasn't easy to type set and reprint Oliver Twist.
But these days, if my creation can be copied instantly and easily, I'm likely not even to move past the creation stage. I'll just go get a job at McDonalds where I can earn more money flipping burgers. You can't really have your "transformative experiences" if the person who created them decided to hand out fries at a drive thru instead.
Well, nevermind, apparently I missed part of the summary. Looks like he found a way into the Ecuadorian embassy, so I guess the question is, how will he find his way out of the UK from there?
In theory, he doesn't have to. Why does he have to leave the Ecuadorian embassy?
Would they even need to sneak him out? I am not really sure how asylum works; if Ecuador says, "Yes, Assange has asylum here," would the UK government have to allow them to move Assange to an airplane and fly him out of the country?
Nope.
The Ecuadorians have diplomatic immunity, not Assange. Assange doesn't suddenly gain immunity by proxy.
(Google hired the WebOS team, so lets see what happens, Android design is all over the place right now)
They hired the Enyo team, not the WebOS team. Enyo is a web framework, and reports indicate those employees were put into the Chrome team, not the Android team.
Google did pick up a few WebOS employees, most notably WebOS's UI designer, but that happened well before even Android 3.0.
One episode down, 171 to go.
How so? This isn't preventing any software from running on PCs, if you actually read what's going on you'll see the only difference is MS is providing a key for their OS such that you can use the standard UEFI feature called SecureBoot if you want to.
Sure it is. The system will actively block you from running a non-MS signed OS unless you disable secure booting (which is on by default.)
How many users do you think are going to know how to disable secure booting? How many places can OEMs find to put that option?
I don't think the problem was Topolsky's line of thinking. It's that despite his motivations, he brought a knife to a gun fight. Despite being right, he still got his ass handed to him because Emanuel was so confident, to the lay person, he looks right.
Does it really matter why? The fact of the matter is that Macs ship with an open EFI and BIOS emulation, and can boot any operating system. That makes Macs a heck of a lot more open than PCs after this transition occurs.
The bad news is the NSA is likely the only group that has the technology to do this sort of monitoring, even for your home network.
The good news is that by simply mentioning a few select keywords on the internet, they will gladly do this monitoring for you for free.
Who puts the fire out if Facebook catches on fire?
Not Singapore, that's who. If he's doing business in Singapore, that's not the US's business. But if he's doing business in the US, he's earning profits under the US, not Singapore.
Not to mention he was definitely in the US when Facebook was starting up, which is where they took the most advantage of the government. The idea behind the government making things easier for startups is that when they start making piles of money, the government gets a cut. The government, by giving startups tax breaks, is basically acting the same as a ground floor private investor, both of whom would expect a payout for their investments.
It's not a matter of not giving investors incentives. It's a matter of giving them reasonable incentives, then them turning around, giving you the middle finger, and not paying their fair share after being giving major tax breaks and government protection.
Just because you're wealthy or a large corporation doesn't mean you get to skimp on your share of the check when it's your turn to pay up.
It's an upgrade if you owned any previous version of Mac OS on that machine.
If you have a Mac, Apple doesn't really need to check that, do they? Unless you'd like to point me to a Mac OS-less Mac Apple sells. In fact, that's their exact check. That you own a Mac and are therefore licensed for an existing version of Mac OS.
Wrong. Apple clearly sold both Snow Leopard in 2 forms. Full license ($129) and Upgrade from Leopard ($29).
Previous to that, Apple did sell full boxed licenses. There was no "upgrade license" versions for anything other than machines that shipped around the same time as the OS release.
No, that's wrong. Apple sold two licenses:
1) A license if you owned any previous version of Mac OS.
2) A license if you owned the preceding version of Mac OS X.
There is no "license if I never owned Mac OS on this machine." Apple doesn't sell any machines without Mac OS, so that wouldn't make very much sense, would it? That's why it mentions all of this in the legal agreements with Mac OS X, which everyone likes to hand wave and ignore, because hey, you're willing to be a lawyer when it comes to buying a "full" copy of OS X to be "legal", but at the same time totally willing to ignore the EULA and define "full" with your own definition.
Nope. If you're running a Mac, you're licensed for OS X, and you can just install whatever version you want.
But again, you have to have an existing Mac OS license. Mac branded hardware implies Mac OS license.
(The only thing that makes it more complicated is if you bought 10.7 through the app store. If so, you have to install 10.6 first in order to get app store access. Newer Macs can install 10.7 from web directly from the firmware though.)
Back in the day, Psystar was able to buy full copies in the store. That's changed in the last couple of years. Still, it's not hard to get a copy for your hackintosh.
They were never full copies. Again, Apple has never sold full copies in the store. They are all upgrade licenses from existing version of Mac OS.
I never saw what Psystar did that was actually wrong. They bought copies of software, installed them on machines, then sold those machines.
Apple doesn't sell fully licensed copies of OS X. They only sell upgrade copies. And the only way to get your initial copy of OS X is to buy a Mac. You can buy it in a box at the Apple store, it's still only an upgrade copy.
It would be like if a Windows OEM was buying upgrade only copies of Windows, hacking them onto blank machines, and then selling them.
People may not like it, but that's the way OS X is licensed.
...features that have been in every other operating system for years.
I can't believe people get excited for this. Now we have to deal with all the fanboys who every time they see these things in other operating systems are going to yell about people ripping off Microsoft.
AT&T has no LTE footprint at all here in Oregon. Yet Apple can still sell the iPad LTE here and call it that. Why? Because if/when AT&T finally brings LTE here, the device will work on it.
I get the whole "consumers walking out of the store thinking they have LTE service" thing. Seems like the simple solution is just to call it an "LTE Ready" device. You've got the LTE modem, and you're ready for the service.
It's an interesting post, but I don't know if it's a great rule of thumb.
I'd agree that using accessors and mutators may not be safe at init or dealloc time. And a property may be backed by an accessor/mutator instead of a synthesize (which, in response to the conversation above, is why synthesize exists in the first place.)
But, at the same time, there are certain risks to not using accessors/mutators. If you have to unsubscribe from notifications, or clear delegates, you might do that within a mutator. This would make the opposite true, it would be risky NOT to use the mutator.
Honestly, if you are writing custom mutators, you should be aware you could get nil as an input, and if you get nil as an input, don't go down the path of doing all your other lovely state mutating things because you have no input.
So part of me agrees with mmalc that you should not use accessor/mutator methods directly in dealloc. But I disagree that you should not use properties, even if they may abstract an accessor/mutator. Not to mention, I picked up that design pattern from people at Apple, so I know they're doing it too. :)
Technically these days you just need one thing, the @property. You don't need anything else. Hard to get less redundant than one definition.
On iOS, you never need the ivar that you put in, so that's needlessly redundant. That's user error, not a language issue. That reduces you to three required references at worst. The property, the synthesize, and the dealloc reference. New LLVM makes the synthesize go away, older LLVM with ARC killed the dealloc reference. So these days you're down to 1 line of code.
Under Obj-C 1.0 it would have been two, the ivar, and the dealloc.
Like I said, you don't seem to have a firm understanding, which is kind of dangerous when critique a language that you don't really know. I took two years of Spanish in high school, doesn't put me in a position to claim I understand Spanish and it's a horrible language.
Honestly, from your example code, it certainly looks like you've worked with Obj-C, but it doesn't look like you really had a strong understanding of it. Not that I don't blame you, with Obj-C 2.0 it became a little harder to understand, but Apple is cleaning that up.
LOL, you deduced that from a couple of lines of code hurriedly typed into a web form? Gimme a break. I could just as easily say something like, "based on your reply, it looks like you've worked with Obj-C, but not much else; you haven't been exposed to enough development to see the weaknesses in your language of choice or appreciate the value of the alternatives." (I'm not saying this is the case, but see how it comes across?)
Thanks for your reply though.
Well, you're critiquing the language, so yes, I'm assuming that you're actually writing out something well reasoned. I mean, we're talking about an example where you are pointing out Objective C's redundancy by writing out needlessly redundant code, so yes, I thought it was fair. Otherwise you're just trolling.
About half of these have been fixed (and were actually new problems that didn't exist in Objc-1.0). Obj-C 2.0 introduced some of the "don't repeat yourself" issues with things like properties and consistency issues between the new property syntax and the existing syntax, but with the new LLVM you can just declare properties and not have to synthesize. In addition, ARC takes care of the memory management code. New LLVM also has Obj-C constants which take care of things like your dictionary example. You haven't needed a backing ivar, so that NSString *title; line in the interface can go.
(Your code is also in bad form. You shouldn't do [title release]. It should be self.title=nil. Much cleaner, and you get the same thing without doing a roundabout around the property. You also clear the reference to reduce any chance of accidentally hitting a dealloc'd object.)
As far as complaining about method names... That seems like a personal taste thing... And honestly, it's considered good form to have long method names these days, because the method names themselves become the comments, and it makes extremely clear exactly what the method does. And autocomplete should keep you from having to type out the entire method. There's been a lot of coding standards material written on why this is a good thing. You may not like it, but it seems like a majority of people actually do, and if you're writing APIs or classes, people aren't going to like short method names very much. Writing long method and variable names that describe exactly what they do was one of the first pieces of advice I got in my programming career, and it's served me very well.
It's actually one of my biggest pet peeves when a C developer starts writing Obj-C stuff. They use these short, truncated method names for no apparent reason, when a longer name will reduce confusion when the code is shared. (And making your code reusable is one of the tenants of Obj-C for very good efficiency reasons.)
As far as XCode, yeah, it sucks. We all know it. But every IDE has it's quarks. Eclipse is slow and also somewhat unstable, and Visual Studio has it's own quarks. There has been a lot of pressure on Apple to make XCode better, and indeed each release seems to be more and more stable, with 4.0 being the low point.
Honestly, from your example code, it certainly looks like you've worked with Obj-C, but it doesn't look like you really had a strong understanding of it. Not that I don't blame you, with Obj-C 2.0 it became a little harder to understand, but Apple is cleaning that up.
Given that Java is one of the top languages, it's a valid point if we're talking about vendor lock in monkeying with the list. If it wasn't for Android, Java would be lower on the list.
If we're talking about C#, there are quite a few new APIs under Windows 7 that are C# only. Is that vendor lock in?
Every vendor has a favorite language, and every vendor builds their new runtimes around it. This hardly goes into vendor-lock in. If I want to use Windows Presentation Foundation, I have to use a managed language in the .Net runtime. I wouldn't be doing so because the .Net languages are necessarily better, but I would have to because of the dreaded "vendor lock in." Microsoft decided not to release an unmanaged version of WPF that I would use with straight C.
Is that a horrible evil thing? No. Microsoft clearly feels that .Net is their future, and they want to concentrate on that. My point is everyone does this, and if Objective-C was a crappy language, developers would have avoided it. Instead, they were chomping at the bit for Apple to release an Obj-C SDK for the iPhone.
And just like iOS, it's impossible to do an Android app without using Java. Sure, just like iOS, there are abstraction toolkits, support for C/C++, etc. But you can't do an Android app without Java.
Yet I didn't see any complaining about Google forcing "Java vendor lock in" in your posts, and complaining about that being unfair.
Before people start flaming me, please consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself.
Not only does Objective C have an extremely rich set of libraries from both Apple and the community (UIKit and Foundation are arguably the best mobile development APIs out there), but Objective C is compatible with all C and C++ libraries.
So I'm not exactly sure what the point is. I suppose if you have to use a C library one could say "Well see, you have to use C anyway!". But at least for me, the important part is while I'm using C, I'm still encapsulating that code in Obj-C.