
Seven Deadly Sins of Modern Objective-C - gglanzani
http://ashfurrow.com/blog/seven-deadly-sins-of-modern-objective-c
======
wyuenho
Point 6 is a rather uninformed opinion. The reason the Keychain and Sandbox
API are written in C is because they are designed to be used straight up by C
programs without calling in obscure Obj-C land. Have you ever wondered why
Mercurial and Subversion are able to put your credentials in Keychain? This is
why. Lower-level, general purpose Mac OS APIs have always been written in C,
and they should.

~~~
Aqua_Geek
I agree with you, but there really should be a nice, easy-to-use wrapper
written in Obj-C as well.

~~~
chrisballinger
I switched to SSKeychain (<https://github.com/soffes/sskeychain>) after using
SFHFKeychainUtils for a while because I think it's cleaner and more regularly
updated.

~~~
Aqua_Geek
Same here. SSKeychain is pretty well done, but it only has support for
passwords/accounts.

------
jensnockert
Point 5 seems like dangerous advice, shortening types (especially floating-
point types) without analysis isn't a good idea and especially not a deadly
sin.

Changing doubles to floats can give a significant performance boost (mainly on
ARM with Neon) but it brings significant limitations on range and accuracy
that can lead to subtle bugs if you don't do the analysis (especially if you
mostly test it with double precision.)

~~~
stephencanon
Very much this. Using floating-point types that have different sizes on
different platforms without detailed analysis of the algorithm is a recipe for
hard-to-diagnose bugs. Use float, or use double, whichever is most
appropriate.

There are some subtle historical reasons why CGFloat is defined the way it is;
a reasonable argument could be made that it "should have" been double on all
platforms with 20/20 hindsight, but it can't be changed now without breaking
binary compatibility.

------
RyanZAG
Regarding the comments on TDD - the important part of TDD is not the unit
tests. The important word in 'Test Driven Development' is the 'Driven'. You
can actually do TDD without any kind of automated testing, by defining user
tests up front in English, and then manually testing these when hitting
milestones. The automated unit tests just make this process more streamlined,
but are very much not the key aspect of TDD.

~~~
revscat
... and are prone to human error. While you _could_ do manual tests before
every check-in, this is prone to error to the point that I would not trust it.
For any a project of any significant size such a thing would inevitably lead
either to steps being missed or the entire thing being skipped altogether.

~~~
RyanZAG
100%. Automated tests are far superior to manual. The point, however, is that
TDD is not the same thing as unit tests. Too many people add some unit tests
to their code and then claim they are doing TDD. Too many people try to do TDD
by having 100% unit test coverage. It's very important to get the two concepts
straight.

~~~
taligent
Automated tests are only superior when it is too intensive to do manually e.g.
integration tests or serialization tests.

But otherwise especially for iPhone apps manual testing is far, far superior.
It will always pick up issues with the UI that automated testing never will.
And the UI issues are the most important ones.

------
bennyg
I hate Storyboards - I can't even come close to manipulating views/subviews
the way I want to with them.

I love dot syntax. Writing myArray.count is a lot easier than [myArray count]
and then when messages start getting nested it bothers me visually - ie
[[myView subviews] count]. Of course, I love messages and the syntax used for
calling functions too.

Objective-C is my first real language though, so what do I know.

~~~
andymoe
I have to say I very much prefer [myArray count] to myArray.count since I
think of it as a method instead of a property though I agree using dot syntax
for synthesized class properties is preferable.

------
eddieroger
Oh man, am I guilty of not using dot syntax consistently. I actually try not
to use it because it is so out of place with the rest of the code, but it's a
leftover habit from other languages, and old habits die hard.

~~~
bitwize
Objective-C dot syntax is fucktarded. The dot is a structure-member indicator;
why are you using it on a value of pointer type?

The thing is, Smalltalk has a perfectly good getter/setter convention that's
almost as compact and straightforward: for a property called 'foo' the getter
is called 'foo' and the setter is called 'foo:' (takes one arg). Apple could
have used this convention in its method synthesizer (they opted to make the
setter the somewhat more awkward 'setFoo:') and everybody would be clear on
what was a struct member access and what was a message sent to an object. But
no.

