The 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.
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.
Bolted on wasn't a value judgement, it was literally bolted on top, it is a strict superset (unlike C++, which is also bolted on, but poorly, since it partially breaks compatibility).
The syntax growing over time is a real issue though. Every time I have to write __bridge_retain I get hives.
i love swift, but i can't help but feel the same... after all this time we still can't get good error messages or fast incremental compilation; it just feels like we are boiling the ocean to get largely the same features but handled by the compiler now instead of the runtime (which has a lot of value, but i feel theres a balance to be had there idk)
if they had really just done objective-c without the c like, the original moniker said...
> 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:
There are actually even better ways of accomplishing this, but this should give you an idea.
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.
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.