![]() (Can't find a quotable source at present) He seems more open to Swift these days than when that article was written. Marco Arment has talked about using Swift in new development for Overcast, although I don't believe he's rewriting existing code. I don’t feel I lost out on anything positive by waiting". "I also wouldn’t change the timeline in which I adopted Swift. "I will remember ObjC and the times we had together fondly, but after a year of being Swift-only I prefer making apps with it". Steve Troughton-Smith has tweeted recently about his work in converting all of his apps to Swift over the last year. Since then, Swift has evolved considerably. Yes, that article is nearly four years old. > Good swift code should generally be faster. IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.Īnd when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!Īs this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. You see, protocols in Swift can be adopted by both structs and classes. The C part of Objective-C (it is most of the actual language) is very static.Īlso, Swift has some pretty amazing dynamic performance pitfalls. > At runtime Swift can utilize static dispatch Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.Īnd there are languages with very comparable feature sets to Swift that are way faster to compile. > ObjC’s only innate advantage is compile time Performance isn't about what you believe should be true, but about what actually is true. I haven't really started into a big learning drive on SwiftUI, yet, so I hope it is in better shape, by the time I get to it. I understand that the SwiftUI documentation is being rapidly improved. ![]() It was so bad, a generous individual developed this site and companion app. Obviously, it was headerdoc-style, and no one was writing header docs, so I was constantly encountering empty pages. SwiftUI has some of the worst documentation I've ever encountered. I would have been lost, in my Swift education, without StackOverflow, although I hardly ever consult it anymore (mostly because it's rapidly becoming less useful not because I don't need the help). The main issue with using it as a documentation source, is that it can easily become "cluttered" especially as I use it in "back-and-forths," over particular commands. I am looking at ways of communicating information in formats other than longform text). I have been using Postman to communicate the API to another engineer that is not RTFM (I've come to learn that folks don't like reading stuff, these days. I have written a server-based framework, including spending a great deal of time developing API documentation, and was relatively recently introduced to Postman. Bringing a new language into the world requires massive amounts of high quality documentation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |