11 ms·

Objective-C's niche: why it survives in a world of alternatives

101 points by stephth 15y ago

allenbrunson 15y ago
I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X. It's not horrible. I don't have any real problems with it. But I think its replacement is long overdue. Given that Apple has a long history of ditching huge swaths of its technology in favor of more modern alternatives, no matter if their userbase screams bloody murder or not, I'm surprised it hasn't happened already. This would be a good project for those billions they've got sitting in the bank. I think it would be great if they would anoint some successor as their new systems language, then port Cocoa to it. Programmers could use either objective-c or the new systems language for a few years, just as we used to decide between Cocoa and Carbon. Then objective-c could gradually fade into the past.
- protomyth 15y ago
  They did try to replace Objective-c with Java and that showed a lot of areas where a framework built for a dynamic language fails on a static language. I think Objective-C is a decent tradeoff of C and Smalltalk. I like the selector syntax as opposed to the C++ syntax.
  - allenbrunson 15y ago
    They didn't actually try to 'replace' objective-c with java, though. It was just an alternative. In the early days of Mac OS X, many programmers were seduced by it, but they complained loud and long about having to learn this weird new language that had practically no adoption outside Apple. My guess is that Apple decided to give them java to quell the complaining. It wasn't adopted widely, so that was that. What they should be replacing objective-c with is something that looks more like, say, Python.
    - msbarnett 15y ago
      Well, Apple has been funding a lot of the development of MacRuby, possibly as an exploration of what it would take to anoint a popular scripting languages as a "nicer" alternative to Objective-C.
    - smackay 15y ago
      The big push for Java was with WebObjects and Apple's half-hearted push into enterprise systems. Initially Apple's version of Java (they wanted tight integration with Cocoa) was always a couple of revisions behind Sun's so that was always a source of frsutration with developers. With the new focus on consumer devices the enterprise space was left to wither and Java with it. Anything that is going to replace Objective-C must be at least as fast - Apples really cares about the customer experience not the developer experience.
- gcv 15y ago
  It's rather sad that Apple Dylan went nowhere. It would have been a terrific language to pair with Cocoa.
- cubicle67 15y ago
  that's fine, but what would they replace it with? Java? C#? not likely. C/C++? well, you can use them already I think MacRuby is the closest we have atm to something being groomed as a successor to Obj-C. It's got a way to go yet, but it's already at the stage where it's viable for smaller projects and there's a (small) number of MacRuby apps available on the OSX app store.
  - noarchy 15y ago
    Any idea how much investment is taking place in MacRuby? If they're really interested in grooming a successor, I'd figure that there would be some serious work going on, behind the scenes. With the success of the platforms on which Obj-C is used, I don't know if a successor will be another language. An update to Obj-C itself might make perfect sense.
    - danieldk 15y ago
      Well apparently, MacRuby is already a private framework in Lion, so it serves some purpose in the eyes of Apple. http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-share/ http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-s...
  - danieldk 15y ago
    I agree that MacRuby is the most likely 'successor' (or rather, alternative). Another advantage of MacRuby over some other 'scripting languages' is that it can be compiled to an executable via LLVM bytecode (per macrubyc). This will be appealing to anyone who doesn't want to give away his/her source code.
  - jaes 15y ago
    why not just smalltalk? or f-script with inline C? either of these would really just be a more convenient syntax for most of the higher level code written now anyway (given my experience). the runtime is sufficiently flexible that a simple change in syntax with a friendlier IDE would get many people raving about how great the platform is in much the same way as those experienced with it do now.
- patrickgzill 15y ago
  Correct me if I am wrong, but there is a huge amount of Obj-C in the guts of OSX. Replacing it with another language would require a large RAM footprint as both older apps and new apps would require a large amount of shared libs to be loaded, for possibly not that much additional benefit.
  - allenbrunson 15y ago
    I am very far from an expert at Mac OS X system internals, but I don't think objective-c is all that ingrained in the kernel. You write device drivers in a restricted subset of C++, as one example. userspace Mac and iOS programs have to link to an obj-c runtime library, but it's not much more onerous than linking to, say, libc or libc++. The big hit would be that, yes, there are gigabytes of objective-c frameworks installed, which would presumably have to be replicated in the new language. But I could see Apple finding a way to sidestep that issue. Maybe the new systems language and objc could both compile down to similar binaries. Painful or not, it's going to have to happen sooner or later. Objective-c is, in my opinion, the most outdated thing in Apple's technology stack. There will come a time when it is as big an albatross around their neck as Mac OS 9 was, which they waited far too long to replace.
    - mambodog 15y ago
      AFAIK MacRuby already works in this way, using the existing (Obj-C) Cocoa frameworks in conjunction with the MacRuby runtime.
- Entlin 15y ago
  John Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 http://arstechnica.com/staff/fatbits/2005/09/1372.ars http://arstechnica.com/staff/fatbits/2005/09/1372.ars Then he revisited it 10 months in 2010: http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis... And then he talked about it 2 weeks ago in the Hypercritical Podcast: http://5by5.tv/hypercritical/14 http://5by5.tv/hypercritical/14 Abstract: new language and new API go hand in hand. A memory managed combo trades execution speed for faster program creation. Was already needed 5 years ago. The recent garbage collection additions don't cut it. Microsoft started working on their successor (.net) 10 years ago and now it's starting to look good. Apple gained some leeway when the iPhone happened. With ever improving CPUs on mobile devices, Apple still risks losing ground down the line. Great podcast episode, I highly recommend it.
  - ryannielsen 15y ago
    You could also argue that, given the current success of iOS and Mac, Cocoa isn't a significant hinderance to Apple's platform's success. (Not to say I wouldn't mind some significant advancements in Apple's preferred runtime, but there's strong evidence that the current runtime is actually quite suitable. If, as you say, .NET is only now starting to look good after a decade's worth of work, perhaps that wasn't the wisest investment on MS's part. Siracusa's been beating this drum for years and, like many of his crusades, I struggle to see how Apple suffers from not following his advice.)
