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.
The Death of Cocoa
91–100 of 118 posts
Re: The Death of Cocoa
#92I 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…
Re: The Death of Cocoa
#93Earlier 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…
Re: The Death of Cocoa
#94I'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…
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
#95Earlier 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…
Re: The Death of Cocoa
#96This 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…
Re: The Death of Cocoa
#97I 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'm using CoreData via Swift and find it mostly more enjoyable than Objective-C.
Re: The Death of Cocoa
#98I 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…
Re: The Death of Cocoa
#99Earlier 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 .
Re: The Death of Cocoa
#100Oh 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…
So aside from being verbosely named, it's also incorrectly named.
If they'd called it [NSJSON parseData:] you wouldn't have been confused.