3 ms·

I have long had the impression, that those who dislike IDEs only really know products such as Visual Studio or Eclipse, rather than Metrowerks CodeWarrior or Th

I have long had the impression, that those who dislike IDEs only really know products such as Visual Studio or Eclipse, rather than Metrowerks CodeWarrior or ThinkC. The simple fact that a tool is an IDE doesn't make it good or bad. I have long preferred IDEs for development on Apple platforms but lately I am working towards moving my iOS development to makefiles with Vim and TextWrangler because Apple's Xcode IDE is so profoundly poorly designed and implemented. I'd love to have codewarrior for iOS development but they no longer support Apple platforms.

quesera 12y ago
> Xcode IDE is so profoundly poorly designed and implemented. That's some strong criticism. I loved Lightspeed/THINK C and Metrowerks CodeWarrior. I also have a generally positive opinion of Xcode (which might be even higher if I was remembering it from 20+ years' distance, instead of dealing with version-version inconsistencies and incremental bits). It's unfortunate that having a good, free, first-party compiler inevitably sucks the oxygen out of any competitive market. But there were some lean years in the Mac compiler world, and I'd never want to go back to that. That said, I use vi for everything else, including lots of non-Cocoa code. I would be completely happy to do Cocoa dev in vi also, if it could be as functional as Xcode. I'm very interested to hear more about your retooling experiences!
- notduncansmith 12y ago
  Xcode is a decent tool for new programmers. Also, features like Cmd+Click (go to definition) can be a huge boon when dealing with an unfamiliar codebase. That said, for anyone used to using "text editors" (Sublime, Vim, Emacs, etc) it is sorely lacking. I'm not afraid to say that text editing in Xcode is barely more tolerable than a standard web textarea in that respect. It's sluggish, prone to crashing (or losing syntax highlighting), and often displays errors in the middle of typing an expression (which linger for a bit until the inline parsing catches up with the entered text, a process that may take several seconds). This, coupled with the limited text-editing ability, make it very painful to use coming from a text editor. In my personal opinion, the worst part of the iOS development experience is the fact that one is forced to use Xcode to get any clear preview what the app will look like, or to set up connections between a view and the viewcontroller code. One can of course lay out views programmatically, but that process is hilarious verbose and the slow build times make the workflow infinitely more painful than say, HTML+CSS (where one can get sub-second feedback on code changes). This makes any sort of visual/UX work on iOS incredibly painful. P.S. If anyone has any tips on how to mitigate either of these pain points, I'd greatly appreciate it! I fully admit that I'm not an expert and may be overlooking some critical feature that would erase these pains.
  - quesera 12y ago
    I agree completely with your criticisms of Xcode, but I don't find those problems all that bothersome. I like to think of Xcode's syntax checking and highlighting as "eventually consistent". The text navigation aspect does foul me up at times. There's an Xcode plugin for vi-style navigation, which I've used and removed several times. It's OK but incomplete, of course. Xcode as a package includes IB and the debugger and profiler, etc. I'm not convinced they need to be so conjoined, but switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement over the current workflow. Xcode does a much harder job than an editor plus a web browser. I do miss the round trip efficiency sometimes.
    - MichaelCrawford 12y ago
      Interface Builder was a standalone application for quite a long time. I don't clearly remember when it became built-in but I think it was around the time of Xcode 5, but it may have been Xcode 4. It would be easy to find out by reading the release notes; Apple has the notes for each release on its developer site. I liked Interface Builder quite a lot more when it was a standalone application. In general, I like a lot of things a lot more when they are separate programs. A gripe I have about Xcode is that I don't readily see a way to have text editing-only windows, and then some other window where I have the project settings. That's how CodeWarrior worked. While Xcode does strictly speaking permit you to open separate text windows, it doesn't really work when you do that. Finally, Apple has never documented any way to add plugins to Xcode. I expect one could reverse-engineer it however that method would not be supported by Apple, and so likely would break in new releases. There is quite a lot of Classic Mac OS code written in Pascal. I see no reason whatsoever that that Pascal couldn't be ported into OS X. There are lots of people who do just that - but they don't do it with Xcode. Even Apple has tons of Pascal code. Pascal code that would be useful on OS X, that would save Apple a lot of money, make life easy for everyone, increase AAPL shareholder value, but no, Steve Jobs for some reason didn't want Pascal on OS X. I really don't have a clue as to why. Consider that while in principle C strings can be of arbitrary length, it is uncommon for them to be very long. To find the length of a C string you have to count all the characters until you find the NUL terminator. To find the length of a Pascal string you just look at the first byte. While that limits the length to 255 characters, that's completely cool with the vast majority of uses of strings of any sort. If you wanted a string-like object of arbitrary length you could define some other type such as a BigString that had a size_t then a character array with no terminator. I don't really know but assertively conjecture that nothing other than converting all your C strings to Pascal strings would make your C/C++/Objective-C programs significantly faster, possibly smaller as well. Consider that strlen takes up the space of pushing the string pointer than calling the function, whereas finding the length of a Pascal string only involves addressing the first byte of an array.
- MichaelCrawford 12y ago
  My gripe about Xcode is how hard it can be to find the settings I need to adjust. Suppose you're using Xcode for the very first time and you have an obvious heap corruption. I advise you to enable guard malloc. How do you enable it? Whenever I have to adjust some build or runtime setting in Xcode, I have to spend quite a lot of time, sometimes well over an hour looking for it, as the UI of Xcode changes so frequently. Google is no help, I would google for say "Xcode 6 guard malloc" and Google displays a bunch of pages that discuss Xcode 6 but not Xcode 4. In CodeWarrior it's easy to find settings. Though it has a lot of settings there is a deterministic process for locating them.