- makecheck 15y ago
  It's fine to push for a better language, but so far you seem to be saying we should do it just because the current language is too old. What are specific things that are wrong with the language Objective-C 2.0 (and not just Cocoa, which is an API; and not just Mac OS X or iOS, which are platforms)? Why should Objective-C not just evolve into something a bit more interesting? And when considering any alternative, what are the most costly considerations for any developer, including Apple? The size of a code base is a significant factor. The fact that established code already works (new code may add bugs) is a significant factor. The wealth of knowledge already accumulated by programmers is a significant factor. A new language is very unlikely to win a war in those areas, so it would almost have to solve some other problem that is still costing developers a lot because they're using today's languages.
  - allenbrunson 15y ago
    Good question! I can think of a lot of reasons why Apple should switch to a more modern systems programming language. We have all read pg's essays where he extols the virtues of Lisp, compared to other languages. His primary argument, as best as I can tell, is you can write programs with far less code than in other languages. Such an advantage would be a big win for the platform, and we may come to a time when Apple is forced to do it, because everybody else has, and they risk being left behind. Objective-C is becoming a weird frankenlanguage. It already was, arguably: a thin layer of smalltalk-like OO sitting on top of C. Just recently, Apple added blocks, which are like continuations in other languages. Maybe that's a good thing, but I think it would be a better thing if we went with a language that had those types of concepts from the beginning. It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was .Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit. The biggest argument I can think of for Apple not to try a new systems language is that their cash cow right now is the iOS platform. Doing this now would no doubt cause serious memory and CPU pressure on small devices which can't afford it. So knowing Apple, their likely answer to that would be to come out with a new generation of devices that are no longer compatible with objc, which you have to rewrite everything for.
- mhd 15y ago
  It took years to get (mostly) rid of Carbon. Heck, Cocoa still has the NextStep prefix. The amount of change Apple is willing to make can be hugely exaggerated, especially if they're able to control the respective technology (which they do mostly, one noticeable exception being desktop CPUs and GPUs).
killerswan 15y ago
With early iOS they were talking about a pretty serious use of JavaScript. I wouldn't be surprised if they pushed that more in the future... I've heard there is a lot of work being done to make Haskell play nicely with Xcode [1]. I don't know if Apple is experimenting with that, but they're probably kicking a lot of options around. [1] http://hackage.haskell.org/platform/mac.html http://hackage.haskell.org/platform/mac.html
- pohl 15y ago
  Did you paste the link you intended to? I don't see how it supports the idea that there is work being done to make Haskell place nicely with XCode.
  - killerswan 15y ago
    Work being done by Haskell people, if not Apple people.
    - pohl 15y ago
      I'm not even getting that from the link. To me, the link only shows that I can download The Haskell Platform for my Mac. The only thing there related to XCode is that one needs to have it installed as a prerequisite for running the haskell platform's installer. This is no surprise because the installer wants to have the "unix development support" package available (it contains gcc, header files, misc command line tools in locations where run-of-the-mill Makefiles can find them...) and it's just incidental that one needs to run the XCode installer in order to get these basic unix amenities on the system.
mirkules 15y ago
Why it survives in a world of alternatives? There are no alternatives if you want to distribute on the most popular mobile platform. Personally, I really dislike Obj-C, but since I want to create apps on the iPhone I have no choice. Unfortunately, making a good business decision sometimes means going against your personal feelings. I think that's how a lot of other people approached it too. If the iOS platform changed overnight to Lisp, we would see articles titled "Why Lisp survives in a world of alternatives"
- stephth 15y ago
  The author is not arguing about how come objc is not dead, but about why Apple hasn't replaced it with a more popular language.
- cppsnob 15y ago
  > There are no alternatives if you want to distribute on the most popular mobile platform. Symbian, Blackberry and Android don't support Objective-C as far as I know. Only iOS does, which is far from the "most popular" mobile platform, especially if you look outside Silicon Valley just for a minute. [Edit] Also, for the record, you can program in C++ and distribute on iOS with minimal Objective C. I thought I'd point this out given my login name.
  - sigzero 15y ago
    I think you both are arguing from different sides of "popular". You are stating popular by sheer numbers while he was stating it from a 3rd party developer prospective. I believe he was right in what he said.
- ryannielsen 15y ago
  > There are no alternatives if you want to distribute on the most popular mobile platform. This statement isn't entirely true: http://www.appleoutsider.com/2010/06/10/hello-lua/ http://www.appleoutsider.com/2010/06/10/hello-lua/ Cocoa is extremely strongly encouraged, but it's possible, under the current developer agreement, to distribute non-Cocoa applications on iOS.
jshen 15y ago
I wish Objective-C were more popular on linux, I like the way I can mix message passing style OO with C code.
- rchowe 15y ago
  There aren't really any good libraries for it. You can compile straight ObjC on linux fairly easily with gcc or clang (use -lobjc), but the thing is without NSString and all of the foundation you'll end up doing a lot of work. And yes, you can get into GNUStep, but that's a whole nother ballgame.
jrockway 15y ago
Objective-C's niche: it's the core of two popular operating systems. A lot of strange programming languages survive because of inertia. Emacs Lisp exists because Emacs was written by Lisp hackers. It survives because Emacs ships with a few million lines of Lisp. Replacing it would take hundreds of man-years. Objective-C survives for the same reason; Cocoa was expensive to write and rewriting it would serve no purpose. So it remains. Is anyone using Objective-C for some reason other than writing OS X or iOS apps?
- _3u10 15y ago
  No, and if there was an easy way to bind UIKit with out Obj-C I'd use it in a heartbeat. I'm seriously considering WAX for LUA. Obj-C has the flexibility of C with the speed of small talk.
  - boucher 15y ago
    That strikes me as a pretty indefensible statement. Objective-C has an incredibly powerful runtime, which is nearly as flexible as the ruby runtime. It's also much much faster than ruby, and probably every other popular dynamic language.
    - fleitz 15y ago
      I'm sure the runtime is great, unfortunately the syntax sucks, there is no GC (on iOS) and it can't curry functions, and you can't put an NSInteger into an NSDictionary with out line noise that would do java proud, it doesn't support passing or currying functions. Sorry, but passing a selector and an object is atrocious, even MS can figure out how to pass a delegate that can figure out whether it needs to pass a this pointer before passing the rest of the arguments. It's lambda syntax is also attrocious [[ ^ (int x, int x) { return x+y; } copy] autorelease] , wtf is that garbage? In ruby I don't need to touch 2 different files and put code in 3 places just to define a property, nor do I have to do this in C# or F#. I doubt it's much faster than C# or F#, especially if it ever involves something simple like putting an integer in a hashtable. I'd hardly call a language dynamically typed when it will fuck up adding a long and an int. Seriously, define a type that takes an int, pass it a long and see what happens. This is exactly what I mean by the flexibility of C (attrocious type system) and the speed of small talk (incurring a call to objc_msg_send anytime you do anything)
