Seven Deadly Sins of Modern Objective-C
ashfurrow.com
ashfurrow.com
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.)
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.
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.
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.
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.
Is he aware that Objective-C can be used on non-Apple platforms?
There's also a slippery slope argument, since something like myMutableArray.removeAllObjects will compile (albeit with a warning).
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.
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 ..
(I ask this in good faith--not trying to troll. I am genuinely curious.)
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.
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.
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.
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..
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.
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 ..
Besides the raw capabilities of the language, the community of Objective-C developers fit very well with the language. Where Ruby would use an abbreviation, ObjC prefers long explicit names. And the interleaved method name/arguments makes the code readable in a very specific and refined aesthetic. It isn't obvious to everyone, and it isn't a natural way to write some kinds of programs. But for writing fast and highly-interactive UIs, it remains a high water mark.
The best advice is: try going through one of the books by Aaron Hillegass to get a sense of the serenity of writing proper Objective-C/Cocoa code.
As another hint, Ruby was pretty heavily influenced by Smalltalk as well. Think about stuff like responds_to? and whatnot, where you're sending messages to objects and objects can actually intercept and react to those messages.
The comparison to C++ is pretty illustrative, if only as a point of contrast; C++ is certainly not the only possible approach to OO in a C-like language. Alan Kay, the guy who did Smalltalk and OO, doesn't particularly approve of the C++ approach to OO.
In practical terms, though, I think it's somewhat historical, to the extent that any programming language's usage is or is not historical. :)
Obj-C tends to bring the best of both worlds, while making slight tradeoffs. It brings the benefits of compile time type checking, while retaining dynamic typing at runtime. Try adding methods at runtime to a C++ object.
Obj-C is reasonably good at a number of things and integrates very cleanly with C++ and C.