Comment by makecheck | Hacker News Reader

Comment by makecheck | Hacker News Reader

Parent Full thread

What disparaging remarks? I'm only stating exactly how Objective-C looks. It is a syntax I happen to like, too. Not sure how you thought otherwise.

Yes, when calling Objective-C, it compiles to C. But since the article talks about the idea of moving away from Objective-C, the only thing that matters is how source code currently is. The millions of Cocoa-dependent projects aren't using just C functions (even if they're compatible), their API calls follow Objective-C style. So, it is those calls that need to transition. It's not impossible, but it would be inelegant to move those API calls to a language that is significantly different than Objective-C style.

[Just so you know, I've been programming for over 20 years. I have years of experience with Objective-C on both Mac and iOS and dozens of projects under my belt, both for companies and open-source. I have used many different programming languages and know their strengths and styles very well. But you're right, you would not be hiring me...because I would definitely choose not to work for you.]

Every Objective-C class/object is a C structure. Every Objective-C message send is actually a C function call (objc_msgSend). Every Objective-C method is actually a C function definition. So, to the contrary, every Cocoa project is just using C functions, types and using the ObjC runtime.

The point you are trying to make is that porting an ObjC application to another language would be difficult because of the syntax of the language, notably, the interspersing of arguments within the method name. My point is that this has zero relevance to adopting a new application-level API.

An application-level API hooks into OS-level calls (which are not ObjC), which gets turned into assembly, which gets turned into machine code. The only way Cocoa applications would no longer run is if the Cocoa library could no longer bridge the the operating system or if they intentionally did not ship the Cocoa library. Thus, creating a new application-level API would deprecate Cocoa, but wouldn't render those applications useless.

Clearly, a company would have to transition to the new language/API. However, once again, the syntax of ObjC would not make it any more difficult or easy to make this transition compared to any other language. And this did not stop Apple 10 years ago, so I don't envision this stopping them again (C Carbon -> ObjC Cocoa; note that you can still make Carbon calls on Mac OS X).

All kinds of things compile down to assembly. Binary compatibility between two programs doesn't say anything about how easy it would be to translate their designs into other languages (which is often a new way of thinking), or different standard libraries. Many approaches are possible, few are worth the effort.

If Apple proposed a new language that didn't support message-passing syntax, and the only way to keep Cocoa dependencies working was with a pile of objc_msgSend() calls and other low-level wrappers, developers would just laugh at them. A single line of Objective-C often contains 3 or 4 pairs of square brackets, and objc_msgSend()-ifying that alone would be a nightmare even in the short term and even with a code generator.

That's why I said, the new language has to follow the same calling conventions. Fundamentally, whenever I see "setFoo:x toBar:y withBaz:z", I should be able to either leave that alone or do very little to that line of code.

Carbon-to-Cocoa was feasible because Objective-C is a superset of C (plus the libraries did share some things, like free casting between the CFStringRef and NSString* types). Not only that, but there's a compiler for Objective-C++. It was very easy to adopt.

So to follow the Carbon-to-Cocoa model, Apple needs a new language that's a superset of Objective-C. And that's actually something I'd like to see.

Reply on news.ycombinator.com