Hacker News Reader

> 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 in 2.6, which was released in October 2008. Likely available as an egg prior, but I don't remember.

There were Objective-C libraries for JSON well before 2011 too. The first one I remember using was in June or so of 2009.

So, I half agree with you. It might be hard to remember nowadays, but JSON wasn't universally seen as a Good Thing initially. It came with a lot of JavaScript baggage, which in some circles hung around for a loong time.

But Apple was definitely late to the JSON party, and it was disappointing at the time.

The biggest difference being that both Python and Ruby were module cultures, so saying that a gem existed actually means something. On the other hand, Mac dev didn't have Cocoapods until 2011. Apple dev at the time (and I'd argue in large part still today), was mainly using Apple's monolithic frameworks (and downloading AFNetworking source code to include in your project), so it was much more important for it to be included in the standard library. However, the point still stands that we now have a new language that still does not have this basic support.

True, the ObjC culture was undeniably different than the CPAN-inspired code sharing cultures of Ruby and Python. So there were fewer quality libraries.

But the libraries did exist, and Apple devs in general came from a background of C and UNIX programming, where static libs weren't an oddity.

This is all different now, due to the huge influx of ObjC devs from the web world. Expectations have changed, CocoaPods emerged in response, etc.

But I have no explanation for the Swift situation, except that it looks and feels like ObjC and Cocoa. I think Mattt's point is that it needn't.

This might be a bit of C culture still showing through...any other conversion process would be, ultimately, magic. ObjC has never been about brevity or implicitness.

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.

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 -
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    	<key>array</key>
    	<array>
    		<string>1</string>
    		<string>2</string>
    		<string>3</string>
    		<string>4</string>
    	</array>
    	<key>david</key>
    	<string>great</string>
    </dict>
    </plist>

    $ sw_vers -productVersion
    10.10.1

> Old style text plists are still supported:

True. Read-only, however. :)

And the type ambiguity is amply demonstrated.

> Read-only, however. :)

Nope! :-) While it's true that plutil doesn't support the format, open the plist in Xcode and edit it and it will save it out in the same old-school format. Editing through the programmatic API will also keep the format.

Well, that's good to know, thank you.

I will now manipulate ancient Plists with less fear. :-)

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 pretty, in this case.

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

And that's why we have plist editor.

> XML parsers prefer the XML version.

Well yeah, but an XML parser would also have no problem with '<tag name="p"><chardata><char>T</char><char>h</char><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>n</char><char>a</char><char>n</char><char>e</char><punctuation type="full-stop" display-char="." /></tag>', 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.

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

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

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

1. The operators are abstract (most people have never seen >>=).

2. Even IF they were functions, (say "bind" and "return"), the actual functions themselves are known to be hard to understand for people.

3. Needing to know these when all you want to do is grab google maps results is the worst place to encounter them. In JavaScript, you don't need to learn "anything", just call JSON.parse. Its fine to encourage learning. When you want to do something completely unrelated that takes no thought in other places though, its a bad place to enforce learning.

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 like "<<x<<" which breaks up visual flow like nobody's business.

> 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 https://www.haskell.org/hoogle/?hoogle=>>=