marssaxman 12y ago
I have fond memories of CodeWarrior, but have never really liked Xcode. It has approached calm once or twice but then Apple has gone and messed with it again, and they have no tolerance for people who want to support their more recent operating systems without necessarily adopting their more recent UI changes.

quesera 12y ago

> Xcode IDE is so profoundly poorly designed and implemented. That's some strong criticism. I loved Lightspeed/THINK C and Metrowerks CodeWarrior. I also have a generally positive opinion of Xcode (which might be even higher if I was remembering it from 20+ years' distance, instead of dealing with version-version inconsistencies and incremental bits). It's unfortunate that having a good, free, first-party compiler inevitably sucks the oxygen out of any competitive market. But there were some lean years in the Mac compiler world, and I'd never want to go back to that. That said, I use vi for everything else, including lots of non-Cocoa code. I would be completely happy to do Cocoa dev in vi also, if it could be as functional as Xcode. I'm very interested to hear more about your retooling experiences!

notduncansmith 12y ago
Xcode is a decent tool for new programmers. Also, features like Cmd+Click (go to definition) can be a huge boon when dealing with an unfamiliar codebase. That said, for anyone used to using "text editors" (Sublime, Vim, Emacs, etc) it is sorely lacking. I'm not afraid to say that text editing in Xcode is barely more tolerable than a standard web textarea in that respect. It's sluggish, prone to crashing (or losing syntax highlighting), and often displays errors in the middle of typing an expression (which linger for a bit until the inline parsing catches up with the entered text, a process that may take several seconds). This, coupled with the limited text-editing ability, make it very painful to use coming from a text editor. In my personal opinion, the worst part of the iOS development experience is the fact that one is forced to use Xcode to get any clear preview what the app will look like, or to set up connections between a view and the viewcontroller code. One can of course lay out views programmatically, but that process is hilarious verbose and the slow build times make the workflow infinitely more painful than say, HTML+CSS (where one can get sub-second feedback on code changes). This makes any sort of visual/UX work on iOS incredibly painful. P.S. If anyone has any tips on how to mitigate either of these pain points, I'd greatly appreciate it! I fully admit that I'm not an expert and may be overlooking some critical feature that would erase these pains.
- quesera 12y ago
  I agree completely with your criticisms of Xcode, but I don't find those problems all that bothersome. I like to think of Xcode's syntax checking and highlighting as "eventually consistent". The text navigation aspect does foul me up at times. There's an Xcode plugin for vi-style navigation, which I've used and removed several times. It's OK but incomplete, of course. Xcode as a package includes IB and the debugger and profiler, etc. I'm not convinced they need to be so conjoined, but switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement over the current workflow. Xcode does a much harder job than an editor plus a web browser. I do miss the round trip efficiency sometimes.
  - MichaelCrawford 12y ago
    Interface Builder was a standalone application for quite a long time. I don't clearly remember when it became built-in but I think it was around the time of Xcode 5, but it may have been Xcode 4. It would be easy to find out by reading the release notes; Apple has the notes for each release on its developer site. I liked Interface Builder quite a lot more when it was a standalone application. In general, I like a lot of things a lot more when they are separate programs. A gripe I have about Xcode is that I don't readily see a way to have text editing-only windows, and then some other window where I have the project settings. That's how CodeWarrior worked. While Xcode does strictly speaking permit you to open separate text windows, it doesn't really work when you do that. Finally, Apple has never documented any way to add plugins to Xcode. I expect one could reverse-engineer it however that method would not be supported by Apple, and so likely would break in new releases. There is quite a lot of Classic Mac OS code written in Pascal. I see no reason whatsoever that that Pascal couldn't be ported into OS X. There are lots of people who do just that - but they don't do it with Xcode. Even Apple has tons of Pascal code. Pascal code that would be useful on OS X, that would save Apple a lot of money, make life easy for everyone, increase AAPL shareholder value, but no, Steve Jobs for some reason didn't want Pascal on OS X. I really don't have a clue as to why. Consider that while in principle C strings can be of arbitrary length, it is uncommon for them to be very long. To find the length of a C string you have to count all the characters until you find the NUL terminator. To find the length of a Pascal string you just look at the first byte. While that limits the length to 255 characters, that's completely cool with the vast majority of uses of strings of any sort. If you wanted a string-like object of arbitrary length you could define some other type such as a BigString that had a size_t then a character array with no terminator. I don't really know but assertively conjecture that nothing other than converting all your C strings to Pascal strings would make your C/C++/Objective-C programs significantly faster, possibly smaller as well. Consider that strlen takes up the space of pushing the string pointer than calling the function, whereas finding the length of a Pascal string only involves addressing the first byte of an array.
MichaelCrawford 12y ago
My gripe about Xcode is how hard it can be to find the settings I need to adjust. Suppose you're using Xcode for the very first time and you have an obvious heap corruption. I advise you to enable guard malloc. How do you enable it? Whenever I have to adjust some build or runtime setting in Xcode, I have to spend quite a lot of time, sometimes well over an hour looking for it, as the UI of Xcode changes so frequently. Google is no help, I would google for say "Xcode 6 guard malloc" and Google displays a bunch of pages that discuss Xcode 6 but not Xcode 4. In CodeWarrior it's easy to find settings. Though it has a lot of settings there is a deterministic process for locating them.

marssaxman 12y ago

I have fond memories of CodeWarrior, but have never really liked Xcode. It has approached calm once or twice but then Apple has gone and messed with it again, and they have no tolerance for people who want to support their more recent operating systems without necessarily adopting their more recent UI changes.