zmitri 15y ago
After starting to read a bunch of objective C, I have to say there are some constructs that are very nice compared to an OO language like java -- for example, selectors and the target action design pattern. There's definitely some nice dynamic properties, but at the same time, some of the basic "methods/messages" for the Foundation APIs aren't very convenient to write and are strangely named. For example, compare NSString to strings in Java, Python, Ruby, etc.
veyron 15y ago
Has anyone used pyobjc or some other interface between objective-C and another language? Thoughts?
- ammmir 15y ago
  pyobjc is how i got exposed to objective-c. it's a joy to use if you have your app in python, but i've heard complaints about the python-objc bridge leaking memory, so you may end up doing memory management in python (alloc, init, etc.) on pyobjc-wrapped objects if you're not careful.
- orangecat 15y ago
  I used PyObjC a few years ago, and enjoyed it much more than straight Objective-C. Far less boilerplate, and the transparent mapping between Python lists and dicts and Cocoa's NSArray and NSDictionary is great.
ignifero 15y ago
Let's face it: in 2011, Obj-C has the sex appeal of COBOL. I think it's primarily a strategic decision: Just like apple likes to lock-in its customers with itunes, so it does with developers, locking them behind an unpopular language with a slow learning curve.
- astrange 15y ago
  The learning curve of Objective-C is about a day if you know C99. Did you have some specific problem?
- cubicle67 15y ago
  that doesn't make even a glimmer of sense
- bonch 15y ago
  Ignoring the disputable claims that it's unpopular or has a slow learning curve (you can describe Objective-C's additions to C in a single page), there's no evidence to claim that Objective-C is about customer lock-in, especially when you can use so many alternatives including the Apple-funded MacRuby. Apple uses Objective-C because they have a lot of code written in it, and it has served them very well. iOS is the most popular mobile platform for third-party development. The dynamic nature of the language has enabled the implementation of some useful features like key-value-observing, while the ability to drop to C retains the flexibility of system-level programming. Even the memory management criticism is overblown. You merely have to follow an easy list of four ownership rules. That's if you're not using the garbage collector that came out four years ago with Leopard.
  - nupark2 15y ago
    If you follow those "easy rules," how do you handle race conditions between weak references held to avoid retain cycles and the execution of those weak reference's -dealloc methods? There's nothing to stop the weak reference's -dealloc from racing with messages to that weak reference. Or, how do you handle the fact that -dealloc can be called on whatever thread calls the last -release, even if you make an effort to only send messages to an object on the main thread (Which will trigger implicit retain/release unless you're incredibly careful). Almost all of the GCD examples out there are subtly broken because of this. As for GC, I look forward to actually being able to use it on iOS.
