Just when I thought Lisp had been ransacked for every last feature that language designers were willing to steal, the "War on commas" pops up -- complete with discussion of the essential differences might exist between "(" and "{", the pain of needing another way to say "if", and the lack of support for the rest of the language. And the last couple interesting Swift libraries I saw had .gyb files and #if directives.…
many modern languages have macros: rust, crystal, elixir, nim not very corporate though, but getting there? with rust(mozilla a bit and others)
SwiftUI Defaults Considered Harmful
101–110 of 135 posts
Re: SwiftUI Defaults Considered Harmful
#102I really don't think this is a good criticism of SwiftUI. The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about comm…
Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.
Re: SwiftUI Defaults Considered Harmful
#103Earlier quoted context omitted.
JSX is 'just' an XML-like syntactic sugar for making nesting function calls nicer in Javascript. Yes, its a DSL, but it keeps the "domain" extremely small and it transpiles in a very straightforward way down plain javascript madeofpalk // is syntactic sugar for React.createElement(Container, null, React.createElement(Text, { weight: "bold" }, "madeofpalk"), React.createElement(Image, { src: profilePic }) ); Whenever…
I guess I'm not sure why this is better than the Kotlin/Tornado/SwiftUI approach of allowing you to move a lambda in the last parameter visually out of the function. So: container { text(weight = "bold") { "madeofpalk" } image(src = profilePic) } It seems more logical and consistent with the rest of the language. The only reason for the HTML-like syntax is JavaScript's tight connection to the web, after all.
JSX does not have conditionals or loops in its syntax. SwiftUI does.
Re: SwiftUI Defaults Considered Harmful
#104Earlier quoted context omitted.
Yeah, I did think it was amusing reading that on my 27" 2550px wide monitor monitor that the site formatted it so narrowly. https://i.imgur.com/VG31Kpj.png
For body copy that line length is pretty much ideal (for readability), but the code blocks could definitely benefit from being as wide as possible...
Re: SwiftUI Defaults Considered Harmful
#105I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…
> ... after having done a lot of React development recently ... All this prompted me to finally give react-native a try. In under 15 minutes I had a working example. The fact that you, a React developer with lots of experience with React were able to come up to speed vastly quicker on React Native shouldn't be surprising, that's a feature of the platform. You are the exact sort of person React Native was designed to…
Re: SwiftUI Defaults Considered Harmful
#106I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…
”after having done a lot of React development recently […] All this prompted me to finally give react-native a try. In under 15 minutes I had a working example“ I agree SwiftUI is poorly documented and (from what others say), probably, not quite production ready, but I also guess that comparison is a bit unfair. Or are react and react-native completely different beasts?
> Or are react and react-native completely different beasts?
The language is the same, and the core concepts are the same, but the SDK's are completely different. You are using different build tools, different API's, different platforms. It's not HTML-in-JS. So a React developer is not going to be fluent in react-native by default.
Re: SwiftUI Defaults Considered Harmful
#107I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…
> Oh and recompiling took a minimum of 30 seconds each time. For a simple hello world SwiftUI app? I just checked a project I had open in xcode and it recompiled in under 1s. Thats on a mid range 2013 MBP. > After making a change I saved the file, alt-tabbed to the simulator and the changes were already applied. I guess Apple is aiming to get something like this experience through previews, which are a little broken…
Re: SwiftUI Defaults Considered Harmful
#108I really don't think this is a good criticism of SwiftUI. The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about comm…
The author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well. Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.
Re: SwiftUI Defaults Considered Harmful
#109Earlier quoted context omitted.
Aw..heck. I'm not gonna get into back-and-forth. I will say that I have been developing Apple software for 34 years, so I tend to be a little on the.."hard-boiled cynic" side. I have taken OpenDoc and QuickDraw GX classes, because they were "The Next Big Thing." I also busted my butt, making sure that my apps were "Copeland-ready" (Darn it, now I have to do fifty push-ups) . I've learned that it's a good idea to stan…
Leaning towards the careful end of the spectrum, I can respect that. Especially once you're fast with UIKit, and Auto Layout. And Auto Layout kinda proves your last point; there's absolutely nothing "auto" about it.
It took me a couple of years to figure out how to use it properly.
Like I said, we're on the right track, and I doubt that Apple will let this fall by the wayside. I think they were planning this at about the same time that they started dreaming up Swift.
Re: SwiftUI Defaults Considered Harmful
#110I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes. After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples…
I think the picture is darker than what you’re describing : as long as apple doesn’t provide a real cross-platform environment (like google does with flutter, or facebook with react) then it doesn’t really matter what they end up doing with swift UI.
My intuition is that they know it, and that they’re working on something pretty big in that field, maybe as an improved , cross-platform version of swift ui. That would explain the lack of documentation (why document something that’s only a temporary version of a tech). But maybe i’m dreaming and everybody at apple live in its own bubble...