5 ms·

SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible:

SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-animations https://github.com/amosgyamfi/open-swiftui-animations So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application, and that does look interesting, so you could write your crossplatform app logic in Zig, and only use Swift the UI That's the advantage that should be advertised, Kotlin tried with Kotlin-Native, seems like a good strategy

nusaru 3y ago
Second paragraph in OP: > One approach to building a native GUI for a cross-platform application is to write all of the business logic in a cross-platform language (C, Rust, Zig, etc.) and then write the platform-specific GUI code. This is the approach I take with my my terminal emulator and it works really well. As of the current date writing this post, 93% of my repository is business logic in Zig and C, and 4% is macOS-specific GUI code in Swift.
benatkin 3y ago
Are you suggesting that Zig never lets you just think about the problem? That's some terrible preoccupation with an idealized concept of a DSL. The swift code examples look kinda slick but it isn't a different paradigm any more than JSX is for building HTML. It seems like a form of The Bipolar Lisp Programmer. https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html > Lisp is like wielding an air gun with power and precision. Those Swift examples you show are very exciting, but it's best not to get carried away. It's the same as those that say that vim is terrible because it's modal and don't believe that vim programmers can think about the problem while they're typing because their brain is distracted with switching between modes.
FpUser 3y ago
>"So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application" I've heard that BS from MS reps when they visited our company sometime in 90s. They were telling us how we should have monkeys drawing forms in VB and gurus making main code in C/C++. Then I showed them Delphi. You had to see how sour their faces turned. >"You'll never be able to write that kind of code with Zig, or C or C++" Your statement looks totally wrong. Looking at code seems like simple "fluent" notation that is quite possible in languages you mentioned.
- deleted 3y ago
  [deleted]
- benatkin 3y ago
  "you could write your crossplatform app logic in Zig, and only use Swift the UI" The UI glue code would be nothing special, and not improved by Swift vs Java. The UI would be designed in a design tool. I like open source, so perhaps Penpot.
turdprincess 3y ago
The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack. Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to mention the extra wrapping layers your native code needs to smooth out the interactions between the shared and native layers. For sure there are settings where it makes sense to take this approach, especially if code is shared across more than two platforms. But just for iOS and Android I wouldn’t necessarily say it’s a more efficient solution. Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?
- andrekandre 3y ago
  > Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another? this is one of the biggest downsides the other big one is the code → write → test → deploy scenario is extremely slow to the point of extreme frustration (at least for kotlin multiplatform anyways) with these kinds of tools
- jb1991 3y ago
  > It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.
  - JimDabell 3y ago
    Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.
wudangmonk 3y ago
React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that. I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications does react represent the best we have managed to come up with?. I've used it as to me it kinda sucks but I have never worked on the UI side of anything except for small web frontends I always just assumed that in the 40+ years there were some better UI libraries but apparently not?.
- deergomoo 3y ago
  The main benefit of declarative UI frameworks is that they remove the need to manually reconcile changes in state with changes in the representation of that state (with the caveat that it often becomes difficult to do so if the DSL doesn’t cover the behaviour you want). UIs inherently have a hell of a lot of state that is constantly in flux, so it can become very difficult to manage those transitions correctly and efficiently. By providing a description of how an interface should look given some program state, the developer only need be concerned with the flow of data, and the framework can automatically create and apply the delta to update the UI in the most efficient way. For example, there’s no possibility to forget to re-enable a button in that rarely-used code path, because the “enabled” state is derived from the rest of your app state and any changes to that automatically cascade downwards. I’m not saying these things are a silver bullet (and I don’t even really do much UI stuff anymore), but when my job involved frontend web stuff, moving from jQuery to Vue was both an unbelievable jump in both productivity and a massive decrease in UI bugs (and LoC!).
  - benatkin 3y ago
    DSL stands for Domain Specific Language, not declarative. It is possible to be declarative without a hybrid DSL like JSX. Angular is declarative, but it doesn't mix html structures and js in the same way.
    - 3y ago

nusaru 3y ago

Second paragraph in OP: > One approach to building a native GUI for a cross-platform application is to write all of the business logic in a cross-platform language (C, Rust, Zig, etc.) and then write the platform-specific GUI code. This is the approach I take with my my terminal emulator and it works really well. As of the current date writing this post, 93% of my repository is business logic in Zig and C, and 4% is macOS-specific GUI code in Swift.

benatkin 3y ago

Are you suggesting that Zig never lets you just think about the problem? That's some terrible preoccupation with an idealized concept of a DSL. The swift code examples look kinda slick but it isn't a different paradigm any more than JSX is for building HTML. It seems like a form of The Bipolar Lisp Programmer. https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html > Lisp is like wielding an air gun with power and precision. Those Swift examples you show are very exciting, but it's best not to get carried away. It's the same as those that say that vim is terrible because it's modal and don't believe that vim programmers can think about the problem while they're typing because their brain is distracted with switching between modes.

FpUser 3y ago

>"So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application" I've heard that BS from MS reps when they visited our company sometime in 90s. They were telling us how we should have monkeys drawing forms in VB and gurus making main code in C/C++. Then I showed them Delphi. You had to see how sour their faces turned. >"You'll never be able to write that kind of code with Zig, or C or C++" Your statement looks totally wrong. Looking at code seems like simple "fluent" notation that is quite possible in languages you mentioned.

deleted 3y ago
[deleted]
benatkin 3y ago
"you could write your crossplatform app logic in Zig, and only use Swift the UI" The UI glue code would be nothing special, and not improved by Swift vs Java. The UI would be designed in a design tool. I like open source, so perhaps Penpot.

turdprincess 3y ago

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack. Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to mention the extra wrapping layers your native code needs to smooth out the interactions between the shared and native layers. For sure there are settings where it makes sense to take this approach, especially if code is shared across more than two platforms. But just for iOS and Android I wouldn’t necessarily say it’s a more efficient solution. Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?

andrekandre 3y ago
> Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another? this is one of the biggest downsides the other big one is the code → write → test → deploy scenario is extremely slow to the point of extreme frustration (at least for kotlin multiplatform anyways) with these kinds of tools
jb1991 3y ago
> It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.
- JimDabell 3y ago
  Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

wudangmonk 3y ago

React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that. I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications does react represent the best we have managed to come up with?. I've used it as to me it kinda sucks but I have never worked on the UI side of anything except for small web frontends I always just assumed that in the 40+ years there were some better UI libraries but apparently not?.

deergomoo 3y ago
The main benefit of declarative UI frameworks is that they remove the need to manually reconcile changes in state with changes in the representation of that state (with the caveat that it often becomes difficult to do so if the DSL doesn’t cover the behaviour you want). UIs inherently have a hell of a lot of state that is constantly in flux, so it can become very difficult to manage those transitions correctly and efficiently. By providing a description of how an interface should look given some program state, the developer only need be concerned with the flow of data, and the framework can automatically create and apply the delta to update the UI in the most efficient way. For example, there’s no possibility to forget to re-enable a button in that rarely-used code path, because the “enabled” state is derived from the rest of your app state and any changes to that automatically cascade downwards. I’m not saying these things are a silver bullet (and I don’t even really do much UI stuff anymore), but when my job involved frontend web stuff, moving from jQuery to Vue was both an unbelievable jump in both productivity and a massive decrease in UI bugs (and LoC!).
- benatkin 3y ago
  DSL stands for Domain Specific Language, not declarative. It is possible to be declarative without a hybrid DSL like JSX. Angular is declarative, but it doesn't mix html structures and js in the same way.
  - 3y ago