4 ms·

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 highlighti

• 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.
• notduncansmith 12y ago
  > I like to think of Xcode's syntax checking and highlighting as "eventually consistent". This made me laugh, but I suppose I've been spoiled by the responsiveness of text editors. Honestly I wish there were a way to turn off the error checking without losing autocomplete as well. > switching to vi for code editing while still using Xcode for the rest doesn't seem like it would be an improvement Agreed - I tried both Sublime and vi alongside Xcode, it's just as (if not more) cumbersome than Xcode alone. I wouldn't even really mind the sluggishness of Xcode if it offered the same text editing capabilities (multi-cursor support, etc) as Sublime. At least then the problem can be reduced to buying a beefier machine.
  • MichaelCrawford 12y ago
    QuickLetter from Working Software ran just fine on an 8 MHz Mac Plus with 4 MB of memory. I expect it would have been able to run, perhaps not acceptably but it would have run, with just 2 MB of memory. It had a full-featured styled text engine - fonts, tabs, margins and so on. It was built on the same CoreEdit styled text engine that MacWrite was. The very first MacWrite, I'm pretty sure ran on the 1984 Superbowl Mac - that model was later given the name "Mac 128k". The Mac 128k had a 64kB ROM and single-sided 400kB floppy disk; there was a port for an external 400kB single-sided floppy however most folks didn't have one as the drives were quite costly. Fast forward to today, and I have a 64-bit Core Quad i7 CPU, a 500 GB SSD drive, 8 GB of DDR3 memory, and all the advances that academic computer science has made in the way of algorithms but even so... it is quite uncommon that I don't regard a GUI program - open source or proprietary - as unacceptably unresponsive to my mouse or keyboard. Consider Moore's Law. I don't think he actually said that hardware doubled in speed every 18 months, rather that the transistor count per chip doubled. But loosely speaking that produces the effect of hardware getting twice as fast. It is incredibly difficult to double the transistor count on an already complex chip. How hard could it possibly be - to make your executable code run half as fast? :-/