I loved C. But it always fell short for me. Objective-C fixed that.
red-sweater.com
red-sweater.com
Reason 1: When you need what C provides, it is right there for you (being a superset of C)
Reason 2: When you need what C does not provide (basic reflection, generics, polymorphism, whatever) it is in the "bracket" part of Objective-C.
Reason 3: The two above do work quite well together - the impedance mismatch is minimal, compared to e.g. Python with extensions written in C.
The fact that Obj-C takes C and adds objects on top is its biggest flaw, just like with C++. Worse than C++ though, Obj-C doesn't even attempt to fix at least some of C's more glaring flaws... you get the whole language, quirks and all.
ARC fits better with the C world of quickly tuning bottlenecks to register speed. Have you ever debugged C code with custom object lifetimes under a garbage collector? It's a nightmare.
But that's, statistically, almost no people out of 'people who use GC'. There aren't that many allocators in common use that even have much in the way of tunable parameters (I can only think of the JVM ones, offhand), the people who spend weeks tuning them have very particular needs - high throughput, low latency, high-enough complexity to warrant a high-level language. These are the sort of people who also do things like start at a PHP page and end up chasing performance improvements in the bowels of a network kernel driver. It's done, but it's unrepresentative.
ARC fits better with the C world
It seems like a much more central reason ARC is more suitable than a GC for Objective C than 'GC tuning is occasionally a dark art'.
I'm only reacting to the idea that (pp) "because it's 2011, nobody should be using ARC". Well, a statistically tiny number of apps may require the bare-metal performance that hand allocation provides, but they're also disproportionately important apps.
(Neither, though, does C++, and smart pointers don't help there either. ;) )
And now MS shows WinRT that is not .Net. Hmmm... :)
Not even Java's fans would defend it as a "well thought out OO" language.
Since this is Hacker News, it maybe appropriate to point out that nothing prevents you from building whatever specific flavour of OO you want on top of the Objective C runtime, if you want it badly enough.
This is where I get to promote my favorite page of documentation ever: http://developer.apple.com/library/mac/#documentation/Cocoa/...
This actually makes me wonder... how much overhead is in each objective c object over a similar struct in c?
But, it's fast enough for 95% of things people do with it.
http://mikeash.com/pyblog/performance-comparisons-of-common-...
And that's from 2008. Clang's improved it a lot.
http://mikeash.com/pyblog/performance-comparisons-of-common-...
Since there are so many developers from outside the Apple ecosystem learning Obj-C in order to develop for iOS, is there any signs of a movement in the other direction? Are developers who don't think of themselves as purely Mac/iOS developers trying to take Obj-C back with them to other platforms?
Posts about how great or poor Obj-C is as a language are kind of irrelevant really as long as it's (effectively) the mandatory language for development on Apple platforms, and isn't much used beyond that. In that situation there are no choices to be made based on opinions about the language's merits or flaws, so they are largely moot.
There are compilers available to use Obj-C (the language) on just about any platform. I guess you could use Obj-C to write GTK or Qt code (I doubt that the Qt preprocessor would like that, though).
If you read that Obj-C is great, that usually means that Obj-C is great for Cocoa. Cocoa and Obj-C make for a great team! Probably comparable to Android and Java or .NET and C#. It ultimately does not matter whether Obj-C would be of much use without Cocoa, since almost all people will be using it as part of Cocoa.
Great tires are of little import if you don't own a car.
http://www.tiobe.com/index.php/paperinfo/tpci/Objective-C.ht...
I have a feeling it would see a distinct dropoff in usage if Apple were to change their focus to, say, Java or C++.
I wouldn't say the same thing about Cocoa though. Cocoa is good, but not great.
Using the Objective-C language on Debian was as easy as doing "apt-get install gobjc". But, as you stated, most of the utility comes from Cocoa.
Even though it's technically possible to use Objective-C without Cocoa, in practice it's almost not worth it. It's not like C++ where you can chose between Qt and Gtk+ or some other big library. There's Cocoa/Foundation or there's nothing. It would be hard to find learning material that didn't use Cocoa, even if you wanted to try it.
There are a few alternative Cocoa implementations that run on Linux and even Windows.
Cocotron lets you create Windows apps using Cocoa, but it's a cross-compiler that runs in XCode. Didn't fit my needs, so I didn't try it.
libNuFound was pretty good for the Foundation part of Cocoa, but it took a bit of work to make it work. Objective-C with only Foundation has a lot more functionality than plain Objective-C, but still no where near the usefulness of Cocoa.
The most complete and most popular option is GNUStep. It implements Foundation and a good chunk of Cocoa. They've done good work, but the documentation was lacking, and I never knew whether code I saw on the web and in Cocoa tutorials would work under GNUStep, without trying it. Apple's developer documentation is really good, and I used it as much as possible, but it was pretty common to run into stuff that didn't work under GNUStep. My other big complaint was that it's a really heavy weight "library." I don't know if it's their fault, but I vaguely remember having to install a bunch of seemingly unrelated dependencies just to get their *-dev packages installed on Debian.
Perhaps not the best comparison, but for me, using GNUStep libraries to develop Cocoa always felt like using Wine to run Windows programs.
I had a few other links about setting everything up, but these two were helpful:
http://blog.vucica.net/2010/12/getting-objective-c-2-0-to-wo...
http://orangejuiceliberationfront.com/playing-with-objective...
FWIW, I did eventually buy a Mac, and can say Objective-C and Cocoa on iMac is much easier on OSX than Debian.
I write my iOS app UIs in Obj-C but the brains are in a C++ core. The new C++11 support in LLVM 3.0 has tipped the balance that much further.
Probably one of the easiest and more powerful ways to create an UI, but not as mature as other consacrated frameworks and not available on iOS anyway.
By the way, how do you handle unicode in the C++ core?
So far I haven't had to do any serious string handling in my C++ engines (mostly audio apps). The new unicode stuff in C++11 ought to make this manageable but I haven't actually tried it yet.
FWIW: https://github.com/NateStedman/FunSize/blob/master/FunSize/N...
Most people who say they like Objective-C actually mean they like programming for Macs and iPhones.
Apple's response? At its inception it had nothing to do with Apple and for a long time was the language of NeXT. It's only since OSX that Apple has adopted Objective-C.
Apple's CEO came from NeXT, as did their lead software architect. OSX is NeXT (ever wonder why so many things extend NSObject?).
Otherwise, I have no idea.
That said, I did quite like some aspects of it: goroutines, channels, functions can be added to structs.
I am hoping that rust makes it out of the lab at some point.
* Everything is a file (/proc, /net) * UTF-8 * WMII
I suppose that's enough for a research OS and its creators to be successful.
Before they worked on Plan 9 they created Unix, that the *nix world lost its way from its simple, small and beautiful roots is clearly something that still pains them greatly.
I would not say that they lost touch with the rest of the world, but that the rest of the world lost touch with them, which has been a great loss.
Things like variable declarations matching the look of how variables are used ('inside out' parsing) are not simple and are responsible for the certain something that makes C work. And Unix was never beautiful, it was always a huge hack.
* The "exception handling" (or lack thereof). Defer, panic, and recover do provide an interesting means to achieve some similar behavior, but I ended up testing return values _a lot_, and all over the place. It felt very boilerplate and messy. Also, I found it odd that they claimed that the 'try-catch-finally idiom' was convoluted, then came up with defer, panic, and recover. Which calls code on function exit. I liked defer (great way to clean up allocations in reverse on the way out), but I did not find panic-recover as a convenient replacement for exception handling (nor does that seem to be the proper use-case for it anyway).
* new vs make. I don't see why they didn't just unify these in some way. Purity over pragmatism, perhaps.
* goto
* static compilation only (no shared libraries). I know static libraries are safer and sure do make deployment dreamy, but it would be nice to benefit from shared libraries if desired (easier to deploy security fixes, memory savings, etc).
But really if that is your biggest issue with the language, I think they are doing a pretty damned good job.
Objective-C was always attractive (I like C), but its close association with NeXT and Apple (and corresponding little support from other platforms) always puts me off.
Example: I wrote a GA-based solver in Objective-C. It worked but it was painfully slow. I re-coded in nice-clean C. The plain C version was incredibly fast and efficient in every way. Best of all, it is highly portable too.
So, there you go: Write your algorithms in C, write your program logic in Objective C. Oh, and I love how the OpenGL C API interacts so nicely with Objective C and Cocoa!
That said, I have a fair bit of experience with PyQt. I would ditch Objective C for something like MacRuby any day, but then I would (sorta) lose the ability to drop down to C if need be. (Still, does anyone have any solid experience in MacRuby? I would love to hear some!)
OpenGL is great. Really well designed :)
The notion of internal state is fine and well for only the most trivial of programs--once you start doing something requiring multithreading nothing but sadness awaits.
Also, if you're calling an Objective-C method and dynamic dispatch is causing measurable performance issues, you can cache a pointer to the C function that backs the method (called the IMP) via the class_getMethodImplementation() runtime API.
And you don't have to give up the power of C (memory pointers etc...) either.
But ramitos is right; it really is a Frankensteinian bolt-on addition of Smalltalk, syntax-wise. The message passing code simply does not look like C.
That said, I'd encourage everyone to give it a chance. I, too, had a negative reaction to it when I first encountered it ("It's so ugly!") but you get used to it, and then it's fine.
Arguably that's a very good thing, because passing a message has very different semantics from calling a function. Making the syntaxes of these operations identical would encourage a lot of confusion between two very different operations.
This is not really a good submission--it's got the rhetorical content of a tweet.