Live data from Hacker News

The Death of Cocoa

nshipster.com

91–100 of 118 posts

Re: The Death of Cocoa

#91
post #78

Earlier quoted context omitted.

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

I'm on latest and the indexing issue is just getting worse and worse for me.

Try removing (backing up) all folders from ~/Library/Developer/Xcode/iOS\ DeviceSupport. It helped for me.

Re: The Death of Cocoa

#92
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 glad I'm not the only one who feels that way. I read through the book on night 1 and was stoked to Swiftify my life, but was disappointed nearly as fast when I realized how icky Cocoa(Touch) was to implement in Swift. It felt unnatural, and I've used languages with named parameters before, but forcing the two paradigms together seems wrong.

Re: The Death of Cocoa

#93
post #6
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…

> 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. JSON was added to Ruby stdlib in 1.9.2, released in August 2010. Available as a gem for years prior. Ruby was probably slow because YAML was the anointed format, and JSON isn't distinctly better than YAML. JSON was added to Python modules…

[deleted]

Re: The Death of Cocoa

#94
post #89

I've been working with Cocoa for 20 years, back from the NeXT days. I certainly see where Swift is going, and there's a possibility that it will surpass Objective-C in the future, but for the time being they will live together in relative peace. Objective-C provides a number of patterns that aren't available in Swift due to the dynamic nature. For example, transparent network proxies are possible in Objective-C using…

Interestingly, Swift may not even be a "better C++" for all domains dominated by C++:

The memory model is strictly ref-counted which is unsuitable for certain tasks (e.g. high perf game programming) and the runtime performance is still extremely brittle (i.e. dependent on optimization passes).

Lots of apps also use c++ as the common core model. Since Swift isn't multiplatform, it is not replacing c++ there either.

Re: The Death of Cocoa

#95
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 actually think something like this might be my ideal -- spurts of intense work, followed by several weeks of not working at all. This is what I tended to do on personal projects when I was younger. I think this could be a quite healthy, long-term sustainable way to arrange work.

Re: The Death of Cocoa

#96
post #36

This feature of strings is cool! It sounds like the end of the Unicode encoding mess that most languages drag the programmer into: "One of the truly clever design choices for Swift's String is the internal use of encoding-independent Unicode characters, with exposed "views" to specific encodings: A collection of UTF-8 code units (accessed with the string’s utf8 property) A collection of UTF-16 code units (accessed wi…

Haven't used Swift of its strings yet, but I have used string/unicode in python, NSString in Cococa, and string in Go. The only one that hasn't bit me in the ass is string in Go; the approach they take is a sequence of bytes, utf8 encoded by convention (which is easy to follow); there are methods to work with unicode code points when you need to, otherwise it's just bytes. It's simple, well-defined, non-magic, and doesn't screw you over.

Re: The Death of Cocoa

#97

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

I don't know about NSOrderedSet, but for number properties on Core Data objects, you can avoid NSNumber entirely by using primitives. There is an option when generating model objects in Xcode to use primitives, which will do so for you. Properties may be a mix of primitives and objects, too. E.g. if I have a "Car" model that has "tankSize" and "milesPerGallon", I could have "tankSize" be a 32-bit int represented by a int32_t, and "milesPerGallon" a 32-bit int represented by a NSNumber*.

I'm using CoreData via Swift and find it mostly more enjoyable than Objective-C.

Re: The Death of Cocoa

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

Minor nit to give credit where it's due. 280 North had three founders: http://en.wikipedia.org/wiki/280_North,_Inc.

Re: The Death of Cocoa

#99

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…

Minor nit to give credit where it's due. 280 North had three founders: http://en.wikipedia.org/wiki/280_North,_Inc .

And for what it's worth, it took a hell of a lot longer than a couple of months to build something useful. Years later and it still isn't a full port of what was available at the time in Cocoa.

Re: The Death of Cocoa

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

JSONObjectWithData can return an NSArray or an NSDictionary in the general case, and a NSString, NSNull or NSNumber if you direct it to allow fragments. It can also return nil.

So aside from being verbosely named, it's also incorrectly named.

If they'd called it [NSJSON parseData:] you wouldn't have been confused.

Post reply on HN