Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Cocoa

nshipster.com

Post reply on HN
Print view View original

51–60 of 118 posts

Re: The Death of Cocoa

#51

Post by LinaLauneBaer »

jawngee wrote: post #49
LinaLauneBaer wrote: post #46

Earlier quoted context omitted.

I agree with most of what you are saying. I have no problem with Objective-C as well. I never had a problem with Objective-C and I have done Objective-C for over 10 years now… But I would like to mention that people seem to overestimate the work required to "port" a framework from one language to another. Take 280North as an example. A tiny company (funded by ycombinator) founded by 2 ex Apple employees. They have de…

Sure, I don't disagree. Though, look at QuickTime for example. That was deprecated in Mavericks, but it's going to be around for another few releases. AVFoundation (the framework I use the most) is used by FinalCut, iMovie, etc. so porting that isn't straight forward because it would break so much stuff. So I do think you'll see deprecation of certain things as maybe they move to design patterns that are a better fit…

One of the reasons why QTKit sticks around is that it has been around since 10.3 and it's foundation is even older going back to I think 1992.

So I think QTKit is an edge case and probably not used by a ton of developers directly. I think the 80/20 rules also applies here... by porting 20% of the frameworks you get 80% of the functionality.

That being said: I think that if it happens it will happen over time. Deprecating something in Mavericks does not mean that it has to be gone in the release after Mavericks. GC was with us for way too long... But you can replace almost anything within lets say 5-7 years. That would be 5-7 major releases.

Re: The Death of Cocoa

#52

Post by LinaLauneBaer »

jawngee wrote: post #49
LinaLauneBaer wrote: post #46

Earlier quoted context omitted.

I agree with most of what you are saying. I have no problem with Objective-C as well. I never had a problem with Objective-C and I have done Objective-C for over 10 years now… But I would like to mention that people seem to overestimate the work required to "port" a framework from one language to another. Take 280North as an example. A tiny company (funded by ycombinator) founded by 2 ex Apple employees. They have de…

Sure, I don't disagree. Though, look at QuickTime for example. That was deprecated in Mavericks, but it's going to be around for another few releases. AVFoundation (the framework I use the most) is used by FinalCut, iMovie, etc. so porting that isn't straight forward because it would break so much stuff. So I do think you'll see deprecation of certain things as maybe they move to design patterns that are a better fit…

btw nice app

Re: The Death of Cocoa

#54

Post by timthorn »

philliphaydon wrote: post #2

"Apple is a company with a long view of technology. It's really difficult to tell whether a technology like JSON is going to stick, or if it's just another fad. Apple once released a framework for PubSub, which despite not being widely known or used, still has to be supported for the foreseeable future. Each technology is a gamble of engineering resources." Apple doubted JSON would be around?

Apple also released a framework for Publish and Subscribe in System 7, though I don't think that's still supported! http://en.wikipedia.org/wiki/Publish_and_Subscribe_(Mac_OS)

Re: The Death of Cocoa

#55

Post by nailer »

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.

Re: The Death of Cocoa

#56

Post by cageface »

jawngee wrote: 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 deal with a collection, for example. 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.

I'm getting out of iOS/OS X coding anyway for other reasons but even if I weren't I certainly wouldn't use Swift for production yet. Apple should not have pitched Swift as production-ready at WWDC. I think a lot of us would be less critical if it had been billed as the technology preview it was (and still is).

Re: The Death of Cocoa

#57

Post by pavlov »

nailer wrote: 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 excessively "literary" style to the arbitrarily shortened style used in many dynamic languages like Ruby. Unlike "JSONObjectWithData", method names like "eql?", "gsub" and "len" can't be deduced, you just have to remember them or look them up.

Re: The Death of Cocoa

#58

Post by gurkendoktor »

This has been my biggest worry since Swift was announced. I am really happy with Foundation (much more than with AppKit or post-iOS 6 UIKit). But if 2014 Apple were to reinvent it, I am sure it would suck.

Has Apple recently released anything that they have dog-fed to themselves before, and that was not buggy? Swift itself is a good example of how Apple seems to work now: Let engineers build a toy, release it as v1.0, wait for the early adopters on Twitter to sing their praises, then maybe start using it internally. Maybe.

I wish Apple had instead designed better frameworks for UI and persistence and then built a language to make working with them easier.

Re: The Death of Cocoa

#59

Post by tempodox »

I think Swift has promise, but I don't expect it to replace Cocoa anytime soon.

My main complaint about Swift is the lack of available documentation. In C languages, you have static header files which you can read and learn about APIs & types / classes / whatever. API documentation in Swift is generated on the fly when you search for a specific term that happens to be a function / type / protocol / whatever. But how do I find out what functions / methods are applicable to, e.g. a String? There is no chance to just `grep` existing headers for 'String' or some such trick, to find everything related to that type. This may seem minor to some, but for me it is a major stumbling block making Swift effectively a black box for me.

Re: The Death of Cocoa

#60

Post by dirtyaura »

[deleted] wrote: 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, using map that returned void crashed the compiler in one beta version. This was actually used in Nate's set implementation and I had to modify it to work.

Post reply on HN