Live data from Hacker News

The Death of Cocoa

nshipster.com

41–50 of 118 posts

Re: The Death of Cocoa

#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 effort it would take to move those to Swift would be fairly substantial, and with no real gain. This doesn't mean that new frameworks won't be written in Swift, but still interoperable with Objective-C, this will probably happen - though I doubt it'll happen in my development lifetime. So we are looking at a gradual replacement of frameworks, or superseding with newer ones (QuickTime -> AVFoundation -> ???).

He brings up Carbon, but erroneously as Cocoa actually predates Carbon and Carbon was only meant to serve as a compatibility bridge from OS 9 to OS X. Carbon was meant to die.

I don't plan to switch to Swift unless I absolutely have to. I spend 14 hours a day developing for OS X, but my problem isn't Objective-C, it's the ambiguous documentation and mildly temperamental behavior of certain frameworks coughAVFoundationcough. I didn't need Swift, wasn't looking for Swift. I have nothing against it, I'm sure it's awesome, but language isn't my issue at this point, so I don't really have much to gain by it.

Re: The Death of Cocoa

#42
post #39

I clicked on this link thinking "yeah, hot chocolate has kind of vanquished cocoa hasn't it?" Very disappointing to discover this had nothing to do with chocolatey drinks.

Cocoa was named partly as a pun of Java. Remember when NeXTStep was folded into Apple, Java was getting a lot of attention.

Cocoa was Java compatible, as a first class target.

Re: The Death of Cocoa

#43
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.

Re: The Death of Cocoa

#45
post #15
post #4

Earlier quoted context omitted.

JSON was invented (discovered ;) ) in 2001, the website went up in 2002. Major services like Google and Yahoo were providing their data in JSON format in 2006. If this article is correct, Apple didn't include JSON functionality in Cocoa until 2011 , that's 9 years after the public website and 5 years after inclusion in major web services. This is an eternity in technology time. I personally find the explanation that…

> Just look at this: https://twitter.com/andy_matuschak/status/549268259871002624 "A pragmatic and intentionally non-abstract solution to JSON decoding / initialization that doesn't require learning about five new operators." What's scary about operators? An API with five new functions doesn't cause the same amount of anxiety, does it?

You can't get to online documentation easily, the calls have a maximum of 1 or 2 arguments, you can't provide alternatives that pop up on autocomplete, and the syntax can be harder to visually parse. To be fair on the last point sometimes it can be easier to visually parse with operators, but not always. For example compare printf format strings where substitutions look like %f vs C++ output streams where they look like "<<x<<" which breaks up visual flow like nobody's business.

Re: The Death of Cocoa

#46
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…

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 developed a JavaScript variant of Objective-C (called Objective-J) and reimplemented the most important parts of AppKit. It took them a couple of months but in the end it all worked out, many people used (and are still using it) Cappuccino (name of the framework) and 280North was bought by Motorola for something like $20.000.000. So two guys => 1 language, a couple of frameworks in a matter of months.

Also I am sure you are aware that every year Apple introduces a ton of new frameworks and deprecates some frameworks. It would only take a couple of releases to deprecate 80% of the frameworks used by most apps and introduce replacements for them.

Swift without a new set of frameworks makes little sense IMHO. So either Swift will dies - just like GC did or it won't and then we will see new frameworks written in Swift.

Talking about GC… When Apple introduced GC they told us that it was the latest and greatest shit. It was the future. When introducing GC they told us that "hey - we have ported Xcode to GC - look it is that easy.". So they had more apps using GC from day 1 than using Swift from day 1 (well the WWDC app written in Swift does not count…). Apple had to ship GC-capable versions of their frameworks from day 1. They were even more committed to GC than they are now to Swift so it would not surprise me at all to see Swift let go in a couple of years and buried deep.

At the moment everything seems possible.

Re: The Death of Cocoa

#47
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.

Not even doctors work that many hours. Holy shit.

Re: The Death of Cocoa

#48
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.

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 sucks because I work so much. Mostly because it isn't really work to me, but mostly because at 41 I know what balance works for me.

But thanks for the concern.

Re: The Death of Cocoa

#49
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…

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 for Swift, but entirely replacing AVFoundation would be straight up insane when it works so well (as long as you are doing everything by the rules laid out in a largely unwritten book).

Re: The Death of Cocoa

#50
post #34
post #33

Earlier quoted context omitted.

Dear Lord in heaven, who can possibly prefer the XML version? That's hideous!

XML parsers prefer the XML version. :) Less glibly, humans never have to deal with it. Data is serialized and deserialized, typically in binary format. It exports to XML merely as a convenience. And critically, XML can be typed properly for all ObjC/Cocoa types (sometimes with characteristic XML awkwardness). That XML is wrongly typed, due to the ambiguous source input. JSON would have similar problems. Correct beats…

> Less glibly, humans never have to deal with it

As long as it works, unless we categorize programmers debugging XML issues as non-human drones.

Post reply on HN