The Death of Cocoa • Hacker News Board

Re: The Death of Cocoa

#21

Post by jarjoura » Tue, Dec 30, 2014, 6:22 AM UTC

Swift has the potential to become a great systems language but I am cautious it will replace Foundation/AppKit/UIKit. For example, a Swift string IS an NSString (at the moment at least).

It's impossible to know for sure, but when you look back 15 years ago when Cocoa was the new and shiny to the old-trusty Carbon. Apple was actually writing software in Cocoa internally. Everything they were building towards extended from the NeXT Objective-C world. Though true, they didn't publicly commit to Cocoa 100% until OS X 10.4, but you better believe internally they were always in. It's just the world didn't see it until the "We're rewriting the Finder in Cocoa" campaign was announced.

At Apple right now, no one outside of the compiler team is working on anything interesting in Swift. It's still locked away from them. To be fair, it's an evolving language and will cause a lot of heartache for everyone until the language has been baked in more.

I know Mattt is excited for Swift. Plus, a lot of developers are already doing some really cool stuff. So we shall see in a couple years how the story plays out.

Re: The Death of Cocoa

#22

Post by rezistik » Tue, Dec 30, 2014, 6:23 AM UTC

imron wrote: post #13

>Will Swift unseat Javascript as the only viable web scripting language by adding interpreter to Safari? Adding Swift to Safari would be an interesting development

About as interesting as adding Dart to Chrome.

Except with none of the market share.

Re: The Death of Cocoa

#23

Post by masters3d » Tue, Dec 30, 2014, 6:31 AM UTC

rezistik wrote: post #22

imron wrote: post #13

>Will Swift unseat Javascript as the only viable web scripting language by adding interpreter to Safari? Adding Swift to Safari would be an interesting development

About as interesting as adding Dart to Chrome. Except with none of the market share.

Only every iPhone and iPad out there.

Re: The Death of Cocoa

#24

Post by imron » Tue, Dec 30, 2014, 6:38 AM UTC

kennyledet wrote: post #20

imron wrote: post #13

>Will Swift unseat Javascript as the only viable web scripting language by adding interpreter to Safari? Adding Swift to Safari would be an interesting development

>only viable But wait, since when was Safari the only viable web browser anyway? Disclaimer: I'm an Apple fanboy and rMBP user.

Safari isn't the only viable web browser. Javascript is the only viable webscripting language in browsers.

Re: The Death of Cocoa

#25

Post by imron » Tue, Dec 30, 2014, 6:41 AM UTC

rezistik wrote: post #22

imron wrote: post #13

>Will Swift unseat Javascript as the only viable web scripting language by adding interpreter to Safari? Adding Swift to Safari would be an interesting development

About as interesting as adding Dart to Chrome. Except with none of the market share.

But with a whole lot of 'developer share' that Dart doesn't have.

Re: The Death of Cocoa

#26

Post by quesera » Tue, Dec 30, 2014, 6:44 AM UTC

__david__ wrote: post #12

quesera wrote: post #10

Earlier quoted context omitted.

NeXT Plists were a lot like JSON, but OSX Plists were XML (or binary). Apple definitely had their anointed interchange format, and it was not JSON, for several reasons -- first among them that Plists predate JavaScript! -- but also because JavaScript types get a bit ambiguous in a ObjC/Cocoa context. Interestingly, Plists can now be XML or JSON (or binary).

> NeXT Plists were a lot like JSON, but OSX Plists were XML (or binary). Old style text plists are still supported: $ cat > /tmp/test.plist { "david" = "great"; "array" = ( 1,2,3,4 ); } $ plutil -convert xml1 /tmp/test.plist -o - array 1 2 3 4 david great $ sw_vers -productVersion 10.10.1

> Old style text plists are still supported:

True. Read-only, however. :)

And the type ambiguity is amply demonstrated.

Re: The Death of Cocoa

#27

Post by [deleted] » Tue, Dec 30, 2014, 7:17 AM UTC

masters3d wrote: post #19

I think vanilla cocoa is being replaced slowly by cocoa touch. They will probably rename it and then force cocoa touch onto macosx. I don't see foundation changing much though. Maybe foundation touch "universal" is coming ;)

[deleted]

Re: The Death of Cocoa

#28

Post by e28eta » Tue, Dec 30, 2014, 7:18 AM UTC

gilgoomesh wrote: post #16

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?

Re: The Death of Cocoa

#29

Post by [deleted] » Tue, Dec 30, 2014, 7:20 AM UTC

jarjoura wrote: post #21

Swift has the potential to become a great systems language but I am cautious it will replace Foundation/AppKit/UIKit. For example, a Swift string IS an NSString (at the moment at least). It's impossible to know for sure, but when you look back 15 years ago when Cocoa was the new and shiny to the old-trusty Carbon. Apple was actually writing software in Cocoa internally. Everything they were building towards extended…

[deleted]

Re: The Death of Cocoa

#30

Post by CookWithMe » Tue, Dec 30, 2014, 7:20 AM UTC

I had the same feeling when I did my first side project in Swift earlier this month. My main experience is with CoreData.

An example with 1:n relationships: CoreData returns and expects an (untyped) NSOrderedSet. Now I may either keep the NSOrderedSet, but have to cast each object I want to use - and my Swift code is just as bloated as Obj C would be:

  let obj = mySet[0] as MyClass

instead of:

  let obj = mySet[0]

Plus, map/reduce etc. won't work on an NSOrderedSet.

Or I create a typed Array from the NSOrderedSet, which is fine to work with in Swift - except that it is not managed by CoreData anymore. So I'd have to be careful to synchronize with CoreData manually, and it's not just saving that I have to watch out for, but also other operations like rollback etc.

Another example is NSNumber. NSNumber needs to be manually mapped to Int, while the other direction works automatically. That makes sense when it is unknown whether NSNumber is an Integer or a Floating Point Number, but in CoreData I have specified that it's an Integer 32... (Well, I think it was similar with Obj C, actually).

So, working with Swift in the Playground felt like a huge improvement over Obj C at first, but then working with some Cocoa APIs it started to feel ... more clunky again.

I think it was/is similar with Scala. If you can stay in the Scala libraries, awesome. It is a huge improvement over Java. But Scala won't automagically turn a terrible Java API in a great Scala API. Yes, you'll save a couple of semicolons and type declarations, but it's not that big of an improvement. Thankfully (in Scala), there are a lot of better frameworks or wrappers for existing frameworks by now. I guess Swift will have to go the same way...