6 ms·

> 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 probl

by cglong 5y ago

> 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.

qaq 5y ago
When you need something like NSTableView that has no SwiftUI equivalent
- afavour 5y ago
  SwiftUI doesn’t but Swift will still work find with NSTableView.
  - qaq 5y ago
    Sure using a bit of Objective-C
vedosity 5y ago
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.
panic 5y ago
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.
- wott 5y ago
  > Obj-C feels more lightweight. That is something I wouldn't have thought I'd hear one day ;-)
thought_alarm 5y ago
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.
- matchbok 5y ago
  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.
  - thought_alarm 5y ago
    > 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.
thewebcount 5y ago
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?)
armadsen 5y ago
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++.

by cglong 5y ago

qaq 5y ago

When you need something like NSTableView that has no SwiftUI equivalent

afavour 5y ago
SwiftUI doesn’t but Swift will still work find with NSTableView.
- qaq 5y ago
  Sure using a bit of Objective-C

vedosity 5y ago

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.

panic 5y ago

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.

wott 5y ago
> Obj-C feels more lightweight. That is something I wouldn't have thought I'd hear one day ;-)

thought_alarm 5y ago

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.

matchbok 5y ago
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.
- thought_alarm 5y ago
  > 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.

thewebcount 5y ago

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?)

armadsen 5y ago

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++.