Soroush Khanlou, an iOS developer, writes about Swift, Objective-C, app architecture and functional programming ideas like monads.
Commenters recommend it as thoughtful and practical, and link posts on long Swift compile times and pure objects.
I've read a ton of such blog posts recently in exploring this subject - seems like the tradition is as soon as you believe you understand the monad you must immediately write a blog post explaining it and pointing out why everyone else's metaphor is too complicated.
This one is kind of nice in its succinctness, but that ends up meaning it doesn't explain why I should care or what I would do with my monad once I have grokked it.
I've yet to write my personal "how I grokked my monad and why everyone else is wrong" post, but I suspect that there's probably a sweet spot somewhere between 'monad is simply a monoid in the category of endofunctors' and a 'plain English' translation of the monad laws with no context. Preferably with an explanation of why I would want or need such a thing up front. Preferably without Haskell notation.
That said, such an intro would probably still be pretty hard going, some things are just hard, or at least difficult to understand without context. I said I've been reading lots of these recently, actually I've been reading them for a couple of years, but I've only been understanding them recently because I've bumped into a problem domain for which the solution I was groping for in the dark turned out to be a monad.
Swift wise, I found the following to be very…
I do think that there's a meaningful difference between writing code that was bad (which I definitely did and do) and writing code where I didn't know what each line did.
early on when I was doing iOS development I learned that "m34" was the magic trick to make flipping a view around have a nice perspective effect, and I didn't know what "m34" actually meant but I definitely knew what the effect of the line of code that mutated it was...
Googling on it now seems like a common experience for early iOS developers :)
https://stackoverflow.com/questions/14261180/need-better-and-simpler-understanding-of-catransform3d
https://stackoverflow.com/questions/3881446/meaning-of-m34-of-catransform3d
https://khanlou.com/2012/09/catransform3d-and-perspectives/
Not mentioned yet: Souroush Khanlou http://khanlou.com is always at the top of my list. Thoughtful and very practical material. Also Dave DeLong: https://davedelong.com/blog/
> I’ve missed Swift 2 & 3
In some ways this is an advantage to you. There was a fair bit of churn in that time period. Things have settled reasonably well now.
can also recommend this approach at the moment: http://khanlou.com/2016/12/guarding-against-long-compiles/
This makes XCode warn you about functions with long compile times.
You can bundle the parameters into plain/pure/humble objects where it makes sense.
https://khanlou.com/2014/12/pure-objects/
http://xunitpatterns.com/Humble%20Object.html
The promise of simplicity does not match the reality. It's explained well here, this was linked in the article too: http://khanlou.com/2013/12/kvo-considered-harmful/