4 ms·

The Unfamiliar (Objective-C & Cocoa)

35 points by donmcc 15y ago

VengefulCynic 15y ago
I'm largely in agreement with Gruber insofar as development environments are largely a matter of taste. On the other hand, I'm rather surprised that Gruber is looking to defend reference counting, especially in light of how well it went for legacy programming languages like VB Classic. John Siracusa is by far the more well-reasoned Apple advocate in terms of programming language design and his Copland 2010 articles are definitely worth checking out if you want to read a cogent argument as to why Cocoa is NOT the way of the future. http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis...
- wmobit 15y ago
  Note the 'Automatic' qualifier on reference counting
- pohl 15y ago
  On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were revealed at WWDC this year, because "reference counting" and "automated reference counting" are not the same things. The latter is in the spirit of the last few paragraphs by Linus Torvalds in his famous 2002 discussion of Garbage Collection, when he says Does it take more effort? Yes. The advantage of GC is that it is automatic. But CG apologists should just admit that it causes bad problems and often _encourages_ people to write code that performs badly. I really think it's the mindset that is the biggest problem. A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. http://news.ycombinator.com/item?id=2473932 http://news.ycombinator.com/item?id=2473932 ...except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part. http://clang.llvm.org/docs/AutomaticReferenceCounting.html http://clang.llvm.org/docs/AutomaticReferenceCounting.html Since you're a Siracusa fan... http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11 http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...
  - smikhanov 15y ago
    except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.
    - pohl 15y ago
      ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.
- quux 15y ago
  I don't think he was defending reference counting as much as trying to explain that garbage collection is probably never going to work satisfactorily with an unmanaged language like Objective-C. Automatic Reference Counting is probably as good as we're going to get without a managed version of Objective-C.
  - nknight 15y ago
    This distinction between "reference counting" and "garbage collection" is either an Apple or Gruber invention. I've never heard anyone try to distinguish cleanly between the two before. Use of (automatic) reference counting is not new (see, for obvious example, Python), and is certainly being used as a form of garbage collection. There are many forms/strategies of garbage collection, reference counting is one of them. Trying to argue that we're never going to have "garbage collection" on iOS is utterly bizarre -- it's being added in iOS 5! It's just taking a different form.
    - schrototo 15y ago
      Well, I think the generally agreed upon meaning of "garbage collection" is something along the lines of "automatic memory management at runtime" (garbage piles up and gets collected) while "automatic reference counting" is "automatic memory management at compile time" (there's nothing to collect since nothing's gonna build up). All those terms sometimes get used differently in different contexts sometimes, but I think that's what's usually meant by them.
      - nknight 15y ago
        You're describing the difference between deterministic and non-deterministic garbage collection, not between garbage collection and some other concept. Even non-deterministic tracing garbage collectors may make use of reference counting. Some interesting references: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc... http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concu... http://www.google.com/search?q=garbage%20collection%20reference%20counting http://www.google.com/search?q=garbage%20collection%20refere...
- donmcc 15y ago
  I think Gruber would elaborate by mentioning that garbage collection has a real and measurable cost in terms of performance and Apple would rather have a development environment that allows devs to produce the smoothest UI performance over one like Java or C# that is novice friendly but harder to get the highest level of performance out of. Personally I really enjoy working in Objective-C and Cocoa/Cocoa Touch. I think they both hit sweet spots in language/framework design and give you just enough high level abstractions to make developing easier without getting in the way. But then again, I program in C for fun :-)
- davedx 15y ago
  You're surprised that Gruber is defending Apple?
- msbarnett 15y ago
  ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring things are destroyed as soon as they are no longer referenced. It's garbage collection without any of the nasty downsides. And Siracusa has been trotting out his pet theory about Objective-C/Cocoa being a dead end for years now. All of the articles he's written on the subject have made it clear that a) he has essentially no experience with the subject he is trying to discuss, and b) he's really, really bad at predicting the future of Apple's development landscape. Since his first article calling Objective-C/Cocoa a dying platform, we've witnessed the introduction of an entirely new platform based on them (iOS), an enormous surge in usage and demand for Objective-C talent, and massive overhauls in the language (Objective-C 2.0) and memory model (first a conservative garbage collector, and now ARC). Siracusa has been out to lunch on the subject for years.
  - chc 15y ago
    It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.
    - strmpnk 15y ago
      I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
      - chc 15y ago
        With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."
