alt Hacker NewsThe problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime.
Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's performance in the process.
SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, rather than treating them as deprecated implementation details that devs nonetheless keep having to drop down into.
These decisions come down to ego, of wanting to do away with the old and carve out your own legacy separate from it. Nice if you want a promotion but not so nice if you're trying to make a long lasting ecosystem for developers to build upon.
At least Swift and SwiftUI have a reasonable interoperability story with the past. Can't say the same about Microsoft's graveyard of UI frameworks.
Replies
> Swift should have just been a much improved syntax over that same runtime
That's exactly how Objective-Smalltalk started, and it's still very good at being just that.
https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
However, it has grown to be, er, a bit more.
https://2024.splashcon.org/details/splash-2024-Onward-papers...
> SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit,
I am also working on a UI "framework" I call InterScript that is (for starters) a wrapper over UIKit and AppKit, and basically solves what I perceive to be the biggest problems of Cocoa:
1. UI specification using object literals. This makes UI-creation very compact and readable. The following example (mostly) reproduces a SwiftUI "Form" example from Apple documentation:
#Grid{ frame: (20@20 extent: 400@340), #rows: [
[ #Label{ text: 'Name' }, #TextField{ stringValue: 'Taylor', frame: (200@24) } ],
[ #Label{ text: 'Email' }, #TextField{ stringValue: '[email protected]', frame: (200@24) } ],
[ #Label{ text: 'Notifications' }, #NSSwitch{ state: 1 } ],
[ #Label{ text: 'Sounds' }, #NSSwitch{ state: 1 } ],
[ #Label{ text: 'Summary' }, #PopUp{ items: [ 'Daily', 'Weekly', 'Monthly' ] } ],
[ #Label{ text: 'Color scheme' }, #NSSegmentedControl{ segments: [ 'System', 'Light', 'Dark' ] } ],
[ #Label{ text: 'Text size' }, #Label{ text: 'Default' } ],
[ #Button{ title: 'Reset All Settings' } ],
] }.
2. Better communication between model and UI by using the support in the language for polymorphic identifiers and dataflow. Because dataflow is in the language, it can be expressed succinctly without making it hidden magic like in SwiftUI. With dataflow and polymorphic identifiers, you also get a dataflow-constraint mechanism similar to Cocoa Bindings, but again with proper support and less magic.
Essentially the solution to this:
https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an...
There is more, for example cross-platform, MDA/Naked Objects/Direct2Web style simplification and web integration with HTMX and HTMXNative.
Gotta take issue with the characterization of “bolted on”. That’s a design feature and it’s huge. It made interoperability trivial. You can write C, C++, and Objective-C within the same source file.