Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Objective-C

inessential.com

Post reply on HN
Print view View original

41–50 of 160 posts

Re: Why Objective-C

#41

Post by anextio »

vintagedave wrote: post #3

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy,…

>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.

Re: Why Objective-C

#42

Post by gwbas1c »

One of the things I miss about Objective C is just how easy it is to call into a C API, or otherwise include a C function if that's the easiest way to call into a C API.

I shipped a cross-platform C# project, and once I realized I could expose "ordinary C" from the Objective C part, it was very easy to integrate the two without using a framework. (It helped that the UI was 100% Objective C, so there wasn't much surface area between the C# and Objective C parts. We initially used MonobjC, but first I had to work around a shortcoming, and then we needed to remove MonobjC due to licensing and some of the newer C# integration layers were not available.)

Re: Why Objective-C

#44

Post by [deleted] »

tarentel wrote: post #14
seanalltogether wrote: post #7

At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.

I don't think objc has the equivalent of a null pointer exception. You can freely send messages to a deallocated object. Since ARC, it is rare, at least in my experience, running into any memory related issues with objc.

[deleted]

Re: Why Objective-C

#45

Post by e28eta »

Me1000 wrote: post #23
tarentel wrote: post #14

Earlier quoted context omitted.

I don't think objc has the equivalent of a null pointer exception. You can freely send messages to a deallocated object. Since ARC, it is rare, at least in my experience, running into any memory related issues with objc.

You can send messages to null, sendings messages to a deallocated pointer is going to be a bad time.

It’s nice not to crash, but unexpected null can still cause bugs in ObjC when the developer isn’t paying attention.

Having done both ObjC with nonnull annotations, and Swift, I agree that it’d be hard to forgo the having first-class support for Optionals

Re: Why Objective-C

#46

Post by estebank »

nicoburns wrote: post #39
vintagedave wrote: post #3

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy,…

> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all…

One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.

Re: Why Objective-C

#48

Post by Towaway69 »

zffr wrote: post #36
mikehall314 wrote: post #34

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html

Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino

More amazingly the guy doing the most recent maintaining[1] is a medical Professor at Freiburg Uni.

[1]: https://github.com/daboe01

Re: Why Objective-C

#49

Post by safercplusplus »

flohofwoe wrote: post #29

IMHO the one great feature of Objective-C (compared to C++) is that it doesn't interfere with any C language features. In C++ the C 'subset' is stuck in the mid-1990s, while Objective-C "just works" with any recent C standard.

Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of clang++ warnings about various things being C11 extensions and not ISO C++ compliant, but it does compile.

[1] https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...

Re: Why Objective-C

#50

Post by steeleduncan »

vintagedave wrote: post #6
frityet wrote: post #2

Good time to check out ObjFW [1], it's a cross platform ObjC framework that's just really awesome [1] https://git.nil.im/ObjFW/ObjFW

I hadn't come across this. Insane (if true, I've never tried) that GnuStep is not 100% compatible, surely that would be the point. How easy is it to port, say, a Leopard-era Objective C app to ObjFW?

I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok

- There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal

- OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories

- The runtime functions are not compatible at all, but most projects wouldn't touch those

- CoreFoundation and the other C APIs are not there at all, so you'll need replacements

- It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do

Post reply on HN