potatolicious 15y ago
Java might've had a lot of FOSS love put into, but the Android toolset... Well, let's just say that I would be a very, very happy man if the Android emulator could run even 50% as fast as the iOS Simulator.
- davedx 15y ago
  Use an actual device. You don't develop for Xbox 360's or PS3's in an emulator, why would you for mobiles?
  - rbritton 15y ago
    Because it's much, much easier and quicker to run most builds in the simulator, especially when you're not dealing with something that has a tricky performance point to balance. At least with the iOS simulator, it makes debugging low memory warnings and secondary screens much easier as well.
  - daeken 15y ago
    Depends on what you're developing. Frequently you develop in parallel for the desktop and your console of choice, when you're doing non-performance-intensive stuff. This is especially true of XNA and the like, where your code is identical.
    - davedx 15y ago
      What I mean is you don't compile and run it on your PC, then run it in a PS3 emulator. You run it on a PS3 dev machine.
  - linc01n 15y ago
    iPhone, Xbox, PS3 are platforms do not have much hardware difference device. But Android supported tons of devices, without a nice emulator sometime you dun know is it your phone(if you test on real device) causing problems or your code.
    - 15y ago
hockeybias 15y ago
Why would we expect anything less than this sort of chatter from Gruber? He can quibble a bit with the author, but there is no hiding the fact that Objective C is a (well done) antique language and that XCode is not horrible, but a far cry from Visual Studio when it comes to ease of use.
deleted 15y ago
[deleted]
kennywinker 15y ago
It's all about the unfamiliar. I've spend countless hours in Xcode, and firing up Eclipse is a nightmare. Same with switching from Xcode 3 to Xcode 4... the unfamiliar seems "wrong" Until you get beyond the unfamiliarity, you're not qualified to judge if it's wrong or right. (That said, the 2 hours I've spent in Visual Studio was remarkably pleasant, considering)
- rheide 15y ago
  I've written 2 iPhone apps in Xcode and am now working on my second Android app in Eclipse. Words cannot describe how much I prefer Eclipse over Xcode. I should note that my background is Java. There's just something about Xcode that I cannot get used to, even after writing 2 apps in it.
mhd 15y ago
I like the Cocoa API and can cope with a C-based language, but I'd have to agree that Visual Studio and Eclipse offer more IDE features for their respective environments. Having said that, they all have pretty crappy editors.
zbowling 15y ago
I agree with Gruber here, which may times I do not. In this case the original article is way off base and he did a good job at pointing it out. In any case though, I don't look up to Gruber as some great technical expert as an engineer though.
mpk 15y ago
I recently started coding Obj-C in XCode and was very surprised that it's far less polished than what you expect from an Apple experience. That is mostly because an Apple experience is consumer-facing and much more time goes into making that a better experience. XCode feels like a GUI for GCC, which it is. It's a whole pile of flags that you can set, tweak, etc. If you don't have some GCC experience, this is a bit of a hurdle. Project settings sometimes break (especially around code-signing), so keep your text editor handy. When things break the error messages can be cryptic and there's usually no 'double-click to get to the error in the IDE'. Obj-C is obviously C, but it's also obviously not and also not syntactically similar to, say, C# or Java (or Ruby, JavaScript, Python, etc). I found the step to Obj-C to be fairly trivial, but I thank time spent with C, GCC and Makefiles for that. After this it's mostly the same as anything else - which is diving into massive amounts of APIs and best-practices. iphoneos-simulator is brilliant. Much, much better to work with than Android simulators (mostly because of the insanely faster startup time and the ability to change hardware on the fly). Another brilliant piece to find was Instruments, which is an Apple GUI for DTrace. Profiling and tracing execution on simulators and devices is a breeze. I think memory management is a bit of a non-issue and I'm surprised that's even being brought up. That many programmers only know one language / IDE and judge everything else as inferior/bad/etc is a reasonable observation (if not a totally obvious one), but that's not going to change anytime soon. TL;DR - XCode has warts - Obj-C is different than Java/C# - Errors can be a pain - iphoneos-simulator is brilliant - Instruments is fantastic - Easy to pick up if you're familiar with GCC
- kposehn 15y ago
  In response to your TL;DR :) - XCode has warts: Yes, it does. Still, it is phenomenally better than other environments for efficiency now and is truly a joy to use. And we have few, if any, crashes. - Obj-C is different than Java/C#: If you're familiar with one language, I can understand disliking that. I went from Java -> C# -> PHP -> Ruby -> Objective-C. That is quite a change! But still, I absolutely love Objective-C. It has everything I could ask for, including my favorite syntax ever created. Nothing is ambiguous to me and our team is able to crank from concept to MVP faster than any other platform by far. Better yet, the speed we can squeeze out of our code blows all other platforms away. - Errors can be a pain: they can be. We ended up setting a standard syntax for logging actions so we could quickly drill down to errors. Wish it was easier and they can definitely improve here. - iphoneos-simulator is brilliant: completely agreed. - Instruments is fantastic: damn skippy. - Easy to pick up if you're familiar with GCC: true.
