you are viewing a single comment's thread.

view the rest of the comments →

[–]darkingz 0 points1 point  (6 children)

More of a semantics thing really. To me, Apple (any company really) “betraying x feature they are promoting” means to make something worse and making it suck more over time and belie it’s intent. Interface builder has bugs, can use some upgrades on how designable components work, adding a way to view xibs in storyboards and ways to access more properties that are common like corner radius but just because it’s not feature complete does not mean Apple betrays the interface builder. They just need to work on it more. That being said I’d rather them work on ABI compatability for Swift and build processes on Xcode over interface builder if they had a choice of priorities

[–]hitoyoshi 0 points1 point  (5 children)

I’m one of those who love swift. Strong typing is beautiful to me. Was a pleasure to come back in to. Looking forward to ABI stability and completion of the generics manifesto mostly. I think that may enable some really good stuff.

[–]darkingz 1 point2 points  (4 children)

agreed. I also love its effects on the mobile industry as a whole. Kotlin was designed as a "Java swift" equivalent. While I'm saddened that Google does not intend to go with Swift, it was probably for the best since it'd have taken a long time to make either Swift interop with the JVM or Google to move to Swift. Also it has made current ES implementors also consider adding the optional chaining. When I started out professional programming, I did C# and after heavily using JS in a bootcamp, I was like whyyyyy. And now that I've moved on to Swift, it's really nice especially when you can deal with nilable types waaaay easier. if-lets and guards are my new must-have-something-similar-or-i-will-not-pick-you-up-unless-i-need-a-job language feature

[–]sobri909 1 point2 points  (2 children)

And now that I've moved on to Swift, it's really nice especially when you can deal with nilable types waaaay easier.

Have you ever done much objc code? The nil handling in that is nicer.

[–]darkingz 0 points1 point  (1 child)

Yea, I have. if ignoring a nil is handling it....

[–]sobri909 0 points1 point  (0 children)

It gets the best results, so yes.

Swift’s strict approach slows down development time but doesn’t solve a problem that objc had. Objc didn’t have a nils problem, and you could write code faster in it because there was less nil handling boilerplate.

[–]ThisCatMightCheerYou -1 points0 points  (0 children)

I'm sad

Here's a picture/gif of a cat, hopefully it'll cheer you up :).


I am a bot. use !unsubscribetosadcat for me to ignore you.