Next article: The How and Why of Cocoa Initializers
Previous article: The iPhone Development Story
Tags: rant xcode
The title isn't wholly appropriate because I'm not going to blame my tools, per se, just complain about them a whole lot. It occurred to me that we as programmers really don't have any good tools, and this has been annoying me for some time.
Xcode sucks. If you're reading this blog then this is probably like saying "the sky is blue". You know already. Big surprise. 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.
But Xcode is hardly unique in this respect. In my experience, most programmer tools are of low quality. There's the occasional gem, like CodeWarrior or Valgrind, but for the most part they all suck, just to different degrees and in different ways.
Compare this to other professions. Take a look at any good mechanic's workshop and you will find a lot of expensive, high-quality tools. They're not shopping at Wal-Mart, they're spending a lot of cash for high-end brands (whose names I do not know, not being a mechanic). And the quality of these tools is such that they're worth every penny.
In the realm of physical tools, the word "expensive" brings up certain concepts. An expensive tool is usually solid and heavy. It lasts forever. If it cuts or drills, it treats the material with contempt, as if it were made from butter or perhaps cheese. In a contest of wills between the tool and its target, the tool always wins.
Now let's think about what "expensive" developer tools are like. In the vast majority of cases, "expensive" automatically implies "horrendous". Think about it. When was the last time you heard about somebody using a $5,000 specialty compiler and it wasn't the beginning of a story about how said compiler was a pile of monkey?
And the free stuff isn't all that great either. Of course for Mac developers there's the canonical example of Xcode, but the GNU toolchain isn't all that great either. The best thing you can really say about gcc and gdb is that they work, and they're available on a ridiculous number of platforms.
So why can't I go out and get a compiler, debugger, or IDE that's the equivalent of the Hole Hawg drill? Free or paid, doesn't matter.
I think that fundamentally it's a sign of the whole industry's immaturity. After all, software development has only been around for about sixty years. The current standard platform of C plus UNIX (Windows being just a funny sort of UNIX these days) has only existed for about half that time, and has only been the de-facto standard for perhaps ten years. Everyone is still preoccupied with the idea of making tools at all. Nobody concentrates on making a truly excellent tool because it's not clear exactly what that truly excellent tool would do, and anyway there's new languages and environments to work on.
I don't think we're without hope. The clang project looks like it might actually produce a worthy C compiler, at last, and in a form which will allow it to form the base of a worthy C editor and worthy C IDE. This is really just a baby step in the right direction, but I'm hoping it's the start of a trend.
I hope that someday it will be obvious what the gold standard in developer tools is, what all reasonable-minded professionals use, and I can just use those. Until then, I'll just muddle along, swearing and banging on keys, doing the best I can.
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.
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!)
(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.
Not looking forward to doing the iphone dev...
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.
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.
And it doesn't cost an arm and a leg!
Christopher Lloyd at 2008-10-09 04:45:49:
Hold the sharp end away from your body and work with the grain.
anon at 2008-10-09 05:55:43:
One word: Emacs.
Emacs is holding the sharp end towards your body. Yes, it's amazing the amount of leverage you can get, but the bleeding sucks.
Steven Smith at 2008-10-09 07:41:14:
Microsoft Visual Studio pretty much works all of the time and is reasonably pleasant to work with.
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.
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.
I'd prefer a language in which I enjoy writing code.
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.
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.
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.
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?
And since I never mentioned it, why did you?
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.
I cannot see what makes them different.
C# has a slightly saner approach to many things. Emphasis on slightly.
Simplified syntax is fine, but Java seems to have a syntax roughly equivalent to almost every other modern language.
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.
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.
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.)
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.
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 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.
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.
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.
And the backtrace mentioned, and other Xcode error messages to the console are at http://borkware.com/hacks/XcodeFail.mov
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.
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.
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.
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.
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 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.
An invisible control character in a source code file caused VC++ to crash the computer. Reproducibly.
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.
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!
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.
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!.
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.
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.)
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.
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.
Comments RSS feed for this page
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.