Ah. I remember CodeWarrior well. It was a gem only in the sense that it didn't completely suck. But viewed against any set of hard objectives you could come up with, it still sucked in many ways.

I don't think Metrowerks ever pulled off a major release that wasn't crippled in some horrible way, for instance, whether it was executables growing in size without bounds, buggy code generation, or IDE crashes.

Note: Above makes it sound like I hate CodeWarrior. Actually, I thought CodeWarrior was comparatively very good. And it looking so good compared to others despite its flaws made (and makes) me sad.

I think Xcode is great, compared to some alternatives!

I have had to use NetBeans in the past, and that is a dodgy program.

(Having said that, I agree with the moral of this post, having come from a career that used power tools, and there's little out there that compares with a good DeWalt battery operated drill...especially not my $13 GMC cheapo!)

The fact that Xcode is good compared to other tools just underlines my point. They all suck!

(I didn't know about all the flaws in CodeWarrior, but when I was using it I was much more of a hobbyist, not a serious user.)

One thing programmers always seem to love when they get together is to complain about development tools.

Now ask yourself, when was the last time you heard a bunch of mechanics complain about their tools? In my experience, it's entirely the opposite. They spend a whole bunch of money, and then gather around and spend all their time talking about how awesome their tools are.

I want to stop saying my tools are good compared to the alternative and start saying that they're just plain good. I doubt it'll happen any time soon though.

Yup, I made such a post earlier this year as well. http://thecodist.com/article/ask-me-how-much-i-hate-xcode-and-c--

Not looking forward to doing the iphone dev...

Perhaps you would do a comparative complexity analysis between the computer software tools and the hardware tool. Actually, this shouldn't be required; as you should already know that the software is more complex. The hardware is designed for (usually) a single specified task, and they do it well. The hardware design is simple and solid. Software on the other hand is a whole different beast. Most software does not only do one thing, it does multiple related tasks. With hardware for example, if you want to pop-rivet something, you need to drill the whole with a drill, use a pop-rivet and a riveting tool to place the pop-rivet.

Software like GCC might not be the most elegant software, but it works quite well. And software and hardware alike, you have to make the best use of what you have available. You could spend forever wishing for better tools.

Like the saying goes, if wishes were wings. Pigs would fly.

codist: Doesn't look like I'm saying the same thing at all. You're basically saying that C++ and Xcode don't match up to Java and IntelliJ. I'm saying that no dev tools anywhere can match the high quality tools you find in other professions.

anonymouse: I don't think I believe the comparative complexity idea. Sure, a wrench compared to a compiler is a no-brainer. But how about a 747 compared to a compiler? I'd wager that the complexity and development effort that went into the 747 far outstrips the entire Xcode toolchain, and yet Boeing was able to create something that doesn't spontaneously fail all the time or lose basic, obvious functionality after new revisions.

Your argument seems to imply that software needs to consist more of components and less of integrated environments. I would tend to agree with that, but it seems pretty clear that this still doesn't get us anywhere close.

It's not like I'm going to stop working while I wait for these better tools. But I'm getting fed up with the current state of the art, and I'm going to express that.

Hold the sharp end away from your body and work with the grain.

One word: Emacs.

I liked the Delphi editor (before the .NET-versions, that is). They were fast and predictable and that was all I wanted.. :)

I think it's pretty simple: great developers build their own tools.

Microsoft Visual Studio pretty much works all of the time and is reasonably pleasant to work with.

And it doesn't cost an arm and a leg!

Emacs is holding the sharp end towards your body. Yes, it's amazing the amount of leverage you can get, but the bleeding sucks.



It doesn't run on any of my machines.

Personally, I consider UNIX to be my toolbox, and people keep wanting to replace my aging toolbox with a powered multitool. An IDE such as Xcode isn't a toolbox, it's an all-in-one tool, and it shows.

Long time ago. I used AMOS on my A500 and later I used Turbo Pascal and Turbo C. These IDE's rocked. Ever since I have been looking for new tools, but havn't found anything nearly as good. Debugging just worked. Help just worked. Syntax coloring worked.

If you're using C, C++, etc., sure, tools suck. It's because the languages don't support tools. For languages like Java, try IntelliJ IDEA. It's not perfect, but it's probably the best IDE in existence.

It's not free, although there is a 30 day evaluation or something.

A language that hasn't been designed with tools in mind is not worth using.

@Kobinator

I'd prefer a language in which I enjoy writing code.

Have you tried <a href=http://www.squeak.org/>;Squeak</a>? I have heard good things about it.

Sorry, here is a better link: <a href=http://www.squeak.org>;http://www.squeak.org<;/a> .

WTH is up with the software. Here is the text of the link: http://www.squeak.org/

Any language that thinks that programs live in files (or their moral equivalent) leads us to tools that consist of a text editor with a more or less well integrated save/compile/run toolchain attached. A large part of the sucking follows from that.

If we could get away from that model we could have much, much better tools. Squeak is a great learning environment and pretty good for development. A commercial Smalltalk (ie, VisualWorks) is even better as regards tooling for production. The commercial Common Lisp environments are fantastic, too. And for much the same reasons.

Anonymous: "Great developers build their own tools." That's a nice idea but utterly impractical, like a machinist building his own machine shop from scratch. It would take much longer than my remaining lifespan to build the tools I need to work, so I must necessarily rely on the tools of others.

Kobinator: How exactly does Java "support tools"? It looks like merely Yet Another Algol-Based Language to me. What special magic does it have to "support tools" that C doesn't?

In any case, no matter how great Java is at supporting tools, it fails because it's a poor tool itself. It's like finding the world's best drill, except it only accepts drill bits made out of paper.

Anonymous: Squeak is a great tool within its own environment. Unfortunately it falls down pretty hard when it comes to talking to the outside world. Also the comments work best if you follow the formatting guide at the bottom and don't try to use extra tags.

Keith Braithwaite: You might be right. The big problem with these Other Languages is that they have, in my experience, a tough time interacting with C in a natural way, and so a tough time integrating with the system. Maybe that means we need a clean break. But I'm pessimistic about the odds of success for that.

Ever coded Java in IntelliJ? It rocks! Best IDE I've ever used. It's commercial, but not expensive given how well it works. It really does make coding a pleasure. If only it understood Objective-C...

See my comment above as to why I find Java IDEs to be inadequate no matter how wonderful they are.

mikeash: Java enables better tools due to the fact that it has reflection and a simplified syntax. At the core, you can get directly at the AST - that's what enables any decent tool.

If you don't like Java itself, C# is another language that has reflection info. There are plenty of decent tools available there as well.

Forget about that in C++ - having an undecidable syntax makes writing parsers more like black magic than anything else. And no runtime modifications to speak of.

C++ is the Windows of programming languages. Sure, it works, and it does a lot of things, and it's widespread - but it carries around the cruft of decades and never makes a clean break.

Reflection seems to be of limited utility, for the simple fact that it won't give you anything if your code isn't complete enough to compile. Simplified syntax is fine, but Java seems to have a syntax roughly equivalent to almost every other modern language.

From my perspective, C# and Java are indistinguishable. Aside from obvious bits of syntax noise and the fact that they're created by two different evil empires, I cannot see what makes them different.

I don't know why everyone keeps bringing up C++. I don't like C++, I mostly don't use C++, and I'm certainly not talking about C++ when I bring up bad tools. C++ is not a tool which is bad despite the best efforts of the people building it, C++ is one of those cheap Wal-Mart tools that will shatter and take off your hand if you look at it wrong. And since I never mentioned it, why did you?

(Do I ever have to say anything besides 'elbow'?)



Probably since most of us suffer through C++ and are envious of the (comparatively) good tools that Java/C# offer. At least for the 'compiled languages' world.



C# has a slightly saner approach to many things. Emphasis on slightly.



It's in the small details. The easier it is to parse your language of choice, the more likely is the creation of tools for that language.

Hence the number of people who advocate storing programs in a non-text representation. If your code is stored in a parsed format, tool creation becomes much easier.

It's the whole toolbox issue - unless your parsing step is a completely separate tool, everybody is going to implement their one parser for each tool they write.

"Elbow" is all there is for now. When that no longer suffices to keep the spammers out, it'll change.

As for ease of parsing, to my mind you get easiest parsing when you let the compiler do it for you, which is really how it ought to be. Simplifying your language's syntax so that editors can parse it is, to my mind, entirely missing the point. It makes no sense to me to have two completely independent parsers on the system, one sitting in front of the compiler and one sitting in the editor. This is part of why I'm interested in clang, as it takes a modular approach which will allow the parser to be used in the editor instead of the editor having to come up with its own crappy ad-hoc parser.

The fact that everybody writes their own parsers just goes to show how crappy the state of developer tools really is. The parsers we have are so single-minded that they can't even be reused elsewhere.

Mike, it might be good if you said why you think Xcode sucks.

I don't think Xcode sucks. I used to, pre-2.0, but a whole damn lot of things were fixed for 2.0 and it's been getting better ever since. (I've worked on the IDE since Xcode 2.1.)

Java and C# are easier than C to create good tools for not because they have run-time reflection, but because they don't have a text-substitution preprocessor. With Java or C#, you can look at a fragment of program text and understand exactly what it will be in the AST, and all of the fancy refactoring, browsing, etc. tools do just that.

C and Objective-C do have a text-substitution preprocessor, so there's a layer of indirection that needs to be maintained up and down the entire process of building tools to work with them. Either that or you have to cheat and do things like build function pop-ups based on regular expressions that are only likely to match most code than guaranteed to be correct 100% of the time. (Guess what every single editor for C ever does?) This is just one example of the kinds of issues that come from working atop a language like C; there are a whole slew of things that it makes difficult.

C++ - which Mike didn't bring up, but which some commenters did - is worse than C and Objective-C when it comes to building good tools because it has not just one but two layers of processing before you get to final program text: The text-substitution preprocessor, and the Turing-complete template language! The preprocessor is an impediment that things like refactoring and indexing tools can work around, but the fact that templates are Turing-complete makes building truly great tools for C++ a series of Ph.D-level research projects.

Oh yeah, also, since you mentioned having trouble with debugging on Twitter: Use DWARF, not STABS, as your debug symbol format. It will work much, much better in most cases. That's why it's there. STABS is there too because sometimes people need to build things on current compilers and debug them on older systems. After all, everything in engineering is about trade-offs.

(Insert obligatory exhortation to file bugs at http://bugreport.apple.com/ here.)

I thought I was pretty clear about how Xcode sucks when I said, "The debugger fails all over the place, autocomplete is broken more often than it works, and the editor won't perform acceptably until you throw four Xeon cores at it."

And historically, the thing has just been full of eels. It's unintuitive, buggy, slow, and annoying. But my point is that all tools are this way, not just Xcode.

As far as filing bugs, my bug about the debugger crashing constantly is still open, but hasn't been updated by Apple since July.

I will try DWARF, but I doubt that Stabs is intended to make the thing completely unusable.

The Xcode editor drives me batty. Random scrolling, cut and paste errors, and so on. I had to use it to write a chapter of tips and tricks for 'Learn Objective-C on the Mac'. About 10-12 pages, 23 radars, *and* I had to buy and burn a DTS incident to figure out why Edit all in Scope was horribly broken.

obtw, radars: 6009823, 6086975, 6088576, 6088600, 6088612, 6088615, 6088657, 6088667, 6099292, 6099307, 6099362, 6099710, 6099742, 6100174, 6101224, 6101277, 6103758, 6104012, 6104040, 6120117, 6120169, 6121737, 6154498

Of which over half are still open.

I didn't think it was that clear. Your statement is basically "it sucks because the debugger sucks, autocomplete sucks, and the editor is slow." I live in Xcode; I used to live in it on a PowerBook G4 and it performed fine (once indexing completed). I debug all the time. I use Code Sense all the time. I work on large projects. And so do a very large number of other people, without experiencing the issues you are. Being more specific about your issues means you might be able to get more than just commiseration.

I cannot overstate how much better a debugging information format DWARF is. It's not so much that "STABS is intended to make the thing completely unusable" as "STABS is a relic of an earlier era that has never worked all that well." Did you notice how I immediately asked what debug format you were using? There's a reason... :)

I have not had - nor have I seen people have - many of the problems with the Xcode editor that either Mike or Mark are reporting. There were a huge number of changes in editing specifically for Xcode 3; it changed a lot to provide better infrastructure for the feature set developers need as well as performance. Similarly with Code Sense and project indexing.

There were bugs introduced during that process, many of them were fixed for 3.1 and some for 3.1.1, so it'll be worth using the latest possible version of the tools. In particular there was a serious but hard to reproduce performance bug found in the 3.0 editor after ship that was addressed in 3.1; maybe that's what you were running into. And indexing in 3.0 and later has to be more in-depth to support refactoring, which causes Xcode's performance to degrade on single-core machines until indexing completes; maybe that's the source of your "Xeon" comment.

Unless you're more specific, those of us who have the "Must help, must help!" gene can only guess at what you might be running into and what might fix it. Though I must thank you for actually reporting bugs; some people have problems but refuse to report them claiming bug reporter is a black hole, which is really far from the truth.

As for your "are still open" crack, Mark: Every engineering effort involves trade-offs and prioritization. You're a good engineer (as is Mike!) so you know that. :) There's always the possibility that an issue was addressed by another fix and it wasn't noticed that they were the same issue; there's also the possibility that there are more important issues that needed to be addressed.

I wasn't more specific because the point of my post did not involve being specific about how Xcode sucks. Rather it was a jumping off point for discussing how all developer tools suck in one way or another. But if you really want specificity....

The Xcode editor bogged down horribly on PPC machines with files over a couple thousand lines long. This was vastly exacerbated if the file in question was being displayed in more than one window, whether by explicitly telling Xcode to open it in a separate editor, or by having it show up in the debugger or build window editors. (If it's not obvious, I use Xcode in an extremely multi-window fashion.) The only way I have been able to avoid having the Xcode editor be slow is to aggressively control the size of my source files (a good thing to do overall, but not always possible) or to throw a Mac Pro at it. And even on the Mac Pro it gets slow sometimes.

Code completion has been driving my up the wall in the Xcode 3 series. It happens all the time where I will type a bit of code and then try to autocomplete a method name by typing "[obj someTh" and then hitting the code completion, and it only gives me global symbols starting with "someTh". To make it give me methods, I have to hit Cmd-S, then wait about five seconds, and then it will suddenly change its mind and start to complete methods instead of global symbols.

My problems with the debugger crashing, freezing, and otherwise misbehaving are recent and have only happened since I installed 3.1. (I am seriously considering going back to 3.0 if I can't find another way to fix them. I have yet to see if my latest reinstall fixed things, and I have yet to try DWARF, and will do those first.) But obvious problems like the debugger simply skipping breakpoints have been there long before. This kind of behavior is ridiculous and unacceptable. And I know it's Xcode because gdb itself behaves perfectly fine when used on its own. (Gdb sucks too, but in very different ways.)

I could go on. Suffice it to say that Xcode has a huge number of warts, strange behaviors, and outright bugs. And it's not just me. It's an article of faith in the my circle that Xcode sucks. Obviously we don't hang out in the same circles, but you should accept the possibility that perhaps it's not just my own personal Xcode-destructo field.

And please note that all of the issues I elaborate on above have existed since long before Xcode was even called Xcode. The editor has always been slow, even with Project Builder. The debugger has always failed in annoying and difficult ways. Code completion has always had various problems actually completing code. Xcode seems to get better and worse in cycles. The Xcode 1 series was a vast step backwards over Project Builder. The Xcode 2 series was a big step forward over Xcode 1. And now Xcode 3 is slowly stepping back from that.

And please don't come back to tell me about limited resources, ad hoc regex-based code parsing, or any of the rest. I'm not really interested in the details of why Xcode sucks. What I'm interested in is the overall causes behind why all developer tools suck. The fact that Apple's limited dev tools engineering resources have been devoted to this instead of that isn't really interesting in that context.

It's hardly a "crack" to talk about bugs still being open. Why do you think that all of us third-party guys think Radar is a black hole? Well, it's probably because Apple provides no evidence otherwise. If you want your dog to jump on command, you have to actually give him a treat from time to time, not just talk to him about how useful his jumping is. And if they're open because they haven't been fixed yet, then that's just further evidence that Xcode does actually suck as claimed, and that it's not just our imaginations. That there are more important things for Apple's employees to be working on is not any kind of argument for non-suck.

ok, so the "still open" was kind of snarky, but the "hey, it works for me is also kind of narrow-focused. There's lots of use cases, and apparently whatever it is I'm doing is making Xcode fall down on its face. hard. repeatedly.

I do appreciate the engineering work that goes into it, but I've also been on the silent end of the Apple bug reporter stick, and I'm really cynical about the whole thing. The FNDA didn't help either, but thankfully that's behind us.

All of my bug reports include a movie showing exactly what's happening. And now I'm re-checking a chapter for a book I'm tech-reviewing, and running into all of these problems again - pasting destroying formatting, Xcode exceptions thrown, and all with the latest and greatest (3.1.1)

So I'm gritting my teeth, checking this chapter, and then heading back to emacs, while warty, is pretty stable, and didn't cost me $195 to figure out why a major feature wasn't working.

OBTW, here's a movie of Xcode failing for me right now : http://borkware.com/hacks/XcodeFail.mov

And the backtrace mentioned, and other Xcode error messages to the console are at http://borkware.com/hacks/XcodeFail.mov

er, the error messages are at http://borkware.com/hacks/XcodeFail.txt . Sigh.

Why do you consider Java and C# bad languages to code in? Sure, Java *used* to be slow and is a little clumsy to write stuff in, but the tools more than make up for that. Equally importantly, it has a ton of libraries for useful things, both in the standard distribution and in the open-source world, and these generally play well together. And it is fully open-source now, with a number of competing JVMs and IDEs, so it's not that much of an evil empire.

C# is like a nicer Java as long as you're willing to sell your soul to Microsoft (which is not too horrible for some things, like if you're trying to reach users of Windows or Windows Mobile). Visual Studio works very well and performs well, even for coding C++. It's really one of the most impressive Microsoft products out there.

I think there is something to the fact that Microsoft, Sun, IBM, and a whole bunch of companies think that managed languages (JVM / .NET) are the way to go. It may take some time to get used to it, it may be annoying not to have all the power of C++, but the tool support that comes from sane language design and industry backing is really nice to have.

Have you heard of CodeLite? it has a bundle for Mac (interl & ppc) excellent code completion and other features for C and C++.

http://codelite.org/

Eran

eranif: Maybe it gets better once you get used to it, but my first impression of that application was utterly horrible. The first thing it smacks me with is a wizard asking where my headers are kept so it can index them; I honestly have no idea what to tell it, given that my headers are kept in several different places and which set I use depends on the project. Once I canceled that I was presented with the ugliest possible MDI project window. I could find no way to explode this stuff out into separate windows, and the unbelievable proliferation of incomprehensible toolbar icons and tabs made me decide that there was no hope to be found here.

matt: I consider Java and C# to be bad languages because, essentially, they are designed for the lowest common denominator. Their implicit design goals (never talked about, but seemingly inherent in how they work) are that they should primarily allow masses of barely-competent code monkeys to be productive without harming the overall project. Large companies want to be able to hire lots of people without going through the painful process of figuring out which ones actually know what they're doing and which ones just sound like it, and Java and C# are strict enough that the latter can make minimal gains without being too destructive.

In particular, and this is specific to Java but I think most apply to C# as well:

- Mandatory static typing means you have to cast things all over the place.

- Extreme lack of expressiveness means writing the same code over and over again. See http://c2.com/cgi/wiki?BlocksInJavaIntro for a good example of how Java lets you do interesting things, but only in very unpleasant ways.

- No macro system to get around the above problem. I don't consider a macro system to be mandatory (although in my heart of hearts I think every language should figure out how to have a Lisp-like macro system). Certainly C's macro system is ugly in many ways. But it's also extremely powerful, and it makes for a good way to work around many deficiencies of the language. For example, Objective-C before 10.5 didn't have a nice way to iterate collections, which meant writing the same for loop over and over again. Or, writing a single macro to do the ugly stuff for me, and then using that. As an example of a language which I don't think needs macros, Python is expressive enough already that it gets by fine without them.

- Poor integration with C. These languages have a very difficult time calling C APIs, especially complicated ones with return-by-reference, variable-size parameter blocks, etc. Yeah, this is unfair. So is life. Fact is that in my daily work I do a lot of work with such C APIs, and if a language can't talk to them then it's pretty useless for that daily work. (This is the primary reason why I still use Objective-C instead of a better language with a Cocoa bridge.) For situations outside of work where I don't need those APIs, why use Java when I can use something better like Python?

- These languages often don't support fun ObjC tricks, and where they do support them they make them annoying or difficult enough that it's hard to use them regularly. These are things like transparent proxies using forwardInvocation:, swapping method implementations on a class, swapping isa pointers to change the type of an object dynamically, posing, categories, etc.

I'm sure there's more, but we approach the limits of my knowledge of the language. C# in particular is not going to get me to use it no matter how many redeeming features, simply because it comes from, and is tied to, Microsoft. You mention "if you're trying to reach users of Windows or Windows Mobile", which is kind of interesting because I never have tried to do so and I never intend to. But in essense, both Java and C# are the COBOL of the modern age, designed by corporate minds for corporate uses and terribly uncomfortable for small independent guys like me. The fact that all these gigantic companies like these languages says nothing positive, and quite possibly much that's negative.

Lastly, could we please stop discussing C++? I hate C++ and would never use it as an example of anything that's good. C++ has most of the problems I ascribe to Java above, and a whole lot more besides. C++ is not a powerful language, it's merely difficult in a way that looks powerful if you don't go too deep.

I used to be a Mac fanboy until I had to use XCode. I think I don't really demand too much of a tool, but the bare minimum requirements I have for a debugger that it is able to single step.

Cmon Apple, this is completely ridiculous! To me, that's like going to a restaurant and being told to use a cheap plastic knife which breaks when you try to 'cut' something like maashed potatoes.

Please Apple, ignore every single feature of XCode and fix single stepping before you do anything else. This is so pathetic.

I could not agree more! Any feature set no matter how awesome is always going to be overshadowed by debugger problems. To me, losing valuable debugger state because the debugger interprets single-step as "run forever", or fails to hit breakpoints, or gets itself into a broken state because I tried to print the wrong ObjC object, is simply unacceptable. Xcode could have a feature which makes me coffee and sandwiches while it writes half my code and this alone would still make it suck way too hard.

Nice post. It's interesting that Chris used to use an G4 PowerBook, because Xcode 3 is totally unusable with a G4 PowerBook. I filed a bug report on editor performance a year ago (5572897); I could reliably induce beachballing for seconds while typing a method implementation, so I was able to get some nice Shark/Instruments traces. My dual G5 will occasionally beachball when I bring Xcode to the foreground (which triggers various UI updates and garbage collection), and editing still feels sluggish.

Debugging hasn't been as bad for me as you describe, but I still occasionally see all of the problems you mention, even using dwarf. A more minor example of brokenness is the disclosure triangles in the debugger's outline view; those were broken in Project Builder, and they're still broken today (it takes an indeterminate number of clicks to open and close them...sometimes 1 click, sometimes 2-3). And no, I don't care enough to spend an hour submitting a -(oneway void)bugreport.

Hi Mike, just a FYI comment: as a language, C# is actually quite more powerful, expressive and flexible than Java and I'd say it solves most if not all of your points above.

As I said, I don't want to convert you, I'm an ObjC developer myself too at the moment, I just thought you were conflating C# a bit too much with Java (which has also finally started to evolve a bit, in its most recent versions).

I'd be interested to know more about how C# can do these things. As far as I know it still has mandatory static typing, expressiveness seems better but still painful, no macro system to fix that, poor integration with C, and no easy (easy is a key point here because it can make the difference between using them all the time and simply knowing that they exist somewhere) way to do fun ObjC tricks like transparent proxies and swapping classes. Am I wrong?

I have zero love for Microsoft. Let me just get that out there. My personal projects are at the moment %100 Apple centric for many reasons. That being said I do have to occasionally work on C# and sometimes Java.
I agree with you assessment of those languages. I do believe Microsoft has made more of an effort to interoperate with C functions. In particular, they can call methods on dlls, pass around structures and even deal with callbacks. I avoid having to do so like the plague, nonetheless it is easier than Java. Java can also do some of this C interfacing through JNI. I had the distinct displeasure of doing so about 5 years ago to interface joysticks on Linux to a Java GUI *sigh*. It does work, but I am sure you will point out, its far from easy and rather painful.
I also agree with you on the general state of tools. I tend to be happy with the tools I use on the mac, but that is only because the tools I am used to working with (embedded platforms, VHDL for FPGAs, matlab, LabView) sucked my will to live.
So I guess it is all relative. Many times, I have considered printf debugging to be a high level tool. I am more used to looking at blinking LEDs and triggering on oscilloscopes. But my primitive existence is no justification for the state of tools. I do hope longingly that clang will make for a brighter future.
Thank you for you thoughtful posts.

Back in 1994 I used Visual C++ on NT.

An invisible control character in a source code file caused VC++ to crash the computer. Reproducibly.

I have been a professional personal computer programmer for nearly 3 decades. I have bult and successfully sold developer tools.

Begin Rant:

I agree wholeheartedly with the sentiment that nearly all tools suck. Certainly Apple's, which is frustrating because there is so much potential there.

Part of the problem is the timeless and immature notion among programmers that tools should be free because, well after all, a programmer can slap together anything to get the job done (this is especially endemic among Unix programmers).

I am currently attempting to use XCode 3.0 on PowerBook G4 to build a simple Carbon application in C.

It SUCKS! Oh, God, it sucks. It has literally reduced me to tears (as in tearing my hair out) and depression over the complete lack of progress in interfaces for us software developers of Mac software. But of course, Xcode was free, so I have no recourse except to jump through huge numbers of hoops in order to report bugs to its authors. Is there phone number I can call for help? No. Is there a human willing to take responsibility for the confusion their software causes a user? No. It sucks.

XCode is without a doubt the single most frustrating piece of development software I have ever used on the Mac. I hate it, I hate it, I hate it. Its interface and its complexity and its inefficiencies make me a far less productive programmer now than I was 10 years ago working with CodeWarrior on System 9. That's a disgrace.

Examples:

Single stepping in the debugger invariably points to the wrong lines of code. This worked on CodeWarrior 10 years ago, even for source code with weird macros. XCode has forced me to go back to 70s-era printf() style debugging to see state.

I wanted to see where spaces are used in a source file. So I use the editor to search and replace every space with a visible character (that was not already in the file). The source file is medium size (200K, mostly comments). Replacement of all these single-character spaces with another string of the SAME LENGTH (and no regular expression searching) literally takes 4 minutes, when it ought to occur in well-under a second on a gigahertz machine. The operation should take no longer than opening the file in the first place.

Instead, after waiting and waiting, I become so impeded in my train of thought that I want to strangle someone (actually, I went and brewed a cup of tea, by which time the replacement was done). Same happened for the inverse step to restore the code.

This kind of sluggage for the simplest operations DESTROYs programmer productivity. A computer interface that breaks its user's train of work thought is a computer interface that sucks.

XCode is trying to be Microsoft Word for Mac development. I hate it as much as my wife hates Word. And she had to pay for Word.

XCode violates any number of sound and time-honored user-interface principles. For instance, the menu system is a travesty of too much choice. There should only be one way to do something, but in XCode it seems there are always a zillion multiple ways.

I Want My Simplicity Back.

I don't care what the excuses are. If a tool in this day and age can't do the most fundamental and basic things correctly and quickly, the first time out of the box ... it SUCKS!

End Rant.

I want to suggest a couple of workarounds for these specific examples. Not that I'm trying to make excuses or anything, I just want to give some tips to a fellow sufferer in need.

For debugging, learn and love gdb. While gdb is not the best either, 90% of Xcode's debugger follies come from the Xcode GUI front-end, not the gdb back-end. Dropping down to the Xcode debugger console (or even running gdb separately) can be a great way to avoid trouble with Xcode's debugger. I realize this is going back to about 1975 in terms of user interface, but it works.

For seeing where spaces are, you can select View->Text->Show Spaces.

For speed, keep your files small. I don't know why, must be some O(n^2) algorithms or something, but Xcode absolutely hates large files. My general guideline is to keep my source files under 2000 lines, and significantly less than that where possible. I find this to be a good thing anyway, as large files are often indicative of design problems, but even if you ignore that, it will keep Xcode happy. Yeah, it should be able to deal with big files, but it can't, and if you please it then it will treat you a bit better.

For more speed, buy a new machine. I know this may not be possible, but the speed difference between Xcode on your G4 and Xcode on a new machine will be enormous. Yeah, there's no reason for Xcode to require a massive Intel processor with a ton of RAM, but let me tell you, it runs a lot better there.

Again, I don't want to sound like I'm making excuses for Xcode or anything, just give you some tips on how you can work around these specific problems.

I appreciate the tip on showing spaces, albeit buried down at the bottom of some sub-menu. It works faster than 4 minutes, so that's a superficially good thing. But my point still stands. A tactical fix is not a strategic fix.

Here's another example of plain bad design, masqueradiing as a "time-saving" shortcut. I'm not using any special editor formatting settings (that I know of, which of course is another problem of featuritus).

I've indented a long, multi-line C block comment so that the left margin of the comment block is 1 tab and 3 spaces (tabs map to four spaces). The line therefore starts with four characters: a tab and then 3 spaces. I want to get rid of the tab during editing, leaving the three spaces, so I do what every Macintosh owner for the last 25 years would do.

I place the cursor using the mouse between the tab and the first of the three spaces, where it happily and blinkingly displays its position as between two characters, and hit the DELETE key.

What happens? XCode's editor leaves the tab alone and FORWARD DELETE's not one but all three spaces, the exact thing that not only did I not want to happen, and which completely contradicts everything I have ever learned as to how editing characters of text works on the Mac. If I had wanted those 3 spaces to go away, I would have either selected them and hit DELETE, or I would have placed the cursor after the third space and hit DELETE three times. Either of these conforms with my inner model of what "is there" based on what I have typed, putting "it" there. Thankfully, both of these 3-space deletions work like they should. But of course I wanted to delete the previous tab.

Nonetheless, I did something completely proper and reasonable, but my "tool" harmed me because I have to clean up the editor's decision to do me a favor. Not only do I resent the time I have to spend on this, but this anomalous behavior Interrupts My Train Of Thought. This harms my zone of focused productivity when coding, without any benefit. Even worse, I can't fathom what the purpose of XCode's editor's decision to behave this way (sudden forward deletion contrary to all editing standards) serves. Maybe it's a bug, but I doubt it after all these years.

When a tool gets in the way of what its user wants to do (no matter how well-intentioned) it violates fundamental "toolhood". Therefore, ... it sucks!.

XCode has crashed twice on me in the last few days, each time losing maybe an hour of my work. All I was doing was scrolling the text editor display, or simply typing. This was in a plain C source file, about half of which is block comments.

Such crashes maximize the likelihood of bugs in my software. This is unacceptable in a source code (or for that matter any other) text editor. Sigh.

I see one big difference between most other tools and software development tools: how long they last.

As an example, I just bought an HP 1742A Oscilloscope. Dunno when it was built, but the most recent calibration sticker on it is from 1996. (There are a couple of stickers under that one.)

It still works just as well as the day it was made. It's technologically obsolete for working on certain types of newer equipment, but for others, and for any old equipment, it works just fine.

And here's why I think that makes a difference: If you've going to use your tools for a long time, you can afford to invest lots of money in buying / building them.

With the current state of software development, no one can afford to build really good tools. The tools won't last long enough to repay the investment.

Further, I predict this won't change until after "Moore's Observation" (I decline to call it "Moore's Law") becomes no longer true.

(It may not change even then, because we're changing the way we think about building software at a pretty fast clip also. All I'm claiming is that it won't change before then; not that it will happen at that time.)

To follow up, the manual for the HP1742A was copyright 1978. So, this tool has probably been in pretty constant use for nigh on to 30 years.

In 1978, I bought an Apple ][ (serial number 2077). Didn't even have a floppy disk drive. I gave it away sometime after 1987. It still worked but wasn't worth my time anymore.

I can't think of a single software tool from that time that I still use.

Stream of rambling consciousness...

Xcode 3.2 sucks less. Still sucks. But sucks less. Maybe someday it will rival Eclipse.

I use vi (Vim) as my editor. rather than Xcode's editor. NOTE: my fingers know 'vi' implicitly. It's too late for me, save yourselves!

I use gdb directly (Xcode calls it the debugger Console), rather than Xcode's GUI-on-top-of-gdb. Been using gdb command-line for many years. Again, too late for me, save yourselves.

emacs? Nice OS, just lacks a good editor.

Eclipse - awesome, if you are programming in Java. I do not program in Java any longer. I did, once, for a year. Good while it lasted.

@mikeash "How exactly does Java "support tools"?"

You really need to program Java using Eclipse IDE for a while. (Or IntelliJ ... I've used that too.) The Java support for tools is incredible.

Eljay: You didn't answer my question. "How do the Heisenburg Compensators work?" "Very well, thank you!" I'm asking about the mechanism by which Java support tools, and I'm pretty sure that seeing that support be incredible is not going to tell me what the mechanism is.

Just for a record as it look like this topic is dead.

http://www.jetbrains.com/idea/features/code_assistance.html

more then 5 years later and XCode still sucks, what changed ? other tools improved tremendously but XCode still suffers from crashes, weird quirks where you need to Clean + Clean build folder + close simulator, Google released TWO IDEs to develop for android but Apple still forces you to use the terrible XCode...
Updating to XCode 5 soon and hopefully it will make a big difference (I'm skeptic...)

Xcode 6.1...
It's my first IDE for something serious after I've started learning something beyond basics, I decided to learn C++ after I have some playtime with Xojo. I fell in love with this beautiful and flexible language. Variety of libraries to use, smart and really objective usage for development. But God help me! I've ducked 'xcode sucks' to read exactly what I've just experienced. I've used IntelliJ IDEA but for web, and it is the way IDE should be in many aspects. They have their new IDE for C/C++ for earlier access programm, I'm going to try it out later this week.

And I have already tried: Eclipse, Komodo, some other apps besides Xcode, even Qt Creator to find out, that they all really suck!

And I'm starting to think about simple text editor with minimum of features, but with minimum of bugs as well.

Just to top this conversation I'd mention, that Xcode 5 times notified me that char** argv is not the same type as char * argv[], then suddenly accepted it. Autocomplete continuously laid out full namespace paths: name::name::name::class in .h file, but agreed to use just class in .cpp file even though using name was typed. Sudden notifications of a file being changed externally, not mentioning veery strange linking issues. I'm still trying to figure out how did it come so that two .dylib files in the very same folder both written as paths to search and as flags to link fall apart so one is good for Xcode, the other one — is not, though they are from the same party from the same bunch of dylib's.
Qt Creator feels better with autocomplete, but it warns me about bugs (preventing the compile process) in STL.
Eclipse just crashes upon launch. And Komodo is a hell for Astigmatic people as I am.
I'm going to try out NetBeans for C/C++ only edition and JetBrains CLion EAP (I've mentioned before).

But now I know for sure how does Apple do cherish its developers.

With friends like those... You know :)

Well, I've tried out CLion RAP and NetBeans narrowed down to C++ only.
To be honest neither of them are good. CLion is still in its EAP version, and even though it is based on the same CMake as a project handler as the NetBeans you really have to be good at CMake to start with this one out.
For a beginner I found it a very non trivial task to learn how to add third party compiled libraries to a project so neither a linker nor compiler nor IDE would complain, after all those hours of frustration, real frustration with seemed to be eternal symbols lost for x86_64 architecture, unexplained stubbornness of some IDEa over other problem, it took me only two minutes to put in and get, sweet Jesus, running just a demo app for a third-party library on the NetBeans. The less expected I'VE worked out of the box with minimal changes to the project configuration.
God, people, how can the world expect perfect software when developers have pervert IDEs?
How can someone realize what a beautiful language is the C++? When it takes days to find an IDE that just works as expected?
Yes, I'm an Apple lover, I had watched every WWDC for three last years that was available online, I had heard those words how does Apple cherish its developers and then I touched the 'Best IDE for Mac' and I've got only one question left: if this one is the best, what the worst looks like?

And, Mikeash, I'd like to thank you very much for keeping this post open after those years and for the post itself, now people can watch the live history of IDE that sucks for years and still dominates as the 'Best IDE for Mac'.

In the previous comment you should read "IDE" instead of "I'VE"

And another year later, 2015, Xcode still sucks - but...

you have to, or maybe not have to, let's say should consider the complexity of what such a thing as Xcode and its tool chain does.

The highest complexity of any mechanical tool is maybe comparable to the command line option parser of clang. I mean just relax, sit back and imagine you would sit on the other side of the screen and had to do what Xcode does throughout a typical session. You will suck. Point is that the the collective of developers implementing Xcode over the decades had to try to do that often times to implement the functionality and they sucked and failed over and over again until they got that monster called Xcode to be what it is now - basically working.

It crashes, bugs don't get fixed, it's not well tested, you have to remove derived data all the time, yes, true. But then again it works.

Over the years I worked with many IDE's or toolchains, Commodore Basic, 6502 assembler, Turbo-C ST, vi/make/emacs/gcc/..., a couple of IDE's where I forgot the name, Sun, IBM, SCO, Visual Studio .NET-2015, Eclipse, JavaBeans, IDEA, what not... All of them had and have their pros and cons, most of them suck and at the same time you always get the job done. parts of the job with ease and pleasure, other parts screaming, cursing and suffering through it.

I came across Macs and Xcode very late, first version I saw was Xcode 4 when 5 was released. It improved quite a lot in that short time. When I first saw Objective-C and first sat in front of Xcode I thought: "Are they serious?" then "Really?". I moved to the mediterranean lately, so I learned quite a lot of new methods of cursing and I had an opportunity to employ these skills in all detail. But then again, after some adaption and time, I came to appreciate the tool. You actually get stuff done quite well.

Tell me which discipline is confronted with such a vast amount of complexity as ours. Its freaking hard to build a good tool for us. And its nearly impossible to build a good one for all of us.

What I really keep finding strange is that they don't fix bugs. That's a shame and really unnecessary. Other than that, I'm quite happy with our toolchain... ;-)