5 ms·

I'm still fairly new at Swift and like it "OK" so far. One thing that I find particularly annoying however is how you very often run into "Compiling failed: the

I'm still fairly new at Swift and like it "OK" so far. One thing that I find particularly annoying however is how you very often run into "Compiling failed: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" when using SwiftUI... It's just shocking to me that the compiler is asking me to help it out.

charliebwrites 2y ago
SwiftUI errors in general are mostly unhelpful. It will go so far as to suggest a change in a thing only for the developer to find out the cause was completely unrelated or even in a model in a different file. Helpful error messages for SwiftUI would go a long way
- jakey_bakey 2y ago
  You just gave me flashbacks to 1.0 in 2019
  - ben_w 2y ago
    In my case, Metrowerks CodeWarrior student edition in the late 90s, when I was going though "C for Dummies" in highschool. Miss a semicolon, every line after but not including the one with the error. ResEdit was better in the 90s than SwiftUI was in Xcode last year. Hoping to find that standard will be re-achieved when I install the update…
    - deleted 2y ago
      [deleted]
- alexashka 2y ago
  Admitting SwiftUI to have been a mistake and reinvesting back into AppKit and UIKit would go a long way. In what other industry does anyone use text to create visual layouts? We still do drag and drop to design the layouts anyway, followed by re-creating the drag and drop version... using text... It's all quite maddening if you try and make sense of it.
  - josv 2y ago
    iOS and macOS had a visual editor forever. Interface Builder was a really interesting take on visual layout, instantiating real objects in the interface and serializing them into nib / xib / storyboard files ready for use in your app. Most developers I know in the ecosystem tried and tried to like the visual editor, but ended up falling back to code. Why? Source code is pretty great. It’s easy to read, write, share, diff, and organize. SwiftUI has, again, a very modern and interesting take on visual editing. The code is the truth, but there’s a rich, realtime preview canvas that makes rountripping possible. For reasons, it’s unfortunately all but unusable for a lot of folks with complex Xcode projects, but it’s a very good idea. In summary: Visual layout editors and text are both pretty great. The devil’s in the details.
    - deleted 2y ago
      [deleted]
    - jwells89 2y ago
      I find that Interface Builder, while not great for editing XIBs on iOS and storyboards on either platform (it's slow and buggy in those cases), is actually still fairly pleasant when working on Mac XIBs. My go-to is pure code UIKit on iOS, but I still reach for XIBs frequently for Mac stuff. If IB's performance and stability issues could be fixed, I think its biggest problem is the near-unintelligible spaghetti XML that it generates for XIBs and storyboards, which is a huge pain for VCS and frequently cause of merge conflicts (which must be manually corrected). If they just cleaned up the XML output or switched to something more friendly to manual editing that'd help a lot.
    - raydev 2y ago
      Android Studio (before Jetpack Compose) split the difference and offered easily editable/readable XML with textual autocomplete AND a visual editor. I much preferred that after having spent years working in Xcode's Interface Builder. xibs and storyboards were also XML but IB would insert attributes that had no visual impact, move lines of XML around simply upon opening the file, or randomly change x/y values of the viewport upon opening the file, or update float values to use 15 decimal places instead of 2, and so on. Apple's insistence on making the visual editor have priority over text led to a worse developer experience as teams grew.
jwells89 2y ago
I think SwiftUI is actually causing Swift a lot of reputation damage. I rarely see the issues common to moderately complex SwiftUI views when writing Swift with code-only AppKit/UIKit, for a CLI program, etc.
- hombre_fatal 2y ago
  I jumped directly into SwiftUI for a few macOS apps I published, and the weird performance issues / UI lag / Compose complexity for even simplistic apps were hard to navigate, even after a year. Yet rewriting components in AppKit/UIKit feels regressive since even Apple's docs migrated to SwiftUI, but sometimes that was the right answer to regain some control over what was going on. Though some of that was limited to macOS which seems to get a lot less attention from Apple than iOS, or because you're naturally building more complex layouts on macOS. But it always makes me appreciate how much better the kit is for building web frontends.
  - jwells89 2y ago
    Most of the layouts I've built on macOS are actually simpler than their iOS counterparts because the mode of interaction is so different. Getting data onto the screen in a somewhat natural way is usually less of a contorted process because one doesn't need to deal with a software keyboard, a narrow viewport, lots of scrolling, etc. The problem with SwiftUI on macOS in my opinion is that it's just not well-suited to the types of layouts common on desktop and especially macOS. It's best at uniform grids and lists which is more of a mobile thing. On macOS you want things like visually balanced whitespace, optical centering of labels+controls in forms, etc which are often rather arbitrary and exactly the thing that SwiftUI is worst at.
- felipefar 2y ago
  I've heard about SwiftUI just some months ago, and was initially excited about the demonstration in WWDC, so I started to pay more attention to it. Now I've been reading comments on how it doesn't handle well more complex UIs, but haven't really read anything in depth. Can you recommend any resources on that?
w10-1 2y ago
> the compiler is asking me to help it out Yeah, this sucks, but it's also mind-boggling. The SwiftUI body result builder returns "some View" which means the compiler has to infer the specific type that the function produces, as a complex combination of whatever different if/then and while loops, along with their transitive function applications and closure contexts (where the type inference can be outside-in instead of inside-out). Then layer in in the @Observation macro magic for observing data types and re-building views when data changes, Swift Data pulling with fully typed predicates from a data store automatically replicated across devices.... It's like rocket thrusters from every angle, and pretty easy to start tumbling off the happy path.
amimetic 2y ago
There is an article about this based on a Chris Lattner talk/links to previous HN discussions: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
- djoldman 2y ago
  This is absolutely wild.
- gwd 2y ago
  Wow. I think sometimes you just don't know how things are going to turn out until you use something "in anger", as they say here in the UK. "Let's try using this fancy type-checker in a production language" is reasonable. "Let's overload + so you can combine things easily" is reasonable. "Let's allow you to express different kinds of types as a string" sounds pretty cool too. How could you know the combination of all of those would change a simple expression with an invalid type in it into a 42-second compile time with a cryptic error message, except by actually doing it? EDIT: Meanwhile, over here in go-land, I just got annoyed that adding a new external authorization library took the average compile time of my 20k project from 7s to 9s.
lenkite 2y ago
Saw this on a video-stream while the poor coder was struggling..you could see his BP rising.

charliebwrites 2y ago

SwiftUI errors in general are mostly unhelpful. It will go so far as to suggest a change in a thing only for the developer to find out the cause was completely unrelated or even in a model in a different file. Helpful error messages for SwiftUI would go a long way

jakey_bakey 2y ago
You just gave me flashbacks to 1.0 in 2019
- ben_w 2y ago
  In my case, Metrowerks CodeWarrior student edition in the late 90s, when I was going though "C for Dummies" in highschool. Miss a semicolon, every line after but not including the one with the error. ResEdit was better in the 90s than SwiftUI was in Xcode last year. Hoping to find that standard will be re-achieved when I install the update…
  - deleted 2y ago
    [deleted]
alexashka 2y ago
Admitting SwiftUI to have been a mistake and reinvesting back into AppKit and UIKit would go a long way. In what other industry does anyone use text to create visual layouts? We still do drag and drop to design the layouts anyway, followed by re-creating the drag and drop version... using text... It's all quite maddening if you try and make sense of it.
- josv 2y ago
  iOS and macOS had a visual editor forever. Interface Builder was a really interesting take on visual layout, instantiating real objects in the interface and serializing them into nib / xib / storyboard files ready for use in your app. Most developers I know in the ecosystem tried and tried to like the visual editor, but ended up falling back to code. Why? Source code is pretty great. It’s easy to read, write, share, diff, and organize. SwiftUI has, again, a very modern and interesting take on visual editing. The code is the truth, but there’s a rich, realtime preview canvas that makes rountripping possible. For reasons, it’s unfortunately all but unusable for a lot of folks with complex Xcode projects, but it’s a very good idea. In summary: Visual layout editors and text are both pretty great. The devil’s in the details.
  - deleted 2y ago
    [deleted]
  - jwells89 2y ago
    I find that Interface Builder, while not great for editing XIBs on iOS and storyboards on either platform (it's slow and buggy in those cases), is actually still fairly pleasant when working on Mac XIBs. My go-to is pure code UIKit on iOS, but I still reach for XIBs frequently for Mac stuff. If IB's performance and stability issues could be fixed, I think its biggest problem is the near-unintelligible spaghetti XML that it generates for XIBs and storyboards, which is a huge pain for VCS and frequently cause of merge conflicts (which must be manually corrected). If they just cleaned up the XML output or switched to something more friendly to manual editing that'd help a lot.
  - raydev 2y ago
    Android Studio (before Jetpack Compose) split the difference and offered easily editable/readable XML with textual autocomplete AND a visual editor. I much preferred that after having spent years working in Xcode's Interface Builder. xibs and storyboards were also XML but IB would insert attributes that had no visual impact, move lines of XML around simply upon opening the file, or randomly change x/y values of the viewport upon opening the file, or update float values to use 15 decimal places instead of 2, and so on. Apple's insistence on making the visual editor have priority over text led to a worse developer experience as teams grew.

jwells89 2y ago

I think SwiftUI is actually causing Swift a lot of reputation damage. I rarely see the issues common to moderately complex SwiftUI views when writing Swift with code-only AppKit/UIKit, for a CLI program, etc.

hombre_fatal 2y ago
I jumped directly into SwiftUI for a few macOS apps I published, and the weird performance issues / UI lag / Compose complexity for even simplistic apps were hard to navigate, even after a year. Yet rewriting components in AppKit/UIKit feels regressive since even Apple's docs migrated to SwiftUI, but sometimes that was the right answer to regain some control over what was going on. Though some of that was limited to macOS which seems to get a lot less attention from Apple than iOS, or because you're naturally building more complex layouts on macOS. But it always makes me appreciate how much better the kit is for building web frontends.
- jwells89 2y ago
  Most of the layouts I've built on macOS are actually simpler than their iOS counterparts because the mode of interaction is so different. Getting data onto the screen in a somewhat natural way is usually less of a contorted process because one doesn't need to deal with a software keyboard, a narrow viewport, lots of scrolling, etc. The problem with SwiftUI on macOS in my opinion is that it's just not well-suited to the types of layouts common on desktop and especially macOS. It's best at uniform grids and lists which is more of a mobile thing. On macOS you want things like visually balanced whitespace, optical centering of labels+controls in forms, etc which are often rather arbitrary and exactly the thing that SwiftUI is worst at.
felipefar 2y ago
I've heard about SwiftUI just some months ago, and was initially excited about the demonstration in WWDC, so I started to pay more attention to it. Now I've been reading comments on how it doesn't handle well more complex UIs, but haven't really read anything in depth. Can you recommend any resources on that?

w10-1 2y ago

> the compiler is asking me to help it out Yeah, this sucks, but it's also mind-boggling. The SwiftUI body result builder returns "some View" which means the compiler has to infer the specific type that the function produces, as a complex combination of whatever different if/then and while loops, along with their transitive function applications and closure contexts (where the type inference can be outside-in instead of inside-out). Then layer in in the @Observation macro magic for observing data types and re-building views when data changes, Swift Data pulling with fully typed predicates from a data store automatically replicated across devices.... It's like rocket thrusters from every angle, and pretty easy to start tumbling off the happy path.

amimetic 2y ago

There is an article about this based on a Chris Lattner talk/links to previous HN discussions: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/

djoldman 2y ago
This is absolutely wild.
gwd 2y ago
Wow. I think sometimes you just don't know how things are going to turn out until you use something "in anger", as they say here in the UK. "Let's try using this fancy type-checker in a production language" is reasonable. "Let's overload + so you can combine things easily" is reasonable. "Let's allow you to express different kinds of types as a string" sounds pretty cool too. How could you know the combination of all of those would change a simple expression with an invalid type in it into a 42-second compile time with a cryptic error message, except by actually doing it? EDIT: Meanwhile, over here in go-land, I just got annoyed that adding a new external authorization library took the average compile time of my 20k project from 7s to 9s.

lenkite 2y ago

Saw this on a video-stream while the poor coder was struggling..you could see his BP rising.