Live data from Hacker News

Swift 5: start your engines

lists.swift.org

181–186 of 186 posts

Re: Swift 5: start your engines

#181
post #173

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.

Absolutely right. This right here is the killer for me.

Re: Swift 5: start your engines

#183

Earlier 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)

If you know, say Agda, Idris is not hard. The point is the concepts in Idris are hard, not the language. People learning haskell as first language in universities have more difficulty learning OO language than we have as we already know many OO languages.

Re: Swift 5: start your engines

#184
post #173

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.

It is actually a solvable problem if you're willing to dig into the details of the file changes. It isn't pleasant, but welcome to life. Team members can make conflicting changes as long as someone is willing to dig through the mud to make them all agree with each other. I've been doing it personally for a long time, it isn't my favorite part of the job but it does enable significant parallel productivity.

Re: Swift 5: start your engines

#186

Earlier 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?

What I was trying to say is that in the olden days of say the 80s, Mac OS used cooperative threads and you just wrote a main loop that was completely self-contained. We made OS calls from there, the OS didn't call us with events like it does today (at least most of the time). So programs were much simpler to debug because we didn't have callback or goto hell.

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.

Post reply on HN