------
bitwize
_Objective-C isn't just for iOS and it isn't just for OS X: the language, and
the runtime, is built for both._

Is he aware that Objective-C can be used on non-Apple platforms?

------
frankus
WRT point 3: Xcode will now allow dot-syntax access to non-property getter
methods, however its arguably clearer to use dot syntax only for properties
since they're declared and documented separately from old-style getter
methods.

There's also a slippery slope argument, since something like
myMutableArray.removeAllObjects will compile (albeit with a warning).

------
skylan_q
I'd say #1 isn't an Objective-C issue, but a Cocoa issue. Do not tarnish the
wonderful language with the terrible framework. :)

~~~
camus
I thought Cocoa was pretty good, what makes you think it is terrible ?

~~~
borgopants
Cocoa is pretty good, but like all frameworks, it definitely has its
downsides. Point #1, unfortunately, seems to be something that the author has
a hangup about.

I find that using a single XIB for a view controller at a time works the best
for me, and maintains some semblance of MVC. I work on a relatively large app,
with more screens than usual, and I never find it hard to figure out view
controller transitions or anything like that.

------
oliland
Unit testing (and by extension, TDD) is easy in Objective C: Just test your
models. Your models are (should be) the only thing that makes your app unique.

------
alayne
Old style properties vs. auto synthesized properties vs. ivars are good for
some entertainment as well.

~~~
primitur
I always ask myself why I'm thinking about these things in the first place.
Its a failure of the language, in my opinion, a deep design flaw that isn't
being recognized.

Why do things need to be synthesized in this day and age. I know why
technologically, but it doesn't have any actual _use_ in real life. Its just
window dressing and something special the developer needs to think about, with
no real solid gain other than to entrench a platform-specific methodology into
the language, and thus ensure developer mindshare is captured and maintained
..

------
angersock
Is there any compelling reason that we know of for Apple using Objective-C in
their development tools? In all seriousness, as a programming language, what
does it bring to the table that C, C++, or some scripting language do not?

(I ask this in good faith--not trying to troll. I am genuinely curious.)

~~~
rbarooah
Obviously people can argue for ever over the merits of one design decision
over another but as someone who has programmed in Java for more than a decade,
and has used Scala and Clojure commercially, I'd say that Objective-C does
have some attractive qualities:

1\. The object model is similar in complexity to Java (i.e. no multiple
inheritance, templates, etc. that fill C++ with corner cases).

2\. It _is_ C but with an object oriented message passing layer on-top. You
can think of an Objective-C program as a bunch of C programs that have a more
loose coupled way of talking to each other. This gives it a balance between
the abstraction of a high-level language and the performance and control of C
that is different from Java and most scripting languages where you need to use
a native-API to talk to C. Whether this is objectively good or not is
debatable but it certainly supports Apple's strategy. Personally I find it
liberating.

3\. The dynamism and looseness of the language make code transformation tools
much harder to write - which is why XCode is only now starting to approach
Eclipse on refactorings and completion. The upside is the dynamism enables a
bunch of things whose equivalents require bytecode manipulation in java - e.g.
property observers, Core Data synthesized accessors, Undo proxies etc.

Java is evolving slowly to make these kinds of thing easier, and Objective-C
is evolving slowly to a tighter language that's more amenable to automated
transformation.

These are just a few reasons. I think it's also fair to say that Objective-C
was pretty crude and was 'behind' even as recently as 2007, but the rate of
improvement since then has been high and has brought it up to date. (Declared
properties, blocks, ARC, GCD, are pretty major steps into the modern era)

There are definitely a lot of rough edges that still remain and there's a lot
more to learn than say a scripting language, plus a very different philosophy
to get to grips with by comparison with the java family but once you do know
it, it's a powerful language with some great strengths.

I'm very interested to see what happens to it over the next few years.

~~~
primitur
C pretty much still Rules the System Layer. Its never going to go away for as
long as its easy, and efficient, to write very good C code which performs
well. In spite of the hate, there is a lot of really good C code out there
still running, still working, still burning up the market. I'm pretty sure
there's nary a system image which doesn't, eventually, get itself operating
per the rules of C, for the most part, somewhere ..

That said, for all your very valid points about Objective-C, the same
(essentially) can be said of Lua, and the Lua VM, for example.