zoul 15y ago
I find it surprising that there are so many people bashing Objective-C here in the comments. I have been programming in Objective-C for living since the iPhone SDK came public and I came to love both the language and the libraries. I think that many people who despise Objective-C syntax are simply not programming long enough in the language to overcome the initial knee-jerk reaction. Mostly the issue seems to be the message passing syntax, which I find very readable and self-documenting. What else should matter if not this? Then there’s comments about speed. I have written two action games for the first-generation iPhones and I have never encountered a performance problem caused by the runtime. Over 99% of the time I could stick to high-level code without resorting to C to gain speed. That says a lot about performance for regular applications. Block syntax could be better, I can’t use closures with such ease as in Perl (for example). But this is one of the things that have to do with Objective-C being a relatively thin layer atop of C. And that I see as a huge win, because you can very easily and naturally mix higher-level Objective-C code with plain C APIs that are very common on most systems. And if you want some lower-level bit-twiddling trickery for performance reasons, you are free to go. For me, C is a very elegant language and Objective-C takes out most of its rough corners. Saying that Objective-C could be replaced by something “smarter” like Lisp or Haskell is simply ignoring the reality. Objective-C has very low language complexity, both the building blocks and their interactions are simple and there are few surprises. This is a huge advantage both for the newcomers and for programmers that deal with the stack most of their working hours. The manual memory management first seemed like a chore to me after coming to Objective-C from Java, but the rules are dead simple and after a few weeks you don’t think about the memory management any more. Yes, Objective-C is not hip. So what? It’s a pragmatic and reasonably expressive language that gets the job done. I don’t think that replacing it would serve any real purpose – and that’s a very good reason to survive.
- tomjen3 15y ago
  My biggest beef with Objective C is that it takes the most retarded feature of C++ -- that you have to write both a header and a implementation file (why oh why can't the compiler compile one?) -- and removes the really nice ability to allocate your object on the stack (which means memory allocation is really, really, cheap and you know when the object is deallocated).
ignifero 15y ago
The title of the post is very misleading: Obj-C would crash and burn if there were native, supported alternatives in OSX, it survives exactly because there are no alternatives.
- ryannielsen 15y ago
  Ok, that's simply not true. On Mac OS X, you're welcome to use any language and runtime you wish for your application. Hell, if you want to use a non-Objective-C language and still present a native experience, use PyObjC, RubyCocoa, MacRuby, or any other language that shims into the Objective-C runtime and get access to all of Apple's Cocoa frameworks in the language of your choice. The same is possible on iOS as well, with the (significant) condition that Apple must first explicitly approve your use of a non-Objective-C runtime before your app can be posted to the App Store. But in direct response to your post, Obj-C has a rather level playing field on OS X and still survives vs. the alternatives.
  - blub 15y ago
    Welcome to use it, except: * it's not officially supported by Apple * it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs) * you can't use it on iOS * you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language
    - ryannielsen 15y ago
      > * it's not officially supported by Apple MacRuby is an Apple project. PyObjC isn't, but ships in Mac OS X. That's rather officially supported. > * it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs) Not true. MacRuby is a prime example of a language that taps directly into the Objective-C runtime, eliminating the need for a bridge. And PyObjC is a great example of a mature bridge – it's been around and robust since the NeXT era. > * you can't use it on iOS http://mobileorchard.com/announcing-iphone-wax-native-uikit-iphone-apps-written-in-lua/ http://mobileorchard.com/announcing-iphone-wax-native-uikit-... > * you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language You can't get jobs programming Ruby, Python, C#, Lua or any other language?
cageface 15y ago
Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and then to move transparently up to a much higher level of abstraction for non-critical code. With the relatively underpowered processors of today's mobile devices, this kind of control is important. However, Obj-C completely falls on its face for anything of real algorithmic complexity. Working with complex, nested data structures and more sophisticated algorithms is very awkward, and manual memory management only clouds things further. In the longer run this may become a liability for Apple.
- zoul 15y ago
  I fail to see how manual (or, in this context, explicit) memory management could “cloud things”. (It seems to me simply like many programmers can’t be bothered to invest the afternoon it takes to learn Cocoa memory management.) Also, could you elaborate why Objective-C makes it hard to work with nested data structures and sophisticated algorithms? In fact, I am struggling to find an example of at least a single general-purpose language that makes working with ”sophisticated algorithms” hard.
  - uxp 15y ago
    I have never understood what is so difficult about Cocoa/ObjC's memory management. In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative. At least we don't have to declare how much memory to alloc and dealloc manually.
    - leon_ 15y ago
      If you just keep to "release what you alloc/new/copy" you'll be golden.
      - nupark2 15y ago
fingerprinter 15y ago
Obj-C survives b/c it is the only real way to write iPhone and iPad apps, plain and simple (ignoring Appcelerator and PhoneGap for the moment). If people had options, it is likely they would use the alternatives. Look at Linux. The "official" language will always be C, but there are toolkits for building GTK apps in Python, Vala, Mono and other even more obscure languages. Some pretty big apps have been written in each and people will continue to use those as long as they are viable options. If, however, someone big enough and with enough clout basically said "only native C/GTK apps will be accepted on our platform", you would see people migrate to that toolchain. It is simple economics. Apple has the clout (imo, unfortunately) to do that and have done it with Obj-C. They basically killed Java, which was an option up until I think 2 years ago. I can see Apple's perspective, supporting two toolkits is expensive and takes time, resource, energy and focus. In their mind, what benefit to they gain from supporting multiple toolkits? Developers? They know they are popular enough that the developers will take up Obj-C when Java was dropped. Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT DEVELOPERS except that they make apps to attract the users. I'm not saying what Apple did is right or wrong, but it does make sense from a strategic point of view. However, there is practically no merit to Obj-c on it's own. There are more compelling alternatives at nearly every turn, but NOT if you want to play in the iphone and ipad ecosystem.
- cubicle67 15y ago
  Are you seriously suggesting it would be better for everyone if developers wrote desktop apps for OSX in Java?! Apple didn't kill Java, Sun did. It was Sun who decided Java apps had to look different (in that special, ugly java kind of way), that they required 5+ seconds to start etc. Java could have been good for desktop apps if done right, but it wasn't and as a result there's very few desktop Java applications (and even fewer good ones). Java was also an awkward fit for Cocoa, lacking the dynamic ability required. Java has it's place, and being a language for desktop apps is not it
  - fingerprinter 15y ago
    I think your misremembering. There was a Cocoa Java API that people could use to write native apps. That is what was killed. Pure Java (Aka. Swing) apps on the desktop is a different thing entirely.
Argorak 15y ago
meta tl;dr: The blog post talks about interesting runtime properties of the Objective-C/Cocoa runtime that differentiate it from C and C++/Java. Hacker News mostly rants about the Smalltalk-like syntax.
njharman 15y ago
> Objective-C remains an impediment for many programmers Really!? If that's such an impediment maybe "many programmers" need to look for a new career. Or, go back to copy pasting PHP / hiding their schlubness amongst the other cogs in some Enterprise Java machine.
jinushaun 15y ago
Based on the comments, seems like most people's objections of Objective-C are really objections about C: header files, manual memory management, function pointers, strong type system, too low level, no native string object, etc. I grew up with C, so learning Objective-C took maybe 10 minutes because it's basically C with some extra syntax for OOP. In general, one only encounters the "strange" syntax when dealing with methods. I personally love the method syntax because it's basically self documenting. Which leads me to wonder, how many programmers both on HN and in general know C? I'm too young to already be a dinosaur in this industry... Where did all the C programmers go? Seems like programmers nowadays started learning how to code with Java or Ruby/Python and expect all other languages to be just as high level. Objective-C is low level, which makes it harder, but doesn't make it suck. As a language, I think Objective-C is a fine one, but I must admit that it is a "dinosaur". The real problem is OOP paradigm. Remember, back in the late 70s and early 80s, OOP was new and exciting and C was the dominant language. People were trying to figure out what OOP should look like and how to make C more OO. NextStep (Apple) just happened to bet on the wrong horse. Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today. Seems like some developers can't wrap their heads around a non-Java syntax for OOP. All that said, Objective-C survives only because Apple hasn't chosen another language to replace it for Mac and iOS programming.
- schrototo 15y ago
  > Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today. It's more than just a syntactic difference. Objective-C implements true message passing which is not the same as "method calling". You can send messages to a nil object, or have an object dynamically respond at runtime to a message it didn't declare at compile time etc. Some seem to think the brackets are just some kind of whimsy, but it's important that sending a message is not to be confused with calling a function.
- ams6110 15y ago
  I know C, but haven't used it in years. I had done a couple of projects in assembly language prior to picking up C and I think that really helped as I had no difficulty with the concepts of allocating and freeing memory, pointers, and the like that seem to be pain points for some.
stcredzero 15y ago
This makes the following situations possible: 1) You want to add a convenience method to someone else's object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI). 2) You want to change the behavior of a class you didn't (and can't) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa). 3) You want to treat objects generically and handle potential differences with runtime introspection. 4) You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object). One can do all of the above with the Go language. In addition, one could also write a reasonably performant compiler in it. (Also JIT dynamic language VMs are good enough now, that I've seen dynamic language parser/compiler implementations perform as well as a naively written Lex/YACC C implementation. And yes, companies paid money for the latter!)

