Apple doubted JSON would be around?
As an aside, I think the lack of built in JSON support in Swift remains telling of Apple's simply puzzling take on this new programming language. When Apple first announced that Swift would be good for both "systems programming" and "scripting", it set off red flags in my mind. That statement is usually only made by people that have worked a majority in one of these domains, and doesn't really understand the other that well. In my mind, if the second you want to grab some data off the internet in the most popular format you either need to 1) drop down to a bridge API that everyone agrees is terrible (as mentioned in this article, NSJSONSerialization is even more frustrating with the optional stuff), 2) download a third party framework, or 3) learn monads or roll your own, then this does not feel like a scripting language by any stretch of the imagination. Just look at this: https://twitter.com/andy_matuschak/status/549268259871002624
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.
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.
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).
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.1Less 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.
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)))
(dict (david great) (array ([int]1 [int]2 [int]3 [int]4)))
(dict (david great) (array ([bin-int]|AQ==| [bin-int]|Ag==| [bin-int]|AW==| [bin-int]|BA==|)))
Not nearly as insane as whoever came up with that XML abomination, though.
As long as it works, unless we categorize programmers debugging XML issues as non-human drones.
True. Read-only, however. :)
And the type ambiguity is amply demonstrated.
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.
I will now manipulate ancient Plists with less fear. :-)
"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?
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.
That's a problem with common search engine. A specialised API search engine can help there. See eg https://www.haskell.org/hoogle/?hoogle=>>=
> In defense of Apple, I once asked an engineer at a WWDC Lab why it took so long for iOS to support JSON. Their answer made a lot of sense.
However, I'm not sure that it makes much sense to me... I guess I may be missing something essential?