As a mobile developer, I'm no longer interested in Objective-C - its only an
Apple Language. But I can take the Lua VM and put it on all the other
machines, host-wise/parasitically, and create my own internally ordered
Framework which runs on all Platforms, and still gain a lot of the benefits of
a re-evaluation of 'language simplicity' versus programmer effectiveness.

After 4 years of Mobile development on iOS and Android, where multiple
projects have blossomed organically into unwieldy godawful trees of complexity
which prove, every day, even more _difficult_ to turn over to other
programmers, themselves creating massive WordSpaceCollections:
ofCode.to_BeMaintained((Some*)Way) || Other { NSLog("grr..", &etc} ;

On a Drama Scale, it goes like this:

"Oh, Android NDK/SDK, how you have blossomed to being something I regret I am
not putting into the trash in the early days. XCode, you %(#@&% Asshole piece
of software, Why I Gotta Download CMDLineTools just to get work done"

..

"SublimeText2, factory settings .. Open Folder->".lua files", build and
distribute for MacOSX, Linux, Windows, iOS, Android, and still only need to
maintain one codebase.

tl;dr - You can't do that with Objective-C.

~~~
rbarooah
This seems like a long way of saying that you don't like Objective-C because
it's not cross platform, and that you've decided instead to write all your
mobile code in Lua and to maintain your own abstraction layer onto MacOSX,
Linux, Windows, iOS, and Android.

The question I was responding to was simply whether there are compelling
reasons for Apple to use Objective-C.

Supporting cross platform native development is clearly not a strategic goal
for them.

I think I'd add another reason - which is that they are in control of the
evolution of Objective-C.

~~~
primitur
I'm really more trying to point out that there is a great way to escape the
trap being laid for you by Apple and their plans for Objective-C, which is
indeed to keep the language in their own privileged domain.

And it really is important enough that anyone considering learning Objective-C
today, or even using it, know that there is a way out of it: roll your own
walled garden and plant what you like within it, on any platform you can.

I would be willing to wager a small bet that says that the scripted-VM-
glommed-in-a-web-of-libs approach to the Platform wars will become more and
more a key survival strategy in software development over the next 2 years.

The OS, and indeed Distributions are dead; long live the new King, VM-managed
library bundling..

~~~
rbarooah
I'm not sure what you mean by 'keep the language in their own privileged
domain' actually means, but I do agree that it is Apple's strategy to invest
in Objective-C above other languages on its own platform, and that they have
no investment in making a cross-platform framework other than HTML5.

I don't see why you describe Apple's approach as a 'trap'. They are providing
a lot of software components that save effort for those who use them. The
results are platform specific, but everyone who uses them knows that and
chooses to make that tradeoff intentionally.

What you describe as "VM-managed library bundling" sounds a lot like "building
your own platform out of open source parts and maintaining a compatibility
layer to your target platforms".

That strategy works for a few of the largest most-well resourced projects -
e.g. the browsers Firefox, Chrome, Safari, Opera etc, plus the Adobe Suite,
and even these draw criticism for the results not being as good as they could
be if they focussed on one platform.

Something like this works on the web too - where people assemble a 'platform'
out of javascript libraries - because the base platform simply doesn't provide
enough.

I don't see it being a viable strategy for a small team or an individual
developer trying to build native applications though because of the amount of
time you'll spend keeping the compatibility layer up-to-date with the rapidly
changing underlying platforms.

~~~
primitur
Run with the pack and eventually become de-marginalized on the slippery
platform being controlled by Apple, or work a bit harder and gain traction on
every platform you can. This has always been a strategic decision for
developers, large and small groups, and both paths have their merits and
pitfalls. Neither is a guarantee of success.

Also, its not as hard to "keep the compatability layer" up to date as you
state .. you need to do it anyway, if you use the vendor-provided native
tools. If you can do that, you can take it one step further, and maintain a
very productive outer-shell over the trap-tools. That can be a very good
strategy, or a poor one; all the examples you provide may be the larger
failure cases, but there are smaller success cases underlooked in your
argument .. MOAI, Love2D, GamePlay .. these are all coming along to eat the
Native Development Devotee's lunch ..

