Re:Safari 14 added WebExtensions support, so where are the e...
by oblio on Monday January 18, 2021 @03:26AM
(#25819506)
To summarize, this is the most Apple of arguments, that you're making:
"You're holding it wrong."
Re:Safari 14 added WebExtensions support, so where are the e...
by dwaite on Monday January 18, 2021 @04:00AM
(#25819721)
Not quite - the origin of "You're holding it wrong" was a response to someone who was quite literally trying to illustrate the cellular signal attenuation issue by pressing down with their fingers on the gap between the two antennas.
I believe the parent was saying that the performance of xcode varies based on the project. This is true - breaking projects up into more modular setups has long optimized project build speeds. The quality you get out of your tools is in many cases based on how you use them.
"You're holding it wrong" would apply if you were deliberately using the tools in a sub-optimal way to try to prove a point.
Re:Safari 14 added WebExtensions support, so where are the e...
by josephg on Monday January 18, 2021 @03:59AM
(#25819706)
Yeah its 2021. There's no excuse for shipping software you know crashes every few hours of normal use. Or lags so badly you can't type sometimes. I doubt XCode in its current form would make it through Apple's own app store review process. Fix your software or replace your staff with people who can.
I choose to abandon programming for Apple's devices entirely rather than put up with xcode.
Re:Safari 14 added WebExtensions support, so where are the e...
by doctor_eval on Monday January 18, 2021 @03:57AM
(#25819691)
I think the parent was just trying to help. I’ve had similar problems with IngelliJ when I had the wrong project view open.
Re:Safari 14 added WebExtensions support, so where are the e...
by jamil7 on Monday January 18, 2021 @04:01AM
(#25819729)
I’ve noticed similar issues, it’s especially a problem with SwiftUI as nesting closures often feels natural there, my brand new M1 mini will still give me the “expression too complex” error on larger SwiftUI components.
For instance a sprawling project with an even split of Objective-C and Swift that constantly call into each other can bring SourceKit to its knees, as can some CocoaPods setups. Going Swift-only or even just reducing the surface between Objective-C and Swift to the absolute bare minimum can speed things up a lot.
As for writing style, there's a few things that can trip SourceKit up but I've found that the main things to avoid are chaining optionals too deeply and nesting closures too deeply (recommend keeping both to 2-3 tops) as well as casting to/from Any too often.