The Death of Cocoa • Hacker News Board

Re: The Death of Cocoa

#71

Post by nailer » Tue, Dec 30, 2014, 12:49 PM UTC

pavlov wrote: post #57

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

> This is perfectly reasonable because valid JSON can also be an array

Are arrays (and primitives which can be boxed) not considered objects in every OO language ever?

Agreed re: usls ctrctns. That's the other extreme. One wants to convey the required meaning in the minimum amount possible - no more, no less.

Edit: thinking about it, you probably mean that the top level object is a hashtable, since ObjC is strongly typed. If I was going to do that I'd rather check the whole structure (rather than just the top) with an interface.

Re: The Death of Cocoa

#72

Post by nailer » Tue, Dec 30, 2014, 12:50 PM UTC

darkFunction wrote: post #64

pavlov wrote: post #57

Earlier quoted context omitted.

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

I don't think anyone is advocating for abbreviations.

Re: The Death of Cocoa

#73

Post by tomelders » Tue, Dec 30, 2014, 12:52 PM 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

When I saw how quickly playgrounds compile and run, this was my very first thought. The fact that Apple announced FTL compiling for javascript just prior to announcing swift makes me wonder wether Apple has plans to make swift the new lingua Franca.

Re: The Death of Cocoa

#74

Post by ZanyProgrammer » Tue, Dec 30, 2014, 12:55 PM UTC

I gave up on Swift when I couldn't just do an import CommonCrypto, and had to do hackish bridging workarounds. For a language that was supposed to be much higher level and just work, it really didn't.

Re: The Death of Cocoa

#75

Post by ktran03 » Tue, Dec 30, 2014, 1:03 PM UTC

cageface wrote: post #56

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…

Initially I was ripping my hair out with Swift, but after couple months of using it full time, things are much smoother now. I still have doubts on it's production-readiness though.

And the strictness is pretty badass imo. Objective-c feels very imprecise and unsafe in many ways.

Re: The Death of Cocoa

#76

Post by Alphasite_ » Tue, Dec 30, 2014, 1:10 PM UTC

FranOntanaya wrote: post #50

quesera wrote: post #34

Earlier quoted context omitted.

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.

And that's why we have list editor.

Re: The Death of Cocoa

#77

Post by Alphasite_ » Tue, Dec 30, 2014, 1:10 PM UTC

FranOntanaya wrote: post #50

quesera wrote: post #34

Earlier quoted context omitted.

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.

And that's why we have plist editor.

Re: The Death of Cocoa

#78

Post by ktran03 » Tue, Dec 30, 2014, 1:12 PM UTC

archagon wrote: post #69

cageface wrote: post #56

Earlier quoted context omitted.

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

Xcode 6.1.1 fixed most of the problems you mentioned in the first paragraph for me. Sourcekit crashes was the biggest annoyance, ughh.

Re: The Death of Cocoa

#79

Post by jrochkind1 » Tue, Dec 30, 2014, 1:14 PM UTC

LinaLauneBaer wrote: post #46

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…

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…

What does "GC" stand for in this context?

Re: The Death of Cocoa

#80

Post by matwood » Tue, Dec 30, 2014, 1:23 PM UTC

jrochkind1 wrote: post #79

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…

What does "GC" stand for in this context?

Garbage Collection. Not that long ago Apple came out with full GC in Objective-C to a lot of fanfare (no more retain releases yay). Not long after that they said to just use ARC (which is compiler retain/releases) because the GC was not working well. Today, it's hard to find any mention of the GC.