This article reads a lot more like "In praise of Cocoa" than anything specific to Objective-C, the language. The author clearly sees them as one beast when they are quite separate. It's somewhat reasonable to lump them together since developing anything in Objective-C without Cocoa is generally prohibitively difficult given the lack of other library support.
That said, nothing he's really talking about has to do with the language itself (save, perhaps, for the performance characteristics closer to C++ than Java). He's more praising what C# developers always praise: he's basically describing it as "Java done better than Java."
They're hardly separate things at this point, @autoreleasepool? The new @[] and @{} constructors for NSArray and NSDictionary? ARC enforces retain/release/autorelease, which are NSObject protocol methods. NSString isn't "part of" Objective-C, but the language has had special literals for a very long time.
I guess that isn't the entirety of Cocoa, but Objective-C and Foundation are very linked now.
FWIW, I was reading the article as someone with no Objective-C experience (outside of skimming a few references) and I could tell he was talking about a library rather than a language. It'd almost be analogous to writing an article titled "In praise of Javascript" and proceed to talk about jQuery functionality. jQuery has certainly had an impact on the Javascript language; but the two (despite popular opinion to the contrary) remain entirely distinct.
> but the two (despite popular opinion to the contrary) remain entirely distinct.
This isn't the case in Objective-C though.
@"foo" is an instance of the NSString class, which is a part of the Foundation library. However, it has its own special syntax. Now, Apple is adding @[] and @{}, which are NSArray and NSDictionary instances.
>This article reads a lot more like "In praise of Cocoa" than anything specific to Objective-C, the language. The author clearly sees them as one beast when they are quite separate.
How so? Since, 99% of Objectice-C development includes Cocoa.
It's like arguing C++ and STL are separate. Might be true, but it's a rather pedantic distinction.
Objective-C has some huge warts (XCode crashes is a big one), while the standard library might be decent, it's much more difficult than it needs to be to package modules for iOS.
What sucks about Java is not the standard library but the line noise. I'm not sure that Obj-C improves much in this regard. Blocks are definitely an improvement over java but again, way too much line noise. Selectors are much better than the java reflection system, as well are categories.
If you compare Obj-C to C# there isn't really much to write home about. In C# it's a bit more difficult to use C but not much and it's tightly integrated enough into the OS that the GUI issues are largely non-existant. The MVVC system does leave something to be desired though, not really sure how much better xib is than xaml, as I tend to avoid both.
There are definitely a class of apps (games) that benefit from the tighter integration with C but in that case I'd look to managed C++ as a comparison, and not java.
I don't think it is quite fair to call Xcode crashes an Objective-C wart. It has nigh-unto absolutely nothing to do with the language, and you can of course execute the compiler directly.
I'd be interested to know what other things you consider warts - of the language, not the utilities. Apart from blocks (which seem to have a clear, concise syntax: certainly cleaner and more concise than lambdas in C++11.)
Yes, to be fair it's an iOS development wart, part of the Obj-C ecosystem. The only reason I'd use Obj-C is to write iOS/Mac apps so it's part and parcel for me. I tend to expect tools that I pay $99/year for to work.
Yes, it's possible to work around all these issues but once you've worked around them you no longer have a very good development environment and are back to vim + make/xcodebuild. Lets not even get into the horrid bugs still present in clang (although arguably this is a defect in the compiler and not the language).
Blocks may be more concise than lambdas in C++ but they are even cleaner in C# and F#. I'd actually prefer a hybrid between the two where there was no return necessary for multistatement lambdas in C# and no fun keyword required in F#. Yes, I'm picky about what I like and dislike in languages.
The __block keyword is also fairly annoying.
The biggest warts for me are the impedance mismatches between various parts of the system.
Primitive types and NSObject mismatches
blocks, function pointers, and selectors (a selector should also be able to capture the object for which it is invoked), similar to how C# works out the differences between methods, delegates, and lambdas.
Also, the lack of generics, although I do appreciate essential lack of type system and ability to violate method signatures if one so chooses. At least in Obj-C the lack of generics conveys some ostensible benefit even if utilizing it is poor form.
>I tend to expect tools that I pay $99/year for to work.
Really? Because you can find tools that crash ever for 1 million/year...
If anything $99/year is on the very low side. I wouldn't expect anything to be bug-free at that price point. Have you tried any other large package, from Autocad to Creative Suite to SAP? Do they work 100% of the time?
No they arent bug free, but they generally don't crash / stop working in some significant way every hour or two. Xcode is buggy as hell, on par with windows 9x. I've used autocad back when it ran on Dos and it wasn't that buggy, same with creative suite. It's worse than vs.net 2002.
"Unfortunately, Java's designers didn't seem to value CPU time at all. The language has a nasty reputation for sluggish interfaces, and its execution speed drags well behind C++'s. Pointer aliasing or not we are many generations of optimisers away from languages such as Java overtaking C++ so if you need fast code C/C++ is the obvious choice."
It's not true. There just isn't great library support on other platforms so doing anything nontrivial outside of OS X or iOS is a pain, although there are projects like Cocotron that are trying to do something about that.
I thought so. I figured the OP is probably referring to the lack of Cocoa-like frameworks on other OS's but that one sentence just jumped out at me, because some people would probably take it at face value.
Technically not true, but in practical terms, it is, because you can't do anything useful in Objective-C on Linux (like write iOS applications, which is the biggest reason people want to use Objective-C these days[1])
And it's true in the context of this post, because the author is conflating Objective-C and Cocoa throughout the entire post, so he's correct in saying that 'Objective-C [with Cocoa] is only available on Apple platforms'.
You certainly can compile iOS apps, with full access to Objective-C and Cocoa, on Linux. The platform does not make a lick of difference when you bring a cross-compiler into the mix.
That is somewhat like saying that OS X being written in Objective-C somehow makes it possible/easier to write iPhone apps (which again, are not at all tied to the runtime or architecture of the host compiler's system).
>>but in practical terms, it is, because you can't do anything useful in Objective-C on Linux (like write iOS applications, which is the biggest reason people want to use Objective-C these days[1])
But let me give you a simple and plausible scenario where running Obj-C on Linux might be worthwhile.
Let's for argument's sake, say I'm an indie Windows developer who wants to do iOS development but has heard the most common complaint about Objective-C -- "the weird syntax".
Before I run out and blow my wad a Mac, I can set up a Linux VM with Obj-C to just play with the language at an abstract and academic level and see if I can even wrap my head around the language first.
If I were to trust the OP's sentence at face value, I wouldn't really know that was possible.
Well, as noted by the top comment in this thread, many of the benefits of Objective-C that he's talking about are really attributable to Cocoa, not the Objective-C language itself.
My main point is that, even if the quoted statement in the parent post to my original comment was technically false, the idea was essentially true. The biggest reason for using Objective-C at this point is for a type of project that can only be done on Apple's hardware and OS, not on Linux.
... not only ObjectiveC is available for Linux and Windows as gcc's gobjc, but also GNUstep - kind of open-source Cocoa (former OpenStep): http://gnustep.org
The OP says that Objective C was "originally designed at NextStep". That's probably not literally true. According to Wikipedia, its design began 4 years before the founding of NextStep at ITT Corporation's Programming Technology Center. It was licensed to NextStep, Inc, 7 years later.
"Unfortunately, Java's designers didn't seem to value CPU time at all. "
Well, it's obvious that people think of (Apple) fanboism when they read such misinformation; apart from the fact that there's no point in writing such statements without citing some numbers or real cases.
I can tell you that I've written my last line of C++ exactly ten years ago. In these ten years I've designed and implemented a good deal of industrial software in different segments and never experienced performance problems. Already in 2004, which is ages ago, I designed and implemented a near real time system for distributing telemetry data in F1 racing - among others, Renault won two championships running that system. It was Java 1.4 and it worked pretty well. The specs were pretty demanding. I recall people wondering whether Java was up to the requisites (at the time it was a reasonable doubt, not today).
I am just lucky as I can mention a publicly known project, but there are tons of people around who daily experience excellent performance with Java and don't feel any desire to go back to C/C++. You'd just attend a couple of Java conferences (or at least read the slides) before publishing uninformed statements.
Objective-C saves you from making the choice between the high
performance C++ or the programmer-friendly Java by adding a
substantial runtime to a language that compiles to native code.
I have seen so many great Mac apps that were unusable in the end because of constant crashes. I doubt this would be the case if developers had picked some higher level language.
I know that ARC was recently added to Obj-C, but you can still accidentally harm yourself even with such simple tasks as adding items to array. If you need to deliver your app fast then sluggish (Java) is better than not working at all.
Actually, I was just wondering today how Cyberduck managed to be so sluggish on my computer.
They've certainly gotten the look and feel right, because I didn't realize it was a Java application, but it is pretty sluggish, at least on my machine.
>If you need to deliver your app fast then sluggish (Java) is better than not working at all.
I don't think this is how it works, at least in the OS X market. I never seen any but 2-3 Java apps become popular, and none that much. All the popular, successful apps are native.
So, you can maybe deliver faster with Java (doubt it, since you'll have to implement all the Cocoa goodies and cool integration APIs by yourself) but it wont get you that far.
Apple has since dropped Java, but back in the day, it was one of the primary supported development environments for Mac OS X. There was a full Cocoa bridge, and you could write native-looking applications in Java.
At least one of the built-in apps on early versions of Mac OS X (10.0/10.1?) was actually Java/Cocoa -- I want to say TextEdit, but I'm not certain. Soon after, of course, everything got ported to Objective-C.
>Apple has since dropped Java, but back in the day, it was one of the primary supported development environments for Mac OS X. There was a full Cocoa bridge, and you could write native-looking applications in Java.
Only up until Tiger. And you still had the "uncanny value" effect, despite the native-ish look and feel to Swing.
Plus, even SUN and then Oracle abandoned Java on the desktop.
>I have seen so many great Mac apps that were unusable in the end because of constant crashes. I doubt this would be the case if developers had picked some higher level language.
Yes, then they would have been unusable because of slow performance and regular gc pauses, like almost any Java program I ever met.
It's a lot faster now that it used to be around 2002+ with the Swing of the day, but still lags perceptibly behind C/C++ for UI work. And don't even think using it for a multimedia app (video/sound) etc, or a game, except if you delegate all the work to a hardware accelerated C/C++ 3D backend.
Possible, but not recommended. Objective-C is a language that, while cool and innovative for the early 1980's, is totally dated (even with Applet's recent updates) and just plain failed in the market. It would have been extinct long, long go if not for Apple buying NeXT and then dragging Obj-C into OSX and iOS and making its use mandatory in practice. Despite the existence of other implementations such as GNU's (including the OpenStep libraries), Obj-C's usage is basically zero in any platform where developers can make the choice; and this holds true even today, after a large number of new developers learned it again due to iOS's popularity.
I'm completely convinced you don't know what you're talking about. Your posting contains several inaccuracies.
1) Whether Objective-C would have been "extinct" is quite subjective, but given that it is the power and force behind the mobile revolution which is happening on the iOS devices (iphone, ipad, etc) and all of the Macs out there. I would venture a guess that you're wrong about it being dated.
2) It has recently been updated... Objective-C 2.0 has features such as Garbage Collection and ARC to make memory management easy. If your conceptualization of a "modern" language is C++ or Java, please think again. "Modern" languages are moving towards flexibility and loose typing (like in Ruby, ObjC, etc...) not language such as C++ or Java.
James Gosling was, indeed, quoted once as citing ObjC as the inspiration for Java. Many NeXT engineers, in fact, helped to build Java when they went to Sun.
3) ObjC's use on other platforms is hardly zero, but it is, nonetheless not very popular on other platforms aside from Mac. But this is not, as you seem to suggest, because it isn't any good, but because many developers don't know that it's useful on other platforms because they think it's restricted to Mac.
So, if any of you would like to help make ObjC more useful, feel free to help the GNUstep project. We have much of Cocoa implemented. Help us make it more complete!!!
Yeah, right. Cocotron doesn't even work on Linux and has limited use on Windows. Also, you MUST own a Mac in order to build a project using Cocotron since it is only a cross compilation system and nothing more.
That said, nothing he's really talking about has to do with the language itself (save, perhaps, for the performance characteristics closer to C++ than Java). He's more praising what C# developers always praise: he's basically describing it as "Java done better than Java."