Earlier quoted context omitted.
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
That just sucks for you . I am not you . 10-14 hours a day is the norm and I still get in the gym, dinner with the wife, vigorous sex, a few games of vain glory and other facets of "normal life". I also take weeks off at a time because I mostly work for myself. In fact, I've been traveling for the last 4 years (I moved to Vietnam from NYC about a year ago). So, it might suck for you, but I would hardly say my life su…
The Death of Cocoa
61–70 of 118 posts
Re: The Death of Cocoa
#62Earlier quoted context omitted.
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
That just sucks for you . I am not you . 10-14 hours a day is the norm and I still get in the gym, dinner with the wife, vigorous sex, a few games of vain glory and other facets of "normal life". I also take weeks off at a time because I mostly work for myself. In fact, I've been traveling for the last 4 years (I moved to Vietnam from NYC about a year ago). So, it might suck for you, but I would hardly say my life su…
Re: The Death of Cocoa
#63I like Matt, but I think he's wrong. Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has C left the building either. There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a good chunk of these are written in Objective-C, a good deal of them are written in C, or Objective-C with the guts in C++. AVFoundation, for example, is mostly C++ in the "backend". The amount of effor…
My initial enthusiasm for Swift faded pretty quickly when I tried to actually use it. The tooling is buggy and unstable. Code that calls Cocoa APIs is often no less verbose than ObjC. Every XCode release brings syntax-breaking changes. It feels like the language design was compromised by the requirement to bridge to Cocoa; all the strictness of the language is just a facade when you're manually casting every time you…
Re: The Death of Cocoa
#64Oh god, NextStep API: NSJSONSerialization What else does JSON do if not serialization? JSONObjectWithData As opposed to JSON things that aren't objects and don't have data? The signal/noise ratio is so low.
"JSONObjectWithData" means that it produces an object from NSData input. This is perfectly reasonable because valid JSON can also be an array and the input could be something else than a buffer, for example a string. I don't find Cocoa's verbose names to be a problem because the logic behind them is very consistently applied and Xcode's autocomplete fills them in anyway. Personally I greatly prefer Cocoa's excessivel…
Re: The Death of Cocoa
#65Earlier quoted context omitted.
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
That just sucks for you . I am not you . 10-14 hours a day is the norm and I still get in the gym, dinner with the wife, vigorous sex, a few games of vain glory and other facets of "normal life". I also take weeks off at a time because I mostly work for myself. In fact, I've been traveling for the last 4 years (I moved to Vietnam from NYC about a year ago). So, it might suck for you, but I would hardly say my life su…
Re: The Death of Cocoa
#66[deleted]
The purpose of Set abstractions is to provide set operations like union, intersection and complement, which Dictionary doesn't provide. Set operations are regularly needed in various algorithms. Void vs. Bool issue might be due to fact that Nate Cook's implementation was written at the time of Xcode and Swift beta and there were a lot of type inference bugs. Maybe Void dictionaries didn't work correctly. For example,…
Re: The Death of Cocoa
#67I like Matt, but I think he's wrong. Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has C left the building either. There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a good chunk of these are written in Objective-C, a good deal of them are written in C, or Objective-C with the guts in C++. AVFoundation, for example, is mostly C++ in the "backend". The amount of effor…
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
Re: The Death of Cocoa
#68Holy clickbait headline, Batman. Yes, Carbon has been replaced in the past but that involved a $400 million acquisition and 10 years of continual complaining, kicking and screaming from established Carbon users who had no desire to change. I doubt it's an example of how future changes will occur. Replacing entire application frameworks is hard. Super, super hard. It seems like it might be simple to start by replacing…
And what's the practical difference between death and deprecation? As the Swift standard library grows, and it becomes the widely preferred language for iOS and Mac development, isn't that a form of death?
Not that they could anyway: according to Chris Lattner, Swift is currently 1-2 years away from including a language "resilience model" that would allow safe linking to frameworks built with a different version of Swift. Until then, the Swift standard library needs to remain as small as possible because it is statically linked into every Swift app (it can't be shipped separately with the OS).
Re: The Death of Cocoa
#69I like Matt, but I think he's wrong. Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has C left the building either. There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a good chunk of these are written in Objective-C, a good deal of them are written in C, or Objective-C with the guts in C++. AVFoundation, for example, is mostly C++ in the "backend". The amount of effor…
My initial enthusiasm for Swift faded pretty quickly when I tried to actually use it. The tooling is buggy and unstable. Code that calls Cocoa APIs is often no less verbose than ObjC. Every XCode release brings syntax-breaking changes. It feels like the language design was compromised by the requirement to bridge to Cocoa; all the strictness of the language is just a facade when you're manually casting every time you…
"I guess I like the strict handling of nils in principle but in practice I've found this often means the user gets a crashed app instead of a more tolerable bug."
How are you using optionals in such a way that it crashes your app? I've found that using optional chaining and the "if let" block guards your code against accidental nilling even more. My rule of thumb so far is to never ever use the "!" operator except for initialization. I've found that whenever I get a crash — which is rare these days — it's usually because I forced an optional, or possibly used "as" instead of "as?".
"All the strictness of the language is just a facade when you're manually casting every time you deal with a collection, for example."
I dunno, I kind of like the explicitness of (cocoaArray[i] as? ABMyObject). It's no more work than you'd be doing with a generic NSArray anyway, and you get type checking for free. (And, of course, all your Swift native arrays and maps don't have to follow this pattern.)
Re: The Death of Cocoa
#70Earlier quoted context omitted.
Only every iPhone and iPad out there.
Awesome. Let us make Apple-only sites! /sarcasm
As a web dev myself, I'd love this solution.