Live data from Hacker News

The Death of Cocoa

nshipster.com

61–70 of 118 posts

Re: The Death of Cocoa

#61
post #48

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…

I take it that you don't sleep?

Re: The Death of Cocoa

#62
post #48

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…

Sorry, I just reread that and I didn't mean to come off like a dick. I'm just saying, I've found the balance that works for me and that work is not really work to me. I do get the normal things in, though sometimes at an accelerated pace. And I don't do the 14 hours every single day, but 10-12 hours is probably more the norm.

Re: The Death of Cocoa

#63
post #41

I 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…

Apple used quite a bit of fanfare (they're just good at it), but I never construed Swift to be more than a beta, and I still don't think that it's more than that.

Re: The Death of Cocoa

#64
post #57
post #55

Oh 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…

I agree entirely. It's just as fast to read and typing abbreviations is actually slower than typing full words most of the time because of keystroke muscle memory. Sure, it can make a screenful of code 'look' uglier but in the end it reads explicitly and that can only be a good thing.

Re: The Death of Cocoa

#65
post #48

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…

I've had many 14 hours days that were awesome, many of them included work. I agree, just because you don't like your "work" doesn't mean you should judge me for enjoying my "work". LOL

Re: The Death of Cocoa

#66
post #53

[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,…

[deleted]

Re: The Death of Cocoa

#67
post #41

I 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.

[deleted]

Re: The Death of Cocoa

#68
post #28

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

Simply: I don't think Apple are going to suddenly replace Foundation (or any other Cocoa framework) with a Swift only version. They'll just iterate the frameworks they currently have to make them a little more modern and a little more Swift friendly.

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

#69
post #41

I 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'm really loving Swift, but Xcode has gotten atrocious. I have a keyboard app with 8 different sub-keyboards, and 80% of the time, when I open my project, Xcode gets stuck in indexing. You can't build, you can't close Xcode, you can't do anything but force-quit and hope it doesn't happen next time. There are also frequent SourceKit crashes, random crashes to the desktop, and incredibly laggy typing and auto-completion. WTF?

"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

#70
post #40

Earlier quoted context omitted.

Only every iPhone and iPad out there.

Awesome. Let us make Apple-only sites! /sarcasm

I would imagine there would be a javascript transpiler so the browser can request .js or .swift file depending on its own capabilities.

As a web dev myself, I'd love this solution.

Post reply on HN