101 points by stephth 15y ago

I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X. It's not horrible. I don't have any real problems with it. But I think its replacement is long overdue. Given that Apple has a long history of ditching huge swaths of its technology in favor of more modern alternatives, no matter if their userbase screams bloody murder or not, I'm surprised it hasn't happened already. This would be a good project for those billions they've got sitting in the bank. I think it would be great if they would anoint some successor as their new systems language, then port Cocoa to it. Programmers could use either objective-c or the new systems language for a few years, just as we used to decide between Cocoa and Carbon. Then objective-c could gradually fade into the past.

protomyth 15y ago
They did try to replace Objective-c with Java and that showed a lot of areas where a framework built for a dynamic language fails on a static language. I think Objective-C is a decent tradeoff of C and Smalltalk. I like the selector syntax as opposed to the C++ syntax.
- allenbrunson 15y ago
  They didn't actually try to 'replace' objective-c with java, though. It was just an alternative. In the early days of Mac OS X, many programmers were seduced by it, but they complained loud and long about having to learn this weird new language that had practically no adoption outside Apple. My guess is that Apple decided to give them java to quell the complaining. It wasn't adopted widely, so that was that. What they should be replacing objective-c with is something that looks more like, say, Python.
  - msbarnett 15y ago
    Well, Apple has been funding a lot of the development of MacRuby, possibly as an exploration of what it would take to anoint a popular scripting languages as a "nicer" alternative to Objective-C.
  - smackay 15y ago
    The big push for Java was with WebObjects and Apple's half-hearted push into enterprise systems. Initially Apple's version of Java (they wanted tight integration with Cocoa) was always a couple of revisions behind Sun's so that was always a source of frsutration with developers. With the new focus on consumer devices the enterprise space was left to wither and Java with it. Anything that is going to replace Objective-C must be at least as fast - Apples really cares about the customer experience not the developer experience.
gcv 15y ago
It's rather sad that Apple Dylan went nowhere. It would have been a terrific language to pair with Cocoa.
cubicle67 15y ago
that's fine, but what would they replace it with? Java? C#? not likely. C/C++? well, you can use them already I think MacRuby is the closest we have atm to something being groomed as a successor to Obj-C. It's got a way to go yet, but it's already at the stage where it's viable for smaller projects and there's a (small) number of MacRuby apps available on the OSX app store.
- noarchy 15y ago
  Any idea how much investment is taking place in MacRuby? If they're really interested in grooming a successor, I'd figure that there would be some serious work going on, behind the scenes. With the success of the platforms on which Obj-C is used, I don't know if a successor will be another language. An update to Obj-C itself might make perfect sense.
  - danieldk 15y ago
    Well apparently, MacRuby is already a private framework in Lion, so it serves some purpose in the eyes of Apple. http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-share/ http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-s...
- danieldk 15y ago
  I agree that MacRuby is the most likely 'successor' (or rather, alternative). Another advantage of MacRuby over some other 'scripting languages' is that it can be compiled to an executable via LLVM bytecode (per macrubyc). This will be appealing to anyone who doesn't want to give away his/her source code.
- jaes 15y ago
  why not just smalltalk? or f-script with inline C? either of these would really just be a more convenient syntax for most of the higher level code written now anyway (given my experience). the runtime is sufficiently flexible that a simple change in syntax with a friendlier IDE would get many people raving about how great the platform is in much the same way as those experienced with it do now.
patrickgzill 15y ago
Correct me if I am wrong, but there is a huge amount of Obj-C in the guts of OSX. Replacing it with another language would require a large RAM footprint as both older apps and new apps would require a large amount of shared libs to be loaded, for possibly not that much additional benefit.
- allenbrunson 15y ago
  I am very far from an expert at Mac OS X system internals, but I don't think objective-c is all that ingrained in the kernel. You write device drivers in a restricted subset of C++, as one example. userspace Mac and iOS programs have to link to an obj-c runtime library, but it's not much more onerous than linking to, say, libc or libc++. The big hit would be that, yes, there are gigabytes of objective-c frameworks installed, which would presumably have to be replicated in the new language. But I could see Apple finding a way to sidestep that issue. Maybe the new systems language and objc could both compile down to similar binaries. Painful or not, it's going to have to happen sooner or later. Objective-c is, in my opinion, the most outdated thing in Apple's technology stack. There will come a time when it is as big an albatross around their neck as Mac OS 9 was, which they waited far too long to replace.
  - mambodog 15y ago
    AFAIK MacRuby already works in this way, using the existing (Obj-C) Cocoa frameworks in conjunction with the MacRuby runtime.
Entlin 15y ago
John Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 http://arstechnica.com/staff/fatbits/2005/09/1372.ars http://arstechnica.com/staff/fatbits/2005/09/1372.ars Then he revisited it 10 months in 2010: http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis... And then he talked about it 2 weeks ago in the Hypercritical Podcast: http://5by5.tv/hypercritical/14 http://5by5.tv/hypercritical/14 Abstract: new language and new API go hand in hand. A memory managed combo trades execution speed for faster program creation. Was already needed 5 years ago. The recent garbage collection additions don't cut it. Microsoft started working on their successor (.net) 10 years ago and now it's starting to look good. Apple gained some leeway when the iPhone happened. With ever improving CPUs on mobile devices, Apple still risks losing ground down the line. Great podcast episode, I highly recommend it.
- ryannielsen 15y ago
  You could also argue that, given the current success of iOS and Mac, Cocoa isn't a significant hinderance to Apple's platform's success. (Not to say I wouldn't mind some significant advancements in Apple's preferred runtime, but there's strong evidence that the current runtime is actually quite suitable. If, as you say, .NET is only now starting to look good after a decade's worth of work, perhaps that wasn't the wisest investment on MS's part. Siracusa's been beating this drum for years and, like many of his crusades, I struggle to see how Apple suffers from not following his advice.)
