Hacker News Reader

Comment by cglong | Hacker News Reader

> an app I developed, Clatters, where I use Swift, SwiftUI, Objective-C and C, the most appropriate programming language being used to solve each specific problem.

Slightly OT, but when might one choose to write part of a new app in Objective-C instead of Swift? From my understanding, Swift can call any ObjC code.

View on HN

The Swift naming convention makes it more difficult to learn, discover, and use large, complex APIs like AppKit and UIKit, so I'll often revert back to Objective-C when writing AppKit (and to a lesser extent, UIKit) when given the choice. It's common for me to still mix the two languages in a single app.

For example, this the AppKit API for pulling a URL off of the pasteboard:

    +[NSURL URLFromPasteboard:]

It's easy to find, since it has both URL and Pasteboard in the name.

The Swift version gets melted down to this:

    URL(from:)

which is obfuscated nonsense. Unless you already know that API exists, you'll never find it.

The Swift version of AppKit is littered with this kind of obfuscation. Since I don't code in AppKit very regularly, I usually just throw my hands up and switch to Obj-C whenever I start running into these kinds of road blocks.

The Obj-C naming convention has advantages and disadvantages, but has always been considered verbose. The Swift designers considered this a problem in need of a solution. As is almost always the case in software development and language design, the solution was a giant overreaction and overcorrection that just replaced one problem with another.

Huh? That makes no sense.

The Swift API is

    init?(from pasteBoard: NSPasteboard)

Which should autocomplete/hint while writing code. The documentation is in the type, not littered within the function name. Much more easier to read and write. The "pasteboard" is still very much in the function declaration.

Compared to the obj-C version:

    + (NSURL *)URLFromPasteboard:(NSPasteboard *)pasteBoard;

Not sure why they insist on no spacing, or sane formatting, for Obj-c. I still can't read most Obj-c - it's horribly designed.

> Which should autocomplete/hint while writing code

It does not. Parameter types and alternate parameter names are ignored by Xcode autocomplete.

If you want to use init(from:), you have to already know that it exists and does something good. Typically, you only find a method like that by looking at the Obj-C header. And that method is declared in the NSPasteboard header, not NSURL.

So, the problem is not the naming, but autocomplete in Xcode?

Or is it impossible to write a good auto-completer for Swift because Swift is rather unique in splitting function names into multiple strings?

IIRC, Xcode uses LSP; is that a bottle-neck?

I use Objective-C when using interfaces that require lots of C-style parameters. In particular Metal requires unsafe pointers to vertex and fragment data and I find the contortions you have to use to get Swift to send such data to Metal to be too much work. It’s just more straightforward in Objective-C. It can be done in Swift, but it ain’t pretty. (Or at least, it wasn’t the last time I tried, which admittedly was about a year ago. Maybe it’s better now?)

I’d compare choosing Objective-C over Swift to choosing C over C++. Swift offers a higher level of abstraction, but Obj-C feels more lightweight.

> Obj-C feels more lightweight.

That is something I wouldn't have thought I'd hear one day ;-)

I prefer to use Objective-C when using a C API that involves heavy use of pointers (buffer pointers, pointers to structs, requires mallocing things, etc.). It’s not that Swift can’t be used, it’s just that doing all of that is painful in Swift, and completely straightforward in ObjC.

I also occasionally need to use C++, which ObjC makes easy in the form of Objective-C++. Swift doesn’t (yet?) have any ability to interface with C++.

At my employer we use Objective-C++ to interface with some shared C++ code. Swift can use C directly but it can be useful to wrap a C library in an Obj-C interface to be easier to use in Swift.

When you need something like NSTableView that has no SwiftUI equivalent

SwiftUI doesn’t but Swift will still work find with NSTableView.

Sure using a bit of Objective-C

Reply on news.ycombinator.com