There is no excuse for XCode. It sucks. The only people - and this probably includes all Apple employees - that think different here are people who have never used a modern IDE. Don't tell me how great XCode is if you have not spent some significant time with either Eclipse, IDEA, or VS.Net. You have no credibility.
I spend quite a bit of time in Eclipse and VS.Net. I've used many others IDEs over the years.
I'll be the first to admit that there are features in other IDEs that I wouldn't mind having in Xcode. However, your assumption that a lack of specific features makes it inferior has a fatal flaw - you are basing what the IDE should have on what your needs are when programming in other languages.
Refactoring, one of your prime examples that Xcode doesn't support, is simply less of an issue, and therefore less of a priority in Objective-C. In Java, you have to refactor a lot because it's strongly-typed and has a much less dynamic messaging system (actually, calling it a messaging system is not even accurate). The design patterns you need to use to design well in Java often need to be refactored due to this nature. There is a price you pay for having the compiler keep you from shooting yourself in the foot. Objective-C will gladly let you shoot yourself in the foot in many ways, but in exchange, it allows design patterns that have much more flexibility and are much less likely to need significant refactoring down the line. In years of developing in Cocoa and OpenSTEP, I can think of maybe a half-dozen times where I've had to refactor at the class or application level. I've had to refactor within methods, but the IDE doesn't help much there. In the same time period, using Java, I've had to refactor dozens upon dozens of classes, both those written by me and those written by others. So, this lack that you claim makes Xcode suck is something that is just not really needed that badly in Xcode in the first place.
Eclipse focuses on the needs and priorities of Java developers. Visual Studio focuses on the needs of C# and VB programmers. Xcode focuses on the needs of Objective-C/Cocoa programmers. If you are judging any of these IDEs on your needs from programming in something else, your premise is skewed. The fact that XCode is lacking features that you use every day in another environment while coding in another language using different libraries and frameworks is absolutely meaningless. Judge the IDE based on what you it's used for.
I hate people who sit down to use something they're not familiar with and believe that any difference is a flaw.
What I intended to illustrate was the steps it took to create an app, put a button on a form and make pressing the button execute some piece of code. That is, after all, the building blocks of desktop applications: controls which respond to events by executing chunks of code
And I still disagree with your basic premise. Both.NET and Cocoa are very fast for putting applications together if you're comfortable with them. There are some specific tasks that can be done faster on one than the other, but neither is clearly faster than the other from an application building perspective. I can put together the basic shell of a Cocoa app just as fast as I can a.NET application. Times for building more complex applications are comparable, usually, though there are a few certain things that one can do noticeably faster in one or the other.
Visual Studio has a lot of nice features that Xcode doesn't, no doubt about that - I don't contest that point at all. But the two toolsets use different approaches and take a different way of looking at the problem. If you use one platform a lot then switch to the other, it will be slower for you for a while, but that is you more than it. I experience that when hopping between IDEs and languages a lot.
I've been doing a lot of Cocoa the last month or so, though, and only a small amount of Visual Studio work, and I can tell you that for me, Cocoa is much faster than.NET at the moment because I'm in that mode.
Another thing: when using the older outlet/action paradigm, you might be able to make a case for what you are arguing (albeit still not a strong case), except that it's unfair to compare the current.NET tools to a somewhat outdated way of doing things in Cocoa. Cocoa Bindings make connecting the interface to your data model and handling common user interactions even easier, often obviating the need to write any code at all for much of the day-to-day stuff an application needs to do. It's good stuff and simply not a slower app building tool overall than.NET if you're familiar with it. I'm not arguing that Cocoa is better in every single aspect, but simply that it's not worse than.NET in the primary way you stated (speed of development), which I stand by.
So Objective C may be a wonderful platform for developers, but it has a fairly high learning curve for the average joe, and this is where you win OS battles. Quality will keep the professionals interested, but quantity of software is where you will win more users.
Do you really think so? You think by having lots of mediocre quality third-party software available, Apple will win? I mean, for the "average joe", there's RealBasic. For real developers, Objective-C just isn't that hard to learn... the language itself can be learned in a few hours. Trying to dive right into Cocoa without any programming experience can be a bit of a challenge, but perhaps the state of software quality would be better if we didn't think that people should be able to program without actually learning how to program.
Sure, they could have. But why would they? They already owned a perfectly good IDE in Project Builder. Why buy a product that would have to be pretty much re-architected from the ground up to work with OS X? That wouldn't make business sense.
No. If you're an idiot, you'll still be one. It's not magic, you know.
Spend some time looking at the overall design and the so-called "best practices" of the two environments, and yeah, you can make a definite argument that the increased up-front productivity in.net has a price in terms of overall maintainability of your application. Lowering the bar to entry does not increase productivity except for the people who couldn't make it over the bar in the first place. If you're truly hiring good developers, you're not going to see any increased productivity because good developers are already over the hump. But if you want people learning while you pay them... well, hey... it's your money.
Great - you can write a specialized application with zero lines. Hey, here's an idea - I'll create a dev tool
You set up the example, not me. I was just correcting your inefficient and exaggerated Cocoa solution to it. Don't compare the two using a simplistic example and then complain about the fact that it's a simplistic example.
(1) The example I gave above was to illustrate the steps it takes to make a button perform a simple action (the action itself isn't the point). So, while I could've done something like have it use a built in action, I chose not to because it's not the point.
How is it a fair comparison if you do it in.net the standard way and then intentionally choose a convoluted, non-standard approach with several unnecessary steps in Cocoa? All methods defined with IBAction can be accessed directly from interface builder without writing code, so I have trouble understanding why you would intentionally choose not to take advantage of such a fundamental feature.
(2) The code I gave was clearly not VB - it was C#
You are absolutely 100% right. Sorry about that.
(3) Even with your solution for a very specific action, it STILL requires more steps
What I suggested was not a solution to a specific problem, it is the standard way of doing the specific task you set up as an illustrative scenario, as you (of course) know. Despite that, how is it possibly more steps? You have to place the button on the window in both environments. It took me one more step to connect the button to the performClose: action method (two if you count each click of the mouse as a separate action) so it's hard to see how it could be more steps, since you have to drop to the code editor and type in a line of code in.net.
I'm willing to bet that if you actually timed the number of seconds it takes to "write" the two apps,.NET would still win out.
I would take that bet. I might just go ahead and do it for grins and giggles since I've got both environments open at the moment.
Great idea, let's compare the sizes!
Interesting. Not the same results I'm seeing, but I'll take your word for it. No point in arguing it, since it's a relatively minor issue.
5) It's called terminate:, not performClose: - at least in Xcode 2.1
No. You said to close the window. On Windows, that's the same as terminating the application, but on the Mac, it's not the same (as I'm sure you know); I was doing what you said - I sent the NSWindow instance a performClose: method, but we could just as easily have sent the application delegate a terminate: message (NSWindow does not have a terminate: method) - it would take no longer. The IDE version we used wouldn't affect which outlets were available in either NSWindow or NSApplication, however.
my "professional" Cocoa work was at Apple so I was on salary, not paid by hours.
Good thing, it would seem.
Even my teammates there admitted that Xcode sucks and Visual Studio is much better. Many people would even use emacs because Xcode was that bad.
I don't doubt that some people even at Apple admit that Visual Studio is a better editor. I wasn't arguing about which one was a better code editor; I was arguing about the flawed comparison you made between how long it takes to build a simple application in the two environments.
You can say what you want about my Cocoa experience,
I don't know anything about your Cocoa experience so have no comment on it; your resume could be absolutely amazing for all I know. The fact that you approached a matter as simple as closing a window in Cocoa by doing a half-dozen unnecessary steps does make me question your competence in Cocoa... but not your experience. If you know better, than it looks like you were intentionally trying to overstate the case to make Cocoa look bad. Neither of the two likely possibilities endears you to me.
.net is targeted at RAD development, hence it being easy to use and slow. The payoff is that good developers can build stable, native applications at blinding speeds. I think the author's point is that Apple doesn't have an answer to that and needs one. Love it or hate it, MS has done extremely well with RAD because there is a huge need for it.
No, this isn't correct..Net's payoff is that mediocre developers can build moderately stable (but spaghetti-code) applications at moderately fast speeds.
If you're comparing good developers, than Cocoa is the clear winner. Good Cocoa developers are as fast as VB.net programmers. Once you get over the learning curve hump, Cocoa is a very fast development suite, so much so that I would say it was the first RAD. And the applications, even though created quickly, are much more likely to be maintainable and well organized because the design of Cocoa encourages that, unlike.net which sacrificies it for the sake of lowering the bars to entry so that mediocre intellects can take a six week course before selling themselves as "professional" developers.
Many of your complaints with the language seem to be much more a "it's different from other things, therefore wrong."
Namespaces is the one I see foisted around the most. I can see some value to adding namespace, but not enough to muck up the language. Objective-C was designed to be the simplest wrapper around C as possible while enabling an OO approach. With the much flatter hierarchies Objective-C's weak-binding and dynamicism encourage, the lack of namespaces is a relatively minor thing. Some people want them, but there's really no compelling need for them. I, for one, am glad that Objective-C has avoided the "throw in everything but the kitch sink" approach that has caused C++ to bloat in recent years.
Abstract class support? Again, why? The language doesn't need this. Objective-C's approach is to trust that the developer knows that he or she is doing. It doesn't take the paranoid approach that C++ and Java and the other Modula-3 inspired languages do, but that's not a flaw, it's a design choice. Objective-C is bad for stupid programmers, that I'll readily admit.
All methods are public, but they don't have to be advertised in your header file. Again, it's the nature of the language, and the result of a conscious design choice, not a flaw. You don't need this, even though many programmers have been indoctrinated into thinking they do.
I give you some points on the constructor issue. A language-level support for the DI or an official "constructor" method would be a good addition and add relatively little to the language and runtime. Garbage Collection is not something I personally want, but I know many people do; it's in the works. GCC 4.0 has support for it, it just hasn't been fully integrated into Cococa yet. Probably with the next release (is it Puma? I can't even remember all the cat names any more).
I characterize Objective C and the Interface Builder integration and a lot of those concepts to have been ten years ahead of its time when it was in its heyday (let's say 1988). So it's a 1998 environment in 2005 -- it's not really getting any younger -- they used up their "ahead of their time" card awhile ago.
NeXT's heyday was a year before the v1.0 release of NeXTSTEP, huh? Interesting. And, if they used up the "ahead of their time" card, why are most other application building tools still using code generation, ferchrissakes? Cocoa has lost ground, especially in terms of spit and polish, that's for sure, but if you value smart design, then it's hard to say they've totally squandered their lead, especially since Cocoa is not stagnating... Core Data, Cocoa Bindings, Key Value Observing... Cocoa's not getting younger, but it is getting better.
Compare, for example, the amount of steps it takes to build a simple app with button on the center that'll close when run it.
Sorry, but this is a bullshit example. Your two solutions shows that you clearly have a lot more experience with.Net than with Cocoa, and if you ever did "professional" Cocoa work, your clients got ripped off if they paid by the hour.
To accomplish your example application, you need to write a single line of code with VB.net. Not bad. But you need to write zero lines of code to accomplish it in Cocoa. The steps to do it would be to drag a button onto the window, control drag from the button to the window's icon and select the performClose: action. That's it. Job done. It's only faster in.Net if you don't know what you're doing in Cocoa.
On top of that, compare the size of the two generated applications. The VB.net application will be noticeably larger (roughly 10-20X larger depending on version and settings)- your one line of VB code created bloated application.
Well, Copeland and OpenDoc are pre-Jobs Apple, so go yell at Amelio or Sculley about those two.
On the rest of it, Apple never made a blanket "use Carbon", or "use Cocoa" claim. They said, consistently, to use Carbon if you have a lot of legacy toolbox code, and to use Cocoa if you were starting a project from scratch or were bringing things over from NextStep. OpenStep is just the old name for Cocoa and Rhapsody is just the old name for OS X, so you're kinda overstating your point just to make it look more schizophrenic than it really was.
Metrowerks was in it for the money just as much as anyone else; they weren't "there" for anybody but themselves (and later, their shareholders). Once Metrowerks released a Windows version, they stopped giving the Mac priority and the tools stagnated. Apple inherited a perfectly good IDE from NeXT and Metrowerks gave no indication that they were chomping at the bit to upgrade their tools in a urry so that developers could be ready when OS X came out. Metrowerks wanted to play it cautious and didn't want to gamble on Apple's transition to OS X, so what else was Apple to do? I've met relatively few people except a few cranky old Toolbox guys who didn't want to make the transition to OS X, who aren't happy with Apple Developer support compared with what it was historically. The Inside Macintosh books used to cost an arm and a leg and weren't available in soft editions, MPW was a nightmare, as you stated, and the only other way to create applications was to buy third party IDE.
Life has been pretty good (not perfect, but pretty good) since Apple bought NeXT. It's been tumultous at times, but has steadily been heading in the right direction, and as a matter of fact, developers have not been leaving the platform in droves; there has been a well-documented and steady increase in the number of developers using OS X as their primary platform.
At a risk of diving into a holy-war topic, I have to say I think both the author and Steve are right.
Jobs is right in stating that Objective-C and Cocoa are perfect. In a sense at least. The approach, and the high level concepts behind it are so much better and more elegant than those that drive.Net, or for that matter, most any application building toolset out there. Once you grok the way it works (which take a bit of learning; don't snap-judge it until you've spent some quality time with it), you come to realize that NeXT was so far ahead of the pack as to not even be funny. I've never used anything to compare with it in terms of quickly creating maintainable, robust desktop applications. Other solutions, like VB.net, trade off maintainability and organization in order to lower the bars to entry, which is a trade off that I think, in the long run, has hurt the state of the industry. I don't think it's necessarily a good thing to make it so anyone can develop software, because then anyone does. Once you grok Cocoa, you can build applications incredibly fast with it, but you do need to understand a bit about how it all fits together, and that's not a bad thing in terms of overall software quality.
And, as to the author's question about what has Apple done for Cocoa developers lately? Well, I'd say Core Data, Cocoa Bindings, Key Value Observing, refinements to the project templates and Xcode would all count and all have been happening at a steady pace since before Jaguar came out.
Now... on the other hand, there is a valid argument that Xcode and Cocoa lag behind Visual Studio/.Net and Eclipse/Java in many respects. There are many refinements and features in Microsoft's current development tools that are extremely nice and which do not have a comparable feature in Apple's tools. Eclipse also has several features that I would love to see added to Xcode. Java and Microsoft's CLR have things that I would like to see incorporated into Objective-C's runtime. To say it's "perfect" is quite a stretch if you look at the big picture and aren't sitting in the RDF.
But having used both Apple's and Microsoft's tools quite a bit (and Eclipse as well), I have to say I still prefer developing in Cocoa over anything else. And not just a little: by far. Despite the fact that it's missing some bells and whistles, and in a few places lacks the polish of the competition, from a high-level view, it's the most elegant tool/language/framework combination I've ever used. I didn't take to it right away, though. You really have to spend some time with Objective-C and Cocoa before the little light bulb goes on in your head and you "get it". But once you do, it's undeniably cool. If you don't see it, then you don't get it.
Now, before you jump on me... "better" is a subjective term. I have and will continue to recommend other solutions to my clients based on the practical considerations of the specific project. I have Visual Studio sitting open on one of my computers at the moment not because my client mandated it, but because I recommended it after looking at the whole situation. Is "Cocoa" better? In a vacuum, probably. In reality, sometimes yes, sometimes no.
Jeff Raskin was NOT the creator of the Mac. He was the originator (IIRC) of the Macintosh project, and its first manager, but his vision of the Macintosh was so at odds with Jobs', that to give Jef any credit for what the Macintosh became is unfair and incorrect. If you want to see Jeff's vision, go look at the Canon Cat, which he designed after being asked to leave teh Macintosh project.
Raskin was a smart guy, but he wanted to design interfaces for smart people; interfaces that had a learning curve associated with them due to all sorts of key combinations to remember. Though he backed away from this a little later in his life, when he saw how successful GUIs were (and, perhaps, wanting to claim an unfair amount of credit for that), all his interfaces were designed to be incredibly efficient for the intelligent geek who wanted to take the time to learn how to use them.
That doesn't really go along with the Mac's tagline "The computer for the rest of us."
Remember that history and fact are not the same thing. Jef & Steve both have (well, in Jef's case, had) their versions of what happened; neither is fact, and the real truth, if there is one, probably lies somewhere in the middle, probably a touch closer to Jobs' version, that is, if you know how to interpret the Jobsian language and make sure to read it outside of the RDF.
Re:Too bad we can't mod the original article Troll
on
Java Is So 90s
·
· Score: 1
Thank you. You said it better (and more nicely) than I would have:)
Too bad we can't mod the original article Troll
on
Java Is So 90s
·
· Score: 3, Insightful
This is just stupid. People are wasting their energy arguing over completely different technologies designed for different purposes, with different strengths and weaknesses. If you think any one toolset is the right solution for every problem, you don't know enough about the all the options to have a valid opinion.
I've used most of the technologies people have mentioned here, some extensively. None of them are clearly all-around better than the others in all ways, and the statistics concerning toolset use are meaningless because technical merits are rarely the deciding factor in what tools or libraries a particular project ends up using. It's usually either the project team deciding to use what they're comfortable with (i.e. the I've-got-a-hammer-so-this-project-must-be-a-nail approach), or imposed top-down by management who were sold on the merits of one solution by a salesperson/article/more technically-savvy friend, etc.
Hell, the closest thing to an all-around great-for-most-anything tool for building web application was NeXT's old Objective-C based WebObjects which, despite the fact that Apple let it die a painful death, was years ahead of anything else on the market, and even now after not being developed or supported for several years, is still ahead of many solutions in some respects. But I'm not about to recommend to one of my clients that they should use it, even though I might think it's technically a better solution than something else. These decisions, even when made intelligently (which is rarely), are not, and should not be, made in a vacuum.
The uniqueness of the human body really can't be compared the the repeititve nature of a computer.
Sure, it can. Absolutely, and without question, as long as you are not including an emotional or intellectual response in what you are measuring. Physiological processes are predictable - they are just an order of magnitude more complex than any computer we've yet built. Your example doesn't show that that the results can't be predicted, it simply illustrates the fact that we haven't mapped all the variables. Yet.
Topeka, Kan, - Today, the Kansas Board of Education redefined Pi to equal 3. Evangelical parents groups pushed for the changes, believing that such a change would help increase statewide scores on standardized math tests. "Pi just never ends! How can we expect kids to remember something like that" said Board Chairman Steve Abrams. "This is a great day! This is the best we could do to help our students compete in the ever-important fields of, you know, math and stuff." Abrams predicted that most other states would follow Kansas' lead within a year or two. As part of the same revision, Kansas also redefined the term "math" in their curriculum to exclude "that really hard stuff like Calculus."
Eugenie Scott, Executive Director of the National Center for Science Education, was asked to comment on the decision, but was suffering from alternating bouts of hysterical laughing and sobbing and was unable to give us a quote before our deadline.
Apple gets credit for doing interesting things, but a minor change in Dell's lineup will see many more customers and far more sales. So which one is really newsworthy?
Obviously, the answer is Apple's "interesting things", otherwise we'd see Dell-related headlines in the news twice a week, which we don't. I'm not commenting on whether that's right or now, just that it's pretty obvious what the major media outlets consider newsworthy.
And you're right that Dell generally does have more sales of CPUs, but I'm pretty sure the iPod is outselling Dell's little MP3 player with the forgettable name by a few orders of magnitude. Also, how much profit does Dell take on each unit it sells? I think if you look at the numbers, Apple made more profits moving far fewer machines last year and last quarter, so I'd say that's also more newsworth (and smart - why work harder for less money?).
And seriously, does anybody even care what Dvorak says any more? I think he just makes outrageous claims about high-profile companies and products in order to get people worked up. He knows that if he posts some ridiculous comment about Apple or Linux that the zealots will get worked up and post them to post to Slashdot, which will get more people to read his tripe, which gives the impression to his editors that a lot of people care what he spews. Puhlease. I wish Slashdot had a killfile for articles... I'd just flag anything with Dvorak's name in it to not show up at all.
and as anyone who bills there time knows, a billed hour is more than an hour of work
Not necessarily so with Lawyers. They typically bill in increments - usually 6 minutes (1/10th hour), but some billing in larger increments - 15 minutes, 30 minutes, a few crooks actually use whole hours.
So, Joe Lawyer makes five one minute phone calls (yes, I've seen it happen, and more than five). He just billed at least 30 minutes of work and possibly as much as 6 hours for those five minutes.
Unlike many other bill-for-time professions like consultants, Lawyers often bill far more than they actually work -- legally (read the retention contract if you hire a lawyer, it'll be in there, you signed it, you agreed to it, it's legal), and they usually have paralegals, admins, and clerks who do a lot of that extra non-billable stuff that other professionals spend their non-billable time doing. They do lose time to business development (i.e. Rain Making), but I don't really count the bulk of that as "work".
How do I know? I was a lawyer (okay, I guess I technically still am, but don't practice). I got disgusted with the industry and went into the less dishonest business of software development and then later management consulting, so I've played both billing games and watched others play both.
Personally, I can't agree with this posters assessment of many lawyers being "great" people. Very few laywers, in my opinion, are "great" people. Many start out as at least "good" people, and some even as "great" people, but you stay in the business long enough, you sell your soul so thoroughly that you lose whatever "greatness" you may have had.
The exception to that are the selfless souls who work for crap pay for a cause they believe in despite debilitating student loans. Those people, I think, qualify as "great", even if I don't believe in their cause.
Those that get the hell out of Dodge stand a chance at regaining their humanity as well, something I've been working on for ten years now.
And excuse my ignorance but what's so "apt" about version number 0.4
I'm guessing this is a reference to The Hitchhiker's Guide to the Galaxy, in which the answer to Life, the Universe, and Everything turned out to be... 42.
What bullshit. The lengths that some people go to to "defend" film. If you like film, use it, but don't come up with these lame arguments, just say you like it and be done with it.
I've NEVER lost a digital file since I went digital back in 1998. I keep my photo library on a computer and do periodic backups to DVD, which I store offsite.
In my years of using film, I did lose negatives (only one copy of them, remember?) had many negatives that could only produce poor quality images because they got scratched, faded, creased, etc., or required a lot of work to get a good print. At many times, I didn't have room to set up my darkroom (and most people don't have one), so I had the negatives, but no way to make copies except to pay someone else - making me dependent on someone else, which is far worse IMHO than being dependent on a file format you don't own.
I only periodically shoot in RAW, but I have an "official" converter that will turn it into any number of open formats, plus Photoshop supports the RAW format. If in some weird stroke of luck, both companies revoked my licenses to use that software, I'd convert them all to an open format. Otherwise, my images are JPEGs or TIFFs. I can do anything I want with them and there's absolutely no doubt that I own them. I can make unlimited copies with no image loss without a darkroom, make backup copies to store elsewhere, and print copies from pictures taken years ago at exactly the quality they were when I took them.
How in the name of Dog is film "better" in terms of image ownership? And how did this lame argument get a +5 insightful?
I dunno. This sounds like something Jobs would do, with his ego. However, there's something about this that sorta rings false to me.
Jobs is a master showman and very media savvy. He HAS to know that his actions are going to cause a spike of interest in this book. The two companies have a long standing relationship.
My money is on this being a media stunt - all planned to increase sales of the book. I could be wrong, and we'll probably never know one way or another, but if Steve had done this because he was pissed off, I somehow think it would have been done quietly without press coverage so as to avoid giving Wiley the benefit of the press exposure.
Slashdot Mirror
I'll be the first to admit that there are features in other IDEs that I wouldn't mind having in Xcode. However, your assumption that a lack of specific features makes it inferior has a fatal flaw - you are basing what the IDE should have on what your needs are when programming in other languages.
Refactoring, one of your prime examples that Xcode doesn't support, is simply less of an issue, and therefore less of a priority in Objective-C. In Java, you have to refactor a lot because it's strongly-typed and has a much less dynamic messaging system (actually, calling it a messaging system is not even accurate). The design patterns you need to use to design well in Java often need to be refactored due to this nature. There is a price you pay for having the compiler keep you from shooting yourself in the foot. Objective-C will gladly let you shoot yourself in the foot in many ways, but in exchange, it allows design patterns that have much more flexibility and are much less likely to need significant refactoring down the line. In years of developing in Cocoa and OpenSTEP, I can think of maybe a half-dozen times where I've had to refactor at the class or application level. I've had to refactor within methods, but the IDE doesn't help much there. In the same time period, using Java, I've had to refactor dozens upon dozens of classes, both those written by me and those written by others. So, this lack that you claim makes Xcode suck is something that is just not really needed that badly in Xcode in the first place.
Eclipse focuses on the needs and priorities of Java developers. Visual Studio focuses on the needs of C# and VB programmers. Xcode focuses on the needs of Objective-C/Cocoa programmers. If you are judging any of these IDEs on your needs from programming in something else, your premise is skewed. The fact that XCode is lacking features that you use every day in another environment while coding in another language using different libraries and frameworks is absolutely meaningless. Judge the IDE based on what you it's used for.
I hate people who sit down to use something they're not familiar with and believe that any difference is a flaw.
And I still disagree with your basic premise. Both
Visual Studio has a lot of nice features that Xcode doesn't, no doubt about that - I don't contest that point at all. But the two toolsets use different approaches and take a different way of looking at the problem. If you use one platform a lot then switch to the other, it will be slower for you for a while, but that is you more than it. I experience that when hopping between IDEs and languages a lot.
I've been doing a lot of Cocoa the last month or so, though, and only a small amount of Visual Studio work, and I can tell you that for me, Cocoa is much faster than
Another thing: when using the older outlet/action paradigm, you might be able to make a case for what you are arguing (albeit still not a strong case), except that it's unfair to compare the current
Sure, they could have. But why would they? They already owned a perfectly good IDE in Project Builder. Why buy a product that would have to be pretty much re-architected from the ground up to work with OS X? That wouldn't make business sense.
No. If you're an idiot, you'll still be one. It's not magic, you know.
.net has a price in terms of overall maintainability of your application. Lowering the bar to entry does not increase productivity except for the people who couldn't make it over the bar in the first place. If you're truly hiring good developers, you're not going to see any increased productivity because good developers are already over the hump. But if you want people learning while you pay them... well, hey... it's your money.
Spend some time looking at the overall design and the so-called "best practices" of the two environments, and yeah, you can make a definite argument that the increased up-front productivity in
If you're comparing good developers, than Cocoa is the clear winner. Good Cocoa developers are as fast as VB
Many of your complaints with the language seem to be much more a "it's different from other things, therefore wrong."
Namespaces is the one I see foisted around the most. I can see some value to adding namespace, but not enough to muck up the language. Objective-C was designed to be the simplest wrapper around C as possible while enabling an OO approach. With the much flatter hierarchies Objective-C's weak-binding and dynamicism encourage, the lack of namespaces is a relatively minor thing. Some people want them, but there's really no compelling need for them. I, for one, am glad that Objective-C has avoided the "throw in everything but the kitch sink" approach that has caused C++ to bloat in recent years.
Abstract class support? Again, why? The language doesn't need this. Objective-C's approach is to trust that the developer knows that he or she is doing. It doesn't take the paranoid approach that C++ and Java and the other Modula-3 inspired languages do, but that's not a flaw, it's a design choice. Objective-C is bad for stupid programmers, that I'll readily admit.
All methods are public, but they don't have to be advertised in your header file. Again, it's the nature of the language, and the result of a conscious design choice, not a flaw. You don't need this, even though many programmers have been indoctrinated into thinking they do.
I give you some points on the constructor issue. A language-level support for the DI or an official "constructor" method would be a good addition and add relatively little to the language and runtime. Garbage Collection is not something I personally want, but I know many people do; it's in the works. GCC 4.0 has support for it, it just hasn't been fully integrated into Cococa yet. Probably with the next release (is it Puma? I can't even remember all the cat names any more).
To accomplish your example application, you need to write a single line of code with VB
On top of that, compare the size of the two generated applications. The VB
Well, Copeland and OpenDoc are pre-Jobs Apple, so go yell at Amelio or Sculley about those two.
On the rest of it, Apple never made a blanket "use Carbon", or "use Cocoa" claim. They said, consistently, to use Carbon if you have a lot of legacy toolbox code, and to use Cocoa if you were starting a project from scratch or were bringing things over from NextStep. OpenStep is just the old name for Cocoa and Rhapsody is just the old name for OS X, so you're kinda overstating your point just to make it look more schizophrenic than it really was.
Metrowerks was in it for the money just as much as anyone else; they weren't "there" for anybody but themselves (and later, their shareholders). Once Metrowerks released a Windows version, they stopped giving the Mac priority and the tools stagnated. Apple inherited a perfectly good IDE from NeXT and Metrowerks gave no indication that they were chomping at the bit to upgrade their tools in a urry so that developers could be ready when OS X came out. Metrowerks wanted to play it cautious and didn't want to gamble on Apple's transition to OS X, so what else was Apple to do? I've met relatively few people except a few cranky old Toolbox guys who didn't want to make the transition to OS X, who aren't happy with Apple Developer support compared with what it was historically. The Inside Macintosh books used to cost an arm and a leg and weren't available in soft editions, MPW was a nightmare, as you stated, and the only other way to create applications was to buy third party IDE.
Life has been pretty good (not perfect, but pretty good) since Apple bought NeXT. It's been tumultous at times, but has steadily been heading in the right direction, and as a matter of fact, developers have not been leaving the platform in droves; there has been a well-documented and steady increase in the number of developers using OS X as their primary platform.
I'd hardly say they're "suffering".
Not to state the obvious or anything, but Objective-C is perfect because that was a troll. Please don't feed the trolls. :)
At a risk of diving into a holy-war topic, I have to say I think both the author and Steve are right.
.Net, or for that matter, most any application building toolset out there. Once you grok the way it works (which take a bit of learning; don't snap-judge it until you've spent some quality time with it), you come to realize that NeXT was so far ahead of the pack as to not even be funny. I've never used anything to compare with it in terms of quickly creating maintainable, robust desktop applications. Other solutions, like VB.net, trade off maintainability and organization in order to lower the bars to entry, which is a trade off that I think, in the long run, has hurt the state of the industry. I don't think it's necessarily a good thing to make it so anyone can develop software, because then anyone does. Once you grok Cocoa, you can build applications incredibly fast with it, but you do need to understand a bit about how it all fits together, and that's not a bad thing in terms of overall software quality.
Jobs is right in stating that Objective-C and Cocoa are perfect. In a sense at least. The approach, and the high level concepts behind it are so much better and more elegant than those that drive
And, as to the author's question about what has Apple done for Cocoa developers lately? Well, I'd say Core Data, Cocoa Bindings, Key Value Observing, refinements to the project templates and Xcode would all count and all have been happening at a steady pace since before Jaguar came out.
Now... on the other hand, there is a valid argument that Xcode and Cocoa lag behind Visual Studio/.Net and Eclipse/Java in many respects. There are many refinements and features in Microsoft's current development tools that are extremely nice and which do not have a comparable feature in Apple's tools. Eclipse also has several features that I would love to see added to Xcode. Java and Microsoft's CLR have things that I would like to see incorporated into Objective-C's runtime. To say it's "perfect" is quite a stretch if you look at the big picture and aren't sitting in the RDF.
But having used both Apple's and Microsoft's tools quite a bit (and Eclipse as well), I have to say I still prefer developing in Cocoa over anything else. And not just a little: by far. Despite the fact that it's missing some bells and whistles, and in a few places lacks the polish of the competition, from a high-level view, it's the most elegant tool/language/framework combination I've ever used. I didn't take to it right away, though. You really have to spend some time with Objective-C and Cocoa before the little light bulb goes on in your head and you "get it". But once you do, it's undeniably cool. If you don't see it, then you don't get it.
Now, before you jump on me... "better" is a subjective term. I have and will continue to recommend other solutions to my clients based on the practical considerations of the specific project. I have Visual Studio sitting open on one of my computers at the moment not because my client mandated it, but because I recommended it after looking at the whole situation. Is "Cocoa" better? In a vacuum, probably. In reality, sometimes yes, sometimes no.
Jeff Raskin was NOT the creator of the Mac. He was the originator (IIRC) of the Macintosh project, and its first manager, but his vision of the Macintosh was so at odds with Jobs', that to give Jef any credit for what the Macintosh became is unfair and incorrect. If you want to see Jeff's vision, go look at the Canon Cat, which he designed after being asked to leave teh Macintosh project.
Raskin was a smart guy, but he wanted to design interfaces for smart people; interfaces that had a learning curve associated with them due to all sorts of key combinations to remember. Though he backed away from this a little later in his life, when he saw how successful GUIs were (and, perhaps, wanting to claim an unfair amount of credit for that), all his interfaces were designed to be incredibly efficient for the intelligent geek who wanted to take the time to learn how to use them.
That doesn't really go along with the Mac's tagline "The computer for the rest of us."
Remember that history and fact are not the same thing. Jef & Steve both have (well, in Jef's case, had) their versions of what happened; neither is fact, and the real truth, if there is one, probably lies somewhere in the middle, probably a touch closer to Jobs' version, that is, if you know how to interpret the Jobsian language and make sure to read it outside of the RDF.
Thank you. You said it better (and more nicely) than I would have :)
This is just stupid. People are wasting their energy arguing over completely different technologies designed for different purposes, with different strengths and weaknesses. If you think any one toolset is the right solution for every problem, you don't know enough about the all the options to have a valid opinion.
I've used most of the technologies people have mentioned here, some extensively. None of them are clearly all-around better than the others in all ways, and the statistics concerning toolset use are meaningless because technical merits are rarely the deciding factor in what tools or libraries a particular project ends up using. It's usually either the project team deciding to use what they're comfortable with (i.e. the I've-got-a-hammer-so-this-project-must-be-a-nail approach), or imposed top-down by management who were sold on the merits of one solution by a salesperson/article/more technically-savvy friend, etc.
Hell, the closest thing to an all-around great-for-most-anything tool for building web application was NeXT's old Objective-C based WebObjects which, despite the fact that Apple let it die a painful death, was years ahead of anything else on the market, and even now after not being developed or supported for several years, is still ahead of many solutions in some respects. But I'm not about to recommend to one of my clients that they should use it, even though I might think it's technically a better solution than something else. These decisions, even when made intelligently (which is rarely), are not, and should not be, made in a vacuum.
Sure, it can. Absolutely, and without question, as long as you are not including an emotional or intellectual response in what you are measuring. Physiological processes are predictable - they are just an order of magnitude more complex than any computer we've yet built. Your example doesn't show that that the results can't be predicted, it simply illustrates the fact that we haven't mapped all the variables. Yet.
Topeka, Kan, - Today, the Kansas Board of Education redefined Pi to equal 3. Evangelical parents groups pushed for the changes, believing that such a change would help increase statewide scores on standardized math tests. "Pi just never ends! How can we expect kids to remember something like that" said Board Chairman Steve Abrams. "This is a great day! This is the best we could do to help our students compete in the ever-important fields of, you know, math and stuff." Abrams predicted that most other states would follow Kansas' lead within a year or two. As part of the same revision, Kansas also redefined the term "math" in their curriculum to exclude "that really hard stuff like Calculus."
Eugenie Scott, Executive Director of the National Center for Science Education, was asked to comment on the decision, but was suffering from alternating bouts of hysterical laughing and sobbing and was unable to give us a quote before our deadline.
And you're right that Dell generally does have more sales of CPUs, but I'm pretty sure the iPod is outselling Dell's little MP3 player with the forgettable name by a few orders of magnitude. Also, how much profit does Dell take on each unit it sells? I think if you look at the numbers, Apple made more profits moving far fewer machines last year and last quarter, so I'd say that's also more newsworth (and smart - why work harder for less money?).
And seriously, does anybody even care what Dvorak says any more? I think he just makes outrageous claims about high-profile companies and products in order to get people worked up. He knows that if he posts some ridiculous comment about Apple or Linux that the zealots will get worked up and post them to post to Slashdot, which will get more people to read his tripe, which gives the impression to his editors that a lot of people care what he spews. Puhlease. I wish Slashdot had a killfile for articles... I'd just flag anything with Dvorak's name in it to not show up at all.
Not necessarily so with Lawyers. They typically bill in increments - usually 6 minutes (1/10th hour), but some billing in larger increments - 15 minutes, 30 minutes, a few crooks actually use whole hours.
So, Joe Lawyer makes five one minute phone calls (yes, I've seen it happen, and more than five). He just billed at least 30 minutes of work and possibly as much as 6 hours for those five minutes.
Unlike many other bill-for-time professions like consultants, Lawyers often bill far more than they actually work -- legally (read the retention contract if you hire a lawyer, it'll be in there, you signed it, you agreed to it, it's legal), and they usually have paralegals, admins, and clerks who do a lot of that extra non-billable stuff that other professionals spend their non-billable time doing. They do lose time to business development (i.e. Rain Making), but I don't really count the bulk of that as "work".
How do I know? I was a lawyer (okay, I guess I technically still am, but don't practice). I got disgusted with the industry and went into the less dishonest business of software development and then later management consulting, so I've played both billing games and watched others play both.
Personally, I can't agree with this posters assessment of many lawyers being "great" people. Very few laywers, in my opinion, are "great" people. Many start out as at least "good" people, and some even as "great" people, but you stay in the business long enough, you sell your soul so thoroughly that you lose whatever "greatness" you may have had.
The exception to that are the selfless souls who work for crap pay for a cause they believe in despite debilitating student loans. Those people, I think, qualify as "great", even if I don't believe in their cause.
Those that get the hell out of Dodge stand a chance at regaining their humanity as well, something I've been working on for ten years now.
You've clearly forgotten about Microsoft Bob.
I'm guessing this is a reference to The Hitchhiker's Guide to the Galaxy, in which the answer to Life, the Universe, and Everything turned out to be... 42.
wget http://download.mozilla.org/?product=firefox-1.0.4 &os=win&lang=en-US
4 &os=win&lang=en-US > firefox.exe
Oh... wait. Windows doesn't have wget, does it. How about
curl http://download.mozilla.org/?product=firefox-1.0.
Hmmm, that won't work, either, will it? Guess you should have chosen a different OS.
What bullshit. The lengths that some people go to to "defend" film. If you like film, use it, but don't come up with these lame arguments, just say you like it and be done with it. I've NEVER lost a digital file since I went digital back in 1998. I keep my photo library on a computer and do periodic backups to DVD, which I store offsite. In my years of using film, I did lose negatives (only one copy of them, remember?) had many negatives that could only produce poor quality images because they got scratched, faded, creased, etc., or required a lot of work to get a good print. At many times, I didn't have room to set up my darkroom (and most people don't have one), so I had the negatives, but no way to make copies except to pay someone else - making me dependent on someone else, which is far worse IMHO than being dependent on a file format you don't own. I only periodically shoot in RAW, but I have an "official" converter that will turn it into any number of open formats, plus Photoshop supports the RAW format. If in some weird stroke of luck, both companies revoked my licenses to use that software, I'd convert them all to an open format. Otherwise, my images are JPEGs or TIFFs. I can do anything I want with them and there's absolutely no doubt that I own them. I can make unlimited copies with no image loss without a darkroom, make backup copies to store elsewhere, and print copies from pictures taken years ago at exactly the quality they were when I took them. How in the name of Dog is film "better" in terms of image ownership? And how did this lame argument get a +5 insightful?
I dunno. This sounds like something Jobs would do, with his ego. However, there's something about this that sorta rings false to me.
Jobs is a master showman and very media savvy. He HAS to know that his actions are going to cause a spike of interest in this book. The two companies have a long standing relationship.
My money is on this being a media stunt - all planned to increase sales of the book. I could be wrong, and we'll probably never know one way or another, but if Steve had done this because he was pissed off, I somehow think it would have been done quietly without press coverage so as to avoid giving Wiley the benefit of the press exposure.