makecheck 15y ago
It's fine to push for a better language, but so far you seem to be saying we should do it just because the current language is too old. What are specific things that are wrong with the language Objective-C 2.0 (and not just Cocoa, which is an API; and not just Mac OS X or iOS, which are platforms)? Why should Objective-C not just evolve into something a bit more interesting? And when considering any alternative, what are the most costly considerations for any developer, including Apple? The size of a code base is a significant factor. The fact that established code already works (new code may add bugs) is a significant factor. The wealth of knowledge already accumulated by programmers is a significant factor. A new language is very unlikely to win a war in those areas, so it would almost have to solve some other problem that is still costing developers a lot because they're using today's languages.
- allenbrunson 15y ago
  Good question! I can think of a lot of reasons why Apple should switch to a more modern systems programming language. We have all read pg's essays where he extols the virtues of Lisp, compared to other languages. His primary argument, as best as I can tell, is you can write programs with far less code than in other languages. Such an advantage would be a big win for the platform, and we may come to a time when Apple is forced to do it, because everybody else has, and they risk being left behind. Objective-C is becoming a weird frankenlanguage. It already was, arguably: a thin layer of smalltalk-like OO sitting on top of C. Just recently, Apple added blocks, which are like continuations in other languages. Maybe that's a good thing, but I think it would be a better thing if we went with a language that had those types of concepts from the beginning. It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was .Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit. The biggest argument I can think of for Apple not to try a new systems language is that their cash cow right now is the iOS platform. Doing this now would no doubt cause serious memory and CPU pressure on small devices which can't afford it. So knowing Apple, their likely answer to that would be to come out with a new generation of devices that are no longer compatible with objc, which you have to rewrite everything for.
mhd 15y ago
It took years to get (mostly) rid of Carbon. Heck, Cocoa still has the NextStep prefix. The amount of change Apple is willing to make can be hugely exaggerated, especially if they're able to control the respective technology (which they do mostly, one noticeable exception being desktop CPUs and GPUs).

killerswan 15y ago

With early iOS they were talking about a pretty serious use of JavaScript. I wouldn't be surprised if they pushed that more in the future... I've heard there is a lot of work being done to make Haskell play nicely with Xcode [1]. I don't know if Apple is experimenting with that, but they're probably kicking a lot of options around. [1] http://hackage.haskell.org/platform/mac.html http://hackage.haskell.org/platform/mac.html

pohl 15y ago
Did you paste the link you intended to? I don't see how it supports the idea that there is work being done to make Haskell place nicely with XCode.
- killerswan 15y ago
  Work being done by Haskell people, if not Apple people.
  - pohl 15y ago
    I'm not even getting that from the link. To me, the link only shows that I can download The Haskell Platform for my Mac. The only thing there related to XCode is that one needs to have it installed as a prerequisite for running the haskell platform's installer. This is no surprise because the installer wants to have the "unix development support" package available (it contains gcc, header files, misc command line tools in locations where run-of-the-mill Makefiles can find them...) and it's just incidental that one needs to run the XCode installer in order to get these basic unix amenities on the system.

mirkules 15y ago

Why it survives in a world of alternatives? There are no alternatives if you want to distribute on the most popular mobile platform. Personally, I really dislike Obj-C, but since I want to create apps on the iPhone I have no choice. Unfortunately, making a good business decision sometimes means going against your personal feelings. I think that's how a lot of other people approached it too. If the iOS platform changed overnight to Lisp, we would see articles titled "Why Lisp survives in a world of alternatives"

stephth 15y ago
The author is not arguing about how come objc is not dead, but about why Apple hasn't replaced it with a more popular language.
cppsnob 15y ago
> There are no alternatives if you want to distribute on the most popular mobile platform. Symbian, Blackberry and Android don't support Objective-C as far as I know. Only iOS does, which is far from the "most popular" mobile platform, especially if you look outside Silicon Valley just for a minute. [Edit] Also, for the record, you can program in C++ and distribute on iOS with minimal Objective C. I thought I'd point this out given my login name.
- sigzero 15y ago
  I think you both are arguing from different sides of "popular". You are stating popular by sheer numbers while he was stating it from a 3rd party developer prospective. I believe he was right in what he said.
ryannielsen 15y ago
> There are no alternatives if you want to distribute on the most popular mobile platform. This statement isn't entirely true: http://www.appleoutsider.com/2010/06/10/hello-lua/ http://www.appleoutsider.com/2010/06/10/hello-lua/ Cocoa is extremely strongly encouraged, but it's possible, under the current developer agreement, to distribute non-Cocoa applications on iOS.

jshen 15y ago

I wish Objective-C were more popular on linux, I like the way I can mix message passing style OO with C code.

rchowe 15y ago
There aren't really any good libraries for it. You can compile straight ObjC on linux fairly easily with gcc or clang (use -lobjc), but the thing is without NSString and all of the foundation you'll end up doing a lot of work. And yes, you can get into GNUStep, but that's a whole nother ballgame.

jrockway 15y ago

Objective-C's niche: it's the core of two popular operating systems. A lot of strange programming languages survive because of inertia. Emacs Lisp exists because Emacs was written by Lisp hackers. It survives because Emacs ships with a few million lines of Lisp. Replacing it would take hundreds of man-years. Objective-C survives for the same reason; Cocoa was expensive to write and rewriting it would serve no purpose. So it remains. Is anyone using Objective-C for some reason other than writing OS X or iOS apps?

_3u10 15y ago
No, and if there was an easy way to bind UIKit with out Obj-C I'd use it in a heartbeat. I'm seriously considering WAX for LUA. Obj-C has the flexibility of C with the speed of small talk.
- boucher 15y ago
  That strikes me as a pretty indefensible statement. Objective-C has an incredibly powerful runtime, which is nearly as flexible as the ruby runtime. It's also much much faster than ruby, and probably every other popular dynamic language.
  - fleitz 15y ago
    I'm sure the runtime is great, unfortunately the syntax sucks, there is no GC (on iOS) and it can't curry functions, and you can't put an NSInteger into an NSDictionary with out line noise that would do java proud, it doesn't support passing or currying functions. Sorry, but passing a selector and an object is atrocious, even MS can figure out how to pass a delegate that can figure out whether it needs to pass a this pointer before passing the rest of the arguments. It's lambda syntax is also attrocious [[ ^ (int x, int x) { return x+y; } copy] autorelease] , wtf is that garbage? In ruby I don't need to touch 2 different files and put code in 3 places just to define a property, nor do I have to do this in C# or F#. I doubt it's much faster than C# or F#, especially if it ever involves something simple like putting an integer in a hashtable. I'd hardly call a language dynamically typed when it will fuck up adding a long and an int. Seriously, define a type that takes an int, pass it a long and see what happens. This is exactly what I mean by the flexibility of C (attrocious type system) and the speed of small talk (incurring a call to objc_msg_send anytime you do anything)

