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

141–150 of 160 posts

Re: Why Objective-C

#141

Post by hackyhacky »

pjmlp wrote: post #131
hackyhacky wrote: post #119

Earlier quoted context omitted.

Sure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as: * rvalue references * the difference between auto, decltype, typeof * unreadable template monstrosities * various different flavors of "smart" pointer * the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc * total absence of a build system or package manage…

No worries, you get some of those in C23, and C2y. Where is C's build system and package management? Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.

You misunderstood. Perpetuating C's weaknesses, and then adding additional complexity, is not a defense.

Re: Why Objective-C

#142

Post by sinnsro »

pjmlp wrote: post #128
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,…

I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it. I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead. However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Programming languages are products, even those tha…

> we wanted Delphi and got Haskell instead

Please elaborate.

> However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.

Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility.

This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.

Re: Why Objective-C

#143

Post by LoganDark »

lightandlight wrote: post #139
LoganDark wrote: post #20

I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing s…

> Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth Any links? > Maybe this is also why Smalltalk fiends are such fans. I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.

> Any links?

For example, this guide I was reading just earlier: https://developer.apple.com/library/archive/documentation/Co...

Generally everything in that documentation archive is absolutely amazing. I don't know why it's an archive; presumably they laid off or reassigned the entire team working on it and there will be no more. The closest thing today would probably be Technotes: https://developer.apple.com/documentation/technotes

Re: Why Objective-C

#144

Post by pjmlp »

hackyhacky wrote: post #141
pjmlp wrote: post #131

Earlier quoted context omitted.

No worries, you get some of those in C23, and C2y. Where is C's build system and package management? Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.

You misunderstood. Perpetuating C's weaknesses, and then adding additional complexity, is not a defense.

It kind of is, when the goal was to be TypeScript for C, before this was even a concept.

Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.

Re: Why Objective-C

#145

Post by pjmlp »

sinnsro wrote: post #142
pjmlp wrote: post #128

Earlier quoted context omitted.

I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it. I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead. However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Programming languages are products, even those tha…

> we wanted Delphi and got Haskell instead Please elaborate. > However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utilit…

> Please elaborate.

Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it.

Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags.

> Users also request those features.

Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next.

Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.

Re: Why Objective-C

#146

Post by tarentel »

favorited wrote: post #107
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 `nil`, but the inverse isn't universally true. APIs like [text stringByAppendingString:other]; will throw an `NSInvalidArgumentException` if `other` is nil.

That is an API choice from Apple that isn't something inherent to objc. This is true of any method. It is up to the person who wrote it to decide how to handle a nil being passed in.

Re: Why Objective-C

#147

Post by zadikian »

mpweiher wrote: post #125
zadikian wrote: post #114

Earlier quoted context omitted.

So you silently ignore something being null when you don't expect it to be? That sounds even worse.

It's just that pointer?.doSomething() is the default. Le horreur!

The Swift way is safer, but I don't like it much either. The ? explicitly says you want to ignore null, so that's fine. The problem is there's no convenient way to throw exception if null, so you're encouraged to overuse ?, as I think you alluded to. (! will crash the entire program instead.) Swift error handling is overall pretty complex too.

Ironically the JS or Py error handling is actually the safest for high-level code. Exceptions are easy to work with and hard to ignore by accident. Very few ways to crash entirely. And Rust's errors are good for systems code.

Re: Why Objective-C

#148

Post by favorited »

tarentel wrote: post #146
favorited wrote: post #107

Earlier quoted context omitted.

You can send messages to `nil`, but the inverse isn't universally true. APIs like [text stringByAppendingString:other]; will throw an `NSInvalidArgumentException` if `other` is nil.

That is an API choice from Apple that isn't something inherent to objc. This is true of any method. It is up to the person who wrote it to decide how to handle a nil being passed in.

Frankly, all of this is an API and ABI choice from Apple. It was not the case that sending a message to nil always returned nil/NULL/0 before Apple's Intel transition, and the subsequent introduction of their modern Objective-C ABI. From Apple's 2006 Cocoa coding guidelines:

> If the message sent to nil returns anything other than the aforementioned value types (for example, if it returns any struct type, any floating-point type, or any vector type) the return value is undefined

And from the Intel transition guide:

> messages to a nil object always return 0.0 for methods whose return type is float, double, long double, or long long. Methods whose return value is a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, will return 0.0 for every field in the data structure. Other struct data types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.

This wasn't just a theoretical issue, either. You could run the same Objective-C code on a PPC Mac, an Intel Mac, the iPhone Simulator, and an iPhone – you'd get a zero-filled struct on Intel and the Simulator, while you'd get garbage on PPC and on real iPhone hardware.

Re: Why Objective-C

#150

Post by andrekandre »

umpalumpaaa wrote: post #122
andrekandre wrote: post #109

Earlier quoted context omitted.

> you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...

Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind.. Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hoo…

  > And it introduces new issues: which methods are being called depends on your imports.
also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift)

  > objc also has lightweight generics. In practice this is all you need.
i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...
Post reply on HN