18.47
ipod touch review
John Gruber says pretty much all that needs to be said on this. Not a sign that things are heading in the right direction, I"m afraid.
Ipod Touch Review
# # 8 GB capacity for about 2,000 songs, 10,000 photos, or 10 hours of video # Up to 40 hours of audio playback or 7 hours of video playback on a single charge # Support for AAC, Protected AAC (iTunes Store) and other audio formats; H.264, MPEG-4,
Ipod Touch Review
# One-year limited warranty # iPod touch has 8 GB capacity for about 2,000 songs, 10,000 photos, or 10 hours of video. # iPod touch has a 3.5-inch (diagonal) widescreen Multi-Touch display with 960-by-640-pixel resolution (326 pixels per inch). › See more technical details.
Ipod Touch Review
# iPod touch has one-year limited warranty. # IPod touch plays up to 40 hours of audio playback or 7 hours of video playback on a single charge. # Motion JPEG video codecs in M4V, MP4, MOV, and AVI formats
Tampilkan postingan dengan label Stupidity. Tampilkan semua postingan
Tampilkan postingan dengan label Stupidity. Tampilkan semua postingan
Selasa, 04 Agustus 2009
Minggu, 02 Agustus 2009
This Concerns Me Greatly
Yes, I'm a little behind. I've been gone for a week, so this is probably not news to any of you, but this really upsets me, so I'm writing about it. I try to give Apple the benefit of the doubt when they make decisions that seem unfair or arbitrary, fully cognizant of the fact that I'm not privy to all the factors that went into the decision.
But, this... Well..., if this is true, it would seem to indicate that maybe I've been wrong in giving Apple the benefit of the doubt. That maybe those who have let out a hue and cry over every little Apple decision they didn't like had a more accurate picture of the situation.
If it's true that Apple won't even give more than a boilerplate reason for pulling an application that had been on the App Store for four months and won't tell the developers what the specific conflicts are so they can fix them, then I think there is more than a little cause for concern. Especially troubling is that now RiverTurn, since they are unable to support or update their app thanks to Apple's decision to pull their application, would like to give refunds, but will have to pay not just their share of the income, but Apple's as well, even though they are only trying to do what's right after Apple put them in a tough situation. This means they not only lose whatever income they might have made in the last four months, but they also have pay out additional money on top of what they invested to develop and market their application.
The FCC has decided to investigate the situation. I'll be interested to see if anything comes of it. I don't have much faith in the FCC, that's for sure, but maybe they can do something good for a change.
Lately I've been bashing Microsoft a lot for making poor decisions and failing to recognize the reality of their situation. In most respects, Apple has been on a roll, making good decisions and making elegant products that people are clamoring to buy even in a poor economy. But, Apple has to realize that a large part of the success of the iPhone has been the App Store. Given that they've based much of their advertising around that single point, it's clear that they do recognize it.
From the start, third party developers have had to live with an arbitrary review process that potentially meant they could spend lots of time and money and end up completely unable to sell their application for failing to comply with some unwritten rule. That was bad enough, and certainly has had a chilling effect on third party application development. The App Store was so hot, though, that most developers accepted the risk, figuring the potential reward outweighed the risk.
This decision by Apple adds a new aspect that is almost certain to drive away some of the most innovative developers. Not only do we have to worry about whether our apps will be approved by the somewhat arbitrary review process, but now we have to worry about having their approved applications removed.
I don't have enough evidence to be able to say I know for sure why Apple did this or why they handled it in this way, but if they don't take steps to fix this and to communicate that they're aware of the problem, it will leave a black stain on their reputation in the eyes of even the most ardent fanboys.
It really concerns me and I hope Apple fixes it, quickly. Apple should, at very least, pay their own share of the refunds. If the people making the decisions have a soul, though, they should offer to pay the full amount of the refund and probably do even more. Riverturn expended time and resources to create a program that any reasonable person would believe complied with the App Store policies and SDK agreement. There are several other apps on the store that haven't been pulled that allow voice communications over wi-fi, including the iPhone Skype App. Heck, Apple's own reviewers must have felt the same way, since they approved the application and it was on sale for four months before somebody said "hey, let's pull this".
Apple, please make this situation right and then fix whatever internal policies allowed it such an injustice to happen.
But, this... Well..., if this is true, it would seem to indicate that maybe I've been wrong in giving Apple the benefit of the doubt. That maybe those who have let out a hue and cry over every little Apple decision they didn't like had a more accurate picture of the situation.
If it's true that Apple won't even give more than a boilerplate reason for pulling an application that had been on the App Store for four months and won't tell the developers what the specific conflicts are so they can fix them, then I think there is more than a little cause for concern. Especially troubling is that now RiverTurn, since they are unable to support or update their app thanks to Apple's decision to pull their application, would like to give refunds, but will have to pay not just their share of the income, but Apple's as well, even though they are only trying to do what's right after Apple put them in a tough situation. This means they not only lose whatever income they might have made in the last four months, but they also have pay out additional money on top of what they invested to develop and market their application.
The FCC has decided to investigate the situation. I'll be interested to see if anything comes of it. I don't have much faith in the FCC, that's for sure, but maybe they can do something good for a change.
Lately I've been bashing Microsoft a lot for making poor decisions and failing to recognize the reality of their situation. In most respects, Apple has been on a roll, making good decisions and making elegant products that people are clamoring to buy even in a poor economy. But, Apple has to realize that a large part of the success of the iPhone has been the App Store. Given that they've based much of their advertising around that single point, it's clear that they do recognize it.
From the start, third party developers have had to live with an arbitrary review process that potentially meant they could spend lots of time and money and end up completely unable to sell their application for failing to comply with some unwritten rule. That was bad enough, and certainly has had a chilling effect on third party application development. The App Store was so hot, though, that most developers accepted the risk, figuring the potential reward outweighed the risk.
This decision by Apple adds a new aspect that is almost certain to drive away some of the most innovative developers. Not only do we have to worry about whether our apps will be approved by the somewhat arbitrary review process, but now we have to worry about having their approved applications removed.
I don't have enough evidence to be able to say I know for sure why Apple did this or why they handled it in this way, but if they don't take steps to fix this and to communicate that they're aware of the problem, it will leave a black stain on their reputation in the eyes of even the most ardent fanboys.
It really concerns me and I hope Apple fixes it, quickly. Apple should, at very least, pay their own share of the refunds. If the people making the decisions have a soul, though, they should offer to pay the full amount of the refund and probably do even more. Riverturn expended time and resources to create a program that any reasonable person would believe complied with the App Store policies and SDK agreement. There are several other apps on the store that haven't been pulled that allow voice communications over wi-fi, including the iPhone Skype App. Heck, Apple's own reviewers must have felt the same way, since they approved the application and it was on sale for four months before somebody said "hey, let's pull this".
Apple, please make this situation right and then fix whatever internal policies allowed it such an injustice to happen.
Rabu, 15 Juli 2009
Gah! Up is Down! Right is Wrong! Make it Stop!
Today, some programmer named Zed Shaw wrote a blog post titled Is BSD The [sic] New GPL?. The crux of his article is that because a few people have, dog forbid, proselytized for the BSD license and tried to get some other projects that are currently using the restrictive GPL license to switch to the BSD license because the viral GPL license prevents code from flowing equally in both directions between the projects that, therefore, the BSD license is now just as bad as the GPL.
What... the... Fuck?
Because a few people suggested that, hey, maybe you guys would consider dropping some of those restrictions on your code so we can all, like, share equally, Zed Fucking Shaw thinks that's exactly the same as a viral license that puts restrictions, in perpetuity, on the code you write as well as on all derivative products, and any code that happened to have been stored on the same hard drive as your product for a little while1. I'd expect anti-logic like this from a marketing executive, lawyer, or clergyman, but not from a programmer. This is a pathetic excuse for logic. It's Orwellian logic. Right is wrong. Up is down. It's not missing the point, it's closing your eyes and screaming "nah-nah-nah" so you can claim you're unaware of the fucking point.
Now, I'm a big fan of openness. Almost every line of code that I've ever written that wasn't written specifically for a client or employer has been released in some form, either under a liberal license like the BSD or MIT license or simply given out as public domain code2. But I have not used and will not use the GPL. In fact, when people ask me if they can include code I've written in a GPL'd project (which they don't have to do, so I do appreciate the gesture) I always grant permission, but specifically request that they document the fact that my code is not covered by the project license.
I'm not a fan of the GPL quite simply because I don't see the GPL as "open". The GPL is not defined by what it is, it's defined by what it isn't. It's "against" proprietary closed source code. It's against corporations. It's against software as a commercial product. It's all about what it's not. It's a political movement replete with a manifesto. No joke. A fucking manifesto. The GPL is about openness in the same way that Stalin was about peace and kindness. And you know what? I don't want my code tied up in a political movement. If I want to share, I'll happily share with no expectation of a direct return. If I don't want to (or can't) share, I won't publish my code.
Sir Isaac Newton uttered a very famous line long ago in what is one of the greatest displays of modesty ever recorded. He said, "If I have seen further it is only by standing on the shoulders of giants." And that modest statement sums up the way science, and all meaningful pursuit of knowledge works. Knowledge is expanded when it is shared. When solutions to problems are shared, that frees us up to tackle the next obstacle rather than spending time solving problems that have already been solved by others. Which, if you read their propaganda, is exactly what the GNU foundation people think they believe. But anyone who has actually read their license terms knows that obviously they don't, because you can't reconcile that with the viral restrictions in their licenses. If you truly believe that knowledge is not a zero-sum game, and that sharing knowledge tends to increase the sum of societal knowledge, then you don't go putting petty restrictions on your knowledge.
Sometimes, when you fight fire with fire, all you get is a bigger fire and you certainly don't put out a fire by loudly exclaiming that water is the new fire.
Footnotes
1 - Okay, I'm kidding about the last one.
2 - Well, that's not completely true. I also don't release code that I know is bad because I don't want people copying or learning from code I know has serious problems.
What... the... Fuck?
Because a few people suggested that, hey, maybe you guys would consider dropping some of those restrictions on your code so we can all, like, share equally, Zed Fucking Shaw thinks that's exactly the same as a viral license that puts restrictions, in perpetuity, on the code you write as well as on all derivative products, and any code that happened to have been stored on the same hard drive as your product for a little while1. I'd expect anti-logic like this from a marketing executive, lawyer, or clergyman, but not from a programmer. This is a pathetic excuse for logic. It's Orwellian logic. Right is wrong. Up is down. It's not missing the point, it's closing your eyes and screaming "nah-nah-nah" so you can claim you're unaware of the fucking point.
Now, I'm a big fan of openness. Almost every line of code that I've ever written that wasn't written specifically for a client or employer has been released in some form, either under a liberal license like the BSD or MIT license or simply given out as public domain code2. But I have not used and will not use the GPL. In fact, when people ask me if they can include code I've written in a GPL'd project (which they don't have to do, so I do appreciate the gesture) I always grant permission, but specifically request that they document the fact that my code is not covered by the project license.
I'm not a fan of the GPL quite simply because I don't see the GPL as "open". The GPL is not defined by what it is, it's defined by what it isn't. It's "against" proprietary closed source code. It's against corporations. It's against software as a commercial product. It's all about what it's not. It's a political movement replete with a manifesto. No joke. A fucking manifesto. The GPL is about openness in the same way that Stalin was about peace and kindness. And you know what? I don't want my code tied up in a political movement. If I want to share, I'll happily share with no expectation of a direct return. If I don't want to (or can't) share, I won't publish my code.
Sir Isaac Newton uttered a very famous line long ago in what is one of the greatest displays of modesty ever recorded. He said, "If I have seen further it is only by standing on the shoulders of giants." And that modest statement sums up the way science, and all meaningful pursuit of knowledge works. Knowledge is expanded when it is shared. When solutions to problems are shared, that frees us up to tackle the next obstacle rather than spending time solving problems that have already been solved by others. Which, if you read their propaganda, is exactly what the GNU foundation people think they believe. But anyone who has actually read their license terms knows that obviously they don't, because you can't reconcile that with the viral restrictions in their licenses. If you truly believe that knowledge is not a zero-sum game, and that sharing knowledge tends to increase the sum of societal knowledge, then you don't go putting petty restrictions on your knowledge.
Sometimes, when you fight fire with fire, all you get is a bigger fire and you certainly don't put out a fire by loudly exclaiming that water is the new fire.
Footnotes
1 - Okay, I'm kidding about the last one.
2 - Well, that's not completely true. I also don't release code that I know is bad because I don't want people copying or learning from code I know has serious problems.
Selasa, 07 Juli 2009
Oh, Good, Here Comes the Justice Department
They did such a bang-up job with the Microsoft situation, I'm so glad to see that the Department of Justice is on the case! Now, if you read any of yesterday's grumpy rants, you know I'm not exactly a big fan of AT&T or of the ability of Federal agencies to improve, well, anything. Truth be told, I would LOVE to see the iPhone freed from AT&T.
But… this is just stupid. Check this quote out:
They specifically call out the iPhone. Wow.
Yes, the iPhone is awesome. Yes, it's a competitive advantage. I mean, duh! Of course it makes it harder for smaller competitors to compete. That's the whole damn point! Have we forgotten what a monopoly even is? It's hard to imagine how it could be illegal to enter into a two- or five- year exclusive agreement with the manufacturer of a phone that accounts for 1.1% of the mobile phone market.
1.1%?
Playing Monopoly by the Department of Justices rules would be no fun, because you'd only need one property before you have monopoly. To heck with requiring players to have 100% of the properties with the same color. If you've got more than 0% of one color, you're good to go. Monopoly, baby. Start building houses! One house is at least 33.33% of a color, so you obviously have a monopoly there!
God, this would be such a waste of taxpayer money. It's is a sad attempt by the Executive branch to appear responsive to negative public sentiment about wireless carriers without any real legal basis and without any intent to actually fix or even really change anything (how'd that split-up of Microsoft work out?). This is using a duct-tape as a band-aid and sticking it nowhere near an actual wound.
But… this is just stupid. Check this quote out:
Among the areas the Justice Department could explore is whether wireless carriers are hurting smaller competitors by locking up popular phones through exclusive agreements with handset makers, according to the people.
They specifically call out the iPhone. Wow.
Yes, the iPhone is awesome. Yes, it's a competitive advantage. I mean, duh! Of course it makes it harder for smaller competitors to compete. That's the whole damn point! Have we forgotten what a monopoly even is? It's hard to imagine how it could be illegal to enter into a two- or five- year exclusive agreement with the manufacturer of a phone that accounts for 1.1% of the mobile phone market.
1.1%?
Playing Monopoly by the Department of Justices rules would be no fun, because you'd only need one property before you have monopoly. To heck with requiring players to have 100% of the properties with the same color. If you've got more than 0% of one color, you're good to go. Monopoly, baby. Start building houses! One house is at least 33.33% of a color, so you obviously have a monopoly there!
God, this would be such a waste of taxpayer money. It's is a sad attempt by the Executive branch to appear responsive to negative public sentiment about wireless carriers without any real legal basis and without any intent to actually fix or even really change anything (how'd that split-up of Microsoft work out?). This is using a duct-tape as a band-aid and sticking it nowhere near an actual wound.
Jumat, 03 Juli 2009
An Exercise in Blatant Bias
I came across an interesting blog post today that purports to be a comparison of Android and iPhone development. And it is a comparison. While the author makes absolutely no claim that he is unbiased, a more fitting and less misleading title would have been A Comparison of iPhone and Android Development by Somebody Who Really, Really, Really, Really Loves Java and Doesn't Want To Be Bothered Actually Learning How to Use the Language and Tools Used in iPhone Development. Okay, I admit that that would be kind of an unwieldy title, but I can imagine a lot of people coming to this blog entry and getting a skewed view of things, so I want to provide a counter-opinion. I don't want to get into a pissing match, but some of the accusations in this posting are indefensibly wrong and tell us more about the author than the things he is comparing.
Let me put up front that I know some people will interpret my response as an attempt to say that Xcode is "better" than other IDEs. That's absolutely not what I'm trying to say. "Better" is a subjective matter. My goal is simply to counter the notion put forward in this blog post that Xcode is "shockingly bad" or that Xcode "takes away from the flow of a developer". It does take away from the flow of a developer who insists on trying to use it as if it was Eclipse or Visual Studio, but that's a flaw in the developer, not the in IDE.
But just like the original posting, this is a biased post based on my own tastes and likes, but unlike the original author, I actually have a comparable amount of experience with both of the things I'm comparing.
I think it was Jeff Atwood who said "the only intuitive interface is the nipple", and that couldn't be more true. Everything we're used to doing in computer programs - the entire paradigm is learned. That's completely true for IDEs and programming languages as well. We learn to use them, and many of us coders spend so much time in our IDE that they become second nature for us to the point where we see the way we work as natural.
One of the most common complaints I see from new iPhone and Mac developers , especially those coming from Visual Studio or Eclipse (like the author of the post linked above), is that they hate Xcode because it's missing this or that feature or it "feels dated". Only the most obstinate and stuck-in-their-ways developers continue to make those claims after working with it full-time for a year or more, however, because the problem isn't with Xcode, the problem is they were trying to do things in Xcode the way they were used to doing them in some other IDE. They were trying to bring to bear all their learned knowledge about how to program in Java or C# or Visual Basic in another IDE with different conventions than are used in coding Objective-C using Xcode.
Now, I'm not trying to say that Xcode is perfect. No IDE is perfect, and they are constantly borrowing ideas from each other. One of Xcode's virtues, in my mind, is that they haven't adopted the kitchen sink approach of trying to implement any feature that anybody thinks up. They've historically had relatively a small, focused user base, and the Xcode team has created a scalpel, not a chainsaw. Xcode is written by some really smart engineers who have to use it every day for writing C, Objective-C, and C++. They aren't using it to write VB or C# and only rarely to write Java. They have different needs and different priorities than the Eclipse team or the Visual Studio team. But to claim that Xcode is "lacking" or "bad" does those developers a grave disservice. It does not try to be everything to everyone, that is true, but it is nonetheless a great IDE for the types of development that its user base does on a daily basis.
Here's the thing. If you are constantly missing some feature from Eclipse of Visual Studio, there's a really, really good chance you are working against the grain, trying to do something based on things you think you know from another language or application framework, or that you simply haven't discovered some piece of functionality in Xcode.
David Green, the author of this blog post, make the claim that Xcode (which he has been working with for "a few months") impedes developer productivity and that it is therefore "inferior" to Eclipse, a program he's worked with day-in and day-out for twelve years. Yes, that sounds like a fair basis for comparison. "This thing I just started using isn't anywhere near as good as this thing I've been using for years and know inside and out."
You can get some insight into the thought process behind this claim from this quote:
Now let me put out there that I have worked with Java since about 1997, which would be, what, say... twelve years? It was my bread and butter for close to ten of those years. I've also got about ten years experience with Cocoa, Objective-C and Xcode(if you include its predecessor Project Builder). So, I have some basis for comparison and let me state that my opinion of the languages and the IDE is almost exactly the opposite of Mr. Green's when it comes to mobile development of GUI applications.
For starters, Java is absolutely not a no-brainer. In fact, Java is a really, really poor choice for embedded development. Oh, I know Java has been pushed as a great choice for embedded devices for years, but it's just not.
Mobile devices are constrained resource devices. The overhead for Java runtime's memory and processor overhead is non-trivial on such a device. And "existing skillsets" may not come easy, but reuse of expertise is no good if the cost for doing so is to make poor choices. You've certainly heard the cliché "if your only tool is a hammer, every problem looks like a nail"? Well, re-read the quote above and tell me that it's not simply a restatement of that cliché as an axiom. He's stating "Java is better because I know it better", nothing more. I know both languages, and Java is a better choice for many tasks, but there's really no way you can claim that it's better for writing a GUI application on an embedded device. Or, for that matter, for writing any GUI application period.
On the other hand, Objective-C is a great choice for writing GUI applications for an embedded device. It has a runtime that provides a lot of dynamic functionality with considerably less overhead. Objective-C has far better introspection than Java and greater flexibility in terms of passing objects of different types through a responder chain without filling up your code with typecasts or constant use of godawful generics (a much-lauded hack to get around a fundamental flaw with strongly-typed static languages like Java when it comes to designing GUI applications).
Some other gems from this blog post:
I honestly had the opposite complaint about Java. I hated that there was only a single file per class. I hated that Java deprived me of the ability to do lots of cool things by separating out the implementation from what is advertised to other classes. I hated, for example, having to use static final variables and hated having to incur the overhead of a method call for tiny bits of functionality that could have been expressed in a precompiler macro or static inline function in another language. That's not to say that Java's approach is bad, just to say that just because it was thought of later doesn't make it inherently better. Its saves a little typing and a small amount of project clutter, but it comes at a price. Personally, I prefer having more flexibility and a few more files in my project.
Split header and implementation files provide extra functionality and the cost is relatively trivial. Navigating between header and implementation files can be accomplished with a configurable key binding. I switch back and forth regularly between header and implementation files. The key command becomes second nature after a little while and it becomes completely a non-issue. I can't even see how this would be an issue worth mentioning if you had spent a few minutes reading about Xcode's key bindings.
ZOMG! I have to release memory! And type in more than one place! Run for the hills!
For the record, I can implement a single property in about 20 seconds using Xcode codesense and key bindings to navigate between the header and implementation files. For those who don't type as fast, check out the excellent Accessorizer. Personally, I can't create Java getters and setters in Java using Eclipse noticeably faster.
Another thing to realize is that Objective-C has a garbage collector, and it's quite a good one at this point, but Apple has intentionally chosen not to support it on the iPhone. This isn't about a shortcoming in the language, it's about a conscious decision made to provide a better user experience. Forcing developers to take responsibility for memory means that well-written applications will be more efficient and use less memory. Sure, there's a risk of memory leaks, but there are ways to track those down, and garbage collection comes with a price. On a device like a mobile phone, that is a non-trivial price even if the garbage collector is pristine and doesn't have any memory leaks itself.
Gosh, it's too bad we don't have anything like that in Xcode. It'd be nice if we had maybe a Design menu, or maybe some text macros for Objective-C. Or at very least, an extensible scripting architecture with provided scripts to help us write our accessors and mutators. It would be even better if we had a persistence framework that completely obviated the need for data model classes at all.
And for those who didn't catch on to my sarcasm in that last paragraph, we do have all of those with Xcode. There is a design menu with tools that help you design data model classes. Under the edit menu, there is menu item called "Insert Text Macro", with several common macros for all the languages Xcode supports, and there's also an Applescript menu with such gems as "Place Accessor Defs on Clipboard".
But, in the vast majority of situations, you don't need to actually write your setters and getters. I don't care if your IDE creates them for you, 95% of the time, those are still code clutter. I'd much rather have a property with a synthesize statement and possibly a release call than tons of cruft in my code.
We also have Core Data, which lets you design data model classes visually without ever creating an Objective-C class. Or you can create a custom subclass, but you only need to put in your custom functionality - no setters or getters unless they do something non-standard.
Let me translate this: "Objective-C annoys me because it doesn't use the same patterns that Java uses and it is therefore bad". Implementing correct init and dealloc methods is non-trivial? How in the world could you possibly say that? If you understand the memory management contract (a whopping four whole rules), it's both trivial and intuitive. It only seems confusing if you haven't bothered to learn one of the fundamental aspects of the language you're using, and if you haven't, well, that's really not Xcode's fault, it's yours.
What he calls a "pain", I call "more flexible". Forward declarations and header imports are more powerful and flexible than java's import mechanism, and if you understand what they are doing, they're really not difficult or time consuming.
Another translation: I kept looking for functionality as if I was working in Java and didn't find things where I expected them. Personally, I find Xcode's documentation browser (especially the new one coming in Xcode 3.2 under Snow Leopard) to be more intuitive and feel like it's designed perfectly for the needs of a knowledgeable Cocoa Touch programmer. It's not surprising that it's not designed to meet the expectations of a programmer learned from using another language, other frameworks, and a different IDE.
And here are some more complaints about the "shockingly bad" Xcode:
Good point. It's just too bad there's no preference for changing to a single-window, or limited-window layout, huh? Oh, wait… there is, isn't there?
Oh, god, no. Please no. You're trying to use the project tree to do the detail panel's job. Just click the node of the tree you want, then in the detail panel, sort the part of the tree you've selected however you want, alphabetically, by code size, whatever. This gives you all the power of Eclipse's horrible project tree, but let's you only work with the section of the hierarchy you are currently interested in. Believe me, this is not a shortcoming in Xcode, this is a shortcoming in the way you're working.
Oh no - he had to read the documentation! No developer should ever have to do that. Anyone who damns Interface Builder with faint praise like this doesn't fully understand it and thinks it's just a form builder like they've used in Eclipse or VS.
Okay, I'm done. Now I'm being a little rough on the guy. He's giving an honest opinion thinking he's helping others, and that should be lauded. The problem is he's making claims that are not just a little biased, they're outright unsupportable. Calling Xcode "shockingly bad" because you haven't taken the time to learn how it works is just ignorant.
Okay, maybe a few more quotes, because there are so many good ones.
The iPhone "will remain a market leader" until "18 new Android handsets" are released? Did you seriously write that with a straight face? You honestly think it's the number of handsets that is holding Android back? Seriously?
But at least he finished off with a great quote:
And the answer is, actually, yes. But who in their right mind would want to? Linux zealotry notwithstanding, the Mach kernel is better, and truth be told, most people - even most developers - don't want to waste time having to compile and install new kernels anyway.
Let me put up front that I know some people will interpret my response as an attempt to say that Xcode is "better" than other IDEs. That's absolutely not what I'm trying to say. "Better" is a subjective matter. My goal is simply to counter the notion put forward in this blog post that Xcode is "shockingly bad" or that Xcode "takes away from the flow of a developer". It does take away from the flow of a developer who insists on trying to use it as if it was Eclipse or Visual Studio, but that's a flaw in the developer, not the in IDE.
But just like the original posting, this is a biased post based on my own tastes and likes, but unlike the original author, I actually have a comparable amount of experience with both of the things I'm comparing.
I think it was Jeff Atwood who said "the only intuitive interface is the nipple", and that couldn't be more true. Everything we're used to doing in computer programs - the entire paradigm is learned. That's completely true for IDEs and programming languages as well. We learn to use them, and many of us coders spend so much time in our IDE that they become second nature for us to the point where we see the way we work as natural.
One of the most common complaints I see from new iPhone and Mac developers , especially those coming from Visual Studio or Eclipse (like the author of the post linked above), is that they hate Xcode because it's missing this or that feature or it "feels dated". Only the most obstinate and stuck-in-their-ways developers continue to make those claims after working with it full-time for a year or more, however, because the problem isn't with Xcode, the problem is they were trying to do things in Xcode the way they were used to doing them in some other IDE. They were trying to bring to bear all their learned knowledge about how to program in Java or C# or Visual Basic in another IDE with different conventions than are used in coding Objective-C using Xcode.
Now, I'm not trying to say that Xcode is perfect. No IDE is perfect, and they are constantly borrowing ideas from each other. One of Xcode's virtues, in my mind, is that they haven't adopted the kitchen sink approach of trying to implement any feature that anybody thinks up. They've historically had relatively a small, focused user base, and the Xcode team has created a scalpel, not a chainsaw. Xcode is written by some really smart engineers who have to use it every day for writing C, Objective-C, and C++. They aren't using it to write VB or C# and only rarely to write Java. They have different needs and different priorities than the Eclipse team or the Visual Studio team. But to claim that Xcode is "lacking" or "bad" does those developers a grave disservice. It does not try to be everything to everyone, that is true, but it is nonetheless a great IDE for the types of development that its user base does on a daily basis.
Here's the thing. If you are constantly missing some feature from Eclipse of Visual Studio, there's a really, really good chance you are working against the grain, trying to do something based on things you think you know from another language or application framework, or that you simply haven't discovered some piece of functionality in Xcode.
David Green, the author of this blog post, make the claim that Xcode (which he has been working with for "a few months") impedes developer productivity and that it is therefore "inferior" to Eclipse, a program he's worked with day-in and day-out for twelve years. Yes, that sounds like a fair basis for comparison. "This thing I just started using isn't anywhere near as good as this thing I've been using for years and know inside and out."
You can get some insight into the thought process behind this claim from this quote:
Java is a no-brainer. I have to say that it’s nice not to have to learn a new language to target mobile. Existing skillsets don’t come easy — so reuse of expertise is worth a lot.
Now let me put out there that I have worked with Java since about 1997, which would be, what, say... twelve years? It was my bread and butter for close to ten of those years. I've also got about ten years experience with Cocoa, Objective-C and Xcode(if you include its predecessor Project Builder). So, I have some basis for comparison and let me state that my opinion of the languages and the IDE is almost exactly the opposite of Mr. Green's when it comes to mobile development of GUI applications.
For starters, Java is absolutely not a no-brainer. In fact, Java is a really, really poor choice for embedded development. Oh, I know Java has been pushed as a great choice for embedded devices for years, but it's just not.
Mobile devices are constrained resource devices. The overhead for Java runtime's memory and processor overhead is non-trivial on such a device. And "existing skillsets" may not come easy, but reuse of expertise is no good if the cost for doing so is to make poor choices. You've certainly heard the cliché "if your only tool is a hammer, every problem looks like a nail"? Well, re-read the quote above and tell me that it's not simply a restatement of that cliché as an axiom. He's stating "Java is better because I know it better", nothing more. I know both languages, and Java is a better choice for many tasks, but there's really no way you can claim that it's better for writing a GUI application on an embedded device. Or, for that matter, for writing any GUI application period.
On the other hand, Objective-C is a great choice for writing GUI applications for an embedded device. It has a runtime that provides a lot of dynamic functionality with considerably less overhead. Objective-C has far better introspection than Java and greater flexibility in terms of passing objects of different types through a responder chain without filling up your code with typecasts or constant use of godawful generics (a much-lauded hack to get around a fundamental flaw with strongly-typed static languages like Java when it comes to designing GUI applications).
Some other gems from this blog post:
One thing that really became clear to me is that Objective-C, though it may have been visionary for its time, is really a language of the '80s. Certain issues such as split header and implementation files and violation of DRY are really time-wasters, and not small ones at that.
I honestly had the opposite complaint about Java. I hated that there was only a single file per class. I hated that Java deprived me of the ability to do lots of cool things by separating out the implementation from what is advertised to other classes. I hated, for example, having to use static final variables and hated having to incur the overhead of a method call for tiny bits of functionality that could have been expressed in a precompiler macro or static inline function in another language. That's not to say that Java's approach is bad, just to say that just because it was thought of later doesn't make it inherently better. Its saves a little typing and a small amount of project clutter, but it comes at a price. Personally, I prefer having more flexibility and a few more files in my project.
Split header and implementation files provide extra functionality and the cost is relatively trivial. Navigating between header and implementation files can be accomplished with a configurable key binding. I switch back and forth regularly between header and implementation files. The key command becomes second nature after a little while and it becomes completely a non-issue. I can't even see how this would be an issue worth mentioning if you had spent a few minutes reading about Xcode's key bindings.
As far as DRY, must I really do 5 things to declare a property??
ZOMG! I have to release memory! And type in more than one place! Run for the hills!
For the record, I can implement a single property in about 20 seconds using Xcode codesense and key bindings to navigate between the header and implementation files. For those who don't type as fast, check out the excellent Accessorizer. Personally, I can't create Java getters and setters in Java using Eclipse noticeably faster.
Another thing to realize is that Objective-C has a garbage collector, and it's quite a good one at this point, but Apple has intentionally chosen not to support it on the iPhone. This isn't about a shortcoming in the language, it's about a conscious decision made to provide a better user experience. Forcing developers to take responsibility for memory means that well-written applications will be more efficient and use less memory. Sure, there's a risk of memory leaks, but there are ways to track those down, and garbage collection comes with a price. On a device like a mobile phone, that is a non-trivial price even if the garbage collector is pristine and doesn't have any memory leaks itself.
Java has a similar problem with properties, though not quite so bad — and the IDE helps you write your getter/setter.
Gosh, it's too bad we don't have anything like that in Xcode. It'd be nice if we had maybe a Design menu, or maybe some text macros for Objective-C. Or at very least, an extensible scripting architecture with provided scripts to help us write our accessors and mutators. It would be even better if we had a persistence framework that completely obviated the need for data model classes at all.
And for those who didn't catch on to my sarcasm in that last paragraph, we do have all of those with Xcode. There is a design menu with tools that help you design data model classes. Under the edit menu, there is menu item called "Insert Text Macro", with several common macros for all the languages Xcode supports, and there's also an Applescript menu with such gems as "Place Accessor Defs on Clipboard".
But, in the vast majority of situations, you don't need to actually write your setters and getters. I don't care if your IDE creates them for you, 95% of the time, those are still code clutter. I'd much rather have a property with a synthesize statement and possibly a release call than tons of cruft in my code.
We also have Core Data, which lets you design data model classes visually without ever creating an Objective-C class. Or you can create a custom subclass, but you only need to put in your custom functionality - no setters or getters unless they do something non-standard.
Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial. @synthesized getters and setters for properties with retain should not be called in these methods. So many conventions and rules to remember!
Let me translate this: "Objective-C annoys me because it doesn't use the same patterns that Java uses and it is therefore bad". Implementing correct init and dealloc methods is non-trivial? How in the world could you possibly say that? If you understand the memory management contract (a whopping four whole rules), it's both trivial and intuitive. It only seems confusing if you haven't bothered to learn one of the fundamental aspects of the language you're using, and if you haven't, well, that's really not Xcode's fault, it's yours.
Objective-C’s imports and forward-declarations (@class) are a pain
What he calls a "pain", I call "more flexible". Forward declarations and header imports are more powerful and flexible than java's import mechanism, and if you understand what they are doing, they're really not difficult or time consuming.
With iPhone on the other hand, finding the functionality that I needed was painful. Classes and methods are poorly organized
Another translation: I kept looking for functionality as if I was working in Java and didn't find things where I expected them. Personally, I find Xcode's documentation browser (especially the new one coming in Xcode 3.2 under Snow Leopard) to be more intuitive and feel like it's designed perfectly for the needs of a knowledgeable Cocoa Touch programmer. It's not surprising that it's not designed to meet the expectations of a programmer learned from using another language, other frameworks, and a different IDE.
And here are some more complaints about the "shockingly bad" Xcode:
A decent window/editor management system. XCode and it’s associated tools (debugger) like to open lots of windows. Want to open a file? How about a new window for you! Very quickly I found myself in open-window-hell. The operating system’s window management is designed for managing multiple applications, not multiple editors within an IDE. It’s simply not capable of providing management of editors in an environment as sophisticated as an IDE.
Good point. It's just too bad there's no preference for changing to a single-window, or limited-window layout, huh? Oh, wait… there is, isn't there?
A project tree view that sorts files alphabetically. Really!
Oh, god, no. Please no. You're trying to use the project tree to do the detail panel's job. Just click the node of the tree you want, then in the detail panel, sort the part of the tree you've selected however you want, alphabetically, by code size, whatever. This gives you all the power of Eclipse's horrible project tree, but let's you only work with the section of the hierarchy you are currently interested in. Believe me, this is not a shortcoming in Xcode, this is a shortcoming in the way you're working.
iPhone app developers are given a pretty good UI builder. It does a great job of showing the UI as it will actually appear. It’s flexible and can model some pretty sophisticated UIs, so I was impressed. I found that using it was a little tricky — I had to read the documentation two or three times before I could really figure out how to use it properly.
Oh no - he had to read the documentation! No developer should ever have to do that. Anyone who damns Interface Builder with faint praise like this doesn't fully understand it and thinks it's just a form builder like they've used in Eclipse or VS.
Okay, I'm done. Now I'm being a little rough on the guy. He's giving an honest opinion thinking he's helping others, and that should be lauded. The problem is he's making claims that are not just a little biased, they're outright unsupportable. Calling Xcode "shockingly bad" because you haven't taken the time to learn how it works is just ignorant.
Okay, maybe a few more quotes, because there are so many good ones.
We may see a shake-up in the mobile market, with at least 18 new Android handsets being released this year. Until that happens, iPhone will remain a market leader and developers will have to put up with XCode and Objective-C.
The iPhone "will remain a market leader" until "18 new Android handsets" are released? Did you seriously write that with a straight face? You honestly think it's the number of handsets that is holding Android back? Seriously?
But at least he finished off with a great quote:
Sure, the iPhone is great — but can you install a new Linux kernel?
And the answer is, actually, yes. But who in their right mind would want to? Linux zealotry notwithstanding, the Mach kernel is better, and truth be told, most people - even most developers - don't want to waste time having to compile and install new kernels anyway.
