Sounds like you're re-making the arguments in the article without realizing it.
No amount of work will make the inherently complex less complex, but doesn't have to be more complicated than it has to be. That's what "as simple as possible" means. If you have to peel down a strange interpretation of a problem or a misguided attempt to "dumb it down" before you get to the complexity, it's definitely more complicated. Over-simplification is pretending the complex doesn't exist, or chipping away at some parts until it looks simple, or straight-up disbelieving that there are complex needs and forgoing them.
I haven't read "Don't make me think", but I have read other books by the same author and his general message is that everything should be clear and approachable such that you can tell what things are and spend your energy actually solving the problem or accomplishing what you want to accomplish.
> The author of this piece (and perhaps the author of "Don't make me think", which I haven't read) respects only the simple desires of the majority of users. S/he does not respect the complex desires and needs of minorities of users, nor the potential for the majority-user to refine and develop their needs and desires.
This reading pairs poorly with this quote from the article: "And I’ve found that good products, ones that respect their users, give them more control." If the author really was out to knee-cap software, that's an odd sentiment to hold. I think you're in agreement with the author, but somehow take offense at the word "simple", maybe taking it as meaning "stripped down in function". There are certainly a lot of products, services, companies and people who take it to mean that.
Implementation may be strictly mechanical if you have everything planned out NASA-binder style, but surely there'll still be a need to adjust the plan from time to time? Then there's debugging and maintenance, both of which may not require all your creativity all the time, but if you're creatively sapped, you're walking into it with a few tires already slashed. At least that's what I've found in my own experience. It's not that you have to be creative constantly, it's that you have to be able to summon up the capacity to be creative at any given time.
No points for "based on LLVM" and "opt-in as you please side by side with Objective-C"? (Side by side with Objective-C probably does not require the Obj-C runtime, but it's hard to see how it wouldn't want to use it.)
I did not predict ARC. I'm not a genius, oracle, memory management expert or compiler writer.
I love Siracusa, but what he's been saying is "well, they're gonna need something or they'll fall behind". Which is a fine bet and was a prescient analysis even in the rounds before. Copland 2010 was his idea in 2005 that they'd essentially have something new and modern by 2010, which they didn't, but they had started evolving Objective-C again and added GC, so they hadn't been completely standing around.
I made a separate bet, saying that "they're working on a new language with these characteristics". For four years, this was an insane idea, they're not going to go all that trouble just to chuck Objective-C, I was mad and should be ignored. This week, that line of dismissal argument changed into "in hindsight, he was only stating the painfully obvious and anyone could have done that", which is nice and weird and a reversal fit for Steve Jobs.
That said, both Siracusa and I completely missed ARC, which is basically probably what made Swift worthwhile.
Yes, I may have been wrong on that part. Or it was planned but not started yet. Or Chris Lattner read that post and thought "we've gotta get on that". Or whatever.
Regardless of that, a lot of details match (opt into it, side-by-side with C and Objective-C, compiler based on LLVM, not based on C, modern language, specifically made to match the frameworks).
This news post is from January. Nadella was appointed in February. Although he's been leading that department for years, so I guess you could say that, but it's not due to him becoming CEO.
Thanks, that's very kind. As you say, it all hinges on every single one of their big mistakes being correctable now and avoidable in the future. Microsoft doesn't have to figure out how to be Apple or Google or what have you; it has to figure out what products they're missing and what the products they already do have has to do in the year 2014 to be relevant. That's not completely different from what they did in the year 2004, but it won't be solved by serving up what they had in 2004 either, nor by skipping to what they think is the endgame.
Beacons are passive. They have an ID and you're supposed to know what that ID means by some other band of communication or intrinsic knowledge.
I can't find a use case for telling the Mona Lisa that you have a dentist appointment or a pending call. You will probably have to pair with the device to get ANCS to start relaying notifications; iBeacons couldn't work if they had to require pairing.
I never said they'd make a watch. I said it's curious that they're so obviously aiming it at a very resources-constrained device (or optimizing out the wazoo for energy efficiency) for which they don't have a client of their own or an announced third-party client. You'll note that they didn't announce "iOS in the Nebulous Theoretical Arbitrary People Transporter" and hope people take it from there.
With iOS in the Car, whatever they're using - probably AirPlay or something riding the various MFi (made-for-iWhatever) protocols - is already transmitting screen images. If they have a notification protocol like ANCS, they will probably not reinvent it, but iOS in the Car already involves several of their own protocols, so why use yet another connection - and if they do, why invent a new protocol and publicly document it for this use case?
Maybe it's about roaming notifications to OS X Mavericks, but there are no (revealed) commands for getting i.e. app icons.
Actually, whether they make a watch or not, it's very curious to see them introduce a new binary protocol in the open. If this is a turn towards being more open, I welcome it. It's far from enough, but it's a start.
No amount of work will make the inherently complex less complex, but doesn't have to be more complicated than it has to be. That's what "as simple as possible" means. If you have to peel down a strange interpretation of a problem or a misguided attempt to "dumb it down" before you get to the complexity, it's definitely more complicated. Over-simplification is pretending the complex doesn't exist, or chipping away at some parts until it looks simple, or straight-up disbelieving that there are complex needs and forgoing them.
I haven't read "Don't make me think", but I have read other books by the same author and his general message is that everything should be clear and approachable such that you can tell what things are and spend your energy actually solving the problem or accomplishing what you want to accomplish.
> The author of this piece (and perhaps the author of "Don't make me think", which I haven't read) respects only the simple desires of the majority of users. S/he does not respect the complex desires and needs of minorities of users, nor the potential for the majority-user to refine and develop their needs and desires.
This reading pairs poorly with this quote from the article: "And I’ve found that good products, ones that respect their users, give them more control." If the author really was out to knee-cap software, that's an odd sentiment to hold. I think you're in agreement with the author, but somehow take offense at the word "simple", maybe taking it as meaning "stripped down in function". There are certainly a lot of products, services, companies and people who take it to mean that.