zmitri 15y ago

After starting to read a bunch of objective C, I have to say there are some constructs that are very nice compared to an OO language like java -- for example, selectors and the target action design pattern. There's definitely some nice dynamic properties, but at the same time, some of the basic "methods/messages" for the Foundation APIs aren't very convenient to write and are strangely named. For example, compare NSString to strings in Java, Python, Ruby, etc.

veyron 15y ago

Has anyone used pyobjc or some other interface between objective-C and another language? Thoughts?

ammmir 15y ago
pyobjc is how i got exposed to objective-c. it's a joy to use if you have your app in python, but i've heard complaints about the python-objc bridge leaking memory, so you may end up doing memory management in python (alloc, init, etc.) on pyobjc-wrapped objects if you're not careful.
orangecat 15y ago
I used PyObjC a few years ago, and enjoyed it much more than straight Objective-C. Far less boilerplate, and the transparent mapping between Python lists and dicts and Cocoa's NSArray and NSDictionary is great.

ignifero 15y ago

Let's face it: in 2011, Obj-C has the sex appeal of COBOL. I think it's primarily a strategic decision: Just like apple likes to lock-in its customers with itunes, so it does with developers, locking them behind an unpopular language with a slow learning curve.

astrange 15y ago
The learning curve of Objective-C is about a day if you know C99. Did you have some specific problem?
cubicle67 15y ago
that doesn't make even a glimmer of sense
bonch 15y ago
Ignoring the disputable claims that it's unpopular or has a slow learning curve (you can describe Objective-C's additions to C in a single page), there's no evidence to claim that Objective-C is about customer lock-in, especially when you can use so many alternatives including the Apple-funded MacRuby. Apple uses Objective-C because they have a lot of code written in it, and it has served them very well. iOS is the most popular mobile platform for third-party development. The dynamic nature of the language has enabled the implementation of some useful features like key-value-observing, while the ability to drop to C retains the flexibility of system-level programming. Even the memory management criticism is overblown. You merely have to follow an easy list of four ownership rules. That's if you're not using the garbage collector that came out four years ago with Leopard.
- nupark2 15y ago
  If you follow those "easy rules," how do you handle race conditions between weak references held to avoid retain cycles and the execution of those weak reference's -dealloc methods? There's nothing to stop the weak reference's -dealloc from racing with messages to that weak reference. Or, how do you handle the fact that -dealloc can be called on whatever thread calls the last -release, even if you make an effort to only send messages to an object on the main thread (Which will trigger implicit retain/release unless you're incredibly careful). Almost all of the GCD examples out there are subtly broken because of this. As for GC, I look forward to actually being able to use it on iOS.

zoul 15y ago

I find it surprising that there are so many people bashing Objective-C here in the comments. I have been programming in Objective-C for living since the iPhone SDK came public and I came to love both the language and the libraries. I think that many people who despise Objective-C syntax are simply not programming long enough in the language to overcome the initial knee-jerk reaction. Mostly the issue seems to be the message passing syntax, which I find very readable and self-documenting. What else should matter if not this? Then there’s comments about speed. I have written two action games for the first-generation iPhones and I have never encountered a performance problem caused by the runtime. Over 99% of the time I could stick to high-level code without resorting to C to gain speed. That says a lot about performance for regular applications. Block syntax could be better, I can’t use closures with such ease as in Perl (for example). But this is one of the things that have to do with Objective-C being a relatively thin layer atop of C. And that I see as a huge win, because you can very easily and naturally mix higher-level Objective-C code with plain C APIs that are very common on most systems. And if you want some lower-level bit-twiddling trickery for performance reasons, you are free to go. For me, C is a very elegant language and Objective-C takes out most of its rough corners. Saying that Objective-C could be replaced by something “smarter” like Lisp or Haskell is simply ignoring the reality. Objective-C has very low language complexity, both the building blocks and their interactions are simple and there are few surprises. This is a huge advantage both for the newcomers and for programmers that deal with the stack most of their working hours. The manual memory management first seemed like a chore to me after coming to Objective-C from Java, but the rules are dead simple and after a few weeks you don’t think about the memory management any more. Yes, Objective-C is not hip. So what? It’s a pragmatic and reasonably expressive language that gets the job done. I don’t think that replacing it would serve any real purpose – and that’s a very good reason to survive.