mosburger 15y ago
> The enormousness of the developer base for Windows and Java is such that many developers feel that those environments are “normal”, and anything different is by nature inferior simply because it’s unfamiliar. They’re offended by Xcode/Cocoa/Objective-C, in some way, because they feel entitled to their familiar languages and tools. Gah - I was with you through the article, maybe not agreeing with everything he said, but did he have to come off like such a jerk in the last sentence? You're painting with pretty broad strokes to call people who aren't very enamored w/ XCode "offended" and "entitled."
- mattgreenrocks 15y ago
  Yeah, but since when did intellectual honesty ever bring visitors in? The bigger the paintbrush, the more people flock to agree/disagree on it, it seems.
- wtallis 15y ago
  Gruber did say many, not all. And when comments like this [http://news.ycombinator.com/item?id=3015433 http://news.ycombinator.com/item?id=3015433] are so common in discussions about Apple's development environment, it's hard to argue that people who feel offended and entitled are uncommon.
jklp 15y ago
> [...] when you fire up Apple’s Xcode and start building CocoaTouch applications in Objective-C you’re going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years I think I'd have to agree with this statement. As someone who's recently started developing in Objective C and coming from a Java / Eclipse background, the toolset provided in Xcode seems to fall short of what Eclipse has to offer (I can't speak for Visual studio). For instance I don't think Xcode does proper static analysis. I.e. it doesn't allow me to produce a proper class hierarchy for a class I'm using, nor can I run a command to see a call hierarchy on a method. And refactoring isn't 100% accurate either, and also very limited, i.e. I can't extract methods from a code fragment, and also once extracted, move that method into another class without issue (typical workflow for extracting helper methods). It's not to say I can't do good work in Xcode. I just have to be aware of it's limitations and keep accurate documentation as I code, instead of relying on the IDE for a lot of the heavy lifting.
deleted 15y ago
[deleted]
JimDabell 15y ago
I can't agree here. Yes, there are a lot of people who turn their nose up at the OS X/iOS development toolchain simply because it is unfamiliar. They see the square brackets and write it off immediately. But the argument that the toolchain is not polished is dead on. If you look at the work Apple are doing under the hood with LLVM etc., then yes, they are doing some very smart things. But everything on top of that is pretty damn dismal. Xcode is incredibly buggy. iTunes Connect is hell. There is functionality that is just plain wrong. There are features that are inexplicably missing. Version control integration is so poor everybody I know uses external tools instead. Code-signing is held together with bits of string. Functional regressions from earlier versions mystify me. Xcode build configuration is so much of a hassle that it's easier to avoid it altogether by putting everything into xcconfigs. The code quality in the templates is awful. If this kind of quality were foisted on end-users, there would be uproar. It's the opposite of Apple's "just works" philosophy. It seems the application-level dev tools team is where they stick all the students and new hires who don't know what they are doing. I think the fundamental design of Objective C is a little old in places but has held up remarkably well over the years. Cocoa has a fantastic design. But christ, the development tools at the application level are a fucking embarrassment.
jcizzle 15y ago
What is interesting to me is that I could replace "Objective-C" with "liberal" and "Java" with "conservative"; or "Eclipse" with "Democrat" and "Xcode" with "Republican" - and this article and all articles like it will fly just fine on CNN, Fox News, etc. It is amazing how predictable humans are, and how far people will go to exploit that predictability: 1. Draw line in sand. 2. Throw rocks at both sides. 3. Profit.
scottdw2 15y ago
GC is inevitable, but so is no GC. In the 80s people wanted to write software on platforms where GC was not practical. Having a GC when you have 640 K of ram is silly. So people used languages that didn't have GC. But then the platforms grew exponentionally, and people started wanting to do more complex things, and they say "all this manual memory management is crazy... lets use GC", just like the previous generation of computer scientists did before them. Then the iPhone came out... ARC isn't a revolution, it's just a stage in a cycle.... In 10 years your 20 core smartphone will have a GC running in it.
- wtallis 15y ago
  "In 10 years your 20 core smartphone will have a GC running in it." Quite possibly. But it's also quite conceivable that Objective-C will still be in use by then, and still not have the what a Java programmer would think of as garbage collection. When iPhone hardware is ready for it, we'll probably see Python or MacRuby or JavaScript become the most common way of interacting with a Cocoa system that is still implemented in Objective-C.
shaggyfrog 15y ago
Focusing just on Xcode for a second, the spirit of the rant is not totally off the mark. The latest version 4, has been, on the whole, a step back. If you were used to Xcode 3, suddenly a lot of functionality is no longer there, or moved, or replaced, or hidden away in a deep recess. To make things worse, a lot of documentation is now hilariously out of date. For example, just about any Core Data guide/sample code/tutorial is not applicable to the brave new world of Xcode 4 (or iOS 4 or OS X 10.7). And there's no indication that any of them will be updated anytime soon -- I speak mostly of Apple's own docs. In other words, there's a lot of pain, currently, surrounding the de facto tool for iOS development, even for seasoned Cocoa programmers. It's too bad the original story (the one Gruber's responding to) got so off track talking about other nonsense (reference counting?! Does that objectively really matter?) when there are so many real problems that actually exist with iOS development. Thankfully, these problems aren't necessarily permanent -- just as long as Xcode 4 continues to get refined/fixed, and documentation is brought up-to-date (i.e. no more Core Data how-to videos that use Xcode 3 on OS X 10.4!).

35 points by donmcc 15y ago

I'm largely in agreement with Gruber insofar as development environments are largely a matter of taste. On the other hand, I'm rather surprised that Gruber is looking to defend reference counting, especially in light of how well it went for legacy programming languages like VB Classic. John Siracusa is by far the more well-reasoned Apple advocate in terms of programming language design and his Copland 2010 articles are definitely worth checking out if you want to read a cogent argument as to why Cocoa is NOT the way of the future. http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis...

wmobit 15y ago
Note the 'Automatic' qualifier on reference counting
pohl 15y ago
On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were revealed at WWDC this year, because "reference counting" and "automated reference counting" are not the same things. The latter is in the spirit of the last few paragraphs by Linus Torvalds in his famous 2002 discussion of Garbage Collection, when he says Does it take more effort? Yes. The advantage of GC is that it is automatic. But CG apologists should just admit that it causes bad problems and often _encourages_ people to write code that performs badly. I really think it's the mindset that is the biggest problem. A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. http://news.ycombinator.com/item?id=2473932 http://news.ycombinator.com/item?id=2473932 ...except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part. http://clang.llvm.org/docs/AutomaticReferenceCounting.html http://clang.llvm.org/docs/AutomaticReferenceCounting.html Since you're a Siracusa fan... http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11 http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...
- smikhanov 15y ago
  except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.
  - pohl 15y ago
    ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.
quux 15y ago
I don't think he was defending reference counting as much as trying to explain that garbage collection is probably never going to work satisfactorily with an unmanaged language like Objective-C. Automatic Reference Counting is probably as good as we're going to get without a managed version of Objective-C.
- nknight 15y ago
  This distinction between "reference counting" and "garbage collection" is either an Apple or Gruber invention. I've never heard anyone try to distinguish cleanly between the two before. Use of (automatic) reference counting is not new (see, for obvious example, Python), and is certainly being used as a form of garbage collection. There are many forms/strategies of garbage collection, reference counting is one of them. Trying to argue that we're never going to have "garbage collection" on iOS is utterly bizarre -- it's being added in iOS 5! It's just taking a different form.
  - schrototo 15y ago
    Well, I think the generally agreed upon meaning of "garbage collection" is something along the lines of "automatic memory management at runtime" (garbage piles up and gets collected) while "automatic reference counting" is "automatic memory management at compile time" (there's nothing to collect since nothing's gonna build up). All those terms sometimes get used differently in different contexts sometimes, but I think that's what's usually meant by them.
    - nknight 15y ago
      You're describing the difference between deterministic and non-deterministic garbage collection, not between garbage collection and some other concept. Even non-deterministic tracing garbage collectors may make use of reference counting. Some interesting references: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc... http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concu... http://www.google.com/search?q=garbage%20collection%20reference%20counting http://www.google.com/search?q=garbage%20collection%20refere...
donmcc 15y ago
I think Gruber would elaborate by mentioning that garbage collection has a real and measurable cost in terms of performance and Apple would rather have a development environment that allows devs to produce the smoothest UI performance over one like Java or C# that is novice friendly but harder to get the highest level of performance out of. Personally I really enjoy working in Objective-C and Cocoa/Cocoa Touch. I think they both hit sweet spots in language/framework design and give you just enough high level abstractions to make developing easier without getting in the way. But then again, I program in C for fun :-)
davedx 15y ago
You're surprised that Gruber is defending Apple?
msbarnett 15y ago
ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring things are destroyed as soon as they are no longer referenced. It's garbage collection without any of the nasty downsides. And Siracusa has been trotting out his pet theory about Objective-C/Cocoa being a dead end for years now. All of the articles he's written on the subject have made it clear that a) he has essentially no experience with the subject he is trying to discuss, and b) he's really, really bad at predicting the future of Apple's development landscape. Since his first article calling Objective-C/Cocoa a dying platform, we've witnessed the introduction of an entirely new platform based on them (iOS), an enormous surge in usage and demand for Objective-C talent, and massive overhauls in the language (Objective-C 2.0) and memory model (first a conservative garbage collector, and now ARC). Siracusa has been out to lunch on the subject for years.
- chc 15y ago
  It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.
  - strmpnk 15y ago
    I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
    - chc 15y ago
      With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."

potatolicious 15y ago

Java might've had a lot of FOSS love put into, but the Android toolset... Well, let's just say that I would be a very, very happy man if the Android emulator could run even 50% as fast as the iOS Simulator.

davedx 15y ago
Use an actual device. You don't develop for Xbox 360's or PS3's in an emulator, why would you for mobiles?
- rbritton 15y ago
  Because it's much, much easier and quicker to run most builds in the simulator, especially when you're not dealing with something that has a tricky performance point to balance. At least with the iOS simulator, it makes debugging low memory warnings and secondary screens much easier as well.
- daeken 15y ago
  Depends on what you're developing. Frequently you develop in parallel for the desktop and your console of choice, when you're doing non-performance-intensive stuff. This is especially true of XNA and the like, where your code is identical.
  - davedx 15y ago
    What I mean is you don't compile and run it on your PC, then run it in a PS3 emulator. You run it on a PS3 dev machine.
- linc01n 15y ago
  iPhone, Xbox, PS3 are platforms do not have much hardware difference device. But Android supported tons of devices, without a nice emulator sometime you dun know is it your phone(if you test on real device) causing problems or your code.
  - 15y ago

hockeybias 15y ago

Why would we expect anything less than this sort of chatter from Gruber? He can quibble a bit with the author, but there is no hiding the fact that Objective C is a (well done) antique language and that XCode is not horrible, but a far cry from Visual Studio when it comes to ease of use.

deleted 15y ago

[deleted]

kennywinker 15y ago

It's all about the unfamiliar. I've spend countless hours in Xcode, and firing up Eclipse is a nightmare. Same with switching from Xcode 3 to Xcode 4... the unfamiliar seems "wrong" Until you get beyond the unfamiliarity, you're not qualified to judge if it's wrong or right. (That said, the 2 hours I've spent in Visual Studio was remarkably pleasant, considering)

rheide 15y ago
I've written 2 iPhone apps in Xcode and am now working on my second Android app in Eclipse. Words cannot describe how much I prefer Eclipse over Xcode. I should note that my background is Java. There's just something about Xcode that I cannot get used to, even after writing 2 apps in it.

mhd 15y ago

I like the Cocoa API and can cope with a C-based language, but I'd have to agree that Visual Studio and Eclipse offer more IDE features for their respective environments. Having said that, they all have pretty crappy editors.

zbowling 15y ago

I agree with Gruber here, which may times I do not. In this case the original article is way off base and he did a good job at pointing it out. In any case though, I don't look up to Gruber as some great technical expert as an engineer though.

mpk 15y ago

I recently started coding Obj-C in XCode and was very surprised that it's far less polished than what you expect from an Apple experience. That is mostly because an Apple experience is consumer-facing and much more time goes into making that a better experience. XCode feels like a GUI for GCC, which it is. It's a whole pile of flags that you can set, tweak, etc. If you don't have some GCC experience, this is a bit of a hurdle. Project settings sometimes break (especially around code-signing), so keep your text editor handy. When things break the error messages can be cryptic and there's usually no 'double-click to get to the error in the IDE'. Obj-C is obviously C, but it's also obviously not and also not syntactically similar to, say, C# or Java (or Ruby, JavaScript, Python, etc). I found the step to Obj-C to be fairly trivial, but I thank time spent with C, GCC and Makefiles for that. After this it's mostly the same as anything else - which is diving into massive amounts of APIs and best-practices. iphoneos-simulator is brilliant. Much, much better to work with than Android simulators (mostly because of the insanely faster startup time and the ability to change hardware on the fly). Another brilliant piece to find was Instruments, which is an Apple GUI for DTrace. Profiling and tracing execution on simulators and devices is a breeze. I think memory management is a bit of a non-issue and I'm surprised that's even being brought up. That many programmers only know one language / IDE and judge everything else as inferior/bad/etc is a reasonable observation (if not a totally obvious one), but that's not going to change anytime soon. TL;DR - XCode has warts - Obj-C is different than Java/C# - Errors can be a pain - iphoneos-simulator is brilliant - Instruments is fantastic - Easy to pick up if you're familiar with GCC

kposehn 15y ago
In response to your TL;DR :) - XCode has warts: Yes, it does. Still, it is phenomenally better than other environments for efficiency now and is truly a joy to use. And we have few, if any, crashes. - Obj-C is different than Java/C#: If you're familiar with one language, I can understand disliking that. I went from Java -> C# -> PHP -> Ruby -> Objective-C. That is quite a change! But still, I absolutely love Objective-C. It has everything I could ask for, including my favorite syntax ever created. Nothing is ambiguous to me and our team is able to crank from concept to MVP faster than any other platform by far. Better yet, the speed we can squeeze out of our code blows all other platforms away. - Errors can be a pain: they can be. We ended up setting a standard syntax for logging actions so we could quickly drill down to errors. Wish it was easier and they can definitely improve here. - iphoneos-simulator is brilliant: completely agreed. - Instruments is fantastic: damn skippy. - Easy to pick up if you're familiar with GCC: true.

mosburger 15y ago

> The enormousness of the developer base for Windows and Java is such that many developers feel that those environments are “normal”, and anything different is by nature inferior simply because it’s unfamiliar. They’re offended by Xcode/Cocoa/Objective-C, in some way, because they feel entitled to their familiar languages and tools. Gah - I was with you through the article, maybe not agreeing with everything he said, but did he have to come off like such a jerk in the last sentence? You're painting with pretty broad strokes to call people who aren't very enamored w/ XCode "offended" and "entitled."

mattgreenrocks 15y ago
Yeah, but since when did intellectual honesty ever bring visitors in? The bigger the paintbrush, the more people flock to agree/disagree on it, it seems.
wtallis 15y ago
Gruber did say many, not all. And when comments like this [http://news.ycombinator.com/item?id=3015433 http://news.ycombinator.com/item?id=3015433] are so common in discussions about Apple's development environment, it's hard to argue that people who feel offended and entitled are uncommon.

jklp 15y ago

> [...] when you fire up Apple’s Xcode and start building CocoaTouch applications in Objective-C you’re going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years I think I'd have to agree with this statement. As someone who's recently started developing in Objective C and coming from a Java / Eclipse background, the toolset provided in Xcode seems to fall short of what Eclipse has to offer (I can't speak for Visual studio). For instance I don't think Xcode does proper static analysis. I.e. it doesn't allow me to produce a proper class hierarchy for a class I'm using, nor can I run a command to see a call hierarchy on a method. And refactoring isn't 100% accurate either, and also very limited, i.e. I can't extract methods from a code fragment, and also once extracted, move that method into another class without issue (typical workflow for extracting helper methods). It's not to say I can't do good work in Xcode. I just have to be aware of it's limitations and keep accurate documentation as I code, instead of relying on the IDE for a lot of the heavy lifting.

deleted 15y ago

[deleted]

JimDabell 15y ago

I can't agree here. Yes, there are a lot of people who turn their nose up at the OS X/iOS development toolchain simply because it is unfamiliar. They see the square brackets and write it off immediately. But the argument that the toolchain is not polished is dead on. If you look at the work Apple are doing under the hood with LLVM etc., then yes, they are doing some very smart things. But everything on top of that is pretty damn dismal. Xcode is incredibly buggy. iTunes Connect is hell. There is functionality that is just plain wrong. There are features that are inexplicably missing. Version control integration is so poor everybody I know uses external tools instead. Code-signing is held together with bits of string. Functional regressions from earlier versions mystify me. Xcode build configuration is so much of a hassle that it's easier to avoid it altogether by putting everything into xcconfigs. The code quality in the templates is awful. If this kind of quality were foisted on end-users, there would be uproar. It's the opposite of Apple's "just works" philosophy. It seems the application-level dev tools team is where they stick all the students and new hires who don't know what they are doing. I think the fundamental design of Objective C is a little old in places but has held up remarkably well over the years. Cocoa has a fantastic design. But christ, the development tools at the application level are a fucking embarrassment.

jcizzle 15y ago

What is interesting to me is that I could replace "Objective-C" with "liberal" and "Java" with "conservative"; or "Eclipse" with "Democrat" and "Xcode" with "Republican" - and this article and all articles like it will fly just fine on CNN, Fox News, etc. It is amazing how predictable humans are, and how far people will go to exploit that predictability: 1. Draw line in sand. 2. Throw rocks at both sides. 3. Profit.

scottdw2 15y ago

GC is inevitable, but so is no GC. In the 80s people wanted to write software on platforms where GC was not practical. Having a GC when you have 640 K of ram is silly. So people used languages that didn't have GC. But then the platforms grew exponentionally, and people started wanting to do more complex things, and they say "all this manual memory management is crazy... lets use GC", just like the previous generation of computer scientists did before them. Then the iPhone came out... ARC isn't a revolution, it's just a stage in a cycle.... In 10 years your 20 core smartphone will have a GC running in it.

wtallis 15y ago
"In 10 years your 20 core smartphone will have a GC running in it." Quite possibly. But it's also quite conceivable that Objective-C will still be in use by then, and still not have the what a Java programmer would think of as garbage collection. When iPhone hardware is ready for it, we'll probably see Python or MacRuby or JavaScript become the most common way of interacting with a Cocoa system that is still implemented in Objective-C.

shaggyfrog 15y ago

Focusing just on Xcode for a second, the spirit of the rant is not totally off the mark. The latest version 4, has been, on the whole, a step back. If you were used to Xcode 3, suddenly a lot of functionality is no longer there, or moved, or replaced, or hidden away in a deep recess. To make things worse, a lot of documentation is now hilariously out of date. For example, just about any Core Data guide/sample code/tutorial is not applicable to the brave new world of Xcode 4 (or iOS 4 or OS X 10.7). And there's no indication that any of them will be updated anytime soon -- I speak mostly of Apple's own docs. In other words, there's a lot of pain, currently, surrounding the de facto tool for iOS development, even for seasoned Cocoa programmers. It's too bad the original story (the one Gruber's responding to) got so off track talking about other nonsense (reference counting?! Does that objectively really matter?) when there are so many real problems that actually exist with iOS development. Thankfully, these problems aren't necessarily permanent -- just as long as Xcode 4 continues to get refined/fixed, and documentation is brought up-to-date (i.e. no more Core Data how-to videos that use Xcode 3 on OS X 10.4!).