

The Unfamiliar (Objective-C & Cocoa) - donmcc
http://daringfireball.net/linked/2011/09/19/the-unfamiliar

======
mpk
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
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.

~~~
2muchcoffeeman
I disagree with your first point. The editing features like finding files, key
bindings, navigating methods within a class etc. are pretty clunky.If they
gave us a vim plugin I would be happy.

~~~
kposehn
Ah, ok. We both have a fundamental difference in terms of code editing
preferences then. I hate vim with a passion, but that is also because I'm a
very visual user. To each their own and what works best then :)

------
VengefulCynic
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-revis...](http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars)

~~~
pohl
_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>

...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>

Since you're a Siracusa fan...

[http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.a...](http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.ars/11)

~~~
smikhanov
_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
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.

------
potatolicious
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
Use an actual device. You don't develop for Xbox 360's or PS3's in an
emulator, why would you for mobiles?

~~~
daeken
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
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.

------
JimDabell
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.

------
kennywinker
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
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.

------
shaggyfrog
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!).

------
mhd
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.

------
jklp
> [...] 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.

------
zbowling
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.

------
scottdw2
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
"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.

------
jcizzle
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.

------
mosburger
> 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."

~~~
wtallis
Gruber did say _many_ , not _all_. And when comments like this
[<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.