tomjen3 15y ago
My biggest beef with Objective C is that it takes the most retarded feature of C++ -- that you have to write both a header and a implementation file (why oh why can't the compiler compile one?) -- and removes the really nice ability to allocate your object on the stack (which means memory allocation is really, really, cheap and you know when the object is deallocated).

ignifero 15y ago

The title of the post is very misleading: Obj-C would crash and burn if there were native, supported alternatives in OSX, it survives exactly because there are no alternatives.

ryannielsen 15y ago
Ok, that's simply not true. On Mac OS X, you're welcome to use any language and runtime you wish for your application. Hell, if you want to use a non-Objective-C language and still present a native experience, use PyObjC, RubyCocoa, MacRuby, or any other language that shims into the Objective-C runtime and get access to all of Apple's Cocoa frameworks in the language of your choice. The same is possible on iOS as well, with the (significant) condition that Apple must first explicitly approve your use of a non-Objective-C runtime before your app can be posted to the App Store. But in direct response to your post, Obj-C has a rather level playing field on OS X and still survives vs. the alternatives.
- blub 15y ago
  Welcome to use it, except: * it's not officially supported by Apple * it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs) * you can't use it on iOS * you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language
  - ryannielsen 15y ago
    > * it's not officially supported by Apple MacRuby is an Apple project. PyObjC isn't, but ships in Mac OS X. That's rather officially supported. > * it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs) Not true. MacRuby is a prime example of a language that taps directly into the Objective-C runtime, eliminating the need for a bridge. And PyObjC is a great example of a mature bridge – it's been around and robust since the NeXT era. > * you can't use it on iOS http://mobileorchard.com/announcing-iphone-wax-native-uikit-iphone-apps-written-in-lua/ http://mobileorchard.com/announcing-iphone-wax-native-uikit-... > * you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language You can't get jobs programming Ruby, Python, C#, Lua or any other language?

cageface 15y ago

Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and then to move transparently up to a much higher level of abstraction for non-critical code. With the relatively underpowered processors of today's mobile devices, this kind of control is important. However, Obj-C completely falls on its face for anything of real algorithmic complexity. Working with complex, nested data structures and more sophisticated algorithms is very awkward, and manual memory management only clouds things further. In the longer run this may become a liability for Apple.

zoul 15y ago
I fail to see how manual (or, in this context, explicit) memory management could “cloud things”. (It seems to me simply like many programmers can’t be bothered to invest the afternoon it takes to learn Cocoa memory management.) Also, could you elaborate why Objective-C makes it hard to work with nested data structures and sophisticated algorithms? In fact, I am struggling to find an example of at least a single general-purpose language that makes working with ”sophisticated algorithms” hard.
- uxp 15y ago
  I have never understood what is so difficult about Cocoa/ObjC's memory management. In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative. At least we don't have to declare how much memory to alloc and dealloc manually.
  - leon_ 15y ago
    If you just keep to "release what you alloc/new/copy" you'll be golden.
    - nupark2 15y ago

fingerprinter 15y ago

Obj-C survives b/c it is the only real way to write iPhone and iPad apps, plain and simple (ignoring Appcelerator and PhoneGap for the moment). If people had options, it is likely they would use the alternatives. Look at Linux. The "official" language will always be C, but there are toolkits for building GTK apps in Python, Vala, Mono and other even more obscure languages. Some pretty big apps have been written in each and people will continue to use those as long as they are viable options. If, however, someone big enough and with enough clout basically said "only native C/GTK apps will be accepted on our platform", you would see people migrate to that toolchain. It is simple economics. Apple has the clout (imo, unfortunately) to do that and have done it with Obj-C. They basically killed Java, which was an option up until I think 2 years ago. I can see Apple's perspective, supporting two toolkits is expensive and takes time, resource, energy and focus. In their mind, what benefit to they gain from supporting multiple toolkits? Developers? They know they are popular enough that the developers will take up Obj-C when Java was dropped. Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT DEVELOPERS except that they make apps to attract the users. I'm not saying what Apple did is right or wrong, but it does make sense from a strategic point of view. However, there is practically no merit to Obj-c on it's own. There are more compelling alternatives at nearly every turn, but NOT if you want to play in the iphone and ipad ecosystem.

cubicle67 15y ago
Are you seriously suggesting it would be better for everyone if developers wrote desktop apps for OSX in Java?! Apple didn't kill Java, Sun did. It was Sun who decided Java apps had to look different (in that special, ugly java kind of way), that they required 5+ seconds to start etc. Java could have been good for desktop apps if done right, but it wasn't and as a result there's very few desktop Java applications (and even fewer good ones). Java was also an awkward fit for Cocoa, lacking the dynamic ability required. Java has it's place, and being a language for desktop apps is not it
- fingerprinter 15y ago
  I think your misremembering. There was a Cocoa Java API that people could use to write native apps. That is what was killed. Pure Java (Aka. Swing) apps on the desktop is a different thing entirely.

Argorak 15y ago

meta tl;dr: The blog post talks about interesting runtime properties of the Objective-C/Cocoa runtime that differentiate it from C and C++/Java. Hacker News mostly rants about the Smalltalk-like syntax.

njharman 15y ago

> Objective-C remains an impediment for many programmers Really!? If that's such an impediment maybe "many programmers" need to look for a new career. Or, go back to copy pasting PHP / hiding their schlubness amongst the other cogs in some Enterprise Java machine.

jinushaun 15y ago

Based on the comments, seems like most people's objections of Objective-C are really objections about C: header files, manual memory management, function pointers, strong type system, too low level, no native string object, etc. I grew up with C, so learning Objective-C took maybe 10 minutes because it's basically C with some extra syntax for OOP. In general, one only encounters the "strange" syntax when dealing with methods. I personally love the method syntax because it's basically self documenting. Which leads me to wonder, how many programmers both on HN and in general know C? I'm too young to already be a dinosaur in this industry... Where did all the C programmers go? Seems like programmers nowadays started learning how to code with Java or Ruby/Python and expect all other languages to be just as high level. Objective-C is low level, which makes it harder, but doesn't make it suck. As a language, I think Objective-C is a fine one, but I must admit that it is a "dinosaur". The real problem is OOP paradigm. Remember, back in the late 70s and early 80s, OOP was new and exciting and C was the dominant language. People were trying to figure out what OOP should look like and how to make C more OO. NextStep (Apple) just happened to bet on the wrong horse. Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today. Seems like some developers can't wrap their heads around a non-Java syntax for OOP. All that said, Objective-C survives only because Apple hasn't chosen another language to replace it for Mac and iOS programming.

schrototo 15y ago
> Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today. It's more than just a syntactic difference. Objective-C implements true message passing which is not the same as "method calling". You can send messages to a nil object, or have an object dynamically respond at runtime to a message it didn't declare at compile time etc. Some seem to think the brackets are just some kind of whimsy, but it's important that sending a message is not to be confused with calling a function.
ams6110 15y ago
I know C, but haven't used it in years. I had done a couple of projects in assembly language prior to picking up C and I think that really helped as I had no difficulty with the concepts of allocating and freeing memory, pointers, and the like that seem to be pain points for some.

stcredzero 15y ago

This makes the following situations possible: 1) You want to add a convenience method to someone else's object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI). 2) You want to change the behavior of a class you didn't (and can't) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa). 3) You want to treat objects generically and handle potential differences with runtime introspection. 4) You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object). One can do all of the above with the Go language. In addition, one could also write a reasonably performant compiler in it. (Also JIT dynamic language VMs are good enough now, that I've seen dynamic language parser/compiler implementations perform as well as a naively written Lex/YACC C implementation. And yes, companies paid money for the latter!)