Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Cocoa

nshipster.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: The Death of Cocoa

#111

Post by wtbob »

quesera wrote: post #34
wtbob wrote: 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…

> XML parsers prefer the XML version.

Well yeah, but an XML parser would also have no problem with 'Thisisinane', but that would be completely insane.

> Less glibly, humans never have to deal with it. […] It exports to XML merely as a convenience.

For…humans, no?

> And critically, XML can be typed

It looks like the plist supported types too, although I don't know for certain. At least, the numbers weren't quoted in the plist.

> JSON would have similar problems.

Would it? '"2" !== 2', IIRC.

Of course, my preferred syntax would be:

    (dict (david great) (array (1 2 3 4)))
if one wanted to treat numbers as text and:

    (dict (david great) (array ([int]1 [int]2 [int]3 [int]4)))
if one wanted to indicate that they are ASCII decimal-encoded integers or:

    (dict (david great) (array ([bin-int]|AQ==| [bin-int]|Ag==| [bin-int]|AW==| [bin-int]|BA==|)))
if one wished to use binary encoding using network-transfer order, but I am clearly insane.

Not nearly as insane as whoever came up with that XML abomination, though.

Re: The Death of Cocoa

#112

Post by maxjg »

frou_dh wrote: post #9
tolmasky wrote: 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…

The NeXT/Apple ASCII encoding of their PLIST format is very similar to JSON and has been around forever. IIRC TextMate 1 made use of it for much of its bundle system.

Xcode project files are still saved in this style of plist.

Re: The Death of Cocoa

#113

Post by dilap »

bpicolo wrote: post #105
dilap wrote: post #96

Earlier quoted context omitted.

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

Python 3 uses utf8-as-a-default as well. Not to mention you can easily specify the encoding as well in python 2. Never bites me.

Wish I had documented my exact frustrations, but it wasn't not being able to choose the encoding...something more of the flavor of:

Most of the time I just trying to shuffle bytes from one place to another, and didn't really care about the contents of the bytes, but I hit numerous bug because of exceptions due to things like "external data wasn't valid utf8" (NOT helpful to throw an exception here), and bugs caused by 'str' vs 'unicode' confusion (made more tricky by lack of static type system).

The one time I did actually need to do some calculation involving unicode I got burned by behavior that didn't match the documentation, because my bullshit package-manager-provided variant of python had some insane compile time option that made it pretend utf16 code units were the same thing as actual utf code points, to which I can only say "ha ha ha...fuck those guys".

Can't speak to python 3, haven't used it, probably never will :)

Re: The Death of Cocoa

#114

Post by yawaramin »

wtbob wrote: post #111
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…

> XML parsers prefer the XML version. Well yeah, but an XML parser would also have no problem with ' T h i s i s i n a n e ', but that would be completely insane. > Less glibly, humans never have to deal with it. […] It exports to XML merely as a convenience. For…humans, no? > And critically, XML can be typed It looks like the plist supported types too, although I don't know for certain. At least, the numbers weren't…

Yes, a plist is defined as containing things of very specific types. See my SO answer [1] for an overview and an attempt at a Swift implementation.

[1] http://stackoverflow.com/a/24051062/20371

Re: The Death of Cocoa

#115

Post by kennyledet »

copperx wrote: post #47
meesterdude wrote: post #43

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.

Not even doctors work that many hours. Holy shit.

Out of school for winter break and I code pretty much 20/7.

Re: The Death of Cocoa

#116

Post by LinaLauneBaer »

coldtea wrote: post #81
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…

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

> GC wasn't that much a deal to let go, because they found a way to do the same thing without it (ARC). It's not like they had to rewrite anything for the new post-GC era.

The official recommendation from Apple was to not transition for GC but only to use it for new projects or for complete rewrites. So it was a big deal for every developer who relied on GC.

And only because something is new does not mean it is modern. All of the concepts that Swift implements are fairly old. Swift is just new.

Re: The Death of Cocoa

#117

Post by dep_b »

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…

There is no reason not to use Swift, Swift can do all that Objective-C can do and more. The language, framework support and the compiler have reached 1.0, the only thing that keeps happening is an error message in Xcode that I can safely ignore and keep working. But projects written in Swift are safe for production.

The reason you could switch to Swift is that it is safer, less verbose (unless you interact with Objective-C) and more flexible. You can choose to use Swift in a way that you are just using Objective-C translated to Swift and ignore all the extras or you can choose to use all the extra goodies you get like map, reduce, currying, advanced switch case statements and more. These features aren't new but they are not common in a lower level language comparable to C++ and Objective-C.

Swift is comparable to Rust in that sense. Nobody needed Rust but Rust doesn't stop you from doing anything you could do before while it gives you a lot of extra goodies from higher level languages.

A lot of people tried Swift when it was in a beta and ran into problems with it and got frustrated. Then repeat those experiences all over the internet like it happened to them just yesterday. There's also a significant portion of the iOS development community that rejects AutoLayouts because it was too alien to them and the first iteration wasn't perfect.

Last but not least: you're not forced to use only Swift in any project. Of course it's easier to wrap C code in Objective-C and then use it with a bridge in your Swift project. I mix and match every day, I'm not going to rewrite perfectly sane Objective-C code because I'm doing a Swift project. Try to be pragmatic about it.

Truth is that Objective-C style libraries really do seem really cumbersome and verbose when you use it in much more lightweight Swift code.

Re: The Death of Cocoa

#118

Post by eru »

jjoonathan wrote: post #45
eru wrote: post #15

Earlier quoted context omitted.

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

> You can't get to online documentation easily, [...]

That's a problem with common search engine. A specialised API search engine can help there. See eg >=" rel="nofollow">https://www.haskell.org/hoogle/?hoogle=>>=

Post reply on HN