Earlier quoted context omitted.
I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.
The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.
Swift 5: start your engines
181–186 of 186 posts
Re: Swift 5: start your engines
#182Android studio start to be nice tool compared to Xcode..
Re: Swift 5: start your engines
#183Earlier quoted context omitted.
Languages are easy. It's always the frameworks (which are usually needed for any real world tasks) that are the killer.
> Languages are easy. Not always true, my favorite example being Idris. (but then again, it's all relative to what you know already)
Re: Swift 5: start your engines
#184Earlier quoted context omitted.
I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.
The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.
Re: Swift 5: start your engines
#185Re: Swift 5: start your engines
#186Earlier quoted context omitted.
Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern: https://en.wikipedia.org/wiki/Delegation_pattern So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible t…
> So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Why on earth would you have a single blocking thread on a UI app?
The tradeoff was that it took pages of boilerplate to make even the simplest app, and Apple got made fun of incessantly for it. So they largely fixed that with OS X's message passing metaphors, but unfortunately due to bloat and a lot of other reasons, the boilerplate issue came back, and now we're also stuck with untraceable program flow.
To answer the original question - I have worked on both blocking and nonblocking code, and unfortunately nonblocking code doesn't scale. It eventually becomes too complex to follow the flow. It's like comparing a coroutine to a state machine. My personal feeling is that we're in a kind of nonblocking bubble right now and that the callback style that pretty much all frameworks use today is not going to be the way it's done in the future. I don't know what will replace it, but it will likely be something more like Redux/Elm/Clojure and declarative GUI syntax like how